Getting to a single artifact per sun contributed service

[Gregg Wonderly]

I want to outline a couple of things about the current Jini environment to make
sure everyone understands the artifacts that exist today.

jsk-platform.jar is the entire Jini platform from a "spec" perspective.  There
are just library classes and interfaces here, not JavaSpace behaviors,
Transaction behaviors etc.  Those are provided by the associated services, largely.

 From a practicle perspective, Sun's contributed implementation has some library
like classes that provide some of the spec'd behavior.  But platform.jar is all
things needed to talk to services without having classes for their implementations.

jsk-lib.jar contains classes which are considered secondary details.  These are
convenience classes such as Entry implementations etc.  If your service
registers with a Name entry, you need this in your classpath for example.

jsk-dl.jar contains many of the same things that jsk-lib.jar contains but is
targeted at provided the ability for all instances downloaded to actually
resolve to some class so that if an client doesn't use a particular Entry that
your service is registered with, its attributes will still resolve even though
the client does not have that class in its classpath.

jsk-policy.jar and jsk-resources.jar provide foundation for activating the
features of Jini that interface with the JDK.  This is policy stuff,
RMIClassLoaderSPI stuff to use PreferredClassLoader etc.

A service will typically put all of these except jsk-dl.jar into its classpath,
and then put jsk-dl.jar in its codebase.  I think most of us probably know and
understand this use of these artifacts.

Those of you using Bantam or who have down web services, are familar with
deploying a single artifact for service activation, the .WAR file.

What I'd like to suggest, is that if maven is something that is decided on, that
it might make sense to reconsider how we deploy services.  We could, for example
create an archive of the classpath and codebase files as a JAR (zip) formatted
archive, and then create tooling that would consume this artifact to do
deployment into various types of configurations.

If we have all of the "stuff" in one archive, then someone could write a tool to
create a com.sun.jini.start compatible set of files (we could also change
ServiceStarter to just consume the archive).  Someone could write a "WAR"
converter, a Seven Converter etc.

Disassembly into the components you need in a structure that you need is much
easier than random gathering from the internet and assembly by hand.

Thoughts and discussion invited...

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to listserv@...