IvyDE
  1. IvyDE
  2. IVYDE-230

Shared Javadoc/Source attachments

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0.final
    • Fix Version/s: 2.2.0.beta1
    • Component/s: classpath container
    • Labels:
      None
    • Environment:

      Eclipse 3.3, IvyDE (2.0.0.final), Ivy (2.1.0.final)

      Description

      It would be nice if IvyDE could attach javadoc artifacts to more than one jar that is published by a module.

      For example, consider a rather large module called 'foo'. It has multiple parts and pieces, some of which may not be required for your particular application. The 'foo' module publishes multiple JAR artifacts:

      foo-a.jar
      foo-b.jar
      foo-c.jar

      The 'foo' module, however, is unfortunately /closed/ and the javadocs are provided to the developer in one large archive 'foo-doc.zip'.

      We are using the default URL resolver against an Ivy repo located on our dev web server.
      The artifact pattern we are using in our ivy settings is:
      <artifact pattern="http://XXXXXX/dev-repo/[organisation]/[module]/[revision]/[artifact][revision]([classifier]).[ext]" />

      After modifying the ivy.xml file for the 'foo' module to publish the docs via: <artifact name="foo" type="javadoc" ext="zip" conf="default" e:classifier="doc"/>. IvyDE/Ivy will then happily pull down the javadoc along with all the other artifacts. But, none of the foo-a, foo-b, or foo-c artifacts will have javadoc attachments in Eclipse (presumably because their artifact basenames do not match).

      Reorganizing the documentation into separate archives is not easy (or even possible) without the source code. Therefore, it would be nice if IvyDE could treat the single supplied javadoc artifact as a candidate for attachment on each of the component JAR artifacts without having to fetch the (possibly large) javadoc archive multiple times under different basenames.

      1. ivyde.patch
        22 kB
        Gregory Fernandez

        Activity

        Jason A. Guild created issue -
        Hide
        Jason A. Guild added a comment - - edited

        After submitting this question to ivy-user, I got a response from Nicolas Lalevee suggesting that this is not possible with the current IvyDE implementation.

        He related that this issue was discussed some time ago and an idea was considered to allow addition of extra metadata in the ivy.xml in the form of attributes on the artifacts published by the module. The extra metadata would indicate to IvyDE the explicit javadoc artifact to attach for use with each of the jar artifacts:

        <artifact name="foo-a" type="jar" ext="jar" conf="default"
        ivyde:javadoc="foo" />
        <artifact name="foo-b" type="jar" ext="jar" conf="default"
        ivyde:javadoc="foo" />
        <artifact name="foo-c" type="jar" ext="jar" conf="default"
        ivyde:javadoc="foo" />

        This is a good possible approach.

        IvyDE/Ivy looks for javadoc artifacts to attach as part of its normal resolve process, probably as each artifact for the module is retrieved based on its name.

        I would suggest that a simple heuristic could be applied where IvyDE, as a final step in its resolution process, notices that only a single javadoc artifact exists for the module and attach it to all JAR artifacts for which no javadoc archives were found based on artifact name matching.

        Show
        Jason A. Guild added a comment - - edited After submitting this question to ivy-user, I got a response from Nicolas Lalevee suggesting that this is not possible with the current IvyDE implementation. He related that this issue was discussed some time ago and an idea was considered to allow addition of extra metadata in the ivy.xml in the form of attributes on the artifacts published by the module. The extra metadata would indicate to IvyDE the explicit javadoc artifact to attach for use with each of the jar artifacts: <artifact name="foo-a" type="jar" ext="jar" conf="default" ivyde:javadoc="foo" /> <artifact name="foo-b" type="jar" ext="jar" conf="default" ivyde:javadoc="foo" /> <artifact name="foo-c" type="jar" ext="jar" conf="default" ivyde:javadoc="foo" /> This is a good possible approach. IvyDE/Ivy looks for javadoc artifacts to attach as part of its normal resolve process, probably as each artifact for the module is retrieved based on its name. I would suggest that a simple heuristic could be applied where IvyDE, as a final step in its resolution process, notices that only a single javadoc artifact exists for the module and attach it to all JAR artifacts for which no javadoc archives were found based on artifact name matching.
        Hide
        Gregory Fernandez added a comment - - edited

        Hello,

        I don't understand why Nicolas Lalevee said it's not possible.

        I've just finished a patch solving your issue.

        Show
        Gregory Fernandez added a comment - - edited Hello, I don't understand why Nicolas Lalevee said it's not possible. I've just finished a patch solving your issue.
        Hide
        Gregory Fernandez added a comment - - edited

        In fact :

        If a module declares only 1 source, or only 1 javadoc artifact, this artifact is associated with all jar artifacts ...

        This patch is a svn diff againt latest trunk

        Show
        Gregory Fernandez added a comment - - edited In fact : If a module declares only 1 source, or only 1 javadoc artifact, this artifact is associated with all jar artifacts ... This patch is a svn diff againt latest trunk
        Gregory Fernandez made changes -
        Field Original Value New Value
        Attachment ivyde.patch [ 12431906 ]
        Hide
        Nicolas Lalevée added a comment -

        Actually I said "this is not possible with the current IvyDE implementation.", meaning without a patch.
        Then thanks for the patch Gregory !

        Show
        Nicolas Lalevée added a comment - Actually I said "this is not possible with the current IvyDE implementation.", meaning without a patch. Then thanks for the patch Gregory !
        Nicolas Lalevée made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Nicolas Lalevée [ hibou ]
        Fix Version/s 2.2.0 [ 12315245 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Nicolas Lalevée
            Reporter:
            Jason A. Guild
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development