On Wed, 11 Sep 2002, Donald Ball wrote:
> Date: Wed, 11 Sep 2002 11:56:45 -0400
> From: Donald Ball <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Packaging error
>
> On 9/11/2002 at 8:47 AM Craig R. McClanahan wrote:
>
> >Ceki,
> >
> >It was nothing wrong with Log4J -- the person who built the Struts release
> >built commons-logging.jar from scratch, but without Log4J in his build
> >environment (so the Log4J wrapper classes weren't included).
> >
> >The final Struts release will include final releases of the Commons
> >packages it relies on, and we'll verify that everything is there.
>
> On that note, could I register a small vote for including some sort of
> version information in the commons (and other) jars? I, at least, use a
> couple of other packages that rely on jakarta commons jars, and it's
> difficult to tell offhand which version is more recent. I'd suggest
> appending datestamps to the jar names if version numbers are not available:
>
> commons-digester-2002-09-11.jar
>
Doing this is really hard on people that build compile classpaths by hand
(instead of letting something like Ant do it for them).
All the commons JARs I'm familiar with include version information in
their MANIFEST.MF files.
For Struts, the rules are simple.
* Nightly builds of Struts include the nightly builds of the
corresponding commons packages (built from source from the
HEAD branch of all repositories).
* Milestones/betas use released versions of commons packages
where they can, but snapshots otherwise. In all such
cases, there is a "STRUTS_1_1_B2" CVS tag (or whatever)
in the commons repository if you need the exact classes.
* Release builds use released versions of Commons components
(check the "Implementation-Version" field in MANIFEST.MF.
> - donald
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
