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 <[email protected]> > 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 <[email protected]> >>>> 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/ >>>>>>> <[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >
