Aries
  1. Aries
  2. ARIES-755

org.apache.aries.jmx at search.maven.org has empty source jar

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 0.3
    • Fix Version/s: None
    • Component/s: JMX
    • Labels:
      None

      Description

      Go to http://search.maven.org/#search%7Cga%7C1%7Caries%20jmx and download the sources.jar file. It only has META-INF files, no source files. Same thing if you pull sources from repo1 via Maven or IDE.

      Here's the full URL:
      http://search.maven.org/remotecontent?filepath=org/apache/aries/jmx/org.apache.aries.jmx/0.3/org.apache.aries.jmx-0.3-sources.jar

        Activity

        Hide
        Jeremy Hughes added a comment -

        Hi, this is a strange side effect of the maven release process. For JMX 0.3, and for 0.3 of other top level modules, a zip of all the files from SVN is produced. In this case it is jmx-0.3-source-release.zip. Each of the sub-modules of JMX have the following released artifacts: binary jar, source jar, sometimes a javadoc jar, pom. There is an asc, md5 and a sha1 file each of them. There is an md5 and sha1 for each of the asc files. The one you have picked: org.apache.aries.jmx-0.3-sources.jar is in fact the sources jar for the top level module.

        There is no java source in the top level module so it is effectively empty. If you need the source for the entire module (including sub-modules) pick the source-release.zip file. If you need source for just one of the sub-modules, pick its sources.jar.

        If this doesn't fit with your usage pattern (e.g. in your IDE) please start a discussion thread on the dev@aries list and we can look at it. Thanks.

        Show
        Jeremy Hughes added a comment - Hi, this is a strange side effect of the maven release process. For JMX 0.3, and for 0.3 of other top level modules, a zip of all the files from SVN is produced. In this case it is jmx-0.3-source-release.zip. Each of the sub-modules of JMX have the following released artifacts: binary jar, source jar, sometimes a javadoc jar, pom. There is an asc, md5 and a sha1 file each of them. There is an md5 and sha1 for each of the asc files. The one you have picked: org.apache.aries.jmx-0.3-sources.jar is in fact the sources jar for the top level module. There is no java source in the top level module so it is effectively empty. If you need the source for the entire module (including sub-modules) pick the source-release.zip file. If you need source for just one of the sub-modules, pick its sources.jar. If this doesn't fit with your usage pattern (e.g. in your IDE) please start a discussion thread on the dev@aries list and we can look at it. Thanks.
        Hide
        Chris Dolan added a comment -

        Aha, that makes sense. I didn't realize the jar I was using was a composite. I'll start using -core and -api instead. But if it's easy to change the build at some point in the future to include the source in the composite jar, I recommend that. Or else maybe put a note in that source jar explaining why there is no source there. It's not at all obvious.

        Show
        Chris Dolan added a comment - Aha, that makes sense. I didn't realize the jar I was using was a composite. I'll start using -core and -api instead. But if it's easy to change the build at some point in the future to include the source in the composite jar, I recommend that. Or else maybe put a note in that source jar explaining why there is no source there. It's not at all obvious.
        Hide
        Chris Dolan added a comment -

        For reference: I filed a related issue against Karaf to use .core.jar and .api.jar instead of jmx.jar: https://issues.apache.org/jira/browse/KARAF-916

        Show
        Chris Dolan added a comment - For reference: I filed a related issue against Karaf to use .core.jar and .api.jar instead of jmx.jar: https://issues.apache.org/jira/browse/KARAF-916
        Hide
        Jeremy Hughes added a comment -

        Since 0.3 we've changed the release process, so each sub-module is released on its own. This is so we can get to the notion of 'release by bundle' rather than release by top-level-module, which is a set of bundles.

        I've just checked, and what happens now is for each module we release you'll get a foo-source-release.zip AND a foo-source.jar ... so I believe we'll need to change that so we only release the source-release.zip.

        You mention 'composite' - do you mean you were using the 'uber' bundle which is a merge of the finer grained bundles - for JMX, jmx-bundle is a merge of jmx-api and jmx-core. By using finer grained bundles, if you are using a runtime that can dynamically replace bundles of a running system, you can (say) replace an implementation bundle that has a bug fix without having to replace the API bundle. Sorry I'm not sure whether Karaf supports that.

        Show
        Jeremy Hughes added a comment - Since 0.3 we've changed the release process, so each sub-module is released on its own. This is so we can get to the notion of 'release by bundle' rather than release by top-level-module, which is a set of bundles. I've just checked, and what happens now is for each module we release you'll get a foo-source-release.zip AND a foo-source.jar ... so I believe we'll need to change that so we only release the source-release.zip. You mention 'composite' - do you mean you were using the 'uber' bundle which is a merge of the finer grained bundles - for JMX, jmx-bundle is a merge of jmx-api and jmx-core. By using finer grained bundles, if you are using a runtime that can dynamically replace bundles of a running system, you can (say) replace an implementation bundle that has a bug fix without having to replace the API bundle. Sorry I'm not sure whether Karaf supports that.
        Hide
        David Jencks added a comment -

        >I've just checked, and what happens now is for each module we release you'll get a foo-source-release.zip AND a foo-source.jar ... so I believe we'll need to change that so we only release the source-release.zip. <

        This is intentional and these serve different purposes and both are a good idea. The source-release zip is the only actual artifact required and voted on for a release at apache, the binary jars are provided as a convenience to users. The -source.jar is another convenience to users as it's in a form that IDEs are set up to consume easily paired with binary jars. For instance in IDEA when you debug into a binary jar it doesn't have the source for, a "donwload source" action appears and gets the ide to try to download the -source.jar from the maven repo containing the binary jar.

        Show
        David Jencks added a comment - >I've just checked, and what happens now is for each module we release you'll get a foo-source-release.zip AND a foo-source.jar ... so I believe we'll need to change that so we only release the source-release.zip. < This is intentional and these serve different purposes and both are a good idea. The source-release zip is the only actual artifact required and voted on for a release at apache, the binary jars are provided as a convenience to users. The -source.jar is another convenience to users as it's in a form that IDEs are set up to consume easily paired with binary jars. For instance in IDEA when you debug into a binary jar it doesn't have the source for, a "donwload source" action appears and gets the ide to try to download the -source.jar from the maven repo containing the binary jar.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chris Dolan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development