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. 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) ........ > > 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. > 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. -- Daniel Kulp [email protected] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
