river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Ramsdale <jeff.ramsd...@gmail.com>
Subject Re: Maven Artefacts RIVER-317 - AR2 Release
Date Thu, 01 Oct 2009 00:51:36 GMT
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.


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 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 <jini@zeus.net.au>
>>>>>> wrote:
>>>>>>> Anyone have any ideas or willing to assist with patches?  It'd
>>>>>>> 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,
>>>>>>>> implementation jar, a download (client) jar and potentially
>>>>>>>> service ui
>>>>>>>> jar.
>>>>>>>> I suggest that we need to be thinking of adding classifiers
for the
>>>>>>>> artifacts, allowing dependencies to be resolved correctly.
>>>>>>>> example, if I
>>>>>>>> am using Outrigger, I need to be able to start Outrigger
>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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