You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2006/10/13 17:56:44 UTC

Dependency management

Hi Mina folks,

as I was attending ApacheCon at Austin, I have had many interesting
discussions with some Maven peeps. It's really good to have those guys -
Martin Van Den Bemt, Jason Van Zyll, all theose 'van' something :) - around.

They showed me a very cool feature of Maven called Dependency Management.
The idea is to a void using jars version into leaf projects, but instead
gather all the used number into the top level project. Ok, let's have a
sample :

we have Mina, and we have many sub-projects like Mina-core,
Mina-filter-compression, etc, all of those guys having a pom.xml depending
on the top-level pom.xml. We are using nlog4j-1.2.25 in almost all the jars,
commons-xxxx in many of those sub-projects, etc. So what we should do is to
declare those dependencies in all the pom.xml, but remove the version number
in all of them, and add a list of dependencies in the top level project with
the vesion, like that :
<dependencyManagement>
   <dependencies>
     <dependency>
      <groupId>antlr</groupId>
      <artifactId>antlr</artifactId>
      <version>2.7.2</version>
    </dependency>
    <dependency>
      <groupId>backport-util-concurrent</groupId>
      <artifactId>backport-util-concurrent</artifactId>
      <version>2.1</version>
    </dependency>
...

</dependencyManagmenent>

and in, let's say, mina-filter-compression pom.xml, we will have that :

...
  <dependencies>

    <dependency>
      <groupId>org.apache.mina</groupId>
      <artifactId>mina-core</artifactId>
      <version>${pom.version}</version>
    </dependency>

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
      <!--version>1.0</version-->                 !!!! Note that I commented
the version here
      <scope>provided</scope>
    </dependency>

What is this good for? It helps us saving time when we have to bump up a new
version of a jar. For instance, nlog4j is used in almsot all sub-poject, so
when we go to 1.2.19 to 1.2.25, it takes a hell of time changing 40
subprojects pom.xml. And it's error prone. Instead of doing that, with
dependency managment, we just have to change one single file.

So, question : what do you think about adopting this technic in Mina ? (the
top level pom.xml will be the MINA ones). It can also be used to bump up
MINA version when a new release is created.

Just tell me, I can do the modification.

Emmanuel Lécharny

-- 
Cordialement,
Emmanuel Lécharny

Re: Dependency management

Posted by Mike Grundvig <mi...@electrotank.com>.
I've used this with Maven before successfully. It makes cross-project 
dependency management much simpler and less error prone.

Michael Grundvig
Electrotank, Inc
http://www.electrotank.com


----- Original Message ----- 
From: "Emmanuel Lecharny" <el...@gmail.com>
To: <mi...@directory.apache.org>
Sent: Friday, October 13, 2006 10:56 AM
Subject: Dependency management


Hi Mina folks,

as I was attending ApacheCon at Austin, I have had many interesting
discussions with some Maven peeps. It's really good to have those guys -
Martin Van Den Bemt, Jason Van Zyll, all theose 'van' something :) - around.

They showed me a very cool feature of Maven called Dependency Management.
The idea is to a void using jars version into leaf projects, but instead
gather all the used number into the top level project. Ok, let's have a
sample :

we have Mina, and we have many sub-projects like Mina-core,
Mina-filter-compression, etc, all of those guys having a pom.xml depending
on the top-level pom.xml. We are using nlog4j-1.2.25 in almost all the jars,
commons-xxxx in many of those sub-projects, etc. So what we should do is to
declare those dependencies in all the pom.xml, but remove the version number
in all of them, and add a list of dependencies in the top level project with
the vesion, like that :
<dependencyManagement>
   <dependencies>
     <dependency>
      <groupId>antlr</groupId>
      <artifactId>antlr</artifactId>
      <version>2.7.2</version>
    </dependency>
    <dependency>
      <groupId>backport-util-concurrent</groupId>
      <artifactId>backport-util-concurrent</artifactId>
      <version>2.1</version>
    </dependency>
...

</dependencyManagmenent>

and in, let's say, mina-filter-compression pom.xml, we will have that :

...
  <dependencies>

    <dependency>
      <groupId>org.apache.mina</groupId>
      <artifactId>mina-core</artifactId>
      <version>${pom.version}</version>
    </dependency>

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
      <!--version>1.0</version-->                 !!!! Note that I commented
the version here
      <scope>provided</scope>
    </dependency>

What is this good for? It helps us saving time when we have to bump up a new
version of a jar. For instance, nlog4j is used in almsot all sub-poject, so
when we go to 1.2.19 to 1.2.25, it takes a hell of time changing 40
subprojects pom.xml. And it's error prone. Instead of doing that, with
dependency managment, we just have to change one single file.

So, question : what do you think about adopting this technic in Mina ? (the
top level pom.xml will be the MINA ones). It can also be used to bump up
MINA version when a new release is created.

Just tell me, I can do the modification.

Emmanuel Lécharny

-- 
Cordialement,
Emmanuel Lécharny



Re: Dependency management

Posted by Emmanuel Lecharny <el...@gmail.com>.
Trustin Lee a écrit :

> Thanks for the heads up, Emmanuel.  I'm not sure we will benefit from 
> this
> feature because we might merge all subprojects into one big fat 
> project with
> 'provided' dependencies.  Of course we need some discussion.

Ok. If you do that, then the proposal is useless.

In which version do you intend to merge all those sub-projects? 2.0 ?

Emmanuel

Re: Dependency management

Posted by Trustin Lee <tr...@gmail.com>.
Thanks for the heads up, Emmanuel.  I'm not sure we will benefit from this
feature because we might merge all subprojects into one big fat project with
'provided' dependencies.  Of course we need some discussion.

Trustin

On 10/14/06, Emmanuel Lecharny <el...@gmail.com> wrote:

> Hi Mina folks,
>
> as I was attending ApacheCon at Austin, I have had many interesting
> discussions with some Maven peeps. It's really good to have those guys -
> Martin Van Den Bemt, Jason Van Zyll, all theose 'van' something :) -
> around.
>
> They showed me a very cool feature of Maven called Dependency Management.
> The idea is to a void using jars version into leaf projects, but instead
> gather all the used number into the top level project. Ok, let's have a
> sample :
>
> we have Mina, and we have many sub-projects like Mina-core,
> Mina-filter-compression, etc, all of those guys having a pom.xml depending
> on the top-level pom.xml. We are using nlog4j-1.2.25 in almost all the
> jars,
> commons-xxxx in many of those sub-projects, etc. So what we should do is
> to
> declare those dependencies in all the pom.xml, but remove the version
> number
> in all of them, and add a list of dependencies in the top level project
> with
> the vesion, like that :
> <dependencyManagement>
>   <dependencies>
>     <dependency>
>      <groupId>antlr</groupId>
>      <artifactId>antlr</artifactId>
>      <version>2.7.2</version>
>    </dependency>
>    <dependency>
>      <groupId>backport-util-concurrent</groupId>
>      <artifactId>backport-util-concurrent</artifactId>
>      <version>2.1</version>
>    </dependency>
> ...
>
> </dependencyManagmenent>
>
> and in, let's say, mina-filter-compression pom.xml, we will have that :
>
> ...
> <dependencies>
>
>    <dependency>
>      <groupId>org.apache.mina</groupId>
>      <artifactId>mina-core</artifactId>
>      <version>${pom.version}</version>
>    </dependency>
>
>    <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>slf4j-simple</artifactId>
>      <!--version>1.0</version-->                 !!!! Note that I
> commented
> the version here
>      <scope>provided</scope>
>    </dependency>
>
> What is this good for? It helps us saving time when we have to bump up a
> new
> version of a jar. For instance, nlog4j is used in almsot all sub-poject,
> so
> when we go to 1.2.19 to 1.2.25, it takes a hell of time changing 40
> subprojects pom.xml. And it's error prone. Instead of doing that, with
> dependency managment, we just have to change one single file.
>
> So, question : what do you think about adopting this technic in Mina ?
> (the
> top level pom.xml will be the MINA ones). It can also be used to bump up
> MINA version when a new release is created.
>
> Just tell me, I can do the modification.
>
> Emmanuel Lécharny
>
> --
> Cordialement,
> Emmanuel Lécharny
>
>


-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6