On 5/20/05, Felipe Leme <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
