I used the assembly:assembly plug to create a distribution, however
the descriptor (src/assembly/bin.xml) needs to be tweaked to drop
out non-re-distributable jars. Hopefully, all the non-re-
distributable jars are not essential to operation, at least not on
JDK 1.5. Currently, you can do java -jar on apache-chainsaw.jar and
the app launches. I added the main-class and path entries to the
chainsaw jar, wouldn't do that on a library jar but hopefully is a
good thing for an application jar.
I've never found that main-class much use because of the external
reference to jars. Personally I like the appassembler distribution
that maven can build, plus the Mac-specific one.
The external referenced jars are the crux of the problem with
Chainsaw. Out-of-the-box, Chainsaw is useful for socket-based
operations and local file reading. For JMS, DB, and VFS style
operations, the 3rd-party requirements make it a tricky distribution
problem.
Which exactly are the non-redistributable jars? Xstream and jmdns
are the only listed dependencies in the pom, both of which are ASL
licensed. JSch (for ssh-based stuff like vfs) used to LGPL but is
now BSD licensed, but we don't actually need to depend on that per-se
(they can go in the plugins directory).
I will probably need to get my head around the distribution
mechanisms. I think we do need a classic distribution tarball that
is farmed out to the distribution mirrors. Keeping the WebStart is
good, but I think it might need to be placed within and use the
Maven repo and have the downloads page point to a nearby Maven mirror.
We might as well be consistent with a tarball distro, but I'm not
sure that's what the users would want to use. For non-webstart
operations I actually think letting the user use Maven to build the
complete distribution including all dependencies is actually probably
the most pain-free for a user.
Branding is another issue. Should Chainsaw be presented as a
separate product or as a log4j companion or some other model. I've
probably not been consistent in what I've set up, but here is how I
see the options:
Chainsaw as a LS product:
Web content: http://logging.apache.org/chainsaw, appear as menu
item on http://logging.apache.org
groupId = apache-chainsaw or log4j
artifactId = apache-chainsaw
Chainsaw as a log4j companion:
Web content: http://logging.apache.org/log4j/companions/chainsaw,
appear as menu item on http://logging.apache.org/log4j and http://
logging.apache.org/log4j/1.2
groupId = log4j
artifactId = apache-log4j-chainsaw
I think that LS product is better since Chainsaw should be usable
with the other LS frameworks and is much more complicated than the
other companions. Also, the plugin components could be considered
"companions" of chainsaw.
Given Chainsaw can interact with non-log4j environments as well with
XML logging, I think a standalone position is probably more appropriate.
I don't have a problem having Chainsaw continue to use the log4j
icon, but maybe we could create a derivative icon that suggest
taking a slice of the log4j cup. Don't know if we have access to
the original drawing for the icon.
Scott and I talked about this a while back, but neither of us a gFx
artists.. :) I had always envisaged an image that was a piece of
paper with text and a chainsaw slicing right through it.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
