> -----Original Message----- > From: Dima Berastau [mailto:[EMAIL PROTECTED]
Hi Dima, [snip] > - Thirdly, you are going to end up with a maintenance nightmare. > A stack of project.xml files that add very little value or > structure to the project. Right, in which case we might as well revert to vanilla Ant. > From what I managed to grasp out of using maven, the golden rule of maven > based project development seems to be: > IF YOUR PROJECT CAN PRODUCE A JAR (and that's more or less it) IT SHOULD. LOL! I would add emphasis on *A*, as in *one*, jar. The POM assumes single codebase components -- which leads to workarounds like two project.xmls at the same level, as in (simple 2 codebase scenario): secured-codebase-project.xml and non-secured-codebase-project.xml. Try to produce two different jars from one component, in which case you'll likely have a separate codebase for each jar for a variety of reasons. Many software projects are more complex than Jakarta Commons projects, but that "Jakarta Commons style" (which are projects typically producing *one* jar file) is currently where Maven shines best. > However, some projects (let's call them INTEGRATION projects) > cannot follow the above > golden rule because they need to put together all these jars possibly > package in some auxiliaries and produce a final deliverable that can be a > war or an ear. Integration projects would then focus not so much on > artefact reuse, but on producing final deliverables. It is for such > projects that this discussion is intended. Amen, brother. :-) Do you and I work for the same company. ;-) > Is there any use in drawing distinction between an integration > project and a standard project? > I think there is and here is an example. I agree. The rest of your example looked good to me. Scott Stirling Framingham, MA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
