Re: maven war not jar'ing class files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

Jamie Bisotti
One command this...one command that...geesh!

http://jira.codehaus.org/browse/MPWAR-30

On 5/4/05, [hidden email] <[hidden email]> wrote:

>
> Hi,
>
> I have set our project up to create a war file.  I would like it to jar up
> the class files however, before it does so.
>
> How can I achieve this in one command?
>
> cheers,
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Jamie Bisotti
Software Engineer
Lexmark International, Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

Brett Porter
On 5/6/05, Jamie Bisotti <[hidden email]> wrote:
> One command this...one command that...geesh!
>
> http://jira.codehaus.org/browse/MPWAR-30
>

I'll respond to your comment here, instead. You said:

" I've mentioned this before on the mailing list...Maven needs to be
careful to balance "the Maven way" vs. making things that should be
trivial, hard on users. As someone mentioned above, this is strictly
about packaging within a WAR; separate projects just to get your
classes JAR'ed and placed in WEB-INF/lib is extreme overkill."

The reason why I was only tending towards a negative vote and not flat
out -1 is because of the reason you cite here. We don't go out of our
way to make things difficult for users.

Bear in mind something trivial, as you say, can easily be implemented
in the user's maven.xml themselves.

The reasons why I am leaning towards the negative on this:

I've not received one good reason why this is actually useful. "It
would be nice" with no justification just means we would be adding
something of little value.

Feature creep is a big problem in Maven 1.x, and it has lead to some
of the plugins being quite confusing because you can do one thing in a
large number of ways. It makes maintenance, testing and documentation
harder.

I know this feature seems trivial, but you have to draw the line
somewhere. As long as we aren't stopping people from doing what they
need to, I think this is the right choice to make.

I also don't agree with your overkill statement. More than it should
be perhaps, and Maven's mutliple project handling could be better, but
at the end of the day you are moving 1 or 2 directories and creating
two small files for the new subproject. That's not a lot for proper
separation of code and presentation.

Hope this clears it up, and am happy to field any more questions or
concerns on the topic.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

Felipe Leme
On Fri, 2005-05-06 at 01:17 +1000, Brett Porter wrote:

> I've not received one good reason why this is actually useful. "It

OK, I will (hopefully) give you some below.

> I also don't agree with your overkill statement. More than it should
> be perhaps, and Maven's mutliple project handling could be better, but
> at the end of the day you are moving 1 or 2 directories and creating
> two small files for the new subproject. That's not a lot for proper
> separation of code and presentation.

What about documentation? Where goes the xdoc stuff like changes.xml,
index.xml and navigation.xml? Should they go in the master project, in
the sub-projects or in both?

And what if I have more than one of such projects (i.e., projects that
had to be broken in multi-projects) in an hierarchy and then I need to
run these now-multiprojects using multi-projects (i.e., I would have two
levels of multiprojects).

What about Eclipse? I can't have one project in one directory (the
multi-project) and then 2 other projects in sub-directories.

So, I understand your reasoning against this issue, but I think that if
weight the pros and cons, there are more scenarios that would benefit
from the change than the opposite.

-- Felipe



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

Brett Porter
On 5/20/05, Felipe Leme <[hidden email]> wrote:
> On Fri, 2005-05-06 at 01:17 +1000, Brett Porter wrote:
>
> > I've not received one good reason why this is actually useful. "It
>
> OK, I will (hopefully) give you some below.

This is a bit out of context. What I haven't seen a reason for is why
WEB-INF/classes should be packaged as a JAR in lib instead, and what
that benefits you.

> > I also don't agree with your overkill statement. More than it should
> > be perhaps, and Maven's mutliple project handling could be better, but
> > at the end of the day you are moving 1 or 2 directories and creating
> > two small files for the new subproject. That's not a lot for proper
> > separation of code and presentation.
>
> What about documentation? Where goes the xdoc stuff like changes.xml,
> index.xml and navigation.xml? Should they go in the master project, in
> the sub-projects or in both?

In this example, if you are separating your model code from your
presentation, I'd say each should be documented accordingly (ie split
into both, not duplicated).

If you are not interested in maintaining the code spearately and are
just separating it for the sake of getting a JAR into lib, keep the
doc in WAR and don't doc the other subproject at all. But I don't
think this is a good idea.

> And what if I have more than one of such projects (i.e., projects that
> had to be broken in multi-projects) in an hierarchy and then I need to
> run these now-multiprojects using multi-projects (i.e., I would have two
> levels of multiprojects).

Why? multiprojects can traverse deeper structures. Or if you actually
want them as multiproejcts so you can aggregate the docs, fine - it
should work. I don't see what problem you have here.

> What about Eclipse? I can't have one project in one directory (the
> multi-project) and then 2 other projects in sub-directories.

This is a general problem and I'm tracking an issue at Eclipse for
them to make this workable. Like always, you have to add each
subproject individually and not use Eclipse to edit your top level
files. It's not a massive hinderance, really.

> So, I understand your reasoning against this issue, but I think that if
> weight the pros and cons, there are more scenarios that would benefit
> from the change than the opposite.

I don't agree.

But I'll also remind you that I just said I was somewhere between -0
and -1. I don't like feature creep for the sake of it, but I don't
want to make Maven stand in the way of users doing something.

The counter arguments keep coming back the same, and addressing the
part saying its problematic to split it up, but nobody is saying why
making the JAR in lib is a requirement in the first place (unless
after it all I have just forgotten :)

I'm still -0.75 to including this. But to make it go away, you can
commit it if you want to, I won't complain. It's not a big problem.

The reason I have kept talking about this, is that I do want to see a
change to the culture that sprang up in m1 where the kitchen sink was
thrown into plugins to follow everyone's preferences. It's made
plugins needlessly complicated, hard to test all features, and some of
the features just become maintained as the mainstream users aren't
interested in them.

Maven's goals are to make the defaults sensible and to cover all the
use cases to make things possible. When it comes down to supporting
individual's preferences that have a mainstream alternative, we need
to carefully consider what the impact is.
 - what impact will it have on the complexity, maintainability and
testability of the plugin?
 - what benefit will it really add? Is this benefit greater than the
loss of standardisation?

Hope this helps...
- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

Felipe Leme
On Sat, 2005-05-21 at 15:16 +1000, Brett Porter wrote:

> This is a bit out of context. What I haven't seen a reason for is why
> WEB-INF/classes should be packaged as a JAR in lib instead, and what
> that benefits you.

Ok, I see your point - I guess it's more of a personal preference.
Anyway, the same argument could apply against the current way: why
should the classes be on WEB-INF/classes instead of a jar?


> But I'll also remind you that I just said I was somewhere between -0
> and -1. I don't like feature creep for the sake of it, but I don't
> want to make Maven stand in the way of users doing something.

Ok, I understand.

> The counter arguments keep coming back the same, and addressing the
> part saying its problematic to split it up, but nobody is saying why
> making the JAR in lib is a requirement in the first place (unless
> after it all I have just forgotten :)

As I said below, it's not a requirement, but not anything forbidden as
well.
So, if the option is up to the user (because the specification allows
both), we should provide the mechanism to let the user decide.


> I'm still -0.75 to including this. But to make it go away, you can
> commit it if you want to, I won't complain. It's not a big problem.

I haven't committed yet because unfortunately the fix is not that
simple:

1.if we use a prereqs="jar:jar", it might interfere with projects that
are plain web pages (i.e., without java classes)

2.if we use a conditional <attainGoal name="jar:jar"/>, the goal jar:jar
might be called twice in many projects, which would slow down some
builds a lot (because jar:jar will in turn call a lot of goals like
test:test)

3.a third option would be to create a new goal and refactor the current
ones. Something like this:

<goal name="war:classes-war" prereqs="war:base-war"/>
<goal name="war:jar-war" prereqs="jar:jar,war:base-war"/>
<goal name="war:war" prereqs="war:classes-war"/>


The old war:war would be refactored to war:base-war, which in turn
checks for the internal maven.war.usesJar property. The war:war by
default would have the same behaviour as before, but if an user wants to
change its behaviour, it would just change it in the projects's
maven.xml to:

<goal name="war:war" prereqs="war:jar-war"/>
 
(notice that the war:jar-war would in turn set the property
maven.war.usesJar to true).


So, each approach has a problem:

2 is undoable due to the multiple goals invocation on attainGoals
3 introduces bloat and complexity
1 is the simplest one but it might cause backward compatibility issues

I for one would opt for option 1 - what do you (and others) think?
Should we call a vote on the dev list about it (explainining the 3
options + the option of marking the bug as WON'T FIX)?


> plugins needlessly complicated, hard to test all features, and some of

Yes, I agree.

> Maven's goals are to make the defaults sensible and to cover all the
> use cases to make things possible. When it comes down to supporting

I think the problem with this particular issue is that there is no
consensus whether packaging the classes or the jar is the default. In
fact, I think there is no default in this case.


-- Felipe



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: maven war not jar'ing class files

Jeff Jensen-3
My .02:

During the code/test cycle, leaving classes loose in the classes dir allow
most app servers to hot swap them.

For deploys beyond the developer workspace (dev, test, QA, stage, prod, et
al), de facto "packaged" means the loose classes are in jars.


I/we don't use Maven for the code/test cycle - the IDE toolset does this.
But Maven does the nightly build.  We package into jars.

So from my standpoint, I need Maven to jar, not leave classes loose.

 

-----Original Message-----
From: Felipe Leme [mailto:[hidden email]]
Sent: Saturday, May 21, 2005 9:31 AM
To: [hidden email]
Subject: Re: maven war not jar'ing class files

On Sat, 2005-05-21 at 15:16 +1000, Brett Porter wrote:

> This is a bit out of context. What I haven't seen a reason for is why
> WEB-INF/classes should be packaged as a JAR in lib instead, and what
> that benefits you.

Ok, I see your point - I guess it's more of a personal preference.
Anyway, the same argument could apply against the current way: why should
the classes be on WEB-INF/classes instead of a jar?


> But I'll also remind you that I just said I was somewhere between -0
> and -1. I don't like feature creep for the sake of it, but I don't
> want to make Maven stand in the way of users doing something.

Ok, I understand.

> The counter arguments keep coming back the same, and addressing the
> part saying its problematic to split it up, but nobody is saying why
> making the JAR in lib is a requirement in the first place (unless
> after it all I have just forgotten :)

As I said below, it's not a requirement, but not anything forbidden as well.
So, if the option is up to the user (because the specification allows both),
we should provide the mechanism to let the user decide.


> I'm still -0.75 to including this. But to make it go away, you can
> commit it if you want to, I won't complain. It's not a big problem.

I haven't committed yet because unfortunately the fix is not that
simple:

1.if we use a prereqs="jar:jar", it might interfere with projects that are
plain web pages (i.e., without java classes)

2.if we use a conditional <attainGoal name="jar:jar"/>, the goal jar:jar
might be called twice in many projects, which would slow down some builds a
lot (because jar:jar will in turn call a lot of goals like
test:test)

3.a third option would be to create a new goal and refactor the current
ones. Something like this:

<goal name="war:classes-war" prereqs="war:base-war"/> <goal
name="war:jar-war" prereqs="jar:jar,war:base-war"/> <goal name="war:war"
prereqs="war:classes-war"/>


The old war:war would be refactored to war:base-war, which in turn checks
for the internal maven.war.usesJar property. The war:war by default would
have the same behaviour as before, but if an user wants to change its
behaviour, it would just change it in the projects's maven.xml to:

<goal name="war:war" prereqs="war:jar-war"/>
 
(notice that the war:jar-war would in turn set the property
maven.war.usesJar to true).


So, each approach has a problem:

2 is undoable due to the multiple goals invocation on attainGoals
3 introduces bloat and complexity
1 is the simplest one but it might cause backward compatibility issues

I for one would opt for option 1 - what do you (and others) think?
Should we call a vote on the dev list about it (explainining the 3 options +
the option of marking the bug as WON'T FIX)?


> plugins needlessly complicated, hard to test all features, and some of

Yes, I agree.

> Maven's goals are to make the defaults sensible and to cover all the
> use cases to make things possible. When it comes down to supporting

I think the problem with this particular issue is that there is no consensus
whether packaging the classes or the jar is the default. In fact, I think
there is no default in this case.


-- Felipe



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven war not jar'ing class files

David Jencks-2
In reply to this post by Felipe Leme

On May 21, 2005, at 7:31 AM, Felipe Leme wrote:

> On Sat, 2005-05-21 at 15:16 +1000, Brett Porter wrote:
>
>> This is a bit out of context. What I haven't seen a reason for is why
>> WEB-INF/classes should be packaged as a JAR in lib instead, and what
>> that benefits you.
>
> Ok, I see your point - I guess it's more of a personal preference.
> Anyway, the same argument could apply against the current way: why
> should the classes be on WEB-INF/classes instead of a jar?
>
Servlet spec 2.4 says this (section 9.5):
• The/WEB-INF/classes/ directory for servlet and utility classes. The
classes in this directory must be available to the application class
loader.
• The/WEB-INF/lib/*.jar area for Java ARchivefiles. These files contain
servlets, beans, and other utility classes useful to the Web
application. The Web application class loader must be able to load
classes from any of these archive files.

The Web application classloader must load classes from the
WEB-INF/classes directory first, and then from library JARs in the
WEB-INF/lib directory. ...

-------------
I conclude from this that the WEB-INF/classes area is the primary area
you are expected to put your classes in, and WEB-INF/lib is a secondary
area for other stuff you scrounged up from somewhere else.  In
particular they are not equivalent, since the WEB-INF/classes area is
first on the classloader path.  Putting everything in WEB-INF/lib
removes the possibility of overriding classes with this mechanism.

 From this I think the most reasonable behavior for maven is to only put
java classes from the current project in WEB-INF/classes and to require
putting the java in a separate project if you want them in a jar in
WEB-INF/lib.

thanks
david jencks

<giant snip>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]