|
Home > Archive > Apache Directory Project > May 2007 > [ApacheDS] Problems building the installers
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[ApacheDS] Problems building the installers
|
|
| Stefan Zoerner 2007-05-21, 7:11 am |
| Hi all!
I have currently the problem that I am unable to build the installers of
ApacheDS 1.5.
I have checked out
https://svn.apache.org/repos/asf/di...th-dependencies
and I am able to perform a "mvn install" on this level.
But if I change directory to apacheds/server-installers and try "mvn
install" I get this
[INFO] Scanning for projects...
[INFO]
-------------------------------------------------------------------------
---
[INFO] Building ApacheDS Server Installers
[INFO] task-segment: [install]
[INFO]
-------------------------------------------------------------------------
---
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does
not exist or no valid version could be found
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Mon May 21 11:04:03 CEST 2007
[INFO] Final Memory: 1M/3M
[INFO]
------------------------------------------------------------------------
A "mvn clean" does not help on any level (runs successfully, but error
persists).
Any help is appreciated.
Thanks in advance,
Stefan
| |
| Emmanuel Lecharny 2007-05-21, 7:11 am |
| Hmmmm...
I just have tested it :
svn up
mvn clean install on root
cd apacheds/server-installers
mvn clean install
no pb at all...
Have you tried to remove completly your .m2 repository before running the
build ?
Emmanuel
On 5/21/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
> Hi all!
>
> I have currently the problem that I am unable to build the installers of
> ApacheDS 1.5.
>
> I have checked out
>
>
> https://svn.apache.org/repos/asf/di...th-dependencies
>
> and I am able to perform a "mvn install" on this level.
>
> But if I change directory to apacheds/server-installers and try "mvn
> install" I get this
>
> [INFO] Scanning for projects...
> [INFO]
> -------------------------------------------------------------------------
> ---
> [INFO] Building ApacheDS Server Installers
> [INFO] task-segment: [install]
> [INFO]
> -------------------------------------------------------------------------
> ---
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does
> not exist or no valid version could be found
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: < 1 second
> [INFO] Finished at: Mon May 21 11:04:03 CEST 2007
> [INFO] Final Memory: 1M/3M
> [INFO]
> ------------------------------------------------------------------------
>
> A "mvn clean" does not help on any level (runs successfully, but error
> persists).
>
> Any help is appreciated.
> Thanks in advance,
> Stefan
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Emmanuel Lecharny 2007-05-21, 7:11 am |
| Hi Stefan,
I have tested it again after having removed the repo, and still working ...
On 5/21/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hmmmm...
>
> I just have tested it :
> svn up
> mvn clean install on root
> cd apacheds/server-installers
> mvn clean install
>
> no pb at all...
>
> Have you tried to remove completly your .m2 repository before running the
> build ?
>
> Emmanuel
>
> On 5/21/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Stefan Zoerner 2007-05-21, 7:11 am |
| Emmanuel Lecharny wrote:
> I have tested it again after having removed the repo, and still working ...
Hi Emmanuel,
I have removed the repo from my machine, rebuilt it all and you are
right: I just came back from lunch and now I have fresh installers.
Thanks for your help,
Stefan
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| Ahhh the unpredictability of Maven strikes again!
Alex
On 5/21/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
> Emmanuel Lecharny wrote:
> ...
>
> Hi Emmanuel,
>
> I have removed the repo from my machine, rebuilt it all and you are
> right: I just came back from lunch and now I have fresh installers.
>
> Thanks for your help,
> Stefan
>
>
| |
| Chris Custine 2007-05-21, 1:11 pm |
| Do you guys think that these problems are from having the SNAPSHOT repos
(regular maven repo and plugin repo) in the maven repo stack? I am
basically in the habit of disabling the SNAPSHOT repos in any project I
build because it does stuff like this. And yes I always disable the
SNAPSHOT repo in ApacheDS pom as well :-)
Its always been in the back of my mind to ask why it is enabled, but I
figured that it allowed someone to build part of the SVN project without
building the entire thing or something along those lines.
Chris
On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Ahhh the unpredictability of Maven strikes again!
>
> Alex
>
> On 5/21/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| I think this was due not to the SNAPSHOT repos but to the fact that we do
not use
a specific revision for all the plugins involved.
If we disable the SNAPSHOT repos there will be other negative effects. For
example
when we are on a SNAPSHOT like say 1.5.1-SNAPSHOT then the snapshot jars are
deployed to the apache snapshot repo. If a user checks out the apacheds
trunk and
tries to build that instead of building the svn area with the dependent
projects then
those snapshots from shared and daemon will not be resolved. Even worse if
a user
checks out apacheds/trunk/server-installers and tries to build that then it
will fail if
the SNAPSHOT repos are not visible.
I think we just have to make sure we assign a specific revision to all the
plugins we
use instead of not including a revision for a plugin. This will prevent the
use of
SNAPSHOT plugins I hope.
There is also a pluginManagement section in the pom that we need to populate
so
we lock all plugins to a specific revision instead of allowing the use of
SNAPSHOTs.
Alex
On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Do you guys think that these problems are from having the SNAPSHOT repos
> (regular maven repo and plugin repo) in the maven repo stack? I am
> basically in the habit of disabling the SNAPSHOT repos in any project I
> build because it does stuff like this. And yes I always disable the
> SNAPSHOT repo in ApacheDS pom as well :-)
>
> Its always been in the back of my mind to ask why it is enabled, but I
> figured that it allowed someone to build part of the SVN project without
> building the entire thing or something along those lines.
>
> Chris
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
| |
| Emmanuel Lecharny 2007-05-21, 1:11 pm |
| We should never use SNAPSHOT of any external dependency, this is the perfect
way to shooting us in the foot. But for internal project like shared, etc,
we must use SNAPSHOT...
On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Do you guys think that these problems are from having the SNAPSHOT repos
> (regular maven repo and plugin repo) in the maven repo stack? I am
> basically in the habit of disabling the SNAPSHOT repos in any project I
> build because it does stuff like this. And yes I always disable the
> SNAPSHOT repo in ApacheDS pom as well :-)
>
> Its always been in the back of my mind to ask why it is enabled, but I
> figured that it allowed someone to build part of the SVN project without
> building the entire thing or something along those lines.
>
> Chris
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Emmanuel Lecharny 2007-05-21, 1:11 pm |
| I think this is already done, and if not, then this should be done.
On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> I think this was due not to the SNAPSHOT repos but to the fact that we do
> not use
> a specific revision for all the plugins involved.
>
> If we disable the SNAPSHOT repos there will be other negative effects.
> For example
> when we are on a SNAPSHOT like say 1.5.1-SNAPSHOT then the snapshot jars
> are
> deployed to the apache snapshot repo. If a user checks out the apacheds
> trunk and
> tries to build that instead of building the svn area with the dependent
> projects then
> those snapshots from shared and daemon will not be resolved. Even worse
> if a user
> checks out apacheds/trunk/server-installers and tries to build that then
> it will fail if
> the SNAPSHOT repos are not visible.
>
> I think we just have to make sure we assign a specific revision to all the
> plugins we
> use instead of not including a revision for a plugin. This will prevent
> the use of
> SNAPSHOT plugins I hope.
>
> There is also a pluginManagement section in the pom that we need to
> populate so
> we lock all plugins to a specific revision instead of allowing the use of
> SNAPSHOTs.
>
> Alex
>
> On 5/21/07, Chris Custine < chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| Yeah we're not there 100% yet. Yet another thing to do. I will file a JIRA
on
doign this so we finally get to it.
Alex
On 5/21/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I think this is already done, and if not, then this should be done.
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org > wrote:
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
| |
| Chris Custine 2007-05-21, 1:11 pm |
| OK, I pretty much figured that this was the case. I think the main problem
is the plugins. I have noticed that when I use the snapshots repo for
plugins, even the basic maven functionality plugins get pulled down as
SNAPSHOT once in a while (recently I noticed surefire and even compiler get
pulled as snapshots), so to limit the versions we would have to list
specific versions of even the core plugins.
Is the only reason for the snapshot plugins because of the daemon-plugin?
If so, we could disable the plugins snapshot repo and just document that if
you want to build the installers from SVN code, then you must build
daemon-plugin first or something similar to that effect....
Chris
On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Yeah we're not there 100% yet. Yet another thing to do. I will file a
> JIRA on
> doign this so we finally get to it.
>
> Alex
>
> On 5/21/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> OK, I pretty much figured that this was the case. I think the main
> problem is the plugins. I have noticed that when I use the snapshots repo
> for plugins, even the basic maven functionality plugins get pulled down as
> SNAPSHOT once in a while (recently I noticed surefire and even compiler get
> pulled as snapshots), so to limit the versions we would have to list
> specific versions of even the core plugins.
Yeah I've noticed the exact same thing. We just need a definitive list of
all the plugins with their versions in the pluginManagement section without
presuming anything from now on. I think we might be able to get a good
list like this from the Geronimo peeps which manage plugins very carefully
in a pluginManagement section. I think we might be able to get these
straight from their master pom.
Is the only reason for the snapshot plugins because of the daemon-plugin?
> If so, we could disable the plugins snapshot repo and just document that if
> you want to build the installers from SVN code, then you must build
> daemon-plugin first or something similar to that effect....
Hmmmm ok you're talking about the snapshot-plugin repos. I thought that you
meant the snapshot repos in general. Now that I got my head straight I
think we could use older versions of the daemon plugin. Now we also have
the partition plugin for the bootstrap schema partition's creation which
adds some more complexity. I guess we could disable all snapshot plugin
repos but just keep the Apache snapshot repo? Would this still pull down
maven snapshots since they also share this repo?
Perhaps with explicit version locking we could reduce this problem but if it
persists then we can just exclude all snapshot repos and find another
workaround. WDYT?
Alex
| |
| Chris Custine 2007-05-21, 1:11 pm |
| On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
>
> On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> Yeah I've noticed the exact same thing. We just need a definitive list of
> all the plugins with their versions in the pluginManagement section without
> presuming anything from now on. I think we might be able to get a good
> list like this from the Geronimo peeps which manage plugins very carefully
> in a pluginManagement section. I think we might be able to get these
> straight from their master pom.
>
> Is the only reason for the snapshot plugins because of the daemon-plugin?
>
>
> Hmmmm ok you're talking about the snapshot-plugin repos. I thought that
> you meant the snapshot repos in general. Now that I got my head straight I
> think we could use older versions of the daemon plugin. Now we also have
> the partition plugin for the bootstrap schema partition's creation which
> adds some more complexity. I guess we could disable all snapshot plugin
> repos but just keep the Apache snapshot repo? Would this still pull down
> maven snapshots since they also share this repo?
The plugin versions are managed totally seperate from the dependency
artifacts, so even if you have the snapshot repo enabled for dependencies
it wouldn't be considered for plugins unless it was listed in
pluginRepositories section.
Perhaps with explicit version locking we could reduce this problem but if it
> persists then we can just exclude all snapshot repos and find another
> workaround. WDYT?
Yeah, that will work... I always thought it was a given that if you are
building from SVN you probably need to checkout and build the top level
project and I never considered supporting partial checkout builds.
Alex
Chris
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| BTW Chris I may be completely over doing it with the need to support a
partial build. I just have
had users complain about it when they checked out just an apacheds branch
and tried to compile.
However this may be a bit too much perhaps.
Alex
On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> The plugin versions are managed totally seperate from the dependency
> artifacts, so even if you have the snapshot repo enabled for dependencies
> it wouldn't be considered for plugins unless it was listed in
> pluginRepositories section.
>
> Perhaps with explicit version locking we could reduce this problem but if
>
>
> Yeah, that will work... I always thought it was a given that if you are
> building from SVN you probably need to checkout and build the top level
> project and I never considered supporting partial checkout builds.
>
> Alex
>
>
>
> Chris
>
>
>
| |
| Chris Custine 2007-05-21, 1:11 pm |
| No, I totally understand. I just have a bit of a personal thing about using
the maven snapshot repo for plugins because of the general craziness that
results once in a while (like what was happening with Stefan this weekend).
I think versioning the plugins will help for out project, but everyone has
to realize that this can affect other projects as well, because once the
SNAPSHOT plugin is downloaded to the local repo, any other project will use
that one too even if they didn't ask for the snapshot repo for plugins.
This is my main compaint with using snapshot repo for plugins.
CC
On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> BTW Chris I may be completely over doing it with the need to support a
> partial build. I just have
> had users complain about it when they checked out just an apacheds branch
> and tried to compile.
>
> However this may be a bit too much perhaps.
>
> Alex
>
> On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
| |
| Alex Karasulu 2007-05-21, 1:11 pm |
| Ahhh ok well then we may just need to remove the snapshot plugin repos and
figure out a workaround
for anything we have in our build that may need them legitimately.
Alex
On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> No, I totally understand. I just have a bit of a personal thing about
> using the maven snapshot repo for plugins because of the general craziness
> that results once in a while (like what was happening with Stefan this
> weekend). I think versioning the plugins will help for out project, but
> everyone has to realize that this can affect other projects as well, because
> once the SNAPSHOT plugin is downloaded to the local repo, any other project
> will use that one too even if they didn't ask for the snapshot repo for
> plugins. This is my main compaint with using snapshot repo for plugins.
>
> CC
>
>
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
| |
| Emmanuel Lecharny 2007-05-22, 1:11 pm |
| Guys,
I have cleant up the shared sub-project so that each dependency is used with
its correct version (version will be declared for each plugin), and each
maven-plugin has been declared with its version too.
I have modified some more things too:
- as shared depends on a parent project (the 1.0.7-SNAPSHOT), there is a
problem if you want to build shared alone while you don't have any jars in
your .m2/repository. So I removed the reference to the TLP pom.xml in the
shared pom.xml. As the TLP pom.xml stilll contains shared as a module, this
is not a big deal. However, doing that, I also had to move the junit
dependency from TLP pom.xml to shared pom.xml
- I removed all the report from shared/convert, ldap and ldap-constants.
They are useless atm
- I also upgraded all the dependencies and plugin to their latest version
(antlr 2.7.7, etc)
I think that the TLP pom.xml should not contain any information about
dependencies and plugins, as it is just a global start. If you want to be
able to build shared, or daemon, or apacheds, standalone, you must not
depend on this TLP pom, IMHO.
We should also try to use always the same version of each plugin and
dependency, which is quite a PITA to do, as we use around 70 of them in our
40 subprojects... What I have done for shared should be done for apacheds
and daemon, and it takes a hell of time !
On 5/21/07, Alex Karasulu < akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Ahhh ok well then we may just need to remove the snapshot plugin repos and
> figure out a workaround
> for anything we have in our build that may need them legitimately.
>
> Alex
>
> On 5/21/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Chris Custine 2007-05-22, 1:11 pm |
| Yeah, I was pretty sure that there would be some major pain involved in
that... I still propose that in the long run we make this a build
documentation issue and tell people that if they build from SVN that they
need to check out and build the top level project at least once before they
do iterative builds on a specific module. Checking out a sub-tree of the
trunk and expecting that part to build seems like an edge case to me.
Chris
On 5/22/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Guys,
>
> I have cleant up the shared sub-project so that each dependency is used
> with its correct version (version will be declared for each plugin), and
> each maven-plugin has been declared with its version too.
>
> I have modified some more things too:
> - as shared depends on a parent project (the 1.0.7-SNAPSHOT), there is a
> problem if you want to build shared alone while you don't have any jars in
> your .m2/repository. So I removed the reference to the TLP pom.xml in the
> shared pom.xml. As the TLP pom.xml stilll contains shared as a module,
> this is not a big deal. However, doing that, I also had to move the junit
> dependency from TLP pom.xml to shared pom.xml
> - I removed all the report from shared/convert, ldap and ldap-constants.
> They are useless atm
> - I also upgraded all the dependencies and plugin to their latest version
> (antlr 2.7.7, etc)
>
> I think that the TLP pom.xml should not contain any information about
> dependencies and plugins, as it is just a global start. If you want to be
> able to build shared, or daemon, or apacheds, standalone, you must not
> depend on this TLP pom, IMHO.
>
> We should also try to use always the same version of each plugin and
> dependency, which is quite a PITA to do, as we use around 70 of them in our
> 40 subprojects... What I have done for shared should be done for apacheds
> and daemon, and it takes a hell of time !
>
>
>
> On 5/21/07, Alex Karasulu < akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
| |
| Emmanuel Lecharny 2007-05-22, 1:11 pm |
| Rigth now, I can build shared as a standalone project
Anyway, it would be better to docuemnt the build process better (there is
some doco on the site, but I don't know how accurate they are right now)
On 5/22/07, Chris Custine <chris.custine-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Yeah, I was pretty sure that there would be some major pain involved in
> that... I still propose that in the long run we make this a build
> documentation issue and tell people that if they build from SVN that they
> need to check out and build the top level project at least once before they
> do iterative builds on a specific module. Checking out a sub-tree of the
> trunk and expecting that part to build seems like an edge case to me.
>
> Chris
>
> On 5/22/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| David Jencks 2007-05-26, 7:11 pm |
| Does this really happen even if you have specified the version for
each plugin in all poms? Not specifying the plugin version is
certainly an invitation to disaster :-)
thanks
david jencks
On May 21, 2007, at 10:13 AM, Chris Custine wrote:
> No, I totally understand. I just have a bit of a personal thing
> about using the maven snapshot repo for plugins because of the
> general craziness that results once in a while (like what was
> happening with Stefan this weekend). I think versioning the
> plugins will help for out project, but everyone has to realize that
> this can affect other projects as well, because once the SNAPSHOT
> plugin is downloaded to the local repo, any other project will use
> that one too even if they didn't ask for the snapshot repo for
> plugins. This is my main compaint with using snapshot repo for
> plugins.
>
> CC
>
>
>
> On 5/21/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> BTW Chris I may be completely over doing it with the need to
> support a partial build. I just have
> had users complain about it when they checked out just an apacheds
> branch and tried to compile.
>
> However this may be a bit too much perhaps.
>
> Alex
<snip>
| |
| Emmanuel Lecharny 2007-05-27, 1:11 pm |
| David Jencks a écrit :
> Does this really happen even if you have specified the version for
> each plugin in all poms? Not specifying the plugin version is
> certainly an invitation to disaster :-)
I don't agree, David, it's *not* an invitation to disaster, it's a
direct disaster  - and we experienced it more than once ... 
I will just smooth a litte bit the prerequisite : if you use the
PluginManagement and DependencyManagement sections in the top level
poms, then you don't need to declare the versions in all the pom. Btw,
declaring plugins/dependencies in all the poms is also a problem, if you
have, like we have, around 50 pom files : sooner or later, you will use
N versions of the same plugin/dependency, something you want to avoid
like plague ...
Maven is powerfull, but needs a lot of wizdom to be able to avoid all
the traps you can be caught in... (or maybe a better doco? ;)
IMHO, Emmanuel.
>
> thanks
> david jencks
>
> On May 21, 2007, at 10:13 AM, Chris Custine wrote:
>
>
> <snip>
>
|
|
|
|
|