On 2009-09-08, at 3:51 PM, Daniel Kulp wrote:
On Tue September 8 2009 4:15:05 am Jason van Zyl wrote:
On 2009-09-01, at 7:22 PM, Daniel Kulp wrote:
However, to accomplish that, we HAVE to make sure the remote-
resources is NOT
loaded in buildtools. Otherwise, due to the bug in maven that
doesn't re-
evaluate plugin dependencies after the first load, the subsequent
modules
would not be able to get the supplements.
Why would we want to revaluate the dependencies after the first load?
It's not a "first load" thing, it's a "per module" thing.
If I have a reactor:
a
-> b
-> c
And b configures a plugin with dependency foo, and c configures the
same
plugin, but with dependency bar, if I run mvn in "c", it works fine
(gets
bar), but if I run from a, it doesn't work right in c. It just
gets foo.
Thus, it works differently depending on where I type "mvn". To me,
that is
bad.
Yes, it's bad. You just want the classloader scoped for the specified
dependencies. Should be easy enough to make an IT for that and fix it
in 3.x.
Other than remote resources, the other plugin I've hit this time and
time
again is antrun. In the above, if (b) just uses antrun without any
dependencies to do basic things, but (c) requires the trax
dependencies for
xslt processing, you have to configure the trax in (b) as well,
which is
stupid. (yes, the proper thing is to configure in pluginManagement
in a, but
my point is the same, the current behavior yields different results
depending
on where it's run)
That is bad too. Again, probably not hard to model with and test.
........
We either need the bug in maven fixed (and on 2.0.x) or we need this
fixed or
we just say Apache parent is useless for us. We've BEEN saying
Apache parent
is useless, but I want to change that.
Or how about changing the facility in the RR plugin? You need to
specify resources bundles and supplemental models. So if the plugin
took care of the loading of these elements that would be more self-
contained.
Umm.. that's exactly what the commit does. It adds configuration
for
artifacts to look in for the supplemental models. That way, it's
not a
"dependency" thing, it's a configuration thing.. It works exactly
(shares
the same code) as the configuration for the resource-bundles itself.
Ok, well I'll use your use case for the first in a series of helper
components so this is not duplicated all over the place in 3.x.
I partially understand. Just not too comfortable with changes made
for
specific projects like CXF when I haven't seen the use case crop up
anywhere else.
Quite possibly because few projects use the supplemental models.
CXF has a
very broad set of dependencies and a lot of them have crappy poms
that need
the supplements. Personally, I'd love to have the deploy plugin
updated to
refuse to deploy poms that don't have the basic bits of information
(name,
url, licenses, organization, etc...), but users probably wouldn't
like that
and it doesn't solve the problem of artifacts not built with maven.
Unfortunately this will not work. We tried to be more strict with
things in the POM and we just had too many complaints. In 3.x we got
strict about versions and particular elements and our clients and
people we were testing with just complained.
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
