maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <michal.mac...@imtf.ch>
Subject RE: dependencies in reactorized builds
Date Mon, 31 Jan 2005 09:35:02 GMT


> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> Sent: Monday, January 31, 2005 7:50 AM
> 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.
> 

Why it would be useful for reactorized builds?

IMO:

a) during the reactor powered builds we know what's the latest version of
any project which is visble for reactor.
   so we could easly have an option (per project) to ignore the version
stated in any pom and use reactor's one.
   So I don't see it as an issue in the context of recatorized builds. It is
rather an issue for "standalone" builds.

b) reactorized builds should be rare for any considerably big project. I
mean that we should rather promote ci tools.
   It doesn't make sense to rebuild entire project if a changes in single
module were made.
   Something simial to what Vincet described here
http://blogs.codehaus.org/people/vmassol/archives/000953_binary_dependency_b
uilds.html
   makes more sense to me for any larger project. That's what we are already
doing with plexus components at the moment and what I am doing at work.
   I am using reactor only for generating web sites and for making
distributions (generally for "aggregation" of information). 
   In the second case (distributions) I am not attempting to build any
artifacts - I am using what already exists in the repository. 
   Note that if builds were made by ci system we could do a lot of "tricks -
e.g. made dual builds:
   - against dependecies stated in the pom 
   - against the latest version visible for ci system. 

   So imo: for large projects reactor is something which is not optimal and
for small project dependencies will be still managebale "by hand".


c) the problem with management of dependencies version exists only because
we don't have good tools 
   for helping to deal with this difficulty (e.g. to upgrade a version of
given dependency in multiple project). 

   

d) (MAIN ISSUE) Project inheritance leads to yet another dependency. If we
are going to change a 
    version of any dependency in the parent pom we still have to upgrade the
version of parent project in all child projects. 
    If we are going to change any dependecy version in any project we have
to increment its version (unless it is in a snaphot state).
    So this will just reduce the amount of work which is needed to keep pom
in sync with development progress, not eliminate
    it completely.  In large projects (and this improvment is supposed to be
useful for project of considerbalr size) this means:
    still __a lot__ of manual work will be needed. I do belive that only c)
can address this issue.


> 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>
> 

[off topic]
I think that the fact that given dependecy should be bundled in the war
should be expressed using "bindTo" semantic.
Simply all runtime dependecies should be bundled in the war. That's why I
suspect that "include/exclude" like semantic for "bindTo" 
will be more appropiate the just "include".




> 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
> 


Michal

Mime
View raw message