If the poms are holding up a release then by all means revert the poms--there's nothing stopping us from retroactively deploying River artifacts via Maven. I do think it would be a mistake, though, to cut a separate release just for Maven artifacts. Maven is simply another way to release the artifacts that have already been released. That's why I initially imagined deploying 2.1.1 to Maven.
-jeff On Wed, Sep 30, 2009 at 5:42 PM, Peter Firmstone <[email protected]> wrote: > What sort of time frame are we looking at for an implementation? > > Unless this can be done in the very near future, how about we reverse Jeff's > Maven Patch for now, release River 2.2.0, patch it back into trunk and aim > for a River 2.2.1 release that includes support for Maven artefacts? > > I'd like to get River 2.2.0 out the door. > > P.S. Excellent discussion, great to see... > > Cheers, > > Peter. > > Dennis Reedy wrote: >> >> Hi Gregg, >> >> To a certain extent I think having an archive would make sense, but as it >> relates to Maven created service artifacts I am not so sure. I am going >> through a conversion of Rio to a maven project, and am actively working on >> better maven integration as well, so alot of what I reference below is an >> ongoing effort. That being said, I think a high level discussion coud put >> things in a better context. Lets discuss how something like Outrigger would >> pan out: >> >> Outrigger would have the following artifacts: >> >> org.apache.river:outrigger -> This would map to outrigger.jar >> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar. The >> key here is creating this artifact with a classifier. The classifier allows >> us to distinguish artifacts that were built from the same POM but differ in >> their content. >> >> So if I have the groupId:artifactId[:classifier] I can get the jars from >> the local repository (and/or download them from a configured repository). >> Once we have that, we should be able to deploy directly from the local Maven >> repository, having the classpath and codebase resolved by dependency >> management. >> >> IMO, this could provide seamless integration with created service >> artifact(s), and perhaps mitigate against creating service archives. >> >> Dennis >> >> >> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote: >> >>> I am still of the opinion that we need to define a 'war' kind of archive >>> of all the "jars" in a Jini service definition and make that the maven >>> artifact (maybe use .jsd for the extension). Then, we need deployment tools >>> that understand such a thing, and can open it and extract the bits out that >>> are needed for each kind of use. >>> >>> I've thought about this some, and think that we could amend >>> com.sun.jini.start to have another "config structure" that provided the >>> appropriate details into the existing classes' construction inside of >>> com.sun.jini.start.ServiceStarter. >>> >>> We might define the following '.jsd' file content from the top level >>> directory perspective as a simple start. >>> >>> 1. META-INF/MANIFEST provides a class-path: entry that details the jars >>> depended on for class path. >>> 2. META-INF/MANIFEST provides a code-base: entry that details the names >>> of jars that must be in the codebase >>> 3. codebase/* contains all the codebase jars which are part of the build >>> 4. service/* contains all of the jars which are part of the classpath >>> 5. java.policy would provide a default policy file >>> >>> The 1 and 2 items would be what containers used to decide how to package >>> a service. They would take provided jars out of 3 and 4 to fill out the >>> details as the primary source. >>> >>> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven >>> artifact names would be a something to use here would it not? We could use >>> different MANIFEST entries to specify simple jars vs known, public maven >>> artifact names. >>> >>> There could also be stuff in the MANIFEST about version etc to help >>> containers decide what version of what is needed. >>> >>> These are the things I've thought a little bit about so far. I've been >>> working on the start of a netbeans plugin to try and deal with testing and >>> using Jini services inside of netbeans and providing the generation of a >>> 'war' kind of thing. It's going fairly well so far, but real work keeps >>> taking precedence. This defined 'packaging' would make such a plug-in >>> container neutral. Containers would then just need to provide a >>> "JiniServiceDeployer" implementing plug-in to allow new services to be >>> deployed out of the IDE. >>> >>> What do the other container authors think about this. Would it be more >>> work to do something like this without a real benefit, or is there something >>> we can all gain by creating some standard packaging to help keep things >>> together and allow service "owners" to create deployment packages more >>> readily for public consumption in various kinds of container environments? >>> >>> Gregg Wonderly >>> >>> Jonathan Costers wrote: >>>> >>>> Sorry, I actually need to thank Jeff for his contribution and Dennis for >>>> his suggestions and remarks. >>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter >>>> Firmstone: >>>>> >>>>> Jeff contributed a patch containing pom's for the River dist jar files, >>>>> which I've added to the main trunk, however it isn't clear how the >>>>> download >>>>> files for service clients are handled, Dennis has made some suggestions, >>>>> however I'm going to need some help with this. >>>>> >>>>> Feel free to check out and have a play. >>>>> >>>>> Thanks in advance, >>>>> >>>>> Peter. >>>>> >>>>> Patrick Wright wrote: >>>>>> >>>>>> Hi Peter >>>>>> >>>>>> Can you update us on the status of River vis-a-vis Maven? How far >>>>>> along are you in creating the POM(s) for the build system? What is >>>>>> missing? >>>>>> >>>>>> >>>>>> Thanks >>>>>> Patrick >>>>>> >>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Anyone have any ideas or willing to assist with patches? It'd be >>>>>>> nice to >>>>>>> have this complete for AR2. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Peter. >>>>>>> >>>>>>> Dennis Reedy (JIRA) wrote: >>>>>>> >>>>>>>> [ >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243 >>>>>>>> ] >>>>>>>> Dennis Reedy commented on RIVER-317: >>>>>>>> ------------------------------------ >>>>>>>> >>>>>>>> I dont see how the -dl.jar files are being handled with this >>>>>>>> approach. How >>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be >>>>>>>> defined? >>>>>>>> With River services we have multiple artifacts per service, an >>>>>>>> implementation jar, a download (client) jar and potentially a >>>>>>>> service ui >>>>>>>> jar. >>>>>>>> I suggest that we need to be thinking of adding classifiers for the >>>>>>>> artifacts, allowing dependencies to be resolved correctly. For >>>>>>>> example, if I >>>>>>>> am using Outrigger, I need to be able to start Outrigger using >>>>>>>> outrigger.jar >>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) >>>>>>>> needs to >>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar. >>>>>>>> >>>>>>>> Declaring dependencies on River produced maven artifacts need to >>>>>>>> account >>>>>>>> for how a maven project will use the artifacts. >>>>>>>> >>>>>>>> >>>>>>>>> Deploy Apache River artifacts to Maven repositories (both release >>>>>>>>> and >>>>>>>>> snapshot) >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> Key: RIVER-317 >>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317 >>>>>>>>> Project: River >>>>>>>>> Issue Type: Task >>>>>>>>> Components: Web site and infrastructure >>>>>>>>> Affects Versions: AR2, AR3 >>>>>>>>> Reporter: Jeff Ramsdale >>>>>>>>> Fix For: AR2 >>>>>>>>> >>>>>>>>> Attachments: river-poms.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> It would be valuable if Apache River artifacts were deployed to a >>>>>>>>> Maven >>>>>>>>> repository upon release. It would be even better if snapshot builds >>>>>>>>> were >>>>>>>>> also deployed to a snapshot repository by Hudson. >>>>>>>>> See thread: >>>>>>>>> >>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >> >> > >
