On Feb 9, 2013, at 432AM, Dan Creswell wrote: > >> >> Well, the only rub with this approach is outlined here >> (http://www.apache.org/dev/publishing-maven-artifacts.html), in the "Getting >> your project setup in the Nexus Repository" section that states: >> >> Maven Group Ids: a list of the groupIds for this project. They should all be >> subgroups of org.apache >> >> I suppose we can ask for net.jini groupId in addition to org.apache.river. >> If denied we will need to go with everything being org.apache.river, or >> choose to publish the net.jini artifacts to Maven central ourselves (which >> is fine with me btw).
I submitted the Jira ticket last night and it looks like we're all set for org.apache.river and net.jini groupIds. >>>> Additionally, the pom directory is setup as a multi-module maven project. >>>> Eventually, I think this is something I would like to see, but until then >>>> what we need is the ability to install/deploy River produced jars to a >>>> Maven repository as 3rd party jars. I'd like to refactor the poms >>>> accordingly to enable this to happen, and provide the ability (using a >>>> script) to deploy to the ASF Maven repository >>>> (http://repository.apache.org). > > Just to satisfy my curiosity/learning desire: What refactoring needs doing? As I mentioned above, the pom directory is setup as a multi-module maven project. This doesn't make any sense if that project does not produce artifacts (jars). There are some dependencies that need fixing (like jsk-lib depends on jsk-platform), every pom should have a description as well as license declaration, and replace the org.apache.river groupId with net.jini groupId where needed. There is no reason to have poms for jini-core, jini-ext or sun-util. We will not be deploying them, they are deprecated. I dont see the need to have parent relationships in the poms, we are dealing with the deployment of jars outside of a multi-module project (either using maven or gradle), so these structural relationships will be removed. Someone put a fair bit of work into the structure and content, it's similar to what I had been working on some time ago, and I will most likely create a branch off of skunk to get a "real" multi-module River project. However, the current structure in the poms directory will be replaced by a directory of poms (reggie.pom. jsk-lib.pom, etc...) and a script to deploy River to the ASF repository. > >>>> >>>> IIRC, if we deploy to the ASF repository, artifacts are synched to Maven >>>> Central. I'd like to deploy 2.2.1 once it becomes available. > > +1 I still need to tag the 2.2 branch as 2.2.1, aside from that what are the steps necessary to create an official River release? Dennis
