Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.220.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=CHZt5YeNpOXxueTACM8f+GCXqrV362rPrcYfyQ4/vLDxe92diztBHMF720vW7Ll/hY
         dP0M/QYqhCNXCNKmTYMNGJNMLofMJdt1M8jKfh/jcY17mcTATV8y3/VrTNd0ZuWrV8kP
         5fFfadnw+UfsvVerGP+S2gfB8paWD2lJQjjsM=
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
From: Dennis Reedy <dennis.reedy@gmail.com>
In-Reply-To: <4AC3DD3A.7070600@wonderly.org>
Date: Wed, 30 Sep 2009 19:07:51 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <B2CDFF18-1DE1-4C3B-BCFF-AB412B628686@gmail.com>
References: <1014271612.1254145216266.JavaMail.jira@brutus>
	 <4AC2FF2F.5060409@zeus.net.au>
	 <64efa1ba0909292351i7200f661k211143a9571c8765@mail.gmail.com>
	 <4AC30557.7060906@zeus.net.au> <1254347537.4813.48.camel@localhost>
 <4AC3DD3A.7070600@wonderly.org>
To: river-dev@incubator.apache.org

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