Aha! Apparently this was fixed in Maven 2.0.5, as I just tested and it failed with 2.0.4, but worked when I tried it right afterward in 2.0.5.
Similarly, I have a project that uses the xfire-generator wsgen task, and I had it defined as an extension. This works with 2.0.4, but is broken with 2.0.5. However, changing it to a plugin dependency made it work again. Beyond this issue of extensions vs. plugin dependencies, the rest of my build worked fine with Maven 2.0.5. -Stephen On 2/12/07, Stephen Duncan <[EMAIL PROTECTED]> wrote:
I've actually been telling people on the mailing list to use extensions for jar with checkstyle configuration, rather than plugin->dependencies. The reason was that, in my testing at the time, if you didn't already have that plugin dependency in your local repo, it would not search for it in all your defined repos, it would only look in central, and therefore break for other people. At the time I just assumed using extensions was the right mechanism, but if plugin->dependencies is 'correct' then it should be verified that it works correctly... -Stephen On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > What Dan describes is probably more correct and we should document > this because extensions are really something that executes where you > really just want something on the classpath of the plugin. But as far > as I can tell with the test that I checked in the extension works, > but that should really be a deprecated form of use. > > jason. > > On 12 Feb 07, at 10:17 AM 12 Feb 07, Daniel Kulp wrote: > > > > > Fabrice, > > > > On Monday 12 February 2007 10:02, Fabrice Bellingard wrote: > >> The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader > >> problem > >> loading a resource from a build extension Jar") still breaks my > >> integrations with this last build of Maven... :-( As you tried the > >> test > >> project successfully, I don't understand what can be specific to my > >> environment . I've made a clean installation of Maven (no local > >> repository > >> and last build of 2.0.5), and still it breaks the test case I > >> attached on > >> JIRA. > >> > >> Is there someone here who develops Checkstyle custom Checks and > >> bundles > >> them in a JAR (along with the configuration file) which is > >> specified in the > >> build extensions of another project? Or at least someone else who > >> could > >> test the case I described on JIRA? (with a clean installation) > > > > Just FYI: we (CXF team) put our checkstyle rules into a jar bundle > > and use > > that. However, we don't put it in the extensions. We put it as > > a direct > > dependency for the plugin: > > <plugin> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-checkstyle-plugin</artifactId> > > <dependencies> > > <dependency> > > <groupId>org.apache.cxf</groupId> > > <artifactId>cxf-buildtools</artifactId> > > <version>..... </version> > > </dependency> > > </dependencies> > > ...... > > <plugin> > > and that works fine with 2.0.5. > > > > > > Dan > > > > > > > >> > >> I may sound insisting on this, but the fact is that we have developed > >> custom Checks in my company, and tens of projects are using them to > >> generate the checkstyle report. As 2.0.5 currently breaks our > >> builds, they > >> wouldn't be able to migrate to this new and awaited version of > >> Maven. Which > >> is sad because they're looking forward to using it... > >> > >> Apart from that, everything works fine. :-) > >> > >> Fabrice. > >> > >> On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > >>> Hi, > >>> > >>> The assemblies that people are interested in are staged here: > >>> > >>> http://people.apache.org/~jvanzyl/staging-repository/org/apache/ > >>> maven/<ht > >>> tp://people.apache.org/%7Ejvanzyl/staging-repository/org/apache/ > >>> maven/> > >>> maven-core/2.0.5/ > >>> > >>> Here is the JIRA roadmap: > >>> > >>> http://jira.codehaus.org/secure/IssueNavigator.jspa ? > >>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/ > >>> order=DESC > >>> > >>> +1 > >>> > >>> Thanks, > >>> > >>> Jason. > >>> > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727 C: 508-380-7194 > > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > 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] > > -- Stephen Duncan Jr www.stephenduncanjr.com
-- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
