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:[EMAIL PROTECTED] Sent: Saturday, May 21, 2005 9:31 AM To: [email protected] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
