If the poms are documented as to what they do and don't do then let's include them as-is (or with any outstanding bits of quick tidy-up that they need).
Making the poms do exactly what we need/want them to do could easily be included in the next major/minor/point release we decide to release anyway - is that not the point of releasing new software versions? It also fits a bit better with the "release little, release often" mantra. Again, as long as the AR2 (or 2.0.0 or whatever it's called), release notes include comments along the lines of "Included maven repositories to get this JAR and this JAR, but not that JAR or that JAR", we're covered. If the current poms do 50% (number chosen at random) of what we want them to do, then fine. My personal opinion is that it would be a bit demoralising to back them out because they're not "perfect" when we can include a valuable contribution and make them "perfect" in the next release. My opinion; however wrong it might be. :-) Cheers, Tom -----Original Message----- From: Jeff Ramsdale [mailto:[email protected]] Sent: 01 October 2009 01:52 To: [email protected] Subject: Re: Maven Artefacts RIVER-317 - AR2 Release 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]> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >> >> > > www.sucdenfinancial.com Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ Telephone +44 203 207 5000 Registered in England no. 1095841 VAT registration no. GB 446 9061 33 Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239 This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify [email protected] immediately and delete it from your computer system. We believe, but do not warrant, that this email and its attachments are virus-free, but you should check. Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email. The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment. This message has been scanned for viruses by Mimecast.
