incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <>
Subject Re: Maven Artefacts RIVER-317 - AR2 Release
Date Wed, 30 Sep 2009 22:35:38 GMT
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 <> 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:
>>>>>    [
>>>>> ]
>>>>> Dennis Reedy commented on RIVER-317:
>>>>> ------------------------------------
>>>>> I dont see how the -dl.jar files are being handled with this approach.
>>>>> 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
>>>>> 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
>>>>> 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
>>>>>> snapshot)
>>>>>> -------------------------------------------------------------------------------
>>>>>>                Key: RIVER-317
>>>>>>                URL:
>>>>>>            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
>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>> See thread:

View raw message