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 jeff.ramsdale@gmail.com
 designates 209.85.222.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=o6E8twQJQUNNCDLRiMwNqthQtXHAP1eX5hwB7+7CiUMwCmYAZbOVdzdIyQ2NAEJmhW
         VPnp2S3zBnW2AAzxghTF0GtfoI5ygAOIM//1f6OxQiw9Ua8YEhMywh8WGXfXnzHRAH3k
         YZHfET1COu3ibVJt4THwy34byzFTWUS2Xi/Dg=
MIME-Version: 1.0
In-Reply-To: <4AC3FB03.3080105@zeus.net.au>
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>
	 <B2CDFF18-1DE1-4C3B-BCFF-AB412B628686@gmail.com>
	 <4AC3FB03.3080105@zeus.net.au>
Date: Wed, 30 Sep 2009 17:51:36 -0700
Message-ID: <e202160f0909301751v64b7fbd6sb5d209bfd42b05b4@mail.gmail.com>
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
From: Jeff Ramsdale <jeff.ramsdale@gmail.com>
To: river-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <jini@zeus.net.au> 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 Jef=
f's
> Maven Patch for now, release River 2.2.0, patch it back into trunk and ai=
m
> 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 i=
t
>> 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 a=
n
>> ongoing effort. That being said, I think a high level discussion coud pu=
t
>> things in a better context. Lets =A0discuss 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 all=
ows
>> 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 M=
aven
>> 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 archiv=
e
>>> of all the "jars" in a Jini service definition and make that the maven
>>> artifact (maybe use .jsd for the extension). =A0Then, we need deploymen=
t 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. =A0META-INF/MANIFEST provides a class-path: entry that details the j=
ars
>>> depended on for class path.
>>> 2. =A0META-INF/MANIFEST provides a code-base: entry that details the na=
mes
>>> of jars that must be in the codebase
>>> 3. =A0codebase/* contains all the codebase jars which are part of the b=
uild
>>> 4. =A0service/* contains all of the jars which are part of the classpat=
h
>>> 5. =A0java.policy would provide a default policy file
>>>
>>> The 1 and 2 items would be what containers used to decide how to packag=
e
>>> 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. =A0M=
aven
>>> artifact names would be a something to use here would it not? =A0We cou=
ld use
>>> different MANIFEST entries to specify simple jars vs known, public mave=
n
>>> 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. =A0I've be=
en
>>> 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. =A0It's going fairly well so far, but real work ke=
eps
>>> 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. =A0Would it be mo=
re
>>> work to do something like this without a real benefit, or is there some=
thing
>>> 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 environmen=
ts?
>>>
>>> Gregg Wonderly
>>>
>>> Jonathan Costers wrote:
>>>>
>>>> Sorry, I actually need to thank Jeff for his contribution and Dennis f=
or
>>>> 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 file=
s,
>>>>> which I've added to the main trunk, however it isn't clear how the do=
wnload
>>>>> files for service clients are handled, =A0Dennis has made some sugges=
tions,
>>>>> 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? =A0It'd be
>>>>>>> nice to
>>>>>>> have this complete for AR2.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>>
>>>>>>>> =A0[
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12=
760243#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 th=
e
>>>>>>>> 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)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------=
--------------
>>>>>>>>>
>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Key: RIVER-317
>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0URL: https://issues.apache.org/jira/br=
owse/RIVER-317
>>>>>>>>> =A0 =A0 =A0 =A0 =A0Project: River
>>>>>>>>> =A0 =A0 =A0 Issue Type: Task
>>>>>>>>> =A0 =A0 =A0 Components: Web site and infrastructure
>>>>>>>>> =A0Affects Versions: AR2, AR3
>>>>>>>>> =A0 =A0 =A0 =A0 Reporter: Jeff Ramsdale
>>>>>>>>> =A0 =A0 =A0 =A0 =A0Fix For: AR2
>>>>>>>>>
>>>>>>>>> =A0 =A0 =A0Attachments: 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 buil=
ds
>>>>>>>>> were
>>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>>> See thread:
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/2009=
08.mbox/<e202160f0908050006t36c061b8qee049ab95bfd1d94@mail.gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>
>