Looks pretty solid. What about phoenix though? Maybe you're lumping that into the tools category?
On 9 February 2013 21:18, Dennis Reedy <[email protected]> wrote: > I'd like to remove the current poms and replace them with poms for the > following artifacts. This would happen for both the 2.2 branch (later to be > tagged as 2.2.1) and for trunk. > > net.jini:jsk-platform > net.jini:jsk-lib > net.jini:jsk-dl > net.jini:jsk-resources > net.jini.lookup:serviceui > org.apache.river:fiddler > org.apache.river:fiddler-dl > org.apache.river:mahalo > org.apache.river:mahalo-dl > org.apache.river:norm > org.apache.river:norm-dl > org.apache.river:outrigger > org.apache.river:outrigger-dl > org.apache.river:reggie > org.apache.river:reggie-dl > org.apache.river:start > > The dependency graph looks something like this (I can add the dot file to > the directory if we think this is helpful). > > > > If there are any questions on this please ask. I did not include all the > tools jars (I figured you could get those when the release is downloaded). > > Regards > > Dennis > > On Feb 9, 2013, at 1030AM, Dennis Reedy wrote: > > > 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 > > >
