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