Ceki,
> Whatever is in the sandbox cannot/should not be released at all! The
> point of the sandbox is to let developers unleash their talent without
> being limited by the committers. I think for example that Jacob should
> have write access to the log4j-sandbox so that he can continue working
>
Hi Richard,
> a) It would be nice to keep the core log4j package as small and
> efficient as possible.
Within reason.
> b) Allow sandbox classes to be built into independant jars (for
> instance, if all I need is core log4j and the smtp appender, then I'd
> deploye log4j.jar and log4j-smtp.jar w
Done. Thanks, Yoav!
My only comment is that whatever jalopy formats, our checkstyle target
should not complain about (except for javadoc non-compliance). So, we
should get the two in-sync. It would be primo is if checkstyle and jalopy
could use the same coding conventions xml file or descriptio
mwomack 2003/02/04 21:44:33
Modified:.build.xml
Log:
Fixed issue in compile.classpath definition.
Revision ChangesPath
1.47 +1 -1 jakarta-log4j/build.xml
Index: build.xml
===
RCS fi
mwomack 2003/02/04 21:42:21
Modified:.build.properties.sample build.xml
Added: .sunCodingConvention.xml
Log:
Changes to incorporate jalopy targets which can be used to format source code
(Thanks Yoav Shapira)
Added a "styled_files" file path definition that
Done. Thanks, Luis!
I also added a target to build an executable jar for LF5. What if the user needs to
include an xml parser in the classpath for these jars?
-Mark
-Original Message-
From: Luis Reis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 5:22 PM
To: Log4J
mwomack 2003/02/04 19:56:47
Modified:.build.xml
Log:
Added targets to build executable jars for chainsaw and lf5 gui viewers (thanks to
Luis Reis).
Modified core jar target to no longer include chainsaw and lf5 classes.
Revision ChangesPath
1.45 +66 -7
Bingo! Thanks Luis.
At 01:22 05.02.2003 +, you wrote:
Mark and Ceki,
I found that there's no need for a manifest file after all...
Here's a "diff -u" to the current build.xml that generates a "runnable"
log4j-chainsaw-.jar file.
I didn't need to make any other changes.
I don't have writ
At 11:01 04.02.2003 -0800, you wrote:
I moved them with the thinking that they were "unproven". While filters and
filter chains are well established in log4j, the base GenericMatchFilter
design that was worked out might need to be "shaken" out a bit. That was
the only thinking. We can move them
Mark and Ceki,
I found that there's no need for a manifest file after all...
Here's a "diff -u" to the current build.xml that generates a "runnable" log4j-chainsaw-.jar file.
I didn't need to make any other changes.
I don't have write access to CVS, so, please, check the code and th
Luis, sorry! I did not look at the enclosures! This is great.
Do you have write access to the cvs tree? If not, I'll figure out where to
check it in and add an ant task tonight. I need to be at home to figure out
where a good place is to put it.
-Mark
> -Original Message-
> From: Luis
Sorry,
That was not the question...
The question was "In which directory should a chainsaw.mf file be placed
?".
Sorry for the misunderstanding,
Luis
On Wed, 2003-02-05 at 00:39, Ceki Gülcü wrote:
The jar task in Ant admits a manifest element. You can also specify the
manifest file
The jar task in Ant admits a manifest element. You can also specify the
manifest file name.
At 00:42 05.02.2003 +, you wrote:
Mark,
I did test everything I've sent in the previous e-mail.
Please, I'm a rookie to log4j's cvs tree, can you tell me where's the
proper place to put that chainsa
Mark,
I did test everything I've sent in the previous e-mail.
Please, I'm a rookie to log4j's cvs tree, can you tell me where's the
proper place to put that chainsaw.mf file ?
Leave the rest to me, I can take it from there.
--
Luis
On Wed, 2003-02-05 at 00:10, Mark Womack wrote:
Hi Luis,
Hi Luis,
We use ant to build all of the released stuff, so it does need to be done in
ant. But it sounds like all we really need is a manifest file that has the
right contents. I can spend the time to figure this out, but if an
interested person out there (Niclas, Luis?) could create and test on
There's no need to have a ant task for that, you just need to add a
"Main-Class" attribute to the log4j-1.2.x.jar file's manifest indicating
either ChainSaw or LogFactor5 (though I think LogFactor5 may need some
more salt than that).
You can generate a "runnable" chainsaw.jar by using the included
No, it just means that there is no absolute necessity to package the
selector classes within log4j.jar.
At 10:31 04.02.2003 -0800, you wrote:
But, does this mean that the selectors should be packaged in their own jar,
separate from the log4j-sandbox jar?
-Mark
> -Original Message-
> Fr
Yoav,
Thanks! I'll review and commit when I get home tonight.
-Mark
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 04, 2003 12:52 PM
> To: Log4J Developers List
> Subject: RE: checkstyle.properties?
>
>
> Howdy,
>
> >Please do not make
Howdy,
>Please do not make jalopy auto-generate Javadoc. If there is one
>thing worse than no Javadoc, and that is auto-generated Javadoc
>which conveys absolutely nothing, but make it very hard to find
>what has not been properly documented.
I agree. I use Jalopy only for formatting, not for ge
Yes - Jalopy is a nice tool - especially the Eclipse plug-in as
Eclipse does not have very strong code formatting capabilities.
Using Jalopy fixes a lot of the simple errors like whitespace.
Please do not make jalopy auto-generate Javadoc. If there is one
thing worse than no Javadoc, and that is a
You heretic, Yoav!
I like this approach, as it greatly simplifies this entire discussion.
And I would be very interested those jalopy ant tasks. Using it would make
it much easier to fix up individual packages as we go.
-Mark
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PRO
I'm thinking that:
a) It would be nice to keep the core log4j package as small and
efficient as possible.
b) Allow sandbox classes to be built into independant jars (for
instance, if all I need is core log4j and the smtp appender, then I'd
deploye log4j.jar and log4j-smtp.jar with my app).
The be
Hello Mark,
Yep,
Hi Mark,
This is exactly why I spoke up about this. Even if Ceki remembered
the resolution, I don't think the consensus was ever made that clear.
So, at a minimum, we need:
log4j-selector.jar
log4j.jar
log4j-sandbox.jar
I would go further and separate any stuff that uses the
I moved them with the thinking that they were "unproven". While filters and
filter chains are well established in log4j, the base GenericMatchFilter
design that was worked out might need to be "shaken" out a bit. That was
the only thinking. We can move them back now or "graduate" them back into
But, does this mean that the selectors should be packaged in their own jar,
separate from the log4j-sandbox jar?
-Mark
> -Original Message-
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 04, 2003 6:40 AM
> To: Log4J Developers List
> Subject: Re: log4j-sandbox op
Hi Ceki,
That sounds fine. I must have forgotten about this resolution.
Sorry for the bother.
Jake
At 03:34 PM 2/4/2003 +0100, you wrote:
Hi Jake,
I thought we had this covered... It would fine to have
log4j.jar+selector.jar available to the shared class loader. This way
log4j+selectors
Hi Jake,
I thought we had this covered... It would fine to have
log4j.jar+selector.jar available to the shared class loader. This way
log4j+selectors would be accessible to Servlet Container class laoder and
the web-application class loaders. This results in one copy of
log4j.jar+selector.ja
One comment I have is that the servlet stuff needs to be run under
WEB-INF/lib of a webapp whereas the selectors need to be wherever an
existing log4j.jar is because there is two-way communication between the
selector and log4j proper. This is especially true for the
ContextClassLoaderSelecto
Howdy,
I'll chime in with my 2 cents (US) but I know I might get some flak ;)
- Leave the checkstyle properties empty (except for baseDir if we want,
since that has nothing to do with style checking), to check for the
standard Sun Java Coding Conventions.
- This will result in many (expect ~500 pe
Hi Mark,
Thanks for the getting the sandbox initiative rolling. However, why are you
moving the filters? They were just fine in log4j proper, no?
At 06:52 04.02.2003 +, you wrote:
mwomack 2003/02/03 22:52:24
Removed: tests/witness filters.LevelMatchFilter.test4.txt
30 matches
Mail list logo
