On 8/28/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> On 8/29/05, dan tran <[EMAIL PROTECTED]> wrote:
> > For example:
> >
> > <parent>
> > <groupId>parentgroupid<groupId>
> > <artifactId>parentid</artifactId>
> > <version>${my.version}</version>
> > </parent>
>
> This won't work without specifying my.version in every POM (you need
> to know what the parent is to find the value of my.version in the
> parent).
Agree that I need to specify <version>${my.version} in every pom.
>
> > <dependencies>
> > <dependency>
> > <groupId>parentgroupid<groupId>
> > <artifactId>parentid</artifactId>
> > <version>${my.version}</version>
> > </dependency>
> > </dependencies>
>
> You can achieve this with <dependencyManagement/> in the root POM. You
> can already use ${version} there to use the current version.
I am currently place all possible external artifacts and internal
build artifacts under dependencyManagement. however, for every new
created sub project, the developer will need to remember to add
his/her artifact's dependencyMangement at the root level. This can
create repeated confusion that I hope to avoid.
In my dependencyManagement section, I also have other external projects that
have many artifacts using their own version for every artifact. So the property
reuse would help here.
But reuse of ${version} at the root pom is a big help here specially for
developer. Big plus!!!!!
>
> >
> > This will help tremendously interm usabitlity where can just
> > modify my
> > root pom and cut a new release without going to every sub project
> > to change the version numbers and deal with SCM.
> >
>
> We plan to look at not requiring a parent version and doing some
> intelligent discovery of the parent. It was controversial so it may or
> may not go ahead.
I saw the JIRA for this issue. It think it only works well when the
user has entired source tree on his/her local space where M2 can
traverse up all the way to the root pom in file system.
For now, I will need to write a custom plugin to traverse to all sub poms
checkout (clearcase term) to make each pom writeable, change
the parent pom version, and checkin the pom.xml for each new release
( we do new release daily)
>
> > In parent pom i can have
> >
> > <properties>
> > <otherprojectincludepath>
> > ${basedir}/../../licencemanager/src/main/h
> > </otherprojectincludepath>
> > many more....
> > </properties>
>
> Why can't you just inherit the plugin configuration for this? Also,
> this won't work if the paths aren't exactly ../...
Like you say, there are many cases, where I can reuse a property expression in
a bunch of configurations
for example
${somepath}/windows for windows build
${somepath}/linux for linux build
Inherit configuration wont help here.
>
> > Other plugins can benefit this as well. For example multiple plugins can
> > reused
> > ${finalName} expression in their builds configuration
>
> That already works - ${build.finalName}
>
Cool, it is new to me. My appology for missing this.
> > Is it possible in term of M2 architecture?
>
> Certainly, but I don't think it is necessary...
>
> Cheers,
> Brett
>
Thanks for the feedback.
-Dan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
