there's one drawback to merging the resources part of the pom. And that's probably a general issue. When stuff is merged, one doesn't have a possibility to exclude something from the parent definition that doesn't apply to this particular project. So when one has 10 projects that share a common resource definition, having it in the parent makes sense, then when the 11th project comes along and needs to override the value, I just modify the 11th project resource section of the pom. With merged resources, I need to create a new level of abstraction, creating a new general pom, and change extend tags.
just my 2 cents. Milos Kleint On Tue, 28 Dec 2004 06:48:04 -0500, Steven Caswell <[EMAIL PROTECTED]> wrote: > Would you mind terribly if I file a JIRA enhancement request if there > isn't one already (I looked around and didn't see one)? > > <my $0.2> > A team that takes the approach of splitting development up into small > subproject chunks needs this feature. The more things are split up, the > more cumbersome it becomes to duplicate the shared resources sections. > Forcing this begins to defeat the purpose of subproject inheritance and > puts up a barrier to adoption. The age-old argument of "put it in one > place" certainly applies here. > </my $.02> > > Thanks. > > Brett Porter wrote: > > >You're correct, resources and unit test include/exclude patterns are > >not inherited. To introduce this would also require a way to > >enable/disable inheritance. > > > >Because resource sections are typically very small, reproducing them > >in the children so you get a single view should not be too cumbersome. > > > >I'm not sure whether we will decide to change this in the future at > >this point, but will keep it in mind. > > > >Cheers, > >Brett > > > > > >On Mon, 27 Dec 2004 07:22:27 -0500, Steven Caswell > ><[EMAIL PROTECTED]> wrote: > > > > > >>Brett Porter wrote: > >> > >> > >> > >>>>Is it still true in maven 1.0.2 when a project.xml is extended, only the > >>>>dependencies are merged, and other tags, such as build, are overriden? > >>>> > >>>> > >>>> > >>>> > >>>No. The only things that aren't merged are lists. Dependencies is the > >>>list that is merged. > >>>http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/java/org/apache/maven/project/Project.java?rev=122478&view=markup > >>>(see mergeParent) > >>> > >>> > >>> > >>> > >>> > >>Sorry if I'm being dense, but I'm not able to tell from the source if > >>something like resources under build/unitTest is merged, but from the > >>behavior I'm seeing it looks like it isn't. > >> > >> > >> > >>>>If it is still true, are there any plans to merge other tags in a future > >>>>release? > >>>> > >>>> > >>>> > >>>> > >>>Which particulary elements do you think it makes sense for? > >>> > >>>- Brett > >>> > >>> > >>> > >>> > >>> > >>Things like resources, source modifications, etc. that a subproject > >>might need to provide additional entries for. In my case I have a parent > >>project.xml that includes resources in the unit test element: > >> > >> <build> > >> <unitTest> > >> <resources> > >> <resource> > >> <directory>src/test/resources</directory> > >> <targetPath>resources</targetPath> > >> <includes> > >> <include>**/*.*</include> > >> </includes> > >> </resource> > >> <resource> > >> <directory>${basedir}/../resources</directory> > >> <includes> > >> <include>log4j-sample.properties</include> > >> <include>beanRefFactory.xml</include> > >> <include>aspectwerkz.xml</include> > >> </includes> > >> </resource> > >> <resource> > >> <directory>${basedir}/../resources/context</directory> > >> <targetPath>context</targetPath> > >> <includes> > >> <include>**/*.*</include> > >> </includes> > >> </resource> > >> </resources> > >> </unitTest> > >> </build> > >> > >>Then in a subproject, I need to add additional resources for just that > >>subproject, keeping those specified in the parent project.xml: > >> > >> <build> > >> <unitTest> > >> <resources> > >> <resource> > >> <directory>../interface/target/test-classes</directory> > >> <targetPath></targetPath> > >> <includes> > >> <include>**/*.class</include> > >> </includes> > >> </resource> > >> </resources> > >> </unitTest> > >> </build> > >> > >>The behavior I'm seeing is that the subproject overrides the resources, > >>rather than merge them. I'd like to have them merged so that I can add > >>specific subproject resources without having to redefine what is in the > >>parent. Perhaps there could be some way for me to tell maven whether I > >>want to override the parent vs. adding to the parent. > >> > >> > >> > >>>>TIA > >>>>-- > >>>>Steven Caswell [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>>> > >>>><http://www.spreadfirefox.com/?q=affiliates&id=0&t=1> > >>>> > >>>>--------------------------------------------------------------------- > >>>>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] > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>-- > >>Steven Caswell [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >> > >><http://www.spreadfirefox.com/?q=affiliates&id=0&t=1> > >> > >>--------------------------------------------------------------------- > >>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] > > > > > > > > > > > > -- > Steven Caswell [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > <http://www.spreadfirefox.com/?q=affiliates&id=0&t=1> > > --------------------------------------------------------------------- > 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]
