On Fri, 2013-02-08 at 14:26, Dennis Reedy wrote: > Hi, > > Looking around the distribution I noticed a directory of Maven poms. I see > that the groupID for all the poms is org.apache.river. Do we want to keep the > net.jini groupId intact for the artifacts produced that have net.jini > packages? >
+1 > We would have the following artifacts: > > net.jini:jsk-resources:version > net.jini:jsk-policy:version > net.jini:jsk-platform:version > net.jini:jsk-lib:version > net.jini:jsk-dl:version > > org.apache.river:reggie:version > org.apache.river:reggie-dl:version > org.apache.river:outrigger:version > org.apache.river:outrigger-dl:version > org.apache.river:mahalo:version > org.apache.river:mahalo-dl:version > org.apache.river:mercury:version > org.apache.river:mercury-dl:version > > etc ... > > 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). > > 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. > Yes, I don't think we currently need to worry about building with Maven, but we should certainly ship the artifacts to the repository. I've been a Maven avoider for a long time (although I'm starting to come around), so I'm afraid I can't be of any help, but if you know what you're doing, have at it! Greg. > Hopefully, as we move forward with a multi-module project (gradle or maven), > this will become straight forward with the project, and the need to deploy > River produced artifacts as 3rd parrty jars goes away. > > Regards > > Dennis >
