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 15:30:21 GMT

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
Mime
View raw message