Grokbase Groups Maven users May 2003
FAQ
Hi,

Description of Issue:

Our overall project has lots of maven sub-projects (in the area of
300+). We have multi-level directory structures like:

Dev/
_ xxx
_ dir1
_ p1
_ yyy
_ dir2
_ p2
We would like to share the dependencies definition (more specifically
the version of dependencies) between projects. Imagine: when we move
from log4j 1.2.6 to 1.2.8 we need to change everywhere and invariably it
is changed only in some projects and not in others.

Possible solutions:

S1/ use the <extend> tag and factorize dependencies. However this is not
possible (because there are no common dependencies and that would mean
several levels of <extend> which is currently not supported by Maven but
moreover it doesn't help as p1 and p2 may both need to use say dbunit
but not p3, p4, etc.

S2/ use properties put in build.properties such as log4j.jar.version =
1.2.6 and then in project.xml use
<version>${log4j.jar.version}</version>

ATM we are using solution S2 as it is the only one available.

However, I don't find an elegant solution. Basically it means Maven is
not supporting this use case and we're finding a way around. I do think
there's a need to be able to share dependencies between project in a not
hierarchical way...

Musing:

Wouldn't it be possible to support in maven either a global
dependencies.xml file or the ability to add dependency *definitions*
(i.e. not used). For example:

<dependencyDefinitions>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.6</version>
</dependency>
[...]
</dependencyDefinitions>

And then in your project.xml you could write:

<dependencies>
<dependency>
<refid>log4j:log4j</refid>
</dependency>
[...]
</dependencies>

or something similar.

And/or

<dependencyExtend>../../whatever/dependencies.xml</dependencyExtend>

<dependencies>
<dependency>
<refid>log4j:log4j</refid>
</dependency>
[...]
</dependencies>

That would allow sharing dependency informations easily between
different projects.

I guess the need doesn't seem obvious until you get to manage 300+
sub-projects all part of a global project.

Comments?

Thanks
-Vincent


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

Search Discussions

  • Paulo Silveira at May 7, 2003 at 6:29 am
    Hello!

    I ve just updated my maven-10 to todays snapshot, and I ve got this:

    ==============
    Attempting to download mail-1.3.jar.
    ...
    Error retrieving artifact from [
    http://www.ibiblio.org/maven/mail/jars/mail-1.3
    .jar]: java.lang.Exception: Can't get mail-1.3.jar.incomplete to
    C:\Documents an
    d Settings\bugs\.maven\repository\mail\jars\mail-1.3.jar.incomplete
    Attempting to download hibernate-1.2.jar.
    =================

    Ok, of course we dont have mail.jar in ibiblio, but I have it in my
    other repository configured at maven.properies. It seems that maven is
    simply ignoring it, since it failed at the first try.

    My other repository is: file://${basedir}/localRepository, and it was
    working just fine.

    Any hints? Bug?

    ------------------------
    Paulo Silveira
    http://www.paulo.com.br/
    http://www.guj.com.br/




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Henri Yandell at May 7, 2003 at 1:15 pm
    Make sure the ibiblio is the last one in your list. I seem to recall that
    repo=serverA,ibiblio,serverB was stopping serverB from working for me in
    b7 or b9.

    If those were working for you and you've not recently changed it repo,
    I've no clue :)

    Hen
    On Wed, 7 May 2003, Paulo Silveira wrote:

    Hello!

    I ve just updated my maven-10 to todays snapshot, and I ve got this:

    ==============
    Attempting to download mail-1.3.jar.
    ...
    Error retrieving artifact from [
    http://www.ibiblio.org/maven/mail/jars/mail-1.3
    .jar]: java.lang.Exception: Can't get mail-1.3.jar.incomplete to
    C:\Documents an
    d Settings\bugs\.maven\repository\mail\jars\mail-1.3.jar.incomplete
    Attempting to download hibernate-1.2.jar.
    =================

    Ok, of course we dont have mail.jar in ibiblio, but I have it in my
    other repository configured at maven.properies. It seems that maven is
    simply ignoring it, since it failed at the first try.

    My other repository is: file://${basedir}/localRepository, and it was
    working just fine.

    Any hints? Bug?

    ------------------------
    Paulo Silveira
    http://www.paulo.com.br/
    http://www.guj.com.br/




    ---------------------------------------------------------------------
    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
  • Emmanuel Venisse at May 7, 2003 at 8:49 am
    Hi Vincent,

    You can override dependencies stated in the pom by define some properties in
    your ${user.home}/build.properties.

    http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Dependencies

    Emmanuel

    ----- Original Message -----
    From: "Vincent Massol" <vmassol@pivolis.com>
    To: <users@maven.apache.org>
    Sent: Wednesday, May 07, 2003 8:06 AM
    Subject: [Musing] Sharing dependency definitions

    Hi,

    Description of Issue:

    Our overall project has lots of maven sub-projects (in the area of
    300+). We have multi-level directory structures like:

    Dev/
    _ xxx
    _ dir1
    _ p1
    _ yyy
    _ dir2
    _ p2
    We would like to share the dependencies definition (more specifically
    the version of dependencies) between projects. Imagine: when we move
    from log4j 1.2.6 to 1.2.8 we need to change everywhere and invariably it
    is changed only in some projects and not in others.

    Possible solutions:

    S1/ use the <extend> tag and factorize dependencies. However this is not
    possible (because there are no common dependencies and that would mean
    several levels of <extend> which is currently not supported by Maven but
    moreover it doesn't help as p1 and p2 may both need to use say dbunit
    but not p3, p4, etc.

    S2/ use properties put in build.properties such as log4j.jar.version =
    1.2.6 and then in project.xml use
    <version>${log4j.jar.version}</version>

    ATM we are using solution S2 as it is the only one available.

    However, I don't find an elegant solution. Basically it means Maven is
    not supporting this use case and we're finding a way around. I do think
    there's a need to be able to share dependencies between project in a not
    hierarchical way...

    Musing:

    Wouldn't it be possible to support in maven either a global
    dependencies.xml file or the ability to add dependency *definitions*
    (i.e. not used). For example:

    <dependencyDefinitions>
    <dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.6</version>
    </dependency>
    [...]
    </dependencyDefinitions>

    And then in your project.xml you could write:

    <dependencies>
    <dependency>
    <refid>log4j:log4j</refid>
    </dependency>
    [...]
    </dependencies>

    or something similar.

    And/or

    <dependencyExtend>../../whatever/dependencies.xml</dependencyExtend>

    <dependencies>
    <dependency>
    <refid>log4j:log4j</refid>
    </dependency>
    [...]
    </dependencies>

    That would allow sharing dependency informations easily between
    different projects.

    I guess the need doesn't seem obvious until you get to manage 300+
    sub-projects all part of a global project.

    Comments?

    Thanks
    -Vincent


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

    _____________________________________________________________________
    Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
    http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France
    _____________________________________________________________________
    Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
    http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Vincent Massol at May 7, 2003 at 12:03 pm
    Yes, sure but it doesn't help me... I think it's actually even worse
    that using the properties solution

    BTW, the properties solution does not work when you're using the reactor
    (which we are) as properties are not inherited!

    Thanks
    -Vincent
    -----Original Message-----
    From: Emmanuel Venisse
    Sent: 07 May 2003 10:46
    To: Maven Users List
    Subject: Re: [Musing] Sharing dependency definitions

    Hi Vincent,

    You can override dependencies stated in the pom by define some
    properties
    in
    your ${user.home}/build.properties.

    http://maven.apache.org/reference/user-
    guide.html#Overriding%20Stated%20Dependencies

    Emmanuel

    ----- Original Message -----
    From: "Vincent Massol" <vmassol@pivolis.com>
    To: <users@maven.apache.org>
    Sent: Wednesday, May 07, 2003 8:06 AM
    Subject: [Musing] Sharing dependency definitions

    Hi,

    Description of Issue:

    Our overall project has lots of maven sub-projects (in the area of
    300+). We have multi-level directory structures like:

    Dev/
    _ xxx
    _ dir1
    _ p1
    _ yyy
    _ dir2
    _ p2
    We would like to share the dependencies definition (more
    specifically
    the version of dependencies) between projects. Imagine: when we move
    from log4j 1.2.6 to 1.2.8 we need to change everywhere and
    invariably it
    is changed only in some projects and not in others.

    Possible solutions:

    S1/ use the <extend> tag and factorize dependencies. However this is
    not
    possible (because there are no common dependencies and that would
    mean
    several levels of <extend> which is currently not supported by Maven
    but
    moreover it doesn't help as p1 and p2 may both need to use say
    dbunit
    but not p3, p4, etc.

    S2/ use properties put in build.properties such as log4j.jar.version
    =
    1.2.6 and then in project.xml use
    <version>${log4j.jar.version}</version>

    ATM we are using solution S2 as it is the only one available.

    However, I don't find an elegant solution. Basically it means Maven
    is
    not supporting this use case and we're finding a way around. I do
    think
    there's a need to be able to share dependencies between project in a
    not
    hierarchical way...

    Musing:

    Wouldn't it be possible to support in maven either a global
    dependencies.xml file or the ability to add dependency *definitions*
    (i.e. not used). For example:

    <dependencyDefinitions>
    <dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.6</version>
    </dependency>
    [...]
    </dependencyDefinitions>

    And then in your project.xml you could write:

    <dependencies>
    <dependency>
    <refid>log4j:log4j</refid>
    </dependency>
    [...]
    </dependencies>

    or something similar.

    And/or

    <dependencyExtend>../../whatever/dependencies.xml</dependencyExtend>

    <dependencies>
    <dependency>
    <refid>log4j:log4j</refid>
    </dependency>
    [...]
    </dependencies>

    That would allow sharing dependency informations easily between
    different projects.

    I guess the need doesn't seem obvious until you get to manage 300+
    sub-projects all part of a global project.

    Comments?

    Thanks
    -Vincent

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
    _____________________________________________________________________
    Envie de discuter en "live" avec vos amis ? Télécharger MSN
    Messenger
    http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de
    France
    _____________________________________________________________________
    Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
    http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

    ---------------------------------------------------------------------
    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
  • Jeffrey D. Brekke at May 7, 2003 at 4:42 pm

    On Wed, 7 May 2003 14:03:04 +0200, "Vincent Massol" <vmassol@pivolis.com> said:
    Yes, sure but it doesn't help me... I think it's actually even worse
    that using the properties solution
    BTW, the properties solution does not work when you're using the
    reactor (which we are) as properties are not inherited!
    I belive the jar override feature is working when using the reactor,
    but only with the reactor. I have/had committed test cases showing
    this. For example:

    Main project
    project.properties <--- jar override=on in here
    project.xml <--- extended project file, no deps listed.
    P1/
    project.xml <--- extends parent and define dependencies with just name, no version
    P2/
    project.xml

    You can build with the reactor and all jar versions defined in the
    main project.properties, but you can't currently build P2 by cd'ing
    into P2 and calling maven since the properties are not inheirited.

    I'd like a solution to this issue also, we have many subprojects I'd
    like to build with maven ( not 300+ though! ) and just can't ask our
    users to maintain the versions in each individual project, its like a
    step backwards.

    As as aside, how are you building sites with maven and that many
    projects? I always get an out of memory when using the reactor and
    attempting to generate the sites/docs.

    --
    =====================================================================
    Jeffrey D. Brekke jbrekke@wi.rr.com
    Wisconsin, USA brekke@apache.org
    ekkerbj@yahoo.com


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Vincent Massol at May 8, 2003 at 7:46 am

    -----Original Message-----
    From: Jeffrey D. Brekke
    Sent: 07 May 2003 18:42
    To: Maven Users List
    Subject: Re: [Musing] Sharing dependency definitions [snip]
    As as aside, how are you building sites with maven and that many
    projects? I always get an out of memory when using the reactor and
    attempting to generate the sites/docs.
    Quick answer: we don't as we also have that memory leak error (note that
    we have 1GB of memory!). In fact we are using the following workaround:
    for each project we start a new JVM and build the site in that JVM. It's
    awfully slow so we only run this once at night whereas we run the
    "normal" build every 2 hours.

    Here is our script snippet we have in our maven.xml if it helps:

    <goal name="xxx:site" description="Build all xxx project sites">

    <!-- WARNING: Due to Maven memory leak problems, we are momentarily
    spawning a new maven process for each site build. This is
    achieved
    by introducing a new xxx:site-singleproject goal which spawns a
    maven process. Normally we would use the "site" goal.
    -->

    <maven:reactor
    basedir="${basedir}"
    includes="**/project.xml"

    excludes="project.xml,**/Prototype/**/project.xml,**/IDEProjects/**/proj
    ect.xml"
    goals="xxx:site-singleproject"
    banner="Building"
    ignoreFailures="true"
    postProcessing="true"
    />
    </goal>

    <goal name="xxx:site-singleproject">
    <copy todir="${basedir}">
    <fileset dir="${xxx.root.dir}/Development/xxx">
    <include name="project.properties"/>
    </fileset>
    </copy>
    <exec
    executable="${maven.home}/bin/maven.bat"
    failonerror="true">
    <arg value="-f"/>
    <arg value="${basedir}/project.xml"/>
    <arg value="site"/>
    </exec>
    <delete file="${basedir}/project.properties"/>
    </goal>

    Note that we have to copy the main project.properties file as properties
    are not inherited...

    -Vincent



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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmaven
postedMay 7, '03 at 6:06a
activeMay 8, '03 at 7:46a
posts7
users5
websitemaven.apache.org
irc#maven

People

Translate

site design / logo © 2019 Grokbase