If you really want to create a jar file instead of deploying your classes in
WEB-INF/classes, just split your project into 2 subprojects.  One subproject
will create your jar file.  The other subproject will build your war file
and will include the jar file as a dependency, with the <war.bundle>
property set to true (just like any other dependency that you bundle into
your war file).

> -----Original Message-----
> From: Brill Pappin [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 28, 2004 2:21 PM
> To: Maven Users List
> Subject: Re: RFE for the war plugin
>
>
> To clarify; I'm not asking that the classes dir go away, I'm just asking
> for the ability to use a jar instead. Which should be a fairly simple
> addition to the war goal.
>
> Doing this allows me to use the manifest versioning, labeling and
> dependency parts of the manifest. For example, my code currently logs
> not only the file and line number that an exception happened in, but
> also the package and version of the jar, because in my situation it's
> possible that I have different servers running different revisions of
> the code.
>
> Your class-load order comment is a good point, but I actually see this
> as a bonus for the JAR argument, in that I can quickly patch a library
> or over-ride a log4j properties file without re-deploying... not that I
> would tend to do this if I could help it, but I've seen the need for it
> recently (in an emergency).
>
> - Brill Pappin
>
> Tomasz Pik wrote:
>
> >On Mon, 28 Jun 2004 16:02:44 +0200, "G�schl,Siegfried"
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hi Tomasz,
> >>
> >>It is actually very convenient to supply a project specific
> log4j.properties since this is the vey first one to be found
> regardless of any other log4j.properties found in JARs
> >>
> >>
> >
> >Yes, I know.
> >And that's why I'm not sure if it's the best idea to package
> classes into jar
> >file during building war file.
> >I understand that it might be useful in case of  huge set of
> small classes but
> >generally packaging classes in 'war' project into jar during
> build war file may
> >leads to problems.
> >So, it there'll be such possibilty in 'war' plugin - please, make it
> >not-default.
> >
> >Regards,
> >Tomek
> >
> >
> >
> >>Cheers,
> >>
> >>Siegfried Goeschl
> >>
> >>
> >>-----Original Message-----
> >>From: Tomasz Pik [mailto:[EMAIL PROTECTED]
> >>Sent: Montag, 28. Juni 2004 15:03
> >>To: Maven Users List
> >>Subject: Re: RFE for the war plugin
> >>
> >>On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin
> <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >>>I'm sure some of us would prefer to keep the WEB-INF/classes dir, so
> >>>my suggestion would be to include a switch property that would allow
> >>>the user to use one or the other.
> >>>
> >>>
> >>Here's one reason: servlet specs define, that classes from
> WEB-INF/classes are loaded before WEB-INF/lib so this may be used
> as some kind of 'overloading', for example for classes from
> 'third party' libraries (I know it's ugly but it's possible due to spec).
> >>
> >>Regards,
> >>Tomek
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> --
> "Any sufficiently advanced magic is indistinguishable from technology."
>                                                   - Arthur C Anticlarke
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to