river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Poms
Date Sat, 09 Feb 2013 21:18:34 GMT
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.


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).



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

View raw message