You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Loehr, Ruel" <rl...@pointserve.com> on 2008/04/10 15:26:06 UTC
multimodule conversion from maven to ant + ivy
We have a legacy project which is maven based. Everyone hates maven, and we use ivy for other projects, thus, a migration is necessary.
I’d like to keep the existing file structure as is, and simply replace the build scripts. That part is done. I need some help with how to handle the versioning though.
Assume we have a multi module structure:
Root
/a
/b
/c
What I “think” should happen is that in the root directory I define a version.properties file with the version. That version should propogate into each submodule.
The ivy.xml in submodule b will list a dependency like this:
<dependency org="a" name="a" rev="${VERSION}" conf="compile->runtime"/>
This works great as long you check out the root folder and always execute each build from the top level aggregator. However, as we develop in eclipse, people must check out each projects as standalone. Their isn’t a version defined when running in that context.
Has anyone else faced this? How do you handle it? In maven, it works due to the sub builds going to the repository and getting the parent pom…..
R
RE: multimodule conversion from maven to ant + ivy
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
Agreed.
While I can tolerate an entire project being checked out in aggregate, eclipse can't.
I'm trying to understand how to handle that particular situation with ivy and eclipse.
I can check out each module independantly (they each have their own ivy.xml), but really, they are all released together as one 1 unit with 1 version number.
It doesn't make sense for me to have go through each submodule and write in dependency versions by hand. Thus, the notion of the parent aggregator makes a lot of sense (they all belong to the same version).
Has anyone ever gotten something like this to work with ivy?
________________________________________
From: Brown, Carlton [Carlton.Brown@compucredit.com]
Sent: Thursday, April 10, 2008 9:24 AM
To: ivy-user@ant.apache.org
Subject: RE: multimodule conversion from maven to ant + ivy
I personally never really liked the Maven aggregation philosophy, it
seemed like a hack to workaround their strict layout rules (just a way
to allow a module to have multiple artifacts). Ivy gives you a lot
more flexibility in defining your own layout, but you do have to choose
a layout and adhere to it.
If you can tolerate the entire project being checked out in aggregate,
then your aggregate really is a single module, and your modules A, B,
and C are really artifacts (or configurations) of the aggregate module.
If, on the other hand, you wish the modules to behave as distinct
modules, then they need to have their own metadata. I don't think it's
unreasonable to have an ivy.xml for each module and store it in the
source code. After all, the dependency definition is just as much a
distinct build input as your source files themselves.
One consideration is whether private builds will ever publish to a
shared repository. If they don't, then it doesn't really matter what
their version number is. I use a dummy version.properties file which
can get incremented by my Ant build script, and cannot be checked in.
I have an Ivy resolver that publishes private artifacts to a local-only
repository, for consumption on that private machine only. It doesn't
matter if my local machine's version is 0.0.0.99 as long as I have a
local resolver that resolves that version only at the appropriate times.
> -----Original Message-----
> From: Loehr, Ruel [mailto:rloehr@pointserve.com]
> Sent: Thursday, April 10, 2008 10:08 AM
> To: ivy-user@ant.apache.org
> Subject: RE: multimodule conversion from maven to ant + ivy
>
> To get a little more detailed:
>
> In my top level module I have a version.properties which
> defines a MAJOR, MINOR, and REVISION property.
>
> When I call the main build, I have three specific targets:,
> dev, nightly, release.
>
> The dev target constructs a version of 2.0.0-dev. It
> publishes to a local repository.
>
> Nightly constructs a version of 2.0.0-SNAPSHOT. It publishes
> to a public repository.
>
> Release constructs a vesion of 2.0.0. Also publishes to a
> public repository.
>
> 1) Still not sure how handle versioning in sub modules. I
> assume that a submodule can be executed standalone and I
> would like to not hardcode values in for project dependencies.
>
>
> Thoughts?
>
>
> -----Original Message-----
> From: Loehr, Ruel [mailto:rloehr@pointserve.com]
> Sent: Thursday, April 10, 2008 8:26 AM
> To: ivy-user@ant.apache.org
> Subject: multimodule conversion from maven to ant + ivy
>
> We have a legacy project which is maven based. Everyone
> hates maven, and we use ivy for other projects, thus, a
> migration is necessary.
>
>
>
> I'd like to keep the existing file structure as is, and
> simply replace the build scripts. That part is done.
> I need some help with how to handle the versioning though.
>
>
>
> Assume we have a multi module structure:
>
>
>
> Root
>
> /a
>
> /b
>
> /c
>
>
>
> What I "think" should happen is that in the root directory I
> define a version.properties file with the version. That
> version should propogate into each submodule.
>
>
>
> The ivy.xml in submodule b will list a dependency like this:
>
>
>
> <dependency org="a" name="a" rev="${VERSION}"
> conf="compile->runtime"/>
>
>
>
>
>
> This works great as long you check out the root folder and
> always execute each build from the top level aggregator.
> However, as we develop in eclipse, people must check out each
> projects as standalone. Their isn't a version defined when
> running in that context.
>
>
>
> Has anyone else faced this? How do you handle it? In
> maven, it works due to the sub builds going to the repository
> and getting the parent pom.....
>
>
>
> R
>
>
>
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
RE: multimodule conversion from maven to ant + ivy
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
I personally never really liked the Maven aggregation philosophy, it
seemed like a hack to workaround their strict layout rules (just a way
to allow a module to have multiple artifacts). Ivy gives you a lot
more flexibility in defining your own layout, but you do have to choose
a layout and adhere to it.
If you can tolerate the entire project being checked out in aggregate,
then your aggregate really is a single module, and your modules A, B,
and C are really artifacts (or configurations) of the aggregate module.
If, on the other hand, you wish the modules to behave as distinct
modules, then they need to have their own metadata. I don't think it's
unreasonable to have an ivy.xml for each module and store it in the
source code. After all, the dependency definition is just as much a
distinct build input as your source files themselves.
One consideration is whether private builds will ever publish to a
shared repository. If they don't, then it doesn't really matter what
their version number is. I use a dummy version.properties file which
can get incremented by my Ant build script, and cannot be checked in.
I have an Ivy resolver that publishes private artifacts to a local-only
repository, for consumption on that private machine only. It doesn't
matter if my local machine's version is 0.0.0.99 as long as I have a
local resolver that resolves that version only at the appropriate times.
> -----Original Message-----
> From: Loehr, Ruel [mailto:rloehr@pointserve.com]
> Sent: Thursday, April 10, 2008 10:08 AM
> To: ivy-user@ant.apache.org
> Subject: RE: multimodule conversion from maven to ant + ivy
>
> To get a little more detailed:
>
> In my top level module I have a version.properties which
> defines a MAJOR, MINOR, and REVISION property.
>
> When I call the main build, I have three specific targets:,
> dev, nightly, release.
>
> The dev target constructs a version of 2.0.0-dev. It
> publishes to a local repository.
>
> Nightly constructs a version of 2.0.0-SNAPSHOT. It publishes
> to a public repository.
>
> Release constructs a vesion of 2.0.0. Also publishes to a
> public repository.
>
> 1) Still not sure how handle versioning in sub modules. I
> assume that a submodule can be executed standalone and I
> would like to not hardcode values in for project dependencies.
>
>
> Thoughts?
>
>
> -----Original Message-----
> From: Loehr, Ruel [mailto:rloehr@pointserve.com]
> Sent: Thursday, April 10, 2008 8:26 AM
> To: ivy-user@ant.apache.org
> Subject: multimodule conversion from maven to ant + ivy
>
> We have a legacy project which is maven based. Everyone
> hates maven, and we use ivy for other projects, thus, a
> migration is necessary.
>
>
>
> I'd like to keep the existing file structure as is, and
> simply replace the build scripts. That part is done.
> I need some help with how to handle the versioning though.
>
>
>
> Assume we have a multi module structure:
>
>
>
> Root
>
> /a
>
> /b
>
> /c
>
>
>
> What I "think" should happen is that in the root directory I
> define a version.properties file with the version. That
> version should propogate into each submodule.
>
>
>
> The ivy.xml in submodule b will list a dependency like this:
>
>
>
> <dependency org="a" name="a" rev="${VERSION}"
> conf="compile->runtime"/>
>
>
>
>
>
> This works great as long you check out the root folder and
> always execute each build from the top level aggregator.
> However, as we develop in eclipse, people must check out each
> projects as standalone. Their isn't a version defined when
> running in that context.
>
>
>
> Has anyone else faced this? How do you handle it? In
> maven, it works due to the sub builds going to the repository
> and getting the parent pom.....
>
>
>
> R
>
>
>
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
RE: multimodule conversion from maven to ant + ivy
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
To get a little more detailed:
In my top level module I have a version.properties which defines a MAJOR, MINOR, and REVISION property.
When I call the main build, I have three specific targets:, dev, nightly, release.
The dev target constructs a version of 2.0.0-dev. It publishes to a local repository.
Nightly constructs a version of 2.0.0-SNAPSHOT. It publishes to a public repository.
Release constructs a vesion of 2.0.0. Also publishes to a public repository.
1) Still not sure how handle versioning in sub modules. I assume that a submodule can be executed standalone and I would like to not hardcode values in for project dependencies.
Thoughts?
-----Original Message-----
From: Loehr, Ruel [mailto:rloehr@pointserve.com]
Sent: Thursday, April 10, 2008 8:26 AM
To: ivy-user@ant.apache.org
Subject: multimodule conversion from maven to ant + ivy
We have a legacy project which is maven based. Everyone hates maven, and we use ivy for other projects, thus, a migration is necessary.
I'd like to keep the existing file structure as is, and simply replace the build scripts. That part is done. I need some help with how to handle the versioning though.
Assume we have a multi module structure:
Root
/a
/b
/c
What I "think" should happen is that in the root directory I define a version.properties file with the version. That version should propogate into each submodule.
The ivy.xml in submodule b will list a dependency like this:
<dependency org="a" name="a" rev="${VERSION}" conf="compile->runtime"/>
This works great as long you check out the root folder and always execute each build from the top level aggregator. However, as we develop in eclipse, people must check out each projects as standalone. Their isn't a version defined when running in that context.
Has anyone else faced this? How do you handle it? In maven, it works due to the sub builds going to the repository and getting the parent pom.....
R