Message meant for the list, Brett your reply-to points to you :-) -- jvz.
Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
--- Begin Message ---On Tue, 2004-10-19 at 08:32, Brett Porter wrote: > I'll start by rounding up thoughts, with specific answer below to the > last email. > > Let me sum up where I think we're at here: > - artifact separation. We've talked about this on the maven and m2-dev > lists a lot in the last 6 months and thinking through all the issues > concluded that one project = one artifact makes sense, and that we just > need to make project creation simple. I don't think we should go over > that again. > - final name properties. > * Strongly disagree with the addition of maven.jar.final.name. > * Strongly agree that maven.final.name should represent the primary > artifact output for the project > * In the instance where a secondary artifact is made (ejb-client), I > have no problem with an additional "final name" property for that artifact > * for the already existing properties such as maven.war.final.name, I > think we should work to deprecate them while remaining backwards compatible > * For the specific instance of the war output - it should be moved to > include the version, but keeping the deprecated backwards compat > generation of pom.artifactId only named artifact. A FAQ should be created. > * None of this affects the filename in the repository > > Are there any points on which we still disagree? Is there anyone else on > the list that disagrees? That sounds good. As long as the artifact goes into the repository in standard maven form it's all good. If the copy with a different name locally provides convenience that's great. Has the WAR always gone into the repository in the standard maven form? If so then this certainly isn't a dire situation. The small nit being the superfluous use of properties other than maven.final.name. > Felipe Leme wrote: > > >On Tue, 2004-10-19 at 02:53, Brett Porter wrote: > > > > > > > >><Context docRoot="/home/bporter/cvs/.../target/foo.war"> > >> > >>Convenient :) > >> > >> > > > >As I said, you need to update the war (ok, you could usen maven console > >for that, but it's not the same). What about: > > > ><Context docRoot="/home/bporter/cvs/.../${maven.war.src"> > > > >(+ a maven.xml goal that copies all the dependencies on WEB-INF/lib and > >maven.compile.target=${maven.war.src}/WEB-INF/class) > > > > > That would be maven war:inplace. But we digress :) > > >>But it -should- be true. Now the plugin has to guess whether to use > >>maven.jar.final.name, maven.war.final.name, etc (sometimes - as for cactus - > >>this is contextual, sometimes not). > >> > >> > > > >No, it will use maven.jar.final.name or maven.war.final.name, depending > >on that it needs the artifact for. > > > That's contextual, but as I think you say next, you don't always know. > > >Besides, maven.final.name would > >suffice, as the plugin wouldn't have a reliable way (except of > >maven.multiproject.type, if I'm now wrong) to know the artifact's > >extension. > > > > > This is right - you need to know what the single build artifact is, and > that should be {maven.final.name}.jar > > > > > > >>I would like to think we could reach consensus or compromise on design issues, > >>not need a vote. So let's keep talking it through. > >> > >> > > > >Ok, agreed. By speaking of design issues, I'm fine about pushing the > >'one artifact per project Maven way', but we should allow users to make > >some exceptions for that rule. For instance, in many circumstances a > >project might need to build a 'primary' artifact and many 'secondary' > >ones, so Maven should support it (without requiring the multi-project > >hell). One such situation is where a project's main artifact is a jar, > >but it also provides a war to test it and maybe another with > >documentation (that would be the case for all Jakarta Taglibs, for > >example). > > > > > Another war with documentation? site:war? A documentation artifact is a > valid secondary artifact, whatever the format. > > I don't believe this is the right way to go for the others - it is > unneeded complexity. examples subproject, test harness subproject that > depend on the original are better. > > Yes, secondary artifacts are needed but they are just that - secondary. > > >BTW, I have discussed this case on Jira and in the users list, but we > >haven't reached any consensus yet: > > > >http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=875047 > >http://jira.codehaus.org/browse/MPWAR-30 > > > > > > > Your argument against what I've said is it is overkill. Making a new pom > is a piece of cake, and it nicely separates things out and they both do > one thing, and do it the same as for anything else. > > Under your scenario, what happens in a multiproject build when you hit > the taglib? Does it build a jar or a war? both? what tests does it run? > > >So, what do you think about this situation in particular, would the > >change make sense or it would be against the design issues? > > > > > Cheers, > Brett > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
--- End Message ---
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
