river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Maven Artefacts RIVER-317 - AR2 Release
Date Thu, 01 Oct 2009 00:42:43 GMT
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 

I'd like to get River 2.2.0 out the door.

P.S. Excellent discussion, great to see...



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 
>>>>> <jini@zeus.net.au> 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...)
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>>> 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/<e202160f0908050006t36c061b8qee049ab95bfd1d94@mail.gmail.com>


View raw message