|
|
On Mon, 2005-01-31 at 17:42 +0100, Vincent Massol wrote:
> Err... I am in agreement of course (this was exactly my point in my earlier
> musing). I think you misread what I was saying ;-)
Sorry, my bad. I indeed misread what you said.
> Thanks
> -Vincent
>
>
> >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: John Casey [mailto:jdcasey@xxxxxxxxxxxxxx]
> > > > Sent: lundi 31 janvier 2005 07:50
> > > > To: Maven 2 Developers List
> > > > Subject: dependencies in reactorized builds
> > > >
> > > > After talking a bit with jason and brett on IRC, I thought I should
> > send
> > > > out a short summary for others to comment on. I'm not sure what other
> > > > discussion has taken place surrounding this, so please bear with me,
> > and
> > > > let's talk it over. If this email staggers around a bit, I'm sorry;
> > it's
> > > > late here. :)
> > > >
> > > > Basically, at issue is how best to convert the current
> > > > openejb/activemq/geronimo process of specifying a single version of an
> > > > artifact for all builds in the group. Obviously, letting these
> > versions
> > > > remain in a properties file is non-portable and really deals with
> > common
> > > > dependency versioning as a secondary issue in the build. In fact, for
> > > > these and many other projects, it's a primary issue.
> > > >
> > > > The current thinking is that we might use a new element in the POM
> > which
> > > > would provide a set of non-validated dependency specifications. These
> > > > would be non-validated, because we don't want to say that every POM
> > > > extending from the current one must depend on these artifacts.
> > Instead,
> > > > artifacts specified in the <dependencies> section could simply omit
> > all
> > > > but {groupId, artifactId, type} and the rest of the information
> > > > {version, properties, lifecycle bindings, ...} could be looked up in
> > the
> > > > new section.
> > > >
> > > > These defaults wouldn't be resolved as actual dependencies until they
> > > > are used.
> > > >
> > > > Obviously, any sub-project dependency not wishing to inherit this
> > > > information would simply specify the information for itself...if you
> > > > specify <version/> you won't inherit the version from the super-pom's
> > > > defaults. What level of information actually negates the inherited
> > > > information is up for discussion (i.e. do you have to specify
> > > > <properties/> in order to not inherit the default dependency
> > properties?).
> > > >
> > > > In addition to dependencies, this new section could also specify
> > plugin
> > > > properties, lifecycle bindings, and other things. Since it has the
> > > > potential to bloat a POM quite a bit, this section would only be used
> > in
> > > > a reactorized build situation. For something as involved as openejb,
> > > > etc. the gains in portability, etc. would more than make up for the
> > > > additional bloat in the super POM. Also, these defaults sections could
> > > > be layered in at different levels of inheritance for really complex
> > > > reactorized builds.
> > > >
> > > > So, a simplified example of a super POM which only specifies a default
> > > > version for a dependency might look like:
> > > >
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <groupId>mygroup</groupId>
> > > > <artifactId>mygroup-root</artifactId>
> > > > <version>1.0</version>
> > > > <name>MyGroup Root POM</name>
> > > >
> > > > <defaults>
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>commons-jelly</groupId>
> > > > <artifactId>commons-jelly</artifactId>
> > > > <version>1.1</version>
> > > > <type>jar</type>
> > > >
> > > > <!-- additional dependency info -->
> > > > <bindTo>
> > > > <phase>test</phase>
> > > > </bindTo>
> > > > <properties>
> > > > <war.bundle>true</war.bundle>
> > > > </properties>
> > > > </dependency>
> > > > </dependencies>
> > > > </defaults>
> > > > .
> > > > .
> > > > .
> > > > </project>
> > > >
> > > > Then, an extending POM might look like:
> > > >
> > > > <project>
> > > > <modelVersion>4.0.0</modelVersion>
> > > > <parent>
> > > > <groupId>mygroup</groupId>
> > > > <artifactId>mygroup-root</artifactId>
> > > > <version>1.0</version>
> > > > </parent>
> > > >
> > > > <artifactId>mygroup-sub</artifactId>
> > > > <name>MyGroup Sub-Artifact</name>
> > > >
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>commons-jelly</groupId>
> > > > <artifactId>commons-jelly</artifactId>
> > > > <!-- default type is jar.-->
> > > > </dependency>
> > > > </dependencies>
> > > > .
> > > > .
> > > > .
> > > > </project>
> > > >
> > > > Anyway, this is the gist of what we discussed on IRC tonight. Please,
> > > > let's talk about it and see what type of consensus we can reach.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > -john
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason at maven.org
> > http://maven.apache.org
> >
> > believe nothing, no matter where you read it,
> > or who has said it,
> > not even if i have said it,
> > unless it agrees with your own reason
> > and your own common sense.
> >
> > -- Buddha
>
>
> _________________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en franais !
> Yahoo! Mail : http://fr.mail.yahoo.com
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
|
|