river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Costers <jonathan.cost...@googlemail.com>
Subject Re: Maven Artefacts RIVER-317 - AR2 Release
Date Wed, 30 Sep 2009 23:06:17 GMT
I am certainly not a container author .. But I find your thoughts very
interesting.
There has been discussion around deployment mechanisms before, IIRC (long
time ago)?

2009/10/1 Gregg Wonderly <gregg@wonderly.org>

> 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>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message