You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Smith <ps...@aconex.com> on 2007/07/02 00:27:56 UTC
Re: Chainsaw harmonization, branding, etc.
>
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw harmonization, branding, etc.
Posted by Paul Smith <ps...@aconex.com>.
>
> I don't think we can redistribute activation.jar, jms-1.1.jar,
> jmxri-1.2.1.jar, jmxtools-1.2.1.jar and mail-1.4.jar which are
> currently included in the generated tarball and zip archive. They
> are in the assembly since they are referenced by log4j, but they
> can be suppressed.
>
None of those should be shipped anyway. Chainsaw either does not use
them, or need to be placed in the plugins directory alongside the
driver-specific jar (in the case of the jms one). We'd also want to
specifically exclude the VFS, DB and JMS Receivers from the
distribution for the same reason, hence the need for some customized
Receiver distribution for Chainsaw only.
>>
>> 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.
>
> That would require Maven and a JDK where the current tarball can be
> launched with just a JRE and tar.
yes true. I was originally thinking that there was more jars that
need to be distributed than can normally be with an Apache
distribution (LGPL etc). Given that the VFS and jmdns bits and bobs
are now ASL compatible I think that has been removed. Now the
Webstart and tarball distribution can contain the exactly the same
elements.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw harmonization, branding, etc.
Posted by Curt Arnold <ca...@apache.org>.
On Jul 1, 2007, at 5:27 PM, Paul Smith wrote:
>>
>> 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.
The combo of Main-Class and Class-Path in there currently does allow
the jar to be double-clicked and successfully launch after the
tarball is expanded. It does seem desirable in addition to the others.
> 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 don't think we can redistribute activation.jar, jms-1.1.jar,
jmxri-1.2.1.jar, jmxtools-1.2.1.jar and mail-1.4.jar which are
currently included in the generated tarball and zip archive. They
are in the assembly since they are referenced by log4j, but they can
be suppressed.
>
>> 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.
That would require Maven and a JDK where the current tarball can be
launched with just a JRE and tar.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org