Disabling a plugin bound to a phase
Hi, We have a multiproject which contains both war and jar projects. I would like (in a profile) to disable the war projects from building their wars - as it takes ages and we only need them now and then. Is this possible? So I want to run mvn install -PnoWars At the parent and get all the jars built but not the wars. Thanks Ben Gidley
Plugin Versions and the Eclipse Plugin
Does anyone know how to force maven 2 to upgrade the eclipse plugin. I have an install of maven 2.0.4 and it isn't using the version documented on http://maven.apache.org/plugins/maven-eclipse-plugin/overview.html. It keeps reporting when I try and set wtp that wtp 1.0 is not supported. I have tried mvn -cpu -U to force a refresh. I have added the snapshot repo's for plugins to my settings.xml. Any other ideas? Ben
[M2] Uploading non-maven jars to a repository
Is there a command to help you upload and generate a fake POM to a repository (as opposed to your local file system). I have found mvn install:install-file -Dfile=path-to-file -DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version -Dpackaging=packaging For putting the file into the local repository but this does not generate check sums and if you upload these jars to a shared repository maven complains. This would make it a lot easier for people to set up POM's for Ibiblio or for private repositories of jars with licenses that prohibit being uploaded to ibiblio. Any one got any ideas? Thanks Ben
Re: [m2] Forking with Surefire
Thanks for this - unfortunately even with this setting I am still having the same problem it appears to be some interaction between the libraries JAXB2 and Surefire is using that even happens when forking is occuring. I have checked (with -X) and I am definitely running Surefire 1.5.2 which is the latest I can see. The JAXB2 guys think it is likely to be something to do with the way surefire is loading classes. Looking at surefire I suspect this could be the case as it is using a custom isolated classloader which then loads the javax.xml namespace a second time (hence the error). The percise error is java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit( RuntimeBuiltinLeafInfoImpl.java:779) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init( RuntimeTypeInfoSetImpl.java:25) I am going to investigate - but any hints would be appreciated. Ben On 2/2/06, Jason van Zyl [EMAIL PROTECTED] wrote: Ben Gidley wrote: I am having issues with Maven running the unit tests on my project. The main error is http://maven.apache.org/plugins/maven-surefire-plugin/howto.html For forkMode you can specify once or pertest which really means per test case. I've added: http://jira.codehaus.org/browse/MSUREFIRE-55 and http://jira.codehaus.org/browse/MSUREFIRE-56 Sorry about the confusion. java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl .clinit( RuntimeBuiltinLeafInfoImpl.java:779) Looking at this list I can see a number of people have hit this and the solution is to fork the JVM for the unit tests. Looking at the surefire plugin documentation I have added the following to my POM plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModeeach/forkMode /configuration /plugin However this make no difference. I then suspected it may be not in the released version of the plugin - so I tried using the snapshot by adding pluginRepository idSnapshots/id nameSnapshots/name urlhttp://snapshots.maven.codehaus.org/maven2//url /pluginRepository and forcing the plugin version. This also appears to make no different. Looking at the code for the plugin in Subversion for surefire it does appear it supports forking and this is the way to turn in on. Am I doing something wrong to make it use the plugin? Has anyone got any ideas of how to get round this issue? Thanks Ben -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Forking with Surefire
Sorry - ignore that. I have found a solution looking at the surefire code. The trick is to turn childdelegation off when forking. This means that the JVM only loads the classes once and it is all good. e.g. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModeonce/forkMode testFailureIgnoretrue/testFailureIgnore childDelegationfalse/childDelegation /configuration executions execution goals goaltest/goal /goals /execution /executions /plugin I will submit a patch to the docs to make this clear. Thanks Ben On 2/2/06, Ben Gidley [EMAIL PROTECTED] wrote: Thanks for this - unfortunately even with this setting I am still having the same problem it appears to be some interaction between the libraries JAXB2 and Surefire is using that even happens when forking is occuring. I have checked (with -X) and I am definitely running Surefire 1.5.2 which is the latest I can see. The JAXB2 guys think it is likely to be something to do with the way surefire is loading classes. Looking at surefire I suspect this could be the case as it is using a custom isolated classloader which then loads the javax.xml namespace a second time (hence the error). The percise error is java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit( RuntimeBuiltinLeafInfoImpl.java:779) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init( RuntimeTypeInfoSetImpl.java:25) I am going to investigate - but any hints would be appreciated. Ben On 2/2/06, Jason van Zyl [EMAIL PROTECTED] wrote: Ben Gidley wrote: I am having issues with Maven running the unit tests on my project. The main error is http://maven.apache.org/plugins/maven-surefire-plugin/howto.html For forkMode you can specify once or pertest which really means per test case. I've added: http://jira.codehaus.org/browse/MSUREFIRE-55 and http://jira.codehaus.org/browse/MSUREFIRE-56 Sorry about the confusion. java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl .clinit( RuntimeBuiltinLeafInfoImpl.java:779) Looking at this list I can see a number of people have hit this and the solution is to fork the JVM for the unit tests. Looking at the surefire plugin documentation I have added the following to my POM plugin groupIdorg.apache.maven.plugins /groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModeeach/forkMode /configuration /plugin However this make no difference. I then suspected it may be not in the released version of the plugin - so I tried using the snapshot by adding pluginRepository idSnapshots/id nameSnapshots/name urlhttp://snapshots.maven.codehaus.org/maven2/ /url /pluginRepository and forcing the plugin version. This also appears to make no different. Looking at the code for the plugin in Subversion for surefire it does appear it supports forking and this is the way to turn in on. Am I doing something wrong to make it use the plugin? Has anyone got any ideas of how to get round this issue? Thanks Ben -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Forking with Surefire
I am having issues with Maven running the unit tests on my project. The main error is java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit( RuntimeBuiltinLeafInfoImpl.java:779) Looking at this list I can see a number of people have hit this and the solution is to fork the JVM for the unit tests. Looking at the surefire plugin documentation I have added the following to my POM plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModeeach/forkMode /configuration /plugin However this make no difference. I then suspected it may be not in the released version of the plugin - so I tried using the snapshot by adding pluginRepository idSnapshots/id nameSnapshots/name urlhttp://snapshots.maven.codehaus.org/maven2//url /pluginRepository and forcing the plugin version. This also appears to make no different. Looking at the code for the plugin in Subversion for surefire it does appear it supports forking and this is the way to turn in on. Am I doing something wrong to make it use the plugin? Has anyone got any ideas of how to get round this issue? Thanks Ben
[m2] site and site:deploy running tests twice.
I am trying to set up site/site deploy so that they automatically run during the deploy phase. However when I do this and have the surefire reports plugin it runs the tests twice - is there a way to stop it running the tests twice? I have got in plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId executions execution iddeploy/id phasedeploy/phase goals goalsite/goal goaldeploy/goal /goals /execution /executions /plugin Thanks Ben
Re: [m2] site and site:deploy running tests twice.
Nik, I have sent the the whole POM off list. The whole project is in CVS at scm:cvs:pserver:[EMAIL PROTECTED]:/cvsroot/zebra:zebra/src/java/zebra-hivemind It is quite odd - it may be some interaction with the other plugins. It does the initial source deploy. Then it runs site and that is when Surefire is kicked off again. Ben On 14/12/05, Nik Gonzalez [EMAIL PROTECTED] wrote: Ben, I can't replicate this. Please send your entire pom.xml. Thanks! Nik Ben Gidley wrote: I am trying to set up site/site deploy so that they automatically run during the deploy phase. However when I do this and have the surefire reports plugin it runs the tests twice - is there a way to stop it running the tests twice? I have got in plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId executions execution iddeploy/id phasedeploy/phase goals goalsite/goal goaldeploy/goal /goals /execution /executions /plugin Thanks Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help with upgrading a plugin
As a quick and dirty fix I add the following goal to the maven.xml of
our projects and tell people to run it if they get plugin problems
goal name=antelope:upgradePlugins
j:forEach var=dep items=${pom.dependencies}
j:if test=${dep.type =='plugin'}
maven:get plugin=${dep.artifactId}
property=plugin
var=plugin /
ant:echo
##
Fetching ${dep.artifactId} Plugin You may have to run your goal again
##
/ant:echo
j:set var=groupId
value=${dep.groupId}/
j:set var=artifactId
value=${dep.artifactId}/
j:set var=version
value=${dep.version}/
attainGoal name=plugin:download/
/j:if
/j:forEach
/goal
On Fri, 29 Oct 2004 06:35:28 +1000, Brett Porter [EMAIL PROTECTED] wrote:
I would suggest that the plugin dependency will work, but only if you
uninstall the original.
The mechanism has problems when two different versions of on plugin are loaded.
On Thu, 28 Oct 2004 09:34:35 -0700, Charles Daniels [EMAIL PROTECTED] wrote:
This is a known issue. Adding a plugin as a dependency doesn't quite
work as you might expect. In fact, in my experience, adding a plugin as
a dependency can cause other little problems. I suggest you remove the
plugin as a dependency and manually download the plugin via the
plugin:download goal. You should probably also manually delete the
plugin jar files from your MAVEN_HOME/plugins directory prior to running
plugin:download. If you simply stick to using plugin:download whenever
you wish to upgrade to a newer plugin version, your older version will
automatically be removed.
-Original Message-
From: Helck, Christopher [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 9:27 AM
To: Maven Users List
Subject: Need help with upgrading a plugin
Note: This is a repost/rephrasing of an ealier question I sent out.
Previous posts have led me to believe that I can upgrade a plugin by
specifying the plugin in my POM. I've tried this and it
partially works.
The new plugin is downloaded and installed in my local repository, but
Maven does not invoke the updated plugin. In this case I'm
trying to use
the latest version of the JXR plugin.
Here's the relevent parts of my POM:
dependencies
dependency
groupIdmaven/groupId
artifactIdmaven-jxr-plugin/artifactId
version1.4.2/version
typeplugin/type
/dependency
...
/dependencies
reports
reportmaven-jxr-plugin/report
...
/reports
When I run maven site and it tries to build the java cross
reference I
get the error:
BUILD FAILED
File /home/chelck/.maven/cache/maven-jxr-plugin-1.4.1/plugin.jelly
Version 1.4.2 of jxr is downloaded and in my cache next to
1.4.1. So why
isn't 1.4.2 being used?
Any ideas? Thanks,
-c. helck
The information contained in this e-mail is confidential.
This e-mail is intended only for the stated addressee. If
you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information
contained in this e-mail. if you have received this e-mail in
error, please inform us immediately and delete it and all
copies from your system.
EBS Dealing Resources International Limited. Registered
address: 55-56 Lincoln's Inn Fields, London WC2A 3LJ, United
Kingdom. Registered number 2669861.
EBS Dealing Resources, Inc, registered in Delaware. Address:
535 Madison Avenue, 24th Floor, New York, NY 10022, USA, and
One upper Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA.
EBS Dealing Resources Japan Limited, a Japanese Corporation.
Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa,
Chuo-Ku, Tokyo 104-0033, Japan.
-
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]
--
Thanks
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: strategy to retrieve the sources of an maven project
I would like to do this to and have started modifying the Eclipse
plugin to get sources from
the dist folder on the repository - unfortunately as far as I can tell
- there is no standard way of getting maven to download the dist
folder
When uploading you can use the goal to create maven:dist to create the
following files. Which I belive are meant to be uploaded to the repo
as follows
/foo/dist/foo-0.1.zip
/foo/dist/foo-0.1-src.zip
/foo/dist/foo-0.1.tar.gz
/foo/dist/foo-0.1-src.tar.gz
The src.zip version works fine when attatched to eclipse.
The zip/tar.gz versions contain classes and javadocs
The src.zip/tar.gz contain just source
If there was a easy way to fetch these modifying the eclipse plugin to
add them would be simple. But I cannot find an easy way to fetch them
- does anyone have any ideas?
Ben Gidley
On Mon, 25 Oct 2004 17:54:49 +0200, Krystian Nowak
[EMAIL PROTECTED] wrote:
Stéphane Nicoll wrote:
We have multiple maven projects used by different teams and they request us to
send soures as well (so that they can debug problems more deeply).
The idea would be to generate a artifact-src.jar as well and deploy it somewhere.
Is there a standard way to do this?
I was thinking about more automated approach:
When you publish your mavenized project you would be able to select if
you are publishing it as:
a) code (*.class) only,
b) code + javadoc
c) code + sources
and then if another project is using yours as dependency
the descriptor of such a dependency in project.xml would look like this:
dependency
groupIdfoo/groupId
artifactIdfoo-bar/artifactId
version1.4.1/version
properties
blah.plugin.srctrue/blah.plugin.src
blah.plugin.javadoctrue/blah.plugin.javadoc
/properties
/dependency
Having code + sources (c) we can generate javadoc and include in our
project's javadoc report. If developers are using Eclipse we can define
e.g. LIB_SRC variable and unpack in LIB_SRC directory all sources from
dependencies (if available).
It would require a unified file and/or directory structure on remove
repository (e.g. ibiblio). Let's say:
.../foo/jars/foo-bar-1.4.1.jar
.../foo/jars/foo-bar-1.4.1-src.jar
.../foo/jars/foo-bar-1.4.1-doc.jar
Of course automated deployment to create those jars is required, too.
Regards,
Krystian
--
Krystian Nowak
krystian{at}man{dot}poznan{dot}pl
===
Poznan Supercomputing and Networking Center
Poland, 60-814 Poznan, Zwierzyniecka 20
tel. (+48 61) 8582164 fax. (+48 61) 8582151
http://www.man.poznan.pl
===
BlueEyes - Human-Operator Monitoring System
http://www.blueeyes.prv.pl
http://www.cs.put.poznan.pl/csidc/2001
===
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
