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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
