Re: A question about artifact resolution
On Sun, 22 Jun 2008 06:02:48 am Jason van Zyl wrote:
> Use the maven-dependency-plugin, it can retrieve artifacts and place
> them so that you can subsequently process them. I suggest staying away
> from the artifact resolver directly.
Then I need to know how to drive maven-dependency-plugin programatically
within another plugin.
Basically I'm tring to drive IzPack with custom panels that need to be copied
into the correct location for IzPack to use. The panels would be artifacts
that would be specified using something like the following config structure
in the project that invoked my plugin:
/usr/local/IzPack-3.10.2/
src/main/izpack/izpack-config.xml
foo.bar
DoSomethingPanel
1.0
I searched but could find no documentation that explained how I might do that
with the dependency plugin, which is why the approach in the cookbook looked
usable.
By the way...why stay away from directly using the artifact resolution API?
Isn't it meant to be used externally? Since I could find so little
documentation on using maven components in a plugin, it strikes me that
someone who knows the internals should make a concise and complete guide
listing all the components and interfaces that people like me can use, rather
than the vague hints out there.
If I did miss some obvious documentation, then I apologise for casting
nasturtiums. Maven's been great from a user's perspective, but harder to
dissect from a developer's perspective.
Eric
>
> On 20-Jun-08, at 7:59 PM, ericr wrote:
> > Hi,
> >
> > I'm trying to develop a plugin in which I want to resolve an
> > artifact so
> > that I can copy it somewhere special before using it. Not knowing
> > how (or if
> > it's even possible) to embed the dependency plugin's resolution
> > functionality, I decided to take what seemed like a simpler approach
> > and
> > perform the basic resolution myself, as according to
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook.
> >
> > Unfortunately I get the following NPE:
> >
> > Caused by: java.lang.NullPointerException
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:129)
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
> > at
> > com
> > .izforge
> > .izpack.maven.plugins.IzPackMojo.copyCustomPanels(IzPackMojo.java:174)
> >
> > The code snippet that I wrote is as follows:
> > /** @component */
> > private org.apache.maven.artifact.factory.ArtifactFactory
> > artifactFactory;
> >
> > /** @component */
> > private org.apache.maven.artifact.resolver.ArtifactResolver
> > resolver;
> >
> > someMethod() {
> > Artifact panelArtifact =
> > artifactFactory.createArtifactWithClassifier(groupId, artifactId,
> > version,
> > "jar", "");
> > try
> > {
> >resolver.resolve(panelArtifact, remoteRepositories,
> > localRepository);
> >
> > Do I need to create a variable in my plugin to store a component
> > similar to
> > the the ArtifactFactory and ArtifactResolver mentioned in the
> > cookbook? Is
> > there a better set of documentation that explains how to accomplish
> > such
> > tasks?
> >
> > Eric
> >
> > --
> > View this message in context:
> > http://www.nabble.com/A-question-about-artifact-resolution-tp18040514p180
> >40514.html Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> --
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
"Anything that is in the world when you're born is normal and ordinary and is
just a natural part of the way the world works. Anything that's invented
between when you're fifteen and thirty-five is new and exciting and
revolutionary and you can probably get a career in it. Anything invented
after you're thirty-five is against the natural order of things."
-- Douglas Adams
signature.asc
Description: This is a digitally signed message part.
Re: A question about artifact resolution
On Mon, 23 Jun 2008 01:58:23 pm Jason van Zyl wrote: > On 22-Jun-08, at 5:50 PM, Eric Rose wrote: > > On Sun, 22 Jun 2008 06:02:48 am Jason van Zyl wrote: > >> Use the maven-dependency-plugin, it can retrieve artifacts and place > >> them so that you can subsequently process them. I suggest staying > >> away > >> from the artifact resolver directly. > > > > Why is that? > > Because from lots of experience I know you probably don't need it. > Make your life simple, the dependency plugin is quite powerful. If you > determine you want to use it directly the dependency plugin is a great > example of how to use the APIs. > > > Surely the dependency plugin can't be appropriate for every case > > of artifact resolution. If the artifact resolver API isn't usable as- > > is, or > > is not documented fully I would expect that to be a problem to be > > addressed. > > It has been in trunk, but that's not what's used on the 2.0.x line > which is probably what you're using. correct. > > > To expand on my problem, I am trying to write a wrapper around > > IzPack so that > > installers can be created with custom panels. A project calling my > > plugin > > would have configuration something like: > > > > > > > > > > > > > > foo.bar > > MyCustomPanel > > 1.0 > > > > > > > > > > > > If there's a way I can call the dependency plugin programatically > > from my > > plugin, to pass along the parsed artifact information from the calling > > project, I'd like to know. So far I have not found anything, hence my > > decision to follow the documentation path that seemed to exist for > > calling > > the resolver directly. > > That's your solution. But your problem is putting some artifacts > somewhere to be packaged up with an installer. If your requirement is > to have all that code controlled from your plugin then use the > resolver, but you can certainly solve your problem without it. The > dependency plugin code would be a good place to start. It is a requirement to do it all within the plugin. Currently I have stuff scattered throughout the client POM, which does make use of maven-dependency-plugin. I need to hide all that behind an easy-to-use facade - a single plugin that allows you to specify (at least) where IzPack is, what custom panels your installer needs and where your IzPack config is. Replicating the process between numerous installer projects; where you need to copy assorted custom panels and other assorted setup for IzPack, invoking IzPack, and then cleaning up afterwards can be seriously messy and fraught with error. The more of that I can peel away from the user, the better. I started out looking at the code for maven-dependency-plugin, but it was so convoluted, that I couldn't get a handle on what it did, and how it initialised maven components as required. As I said, the cookbook has so far been the only place that spells out some basic steps on interaction with the maven infrastructure in a programmatic manner. If someone can give me a couple of pointers to more information, I would be grateful. > Plugins depending on plugins is not a good thing. We learned the hard > way with Maven 1.x where this was possible. It certainly wouldn't be my first choice for solving my problem :) Eric > > > FooPlugin foo = new FooPlugin(); > > foo.setBar1(xxx); > > foo.setBar2(yy); > >foo.execute(); > > > > where setBarX() methods mirror the plugin parameters? > > > > By the way, there appears to be scant information on what components > > can be > > used and how to use them property. Is there a definitive set of > > documentation > > that I should be looking at? If I'm casting nasturtiums unjustly, I > > apologise, but maven appears great from a user's perspective and > > very hard to > > pull apart from a programmer's perspective, and that's mainly a > > documentation > > issue, IMO. > > > > Eric > > > >> On 20-Jun-08, at 7:59 PM, ericr wrote: > >>> Hi, > >>> > >>> I'm trying to develop a plugin in which I want to resolve an > >>> artifact so > >>> that I can copy it somewhere special before using it. Not knowing > >>> how (or if > >>> it's even possible) to embed the dependency plugin's resolution > >>> functionality, I decided to take what seemed like a simpler approach > >>> and > &g
Re: A question about artifact resolution
On Sun, 22 Jun 2008 06:02:48 am Jason van Zyl wrote:
> Use the maven-dependency-plugin, it can retrieve artifacts and place
> them so that you can subsequently process them. I suggest staying away
> from the artifact resolver directly.
Why is that? Surely the dependency plugin can't be appropriate for every case
of artifact resolution. If the artifact resolver API isn't usable as-is, or
is not documented fully I would expect that to be a problem to be addressed.
To expand on my problem, I am trying to write a wrapper around IzPack so that
installers can be created with custom panels. A project calling my plugin
would have configuration something like:
foo.bar
MyCustomPanel
1.0
If there's a way I can call the dependency plugin programatically from my
plugin, to pass along the parsed artifact information from the calling
project, I'd like to know. So far I have not found anything, hence my
decision to follow the documentation path that seemed to exist for calling
the resolver directly.
In fact, there appears no information I could find on how, if it is at all
possible, to embed plugins within plugins, in such a manner. Should the
general principle be something like?
FooPlugin foo = new FooPlugin();
foo.setBar1(xxx);
foo.setBar2(yy);
foo.execute();
where setBarX() methods mirror the plugin parameters?
By the way, there appears to be scant information on what components can be
used and how to use them property. Is there a definitive set of documentation
that I should be looking at? If I'm casting nasturtiums unjustly, I
apologise, but maven appears great from a user's perspective and very hard to
pull apart from a programmer's perspective, and that's mainly a documentation
issue, IMO.
Eric
>
> On 20-Jun-08, at 7:59 PM, ericr wrote:
> > Hi,
> >
> > I'm trying to develop a plugin in which I want to resolve an
> > artifact so
> > that I can copy it somewhere special before using it. Not knowing
> > how (or if
> > it's even possible) to embed the dependency plugin's resolution
> > functionality, I decided to take what seemed like a simpler approach
> > and
> > perform the basic resolution myself, as according to
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook.
> >
> > Unfortunately I get the following NPE:
> >
> > Caused by: java.lang.NullPointerException
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:129)
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
> > at
> > com
> > .izforge
> > .izpack.maven.plugins.IzPackMojo.copyCustomPanels(IzPackMojo.java:174)
> >
> > The code snippet that I wrote is as follows:
> > /** @component */
> > private org.apache.maven.artifact.factory.ArtifactFactory
> > artifactFactory;
> >
> > /** @component */
> > private org.apache.maven.artifact.resolver.ArtifactResolver
> > resolver;
> >
> > someMethod() {
> > Artifact panelArtifact =
> > artifactFactory.createArtifactWithClassifier(groupId, artifactId,
> > version,
> > "jar", "");
> > try
> > {
> >resolver.resolve(panelArtifact, remoteRepositories,
> > localRepository);
> >
> > Do I need to create a variable in my plugin to store a component
> > similar to
> > the the ArtifactFactory and ArtifactResolver mentioned in the
> > cookbook? Is
> > there a better set of documentation that explains how to accomplish
> > such
> > tasks?
> >
> > Eric
> >
> > --
> > View this message in context:
> > http://www.nabble.com/A-question-about-artifact-resolution-tp18040514p180
> >40514.html Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> --
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
>
Re: Maven ignores my archetype selection
t; > 12: internal -> maven-archetype-mojo (A Maven Java plugin development > > > project) > > > 13: internal -> maven-archetype-portlet (A simple portlet application) > > > 14: internal -> maven-archetype-profiles () > > > 15: internal -> maven-archetype-quickstart () > > > 16: internal -> maven-archetype-site-simple (A simple site generation > > > project) > > > 17: internal -> maven-archetype-site (A more complex site project) > > > 18: internal -> maven-archetype-webapp (A simple Java web application) > > > 19: internal -> struts2-archetype-starter (A starter Struts 2 > > > > application > > > > > with Sitemesh, DWR, and Spring) > > > 20: internal -> struts2-archetype-blank (A minimal Struts 2 > > > application) 21: internal -> struts2-archetype-portlet (A minimal > > > Struts 2 > > > > application > > > > > that can be deployed as a portlet) > > > 22: internal -> struts2-archetype-dbportlet (A starter Struts 2 portlet > > > that > > > demonstrates a simple CRUD interface with db backing) > > > 23: internal -> struts2-archetype-plugin (A Struts 2 plugin) > > > 24: internal -> shale-archetype-blank (A blank Shale web application > > > > with > > > > > JSF) > > > 25: internal -> maven-adf-archetype (Archetype to ease the burden of > > > creating a new application based with ADF) > > > 26: internal -> data-app (A new Databinder application with sources and > > > resources.) > > > 27: internal -> jini-service-archetype (Archetype for Jini service > > > > project > > > > > creation) > > > 28: internal -> softeu-archetype-seam (JSF+Facelets+Seam Archetype) > > > 29: internal -> softeu-archetype-seam-simple (JSF+Facelets+Seam (no > > > persistence) Archetype) > > > 30: internal -> softeu-archetype-jsf (JSF+Facelets Archetype) > > > 31: internal -> jpa-maven-archetype (JPA application) > > > 32: internal -> spring-osgi-bundle-archetype (Spring-OSGi archetype) > > > 33: internal -> confluence-plugin-archetype (Atlassian Confluence > > > plugin archetype) > > > 34: internal -> maven-archetype-har (Hibernate Archive) > > > 35: internal -> maven-archetype-sar (JBoss Service Archive) > > > 36: internal -> wicket-archetype-quickstart (A simple Apache Wicket > > > project) > > > Choose a number: > > > > (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36): > > > It did exactly the same thing! Why has it ignored my selection of the > > > archetype? Why doesn't it try to download trails-archetype? I can see > > > > http://repo1.maven.org/maven2/org/trailsframework/trails-archetype/1.1.1/ > >which > > > > > looks to match the archetype specified pretty well. > > > > > > This looks a bit as though it might be related to issue MNG-3356, but I > > > > > > don't have any other commons-cli installation: > > > >apt-cache policy libcommons-cli-java > > > > > > libcommons-cli-java: > > > Installed: (none) > > > Candidate: 1.0-8 > > > Version table: > > > 1.0-8 0 > > >500 http://au.archive.ubuntu.com gutsy/universe Packages > > > > > > and besides Maven looks like it has its own version built in: > > > >jar tf /usr/local/apache-maven/lib/maven-2.0.8-uber.jar | grep > > > > > > commons/cli > > > org/apache/commons/cli/ > > > org/apache/commons/cli/AlreadySelectedException.class > > > org/apache/commons/cli/ParseException.class > > > org/apache/commons/cli/CommandLine.class > > > org/apache/commons/cli/Option.class > > > org/apache/commons/cli/CommandLineParser.class > > > org/apache/commons/cli/Options.class > > > org/apache/commons/cli/OptionGroup.class > > > org/apache/commons/cli/Parser.class > > > org/apache/commons/cli/MissingOptionException.class > > > org/apache/commons/cli/GnuParser.class > > > org/apache/commons/cli/HelpFormatter$StringBufferComparator.class > > > org/apache/commons/cli/HelpFormatter$1.class > > > org/apache/commons/cli/HelpFormatter.class > > > org/apache/commons/cli/MissingArgumentException.class > > > org/apache/commons/cli/PatternOptionBuilder.class > > > org/apache/commons/cli/PosixParser.class > > > org/apache/commons/cli/TypeHandler.class > > > org/apache/commons/cli/UnrecognizedOptionException.class > > > org/apache/commons/cli/OptionBuilder.class > > > org/apache/commons/cli/BasicParser.class > > > > > > What am I doing wrong??? > > > > > > Tom -- Eric Rose | "Sed quis custodiet ipsos custodes?" [EMAIL PROTECTED] | Juvenal (Satires, VI.347-8) *** This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). If you wish to opt out from future messages, send an email to [EMAIL PROTECTED] with the subject UNSUBSCRIBE signature.asc Description: This is a digitally signed message part.
Re: SCM problems
On Friday 02 February 2007 19:27, Emmanuel Venisse wrote: > [EMAIL PROTECTED] a écrit : > > I'm not sure if this is the correct answer, but I had the same problem > > (although with SourceSafe), and as far as I could understand it, it was > > due to > > the fact that when you trigger the build, you check out the source code, > > which includes the POM file. > > > > Since the POM file in cvs contains the old scm url, it overwrites the one > > in the build definition, although I'm not really sure why. I almost went > > nuts over this until I > > figured it out. I wish it didn't. Currently tring to accommodate that behaviour breaks otherwise functional configuration (see below). > > > > My solution was to modify the POM file, check it in, then either change > > the build definition or remove and add the project again. > > It has worked flawless ever since. > > Yes, it's the correct solution. scm informations in pom must be correct. I changing this at one point, but then maven failed (in building the site, IIRC) when I tried to build the project manually, complaining about an invalid SCM URL, and it wasn't until I changed it back that I could build the project. Eric > > Emmanuel > > > Regards > > > > Joakim Zetterberg > > > > Eric Rose <[EMAIL PROTECTED]> wrote on 2007-02-02 01:06:07: > >> Hi, > >> > >> I am trying to get continuum working to see if it will do a better job > > > > than > > > >> our current cruisecontrol setup. The version of continuum I am usingis > > > > 1.0.3 > > > >> and I cannot get a reliable build from it. > >> > >> The POM contains a SCM connection string like the following: > >> > >> scm:cvs:pserver:[EMAIL PROTECTED]:2401/path/to/module > >> > >> which works fine for Maven. > >> > >> When I added the project and triggered a build, it failed with the error > > > > that > > > >> a password was needed. According to the FAQ, the SCM URL should be > > > > changed > > > >> to :anonymous:@cvsserver: so I did this and the build worked. So far so > >> good... > >> > >> I then triggered another build and it failed again with the initial > > > > error. > > > >> Going back to check the project info, I notice that the original SCM URL > > > > has > > > >> replaced my modified version. Has anyone else seen, and hopefully found > > > > a > > > >> reason for, this lacy of persistence of a project configuration? > >> > >> A second issue is that the port number in my URL causes problems, > >> and I end up > >> with messages in wrapper.log like the following: > >> > >> INFO | jvm 1| 2007/02/02 10:36:04 | 2007-02-02 10:36:04,122 > > > > [Thread-2] > > > >> DEBUG ScmManager - > >> cvsRoot: :pserver:[EMAIL PROTECTED]:24012401/path/to/module > >> > >> If I remove the port number from the configuration, I run into the > >> first issue > >> where the changes aren't persisted to further builds. > >> > >> Thanks for any pointers, > >> > >> Eric > >> > >> -- > >> Eric Rose | "Sed quis custodiet ipsos custodes?" > >> [EMAIL PROTECTED] | Juvenal (Satires, VI.347-8) > >> > >> *** > >> This message contains privileged and confidential information intended > >> only for the use of the addressee named above. If you are not the > >> intended recipient of this message you must not disseminate, copy or > >> take any action in reliance on it. If you have received this message > >> in error please notify the sender immediately. Any views expressed in > >> this message are those of the individual sender, except where the > >> sender specifically states them to be the views of another (including > >> a Body Corporate). > >> > >> If you wish to opt out from future messages, send an email to > >> [EMAIL PROTECTED] with the subject UNSUBSCRIBE > >> > >> > >> [attachment "att0cowi.dat" deleted by Joakim > >> Zetterberg/H00JZG/HK_ITLOG/BORÅS/ICA/SE] -- Eric Rose | "Sed quis custodiet ipsos custodes?" [EMAIL PROTECTED] | Juvenal (Satires, VI.347-8) *** This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). If you wish to opt out from future messages, send an email to [EMAIL PROTECTED] with the subject UNSUBSCRIBE pgpBd9RaPHnyw.pgp Description: PGP signature
SCM problems
Hi, I am trying to get continuum working to see if it will do a better job than our current cruisecontrol setup. The version of continuum I am using is 1.0.3 and I cannot get a reliable build from it. The POM contains a SCM connection string like the following: scm:cvs:pserver:[EMAIL PROTECTED]:2401/path/to/module which works fine for Maven. When I added the project and triggered a build, it failed with the error that a password was needed. According to the FAQ, the SCM URL should be changed to :anonymous:@cvsserver: so I did this and the build worked. So far so good... I then triggered another build and it failed again with the initial error. Going back to check the project info, I notice that the original SCM URL has replaced my modified version. Has anyone else seen, and hopefully found a reason for, this lacy of persistence of a project configuration? A second issue is that the port number in my URL causes problems, and I end up with messages in wrapper.log like the following: INFO | jvm 1| 2007/02/02 10:36:04 | 2007-02-02 10:36:04,122 [Thread-2] DEBUG ScmManager - cvsRoot: :pserver:[EMAIL PROTECTED]:24012401/path/to/module If I remove the port number from the configuration, I run into the first issue where the changes aren't persisted to further builds. Thanks for any pointers, Eric -- Eric Rose | "Sed quis custodiet ipsos custodes?" [EMAIL PROTECTED] | Juvenal (Satires, VI.347-8) *** This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). If you wish to opt out from future messages, send an email to [EMAIL PROTECTED] with the subject UNSUBSCRIBE pgpXCMqQCoxa3.pgp Description: PGP signature
Re: [ANN] Maven Checkstyle Plugin 3.0 for Maven 1.x released
On Sunday 19 February 2006 08:11, Lukas Theussl wrote:
> I have deployed a new snapshot which uses a jsl transform instead of
> ant's style task. This should eliminate any jdk related issues, please
> test:
>
> maven plugin:download
> -Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repo
>sitory/ -DgroupId=maven -DartifactId=maven-checkstyle-plugin
> -Dversion=3.0.1-SNAPSHOT
The plugin failed for me with a message as follows:
BUILD FAILED
File..
/usr/local/mavenPluginRepository/cache/maven-checkstyle-plugin-3.0.1-SNAPSHOT/plugin.jelly
Element... util:file
Line.. 99
Column 75
You must define an attribute called 'name must be specified' for this tag.
Total time: 21 seconds
Finished at: Mon Feb 20 09:34:29 EST 2006
But I think this might be related to MPCHECKSTYLE-9
Once I set the ${maven.checkstyle.header.file} explicitly, the checkstyle
plugin worked fine.
Eric
--
Eric Rose | "Sed quis custodiet ipsos custodes?"
[EMAIL PROTECTED] | Juvenal (Satires, VI.347-8)
***
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message you must not disseminate, copy or
take any action in reliance on it. If you have received this message
in error please notify the sender immediately. Any views expressed in
this message are those of the individual sender, except where the
sender specifically states them to be the views of another (including
a Body Corporate).
If you wish to opt out from future messages, send an email to
[EMAIL PROTECTED] with the subject UNSUBSCRIBE
pgpu0ZRhMRu2H.pgp
Description: PGP signature
Re: [ANN] Maven Checkstyle Plugin 3.0 for Maven 1.x released
On Tuesday 07 February 2006 06:18, [EMAIL PROTECTED] wrote: > We are pleased to announce the Maven Checkstyle Plugin 3.0 release! > > http://maven.apache.org/maven-1.x/reference/plugins/checkstyle/ Hi, I'm using Maven 1.0.2 and had been running with no errors using the Checkstyle Plugin 2.5, but am getting the following after upgrading to version 3.0: checkstyle:init: checkstyle:report: checkstyle:run: [echo] Using file:/usr/local/forge/ForgeLibs/BuildTools/etc/checkstyle.xml for checkstyle ... [echo] LocaleCountry : en [checkstyle] Running Checkstyle 4.1 on 1396 files checkstyle:report-internal: [style] Processing /home/ericr/workspace/mapIntelligence/tmp/checkstyle/checkstyle-raw-report.xml to /home/ericr/workspace/mapIntelligence/tmp/checkstyle/checkstyle-summary-report.xml [style] Loading stylesheet /usr/local/mavenPluginRepository/cache/maven-checkstyle-plugin-3.0/plugin-resources/checkstyle-summary.xsl BUILD FAILED File.. /usr/local/mavenPluginRepository/cache/maven-checkstyle-plugin-3.0/plugin.jelly Element... style Line.. 238 Column 59 Provider for javax.xml.transform.TransformerFactory cannot be found Total time: 36 seconds Finished at: Tue Feb 07 15:58:56 EST 2006 I presume that I'll have to add -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl somewhere, but I'm not sure where best to put it or of there's a better solution. Any clues? Eric -- Eric Rose | "Sed quis custodiet ipsos custodes?" [EMAIL PROTECTED] | Juvenal (Satires, VI.347-8) *** This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). If you wish to opt out from future messages, send an email to [EMAIL PROTECTED] with the subject UNSUBSCRIBE pgppwFmiUj5me.pgp Description: PGP signature
