Re: War packaging

[Brett Porter <br...@apache.org>]

Fabrizio Giustina wrote:

>I followed the discussion in the past, but I still can't really
>understand what are the reasons why this is such "a bad idea". I only
>repeatedly heard that this is "against Maven way of doing thing" and
>"produce two things from a project".
>  
>
This is not it at all, as long as the jar itself is not used outside of
the WAR.

I've said in the past I will apply a decent patch for it. Nobody came
forward with one (the one attached to MPWAR had a few problems I pointed
out that were never fixed). This still stands.

Really, this has become a showcase issue for a principle. While it is
not all that bad in itself, if we accepted every issue like this the
plugins would become confusing and unwieldly to develop.

The reasons we've not rushed to implement it:
- it has mostly been a case of "I want to do this for the sake of being
different". Well, that's exactly what Maven is about preventing! By
encouraging consistency it means that people can more easily jump from
project to project and know where things are. As Jason has put it -
everyone applies patterns to their software design, why not the build?
- there are good reasons to use WEB-INF/classes itself, such as
reloading and I believe someone quoted something from the servlet spec
in the past that recommended it.

>I am still convinced that this has nothing to do with the production
>of two artifact: it's always a single war artifact, simply packaged in
>a different way. Wars can have classes unexpanded in WEB-INF/classes
>or jarred in WEB-INF/lib.
>Putting classes inside a jar doesn't mean you have to produce a
>standalone jar artifact (e.g. in M2 this should be done entirely by
>the war plugin while producing the war, not by the jar mojo)
>
>  
>
Yep, totally agree on this.

>Some reason why I usually *would like* to have a war with classes
>packages as a jar file:
>  
>
it's good to see real reasons, and as I say I've no problem with
applying a patch for the feature on these grounds (though I'll still
list alternatives)

>- access packaging information (version etc) from manifest, you can't
>do that with unexpanded classes
>  
>
If it were written to the WAR manifest you could though, right?

>- avoid declaring tag libraries in web.xml (tld are automatically
>discovered only in jar files)
>  
>
this is a good one, though I'd strongly argue taglibs should be in a
whole other project producing a jar anyway so they can be shared (yes, I
know you only use them here today, but what about tomorrow :)

>- faster deploy if you only have to replace classes on an existing web
>application (without a full war redeploy)
>  
>
this sounds more like a case against... single classes reload just fine.

a better case in MPWAR-30 was the one for easily patching a system, but
I don't entirely buy that. You're just as likely to patch web files, so
you are back to square one and needing to put up the whole war again
anyway, and also patching a running app like that is an accident waiting
to happen (I've done it and regretted it before when an emergency fix
didn't find its way to the next release!)

Anyway, not trying to be a killjoy but am asking people to think about
why they need a feature before asking for it.

- Brett


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

Re: War packaging

[Fabrizio Giustina <fg...@gmail.com>]

Hi Brett

On 8/21/05, Brett Porter <br...@apache.org> wrote:
> I've said in the past I will apply a decent patch for it. Nobody came
> forward with one (the one attached to MPWAR had a few problems I pointed
> out that were never fixed). This still stands.

Now you have a working patch there ;)

> Really, this has become a showcase issue for a principle. While it is
> not all that bad in itself, if we accepted every issue like this the
> plugins would become confusing and unwieldly to develop.

ok, I can undestand that...


> The reasons we've not rushed to implement it:
> - it has mostly been a case of "I want to do this for the sake of being
> different". Well, that's exactly what Maven is about preventing! By
> encouraging consistency it means that people can more easily jump from
> project to project and know where things are. As Jason has put it -
> everyone applies patterns to their software design, why not the build?
> - there are good reasons to use WEB-INF/classes itself, such as
> reloading and I believe someone quoted something from the servlet spec
> in the past that recommended it.

Absolutely, that's exactly the same reason for a recommended project
layout. But you know that, while you can assure this is the best
layout every project should use, you have to allow customizations...

...
> >- access packaging information (version etc) from manifest, you can't
> >do that with unexpanded classes
> >
> If it were written to the WAR manifest you could though, right?

Never thought about that!
Anyway, no, it doesn't work since tomcat will unexpand the war and
packaging information is not available anymore :(

> >- avoid declaring tag libraries in web.xml (tld are automatically
> >discovered only in jar files)
> >
> >
> this is a good one, though I'd strongly argue taglibs should be in a
> whole other project producing a jar anyway so they can be shared (yes, I
> know you only use them here today, but what about tomorrow :)

Absolutely agree to this too, but sometime that's absolutely overkilling:
imagine you have a war project, a fully working build and so on. Now
you think to add a simple tag needed for your application (that you
don't plan to reuse anywere.... at least not now!):
with M1 you have to create a separate project for the taglib + a
reactor project;
then you have to fix dependencies, fix your IDE and nightly build
configuration, etc.
After that you'll realize that your tag dependes on a class you have
in your war, so (assuming you want to follow the "maven way") you need
to add a 4° project moving the core application classes there and fix
dependencies again.
Now you will have to refactor the site layout, fight against that
not-optimal handling of multiproject in maven 1 and so on.
maybe that could pay in future, but who will expect such effort for
adding a single tag now?

(yes, I tried this situation :( )


> Anyway, not trying to be a killjoy but am asking people to think about
> why they need a feature before asking for it.

my 2 cents, so

fabrizio

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