Keep the TLP pom slim and used just for TLP information.  Do not stuff in
project specific plugin versions since some projects under Directory might
be stuck to using a specific version of a plugin due to some bug etc. 

If a new project foo is created and foo does not use any of the maven plugins
you listed in the TLP pom then these declarations will still be loaded and
inherited.  Of course the foo pom can override these versions if it uses those
plugins but why parse and include these versions in the TLP pom?

If we had 10-15 projects I can see the value of it to prevent duplication which
might occur on a greater scale but I don't see this for 3 projects.

Alex

On 8/22/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> I'm not sure what your reasoning is here.  shared and apacheds and
> daemon all use org.apache.directory.project:project:7:pom as their
> parent so I thought it would be useful to move the
> dependencyManagement and pluginManagement for "core" dependencies/
> plugins that all those use into the parent to reduce duplication.  I
> haven't looked to see if studio uses the same parent or not, but I
> would think it would be a good idea if it did.  I'm planning to
> change my copy of triplesec to use it.

What if someone just svn co shared, without the parent pom  ? Someone
might want to build shared without anything else, and even avoiding to
download the root pom.xml . This is a valid operation as soon as you
don't push dependencies versions in this pom.xml.

This is one of the reasons why we keep them in apacheds, shared and daemon.

Does it make sense ?

>
> thanks
> david jencks
>
> >
> > Emmanuel
> >
> > On 8/22/07, David Jencks <david_jencks@yahoo.com> wrote:
> >> My xbean-spring patches move to spring 2.0.5 with no apparent
> >> problems. So, hint hint hint, maybe someone can review DIRSERVER-1023
> >> (which also contains the xbean-spring changes) and I could apply
> >> them?
> >>
> >> I think you missed the "project" pom.  I think it would be a good
> >> idea to move some of the base dependencies such as maven plugin
> >> versions into that and release a version 8.
> >>
> >> thanks
> >> david jencks
> >>
> >> On Aug 22, 2007, at 6:18 AM, Emmanuel Lecharny (JIRA) wrote:
> >>
> >>> Upgrading dependencies and maven plugins
> >>> ----------------------------------------
> >>>
> >>>                  Key: DIRSERVER-1028
> >>>                  URL: https://issues.apache.org/jira/browse/
> >>> DIRSERVER-1028
> >>>              Project: Directory ApacheDS
> >>>           Issue Type: Task
> >>>     Affects Versions: 1.5.0
> >>>             Reporter: Emmanuel Lecharny
> >>>              Fix For: 1.5.1
> >>>
> >>>
> >>> Here is a list of dependencies and maven plugins version we are
> >>> using compared to the current version (first number is the last
> >>> version, second number is the version we are using). We should
> >>> consider upgrading the versions of all those dependencies.
> >>>
> >>> apacheds
> >>>       mina-core       1.1.2   1.0.3
> >>>       mina-filter-ssl 1.1.2   1.0.3
> >>>       commons-io      1.3.2   1.3.1
> >>>       commons-collections     3.2     3.2
> >>>       commons-daemon  1.0.1   1.0.1
> >>>       commons-lang    2.3     2.3
> >>>       commons-cli     1.1      1.0
> >>>       commons-dbcp    1.2.2   1.2.2
> >>>       commons-pool    1.3     1.3
> >>>       jcl104-over-slf4j       1.4.3   1.4.0
> >>>       slf4j-api       1.4.3   1.4.0
> >>>       nlog4j  1.2.25  1.2.25
> >>>       jdbm    1.0     1.0
> >>>       velocity-dep    1.5     1.4.0
> >>>       antlr   2.7.7   2.7.7
> >>>       junit   4.4     3.8.1
> >>>       quartz  1.6.0   1.5.1
> >>>       jug-asl 2.0.0   2.0.0
> >>>       derby   10.3.1.4        10.2.2.0
> >>>       spring-core     2.0.6   1.2.9
> >>>       spring-beans    2.0.6   1.2.9
> >>>       spring-context  2.0.6   1.2.9
> >>>       maven-plugin-api         2.0.7   2.0.6
> >>>       maven-project   2.0.7   2.0.6
> >>>       maven-archiver  2.2     2.0.5
> >>>       plexus-utils    1.4.5   1.4.2
> >>>       maven-artifact   2.0.7   2.0.6
> >>>       ldapsdk 4.17    4.1
> >>>       dependency-maven-plugin 1.0     1.0
> >>>
> >>>       maven-surefire-plugin   2.3     2.3
> >>>       maven-compiler-plugin   2.0.2   2.0.2
> >>>       maven-eclipse-plugin    2.4     2.3
> >>>       maven-antlr-plugin      2.0-beta-1      2.0-beta-1
> >>>       maven-remote-resources-plugin   1.0-alpha-5      1.0-alpha-5
> >>>       maven-jar-plugin        2.1     2.1
> >>>       maven-assembly-plugin   2.2-beta-1      2.1
> >>>       maven-javadoc-plugin    2.3     2.3
> >>>
> >>>
> >>>
> >>>
> >>> shared
> >>>       commons-collections     3.2     3.2
> >>>       commons-lang    2.3     2.3
> >>>       slf4j-api       1.4.3   1.4.0
> >>>       nlog4j  1.2.25  1.2.25
> >>>       antlr   2.7.7   2.7.7
> >>>       mina-core       1.1.2   1.0.3
> >>>       junit   4.4     3.8.1
> >>>
> >>>       maven-surefire-plugin   2.3     2.3
> >>>       maven-compiler-plugin   2.0.2   2.0.2
> >>>       maven-antrun-plugin     1.1     1.1
> >>>       maven-antlr-plugin       2.0-beta-1      2.0-beta-1
> >>>       maven-remote-resources-plugin   1.0-alpha-5     1.0-alpha-5
> >>>       maven-javadoc-plugin    2.3     2.3
> >>>
> >>> daemon
> >>>       slf4j-api       1.4.3   1.4.0
> >>>       nlog4j  1.2.25  1.2.25
> >>>       commons-daemon  1.0.1   1.0.1
> >>>       junit   4.4     3.8.1
> >>>       wrapper 2.3.2   2.3.2
> >>>       maven-surefire-plugin   2.3     2.3
> >>>       maven-remote-resources-plugin   1.0-alpha-5     1.0-alpha-5
> >>>       maven-jar-plugin        2.1     2.1
> >>>       maven-compiler-plugin   2.0.2   2.0.2
> >>>       maven-install-plugin    2.2     2.2
> >>>       maven-javadoc-plugin    2.3     2.3
> >>>
> >>>
> >>> --
> >>> This message is automatically generated by JIRA.
> >>> -
> >>> You can reply to this email to add a comment to the issue online.
> >>>
> >>
> >>
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
>
>


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com