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