River
  1. River
  2. RIVER-317

Deploy Apache River artifacts to Maven repositories (both release and snapshot)

    Details

      Description

      It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.

      See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e202160f0908050006t36c061b8qee049ab95bfd1d94@mail.gmail.com>

      1. river-poms.patch
        23 kB
        Jeff Ramsdale

        Issue Links

          Activity

          Hide
          Jeff Ramsdale added a comment -

          I've created a set of basic poms for what I understand to be the Apache River artifacts of greatest interest-that is, all the core and standard service artifacts. Of course the poms perform no build function for Apache River (although they could lead to that...)-they simply are meant to aid in deployment of the artifacts to Maven repositories. I did capture the artifact dependencies based on the contents of their respective manifest files.

          I named all the artifacts with groupId: org.apache.river. There are earlier artifacts in the central repository under com.sun.jini, net.jini, jini, and possibly others. I thought preparing for the next release with the new path made sense, even if internally the old package names remain. This may require some discussion.

          There should also be some discussion around where these artifacts are deployed. Some projects at Apache seem to be embracing the Nexus repository at https://repository.apache.org/index.html. See: https://issues.apache.org/jira/browse/INFRA-1896 for more details. I, myself, am a fan of Nexus and would favor deploying Apache River artifacts there.

          Show
          Jeff Ramsdale added a comment - I've created a set of basic poms for what I understand to be the Apache River artifacts of greatest interest- that is, all the core and standard service artifacts. Of course the poms perform no build function for Apache River (although they could lead to that...) -they simply are meant to aid in deployment of the artifacts to Maven repositories. I did capture the artifact dependencies based on the contents of their respective manifest files. I named all the artifacts with groupId: org.apache.river. There are earlier artifacts in the central repository under com.sun.jini, net.jini, jini, and possibly others. I thought preparing for the next release with the new path made sense, even if internally the old package names remain. This may require some discussion. There should also be some discussion around where these artifacts are deployed. Some projects at Apache seem to be embracing the Nexus repository at https://repository.apache.org/index.html . See: https://issues.apache.org/jira/browse/INFRA-1896 for more details. I, myself, am a fan of Nexus and would favor deploying Apache River artifacts there.
          Hide
          Jeff Ramsdale added a comment -

          Ping. Could I get some feedback on these? How can we move forward?

          Show
          Jeff Ramsdale added a comment - Ping. Could I get some feedback on these? How can we move forward?
          Hide
          Peter Firmstone added a comment -

          Hi Jeff,

          I have very little experience with maven, reading your patch, it looks like you know what your doing, I can't see any problems uploading Apache River artifacts to Nexus, this seems like a good idea.

          I don't have any objections to merging the patch, if it doesn't cause any issues with the existing build.

          Anyone else care to comment?

          Regards,

          Peter.

          Show
          Peter Firmstone added a comment - Hi Jeff, I have very little experience with maven, reading your patch, it looks like you know what your doing, I can't see any problems uploading Apache River artifacts to Nexus, this seems like a good idea. I don't have any objections to merging the patch, if it doesn't cause any issues with the existing build. Anyone else care to comment? Regards, Peter.
          Hide
          Jeff Ramsdale added a comment -

          I wouldn't swear they are perfect, but I hope they are a good start. Would love to have them validated by someone. Some questions:

          1) What is the process for applying these poms to the artifacts and rolling them out?
          2) Can we set up snapshots to deploy too, with CI? (optional, to start)
          3) Is there anyone who is able to validate these poms before we push?
          4) Rather than waiting for AR2 can we push the current artifacts now as a test-run for a later AR2 push? That gets the artifacts out there so they can be tested by downstream consumers.

          Show
          Jeff Ramsdale added a comment - I wouldn't swear they are perfect, but I hope they are a good start. Would love to have them validated by someone. Some questions: 1) What is the process for applying these poms to the artifacts and rolling them out? 2) Can we set up snapshots to deploy too, with CI? (optional, to start) 3) Is there anyone who is able to validate these poms before we push? 4) Rather than waiting for AR2 can we push the current artifacts now as a test-run for a later AR2 push? That gets the artifacts out there so they can be tested by downstream consumers.
          Hide
          Peter Firmstone added a comment -

          Are the *-dl.jar files I see in the patch maven artifacts? If so wouldn't these be downloaded dynamically by the jini/River client?

          Show
          Peter Firmstone added a comment - Are the *-dl.jar files I see in the patch maven artifacts? If so wouldn't these be downloaded dynamically by the jini/River client?
          Hide
          Peter Firmstone added a comment -

          I've committed the patch, so we can check it, sort it and release it with AR2.

          Show
          Peter Firmstone added a comment - I've committed the patch, so we can check it, sort it and release it with AR2.
          Hide
          Dennis Reedy added a comment -

          I dont see how the -dl.jar files are being handled with this approach. How will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined? With River services we have multiple artifacts per service, an implementation jar, a download (client) jar and potentially a service ui jar.

          I suggest that we need to be thinking of adding classifiers for the artifacts, allowing dependencies to be resolved correctly. For example, if I am using Outrigger, I need to be able to start Outrigger using outrigger.jar and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to only have outigger-dl.jar in it's classpath not outrigger.jar.

          Declaring dependencies on River produced maven artifacts need to account for how a maven project will use the artifacts.

          Show
          Dennis Reedy added a comment - I dont see how the -dl.jar files are being handled with this approach. How will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined? With River services we have multiple artifacts per service, an implementation jar, a download (client) jar and potentially a service ui jar. I suggest that we need to be thinking of adding classifiers for the artifacts, allowing dependencies to be resolved correctly. For example, if I am using Outrigger, I need to be able to start Outrigger using outrigger.jar and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to only have outigger-dl.jar in it's classpath not outrigger.jar. Declaring dependencies on River produced maven artifacts need to account for how a maven project will use the artifacts.
          Hide
          Jeff Ramsdale added a comment -

          I agree with everything Dennis says above.

          I suppose the only option is to have another set of poms for the dl jars? Trying to set up some sort of automation would be more trouble than it's worth, I imagine... I'll try to work on these...

          Show
          Jeff Ramsdale added a comment - I agree with everything Dennis says above. I suppose the only option is to have another set of poms for the dl jars? Trying to set up some sort of automation would be more trouble than it's worth, I imagine... I'll try to work on these...
          Hide
          Dennis Reedy added a comment -

          I'm not sure if you need a new set of poms. For my Rio maven work I needed to add reggie to Rio's maven repository. To day that I simply aded a classifier when deploying the jar:

          mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \
          -DartifactId=reggie -Dfile=apache-river/lib-dl/reggie-dl.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \
          -DrepositoryId=rio -Dclassifier=dl -Durl=scp:/...

          mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \
          -DartifactId=reggie -Dfile=apache-river/lib/reggie.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \
          -DrepositoryId=rio -Durl=scp://...

          Show
          Dennis Reedy added a comment - I'm not sure if you need a new set of poms. For my Rio maven work I needed to add reggie to Rio's maven repository. To day that I simply aded a classifier when deploying the jar: mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \ -DartifactId=reggie -Dfile=apache-river/lib-dl/reggie-dl.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \ -DrepositoryId=rio -Dclassifier=dl -Durl=scp:/... mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \ -DartifactId=reggie -Dfile=apache-river/lib/reggie.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \ -DrepositoryId=rio -Durl=scp://...
          Hide
          Jeff Ramsdale added a comment -

          Now that I think about it, though, isn't it possible that the dl jar would have different dependencies? If you were to use these in a Maven context would you want to bring along transitive dependencies that came from the non-dl jar's pom if it were shared?

          Show
          Jeff Ramsdale added a comment - Now that I think about it, though, isn't it possible that the dl jar would have different dependencies? If you were to use these in a Maven context would you want to bring along transitive dependencies that came from the non-dl jar's pom if it were shared?
          Hide
          Dennis Reedy added a comment -

          Not only is it possible, but it will happen most all the time. But here is the issue with this:

          Even if you break out a different module for the -dl.jar, the -dl.jar will have a dependency on the impl jar, since it is a subset of the impl jar. So you are stuck with either duplicating the sources that end up in the -dl.jar, or declaring that the -dl.jar has a dependency on the impl jar.

          In resolving the -dl jar's dependencies, the impl jar comes along, including all of it's transitive dependencies. This isnt exactly right, since the -dl.jar only requires the impl jar in order to run classdepandjar on it.

          I think it comes down to whether this is more of an assembly issue. IMO, having one pom for a service that produces > 1 artifacts that in turn declares dependencies on other services (with classifiers where appropriate) seems to be the right way to go. I think it could get very confusing (not that this is all crystal clear) having a service devolve into a multi-module entity.

          Show
          Dennis Reedy added a comment - Not only is it possible, but it will happen most all the time. But here is the issue with this: Even if you break out a different module for the -dl.jar, the -dl.jar will have a dependency on the impl jar, since it is a subset of the impl jar. So you are stuck with either duplicating the sources that end up in the -dl.jar, or declaring that the -dl.jar has a dependency on the impl jar. In resolving the -dl jar's dependencies, the impl jar comes along, including all of it's transitive dependencies. This isnt exactly right, since the -dl.jar only requires the impl jar in order to run classdepandjar on it. I think it comes down to whether this is more of an assembly issue. IMO, having one pom for a service that produces > 1 artifacts that in turn declares dependencies on other services (with classifiers where appropriate) seems to be the right way to go. I think it could get very confusing (not that this is all crystal clear) having a service devolve into a multi-module entity.
          Hide
          Peter Firmstone added a comment -

          Does anybody have some time to devote to this issue, it's marked for an AR2 release, I'd like to either resolve the issue now or postpone it until after AR2.

          Show
          Peter Firmstone added a comment - Does anybody have some time to devote to this issue, it's marked for an AR2 release, I'd like to either resolve the issue now or postpone it until after AR2.
          Hide
          Peter Firmstone added a comment -

          Postpone until AR3, clearing AR2 for release.

          Show
          Peter Firmstone added a comment - Postpone until AR3, clearing AR2 for release.
          Hide
          Peter Firmstone added a comment -

          Issue resolution delayed until following release

          Show
          Peter Firmstone added a comment - Issue resolution delayed until following release
          Hide
          Greg Trasuk added a comment -

          poms added in r1444456

          Show
          Greg Trasuk added a comment - poms added in r1444456
          Hide
          Jonathan Costers added a comment -

          The "deploy-artifacts" task, which is already present in build.xml, should allow us to integrate this into our CI builds, if we set the right location in property m2.repository:

          <!-- TODO: cleanup and find out where exactly to publish to -->
          <!-- Note that you need the Maven Ant tasks (http://maven.apache.org/ant-tasks/)
          installed to use this task -->
          <target name="deploy-artifacts" depends="jars">
          <!--<artifact:install-provider artifactId="wagon-file" version="1.0-beta-2"/>
          <artifact:install-provider artifactId="wagon-http" version="1.0-beta-2"/>
          <artifact:install-provider artifactId="wagon-ssh" version="1.0-beta-2"/>-->
          <!-- Override this in <river src distr. home>/build.properties to try out -->
          <property name="m2.repository" value="file:///home/jonathan/maven" />
          <macrodef name="deploy">
          <attribute name="file" />
          <attribute name="pom" />
          <sequential>
          <artifact:deploy file="@

          {file}

          " >
          <remoteRepository url="$

          {m2.repository}

          "/>
          <pom refid="@

          {pom}

          "/>
          </artifact:deploy>
          </sequential>
          </macrodef>
          <artifact:pom id="parent" file="$

          {poms.dir}/pom.xml" />
          <artifact:pom id="jini-core" file="${poms.dir}

          /jini-core/pom.xml" />
          <artifact:pom id="jini-ext" file="$

          {poms.dir}/jini-ext/pom.xml" />
          <artifact:pom id="jsk-lib" file="${poms.dir}

          /jsk-lib/pom.xml" />
          <artifact:pom id="jsk-dl" file="$

          {poms.dir}/jsk-dl/pom.xml" />
          <artifact:pom id="jsk-resources" file="${poms.dir}

          /jsk-resources/pom.xml" />
          <artifact:pom id="jsk-platform" file="$

          {poms.dir}/jsk-platform/pom.xml" />
          <artifact:pom id="jsk-policy" file="${poms.dir}

          /jsk-policy/pom.xml" />
          <artifact:pom id="serviceui" file="$

          {poms.dir}/serviceui/pom.xml" />
          <artifact:pom id="sun-util" file="${poms.dir}

          /sun-util/pom.xml" />
          <artifact:pom id="start" file="$

          {poms.dir}/start/pom.xml" />
          <artifact:pom id="tools" file="${poms.dir}

          /tools/pom.xml" />
          <deploy file="$

          {lib.dir}/jini-core.jar" pom="jini-core" />
          <deploy file="${lib.dir}

          /jini-ext.jar" pom="jini-ext" />
          <deploy file="$

          {lib.dir}/jsk-lib.jar" pom="jsk-lib" />
          <deploy file="${lib-dl.dir}/jsk-dl.jar" pom="jsk-dl" />
          <deploy file="${lib.dir}

          /jsk-resources.jar" pom="jsk-resources" />
          <deploy file="$

          {lib.dir}/jsk-platform.jar" pom="jsk-platform" />
          <deploy file="${lib-ext.dir}/jsk-policy.jar" pom="jsk-policy" />
          <deploy file="${lib.dir}

          /serviceui.jar" pom="serviceui" />
          <deploy file="$

          {lib.dir}/sun-util.jar" pom="sun-util" />
          <deploy file="${lib.dir}

          /start.jar" pom="start" />
          <deploy file="$

          {lib.dir}

          /tools.jar" pom="tools" />
          </target>

          Show
          Jonathan Costers added a comment - The "deploy-artifacts" task, which is already present in build.xml, should allow us to integrate this into our CI builds, if we set the right location in property m2.repository: <!-- TODO: cleanup and find out where exactly to publish to --> <!-- Note that you need the Maven Ant tasks ( http://maven.apache.org/ant-tasks/ ) installed to use this task --> <target name="deploy-artifacts" depends="jars"> <!--<artifact:install-provider artifactId="wagon-file" version="1.0-beta-2"/> <artifact:install-provider artifactId="wagon-http" version="1.0-beta-2"/> <artifact:install-provider artifactId="wagon-ssh" version="1.0-beta-2"/>--> <!-- Override this in <river src distr. home>/build.properties to try out --> <property name="m2.repository" value="file:///home/jonathan/maven" /> <macrodef name="deploy"> <attribute name="file" /> <attribute name="pom" /> <sequential> <artifact:deploy file="@ {file} " > <remoteRepository url="$ {m2.repository} "/> <pom refid="@ {pom} "/> </artifact:deploy> </sequential> </macrodef> <artifact:pom id="parent" file="$ {poms.dir}/pom.xml" /> <artifact:pom id="jini-core" file="${poms.dir} /jini-core/pom.xml" /> <artifact:pom id="jini-ext" file="$ {poms.dir}/jini-ext/pom.xml" /> <artifact:pom id="jsk-lib" file="${poms.dir} /jsk-lib/pom.xml" /> <artifact:pom id="jsk-dl" file="$ {poms.dir}/jsk-dl/pom.xml" /> <artifact:pom id="jsk-resources" file="${poms.dir} /jsk-resources/pom.xml" /> <artifact:pom id="jsk-platform" file="$ {poms.dir}/jsk-platform/pom.xml" /> <artifact:pom id="jsk-policy" file="${poms.dir} /jsk-policy/pom.xml" /> <artifact:pom id="serviceui" file="$ {poms.dir}/serviceui/pom.xml" /> <artifact:pom id="sun-util" file="${poms.dir} /sun-util/pom.xml" /> <artifact:pom id="start" file="$ {poms.dir}/start/pom.xml" /> <artifact:pom id="tools" file="${poms.dir} /tools/pom.xml" /> <deploy file="$ {lib.dir}/jini-core.jar" pom="jini-core" /> <deploy file="${lib.dir} /jini-ext.jar" pom="jini-ext" /> <deploy file="$ {lib.dir}/jsk-lib.jar" pom="jsk-lib" /> <deploy file="${lib-dl.dir}/jsk-dl.jar" pom="jsk-dl" /> <deploy file="${lib.dir} /jsk-resources.jar" pom="jsk-resources" /> <deploy file="$ {lib.dir}/jsk-platform.jar" pom="jsk-platform" /> <deploy file="${lib-ext.dir}/jsk-policy.jar" pom="jsk-policy" /> <deploy file="${lib.dir} /serviceui.jar" pom="serviceui" /> <deploy file="$ {lib.dir}/sun-util.jar" pom="sun-util" /> <deploy file="${lib.dir} /start.jar" pom="start" /> <deploy file="$ {lib.dir} /tools.jar" pom="tools" /> </target>

            People

            • Assignee:
              Unassigned
              Reporter:
              Jeff Ramsdale
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development