logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <Paul.Sm...@lawlex.com.au>
Subject RE: [Chainsaw] new version moving into log4j-sandbox
Date Thu, 24 Apr 2003 03:54:42 GMT
> I haven't said anything about the manifest settings we do for 
> the chainsaw
> and lf5 jars, but aren't they kind of a bust?  With the 
> dependencies on an
> xml jar (and Scott is adding new dependencies) I always end 
> up running it
> from a java command line with the classpath set to my 
> particular set of
> jars.  So, seems like a wash to me.  I like the idea, but it 
> doesn't seem to
> work out.  Is there something I am missing here?

Mmm, you have a good point.  It would be nice if there was an EAR runner or
something equivalent.  Be nice to just have a single distributable, in SOME
instances.  While we're still in the sandbox, a simple Ant target is all we
need.  You're right.
> As for what gets moved into the sandbox, I vote for taking the current
> chainsaw package and copying it into the sandbox.  Then it 
> can get modified
> in there (with Scott's changes, other changes, etc).  Once 
> happy, we can
> move it back.  I'm sure Oliver might have some thoughts here.

>From the looks of it, it might be easier to just use the new source code,
it's probably not worth the merging effort at this point.  Scott's approach
is different enough from the current Chainsaw code, we can defer any merge
issues when we finally move out of the sandbox and into the main
jakarta-log4j module sometime down the track.
> I don't see much difference.  Either we generate the jars 
> separately or we
> generate them together.  Either way, you have to generate 
> them.  I think the
> idea is that if the developer can build the sandbox projects, 
> then they
> should be able to generate the log4j-core as well.  Sandbox 
> components are
> not allowed to be "officially" released, but posting built versions of
> sandbox code to the dev email list is probably ok with 
> appropriately named
> jars and disclaimers.

Yeah, as I said above, scratch my idea, and go with a simple Ant target for
now.  A lot simpler.  Initially at least we're interested in log4j-dev user
feedback, and they should be able to get the CVS module and run the ant


To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message