maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@maven.org>
Subject Re: Merging non-dependency tags in extended project.xml
Date Wed, 29 Dec 2004 01:58:49 GMT
On Tue, 2004-12-28 at 04:50, Milos Kleint wrote:
> 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 popping my head in here to offer a solution that we are using in m2
which takes care of pretty much any static resources. To make a long
story short we've decided to have a standard

${basedir}/src/main/resources

Directory, and within that you layout your resources as you would like
to have them packaged in your final JAR. Might cumbersom at first but
makes all your projects the same and extremely easy for someone to
figure out what resources are going where as the tree in your project
layout is what it is in your JAR.

In m2 there is the notion of a super POM which encapsulates all standard
defaults so in my case for a project with ~100 subprojects one
definition for where resources are works just fine.

But the same practice could apply to m1 where you simply define your
resources section in your parent to be ${basedir}/src/resources and
you're set. Easy to see where the resources are, where they go, and one
definition will work.

> just my 2 cents.
> 
> Milos Kleint 
> 
> 
> 
> On Tue, 28 Dec 2004 06:48:04 -0500, Steven Caswell
> <scaswell@termnetinc.com> 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
> > ><scaswell@termnetinc.com> 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 scaswell@termnetinc.com <mailto:scaswell@termnetinc.com>
> > >>>>
> > >>>><http://www.spreadfirefox.com/?q=affiliates&id=0&t=1>
> > >>>>
> > >>>>---------------------------------------------------------------------
> > >>>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >>>>For additional commands, e-mail: users-help@maven.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >>>For additional commands, e-mail: users-help@maven.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>--
> > >>Steven Caswell scaswell@termnetinc.com <mailto:scaswell@termnetinc.com>
> > >>
> > >><http://www.spreadfirefox.com/?q=affiliates&id=0&t=1>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >>For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> > >
> > >
> > >
> > 
> > --
> > Steven Caswell scaswell@termnetinc.com <mailto:scaswell@termnetinc.com>
> > 
> > <http://www.spreadfirefox.com/?q=affiliates&id=0&t=1>
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
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 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message