R: problem with modifying bundled plugins in rc3
It seems to be related to how the plugins are loaded by maven. Try to run maven with the -X option to see if the vanilla jar file is loaded before the one that you modified. In that case it means that jelly scripting follows the same rules of classloading for the java classes. Bye -Messaggio originale- Da: Denis McLaughlin [mailto:[EMAIL PROTECTED] Inviato: venerdì 4 giugno 2004 6.06 A: [EMAIL PROTECTED] Oggetto: problem with modifying bundled plugins in rc3 Hi, I've begun to use Maven RC3, and have noticed a problem when trying to use a modified version of one of the plugins bundled with RC3. I've been discussing fixes to the javadoc plugin on the list. The patched javadoc plugin wasn't in RC3, but that's cool, I'm sure it'll be in the next release. However, because I need the new functionality, I had to patch the javadoc plugin that came with RC3. So I took a copy of the maven-javadoc-plugin-1.5.jar from MAVEN_HOME/plugins, unjarred it, modified the plugin.jelly file to get it to use maven.compile.src.set, rejarred it as maven-javadoc-plugin-1.5-dm1.jar and put it on my repository (maven.repo.remote). Then I went into my project and changed the project.xml to refer to my modified javadoc plugin. When I then ran a clean or a build, maven would install both the vanilla 1.5 plugin and my modified plugin in ~/.maven/plugins. However, when I actually executed the javadoc:generate goal, it used the goal as described by the vanilla 1.5 plugin, rather than using my modified plugin. This was in spite of my having made no mention in any project.xml files to the vanilla plugin, I was only specifying a dependency on my modified plugin. After playing with it, I found the following: - for any goal that was in the vanilla 1.5 plugin, but not in my modified plugin, the goal from the vanilla plugin would be used - for any goal that was in my modified plugin, but not in the vanilla 1.5 plugin, the goal from my modified plugin would be used - for any goal that was in both the vanilla 1.5 plugin and in my modified plugin, the goal from the vanilla plugin would be used To work around this problem, I deleted the vanilla 1.5 plugin from MAVEN_HOME/plugins: then only my modified plugin would be installed into ~/.maven, and the correct goal would be run. Anything I'm doing wrong? If this sounds like an unreported bug, I'll open a jira against it. Denis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. su www.tim.it - 119 Self Service -, puoi controllare il tuo traffico online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: retrieve the path of a particular artifact
-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
Sent: 03 June 2004 17:18
To: [EMAIL PROTECTED]
Subject: retrieve the path of a particular artifact
Hei,
I have tried to use cactus ant script within maven (without the
maven-cactus plugin, because I was offline and couldn't download it).
I managed to make it work.
At some point I needed to add some cactus libs (or dependencies) to
the
classpath, which required me to add a particular path.
I solved it doing the following:
j:forEach var=artifact items=${pom.artifacts}
j:if test=${artifact.dependency.artifactId =='httpunit'}
ant:property name=httpunit.path value=${artifact.path}/
echo message=found httpunit path ${httpunit.path}/
/j:if
[...]
/j:forEach
I guess there's something cleaner allowing to access directly an
artifact given its name or id.
Any idea?
Yes! Check the maven plugin jelly code for example... ;-)
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Variable overview
Hello all, I was wondering if any of you you know of a resource with an overview of the different maven variables? I.e i now of a variable : maven.test.mail.report an thought this might be documented under the properties of the test plugin - it isent! Any pointer are appreciated :) Jesper Linvald MAERSK DATA TRANSPORT Tel no.: +45 3911 1891 e-mail: [EMAIL PROTECTED]
Réf. : Variable overview
Hi the base properties are documented in http://maven.apache.org/reference/user-guide.html the plugin properties are on the Properties page of the related plugin J. Extranet [EMAIL PROTECTED] - 04/06/2004 11:26 Veuillez répondre à [EMAIL PROTECTED] Pour : users cc : Objet : Variable overview Hello all, I was wondering if any of you you know of a resource with an overview of the different maven variables? I.e i now of a variable : maven.test.mail.report an thought this might be documented under the properties of the test plugin - it isent! Any pointer are appreciated :) Jesper Linvald MAERSK DATA TRANSPORT Tel no.: +45 3911 1891 e-mail: [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: share properties within pre/postGoals
Good morning, I couldn't find a way other than persisting the old version into a temp file via ant:echo in the preGoal and load this file in the postGoal for further processing. However, this does the job for me. Cheers, Dominik On Thu, 2004-06-03 at 20:59, Dominik Dahlem wrote: Hi all, I'm wondering whether it is possible to set a property in preGoal and use it in postGoal without specifying it in any of the property files? I would like to retrieve the latest snapshot version of a component (via loadFile from jelly:util) in the preGoal of jar:deploy-snapshot to be able to remove this version in the appropriate postGoal from my repository which I keep in CVS. Additionally, I add the latest snapshot version (which has just been created) into CVS in the postGoal. With this approach I ensure that the repository in CVS is not polluted with lots of timestamped snapshot versions. I only want to keep the latest one. Thanks for any help. Dominik -- Dominik Dahlem [EMAIL PROTECTED] --- Trinity College Dublin Department of Computer Science, Dublin 2, Ireland tel: (+353) 1-608 1539 fax: (+353) 1-677 2204 www: http://www.cs.tcd.ie/Dominik.Dahlem/ --- signature.asc Description: This is a digitally signed message part
RE: [ANN] Mevenide releases
Eclipse RC1 is out today and is basically a bug fix release of M9 -Original Message- From: Rafal Krzewski [mailto:[EMAIL PROTECTED] Sent: 02 June 2004 13:15 To: Maven Users List Subject: Re: [ANN] Mevenide releases Maczka Michal wrote: Yeap! You right. I am almost sure that I read somewhere taht m9 = rc1. Almost right. M9 == RC0 Rafal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] .. BUPA . BUPA House, 15-19 Bloomsbury Way, London, WC1A 2BA . Internet communications are not secure and therefore BUPA does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of BUPA. .
RE: retrieve the path of a particular artifact
On Fri, 2004-06-04 at 04:59, Vincent Massol wrote:
-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
Sent: 03 June 2004 17:18
To: [EMAIL PROTECTED]
Subject: retrieve the path of a particular artifact
Hei,
I have tried to use cactus ant script within maven (without the
maven-cactus plugin, because I was offline and couldn't download it).
I managed to make it work.
At some point I needed to add some cactus libs (or dependencies) to
the
classpath, which required me to add a particular path.
I solved it doing the following:
j:forEach var=artifact items=${pom.artifacts}
j:if test=${artifact.dependency.artifactId =='httpunit'}
ant:property name=httpunit.path value=${artifact.path}/
echo message=found httpunit path ${httpunit.path}/
/j:if
[...]
/j:forEach
I guess there's something cleaner allowing to access directly an
artifact given its name or id.
Any idea?
Yes! Check the maven plugin jelly code for example... ;-)
In that file? maven-plugins/plugin/plugin.jelly
you mean that?
u:file var=localPluginFile
name=${maven.repo.local}/${groupId}/plugins/${artifactId}-${version}.jar /
Here I have to hardcode even more things. And it's dependant on the layout of the
local repos.
Maybe I misunderstood you?!
J
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
jar goal depending on test goal
Hi Is there any good reason for having the jar:jar depend on test:test? The problem I have with that is that, even if I make a very little change and want to check it on the application, I need to have the whole unit test suite executed for nothing. In addition, I can't get the jar file if all the tests do not succeed which is not very convenient on a developing phase. On the other way, I can accept the responsibility of ensuring that my test suite is fully executed before releasing the application jar file. I have the same comment regarding the site goal which will rerun all the tests, the coverage and so on even though nothing has changed. A very convenient feature should be to have some tunable which will allow me to execute a goal event if some of the dependencies have not been verified. An other solution should be to have some persistence on goals state, for example do not rerun the unit test suite if no source file has changed. Regards Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar goal depending on test goal
Frederic Gedin wrote: Hi Is there any good reason for having the jar:jar depend on test:test? The problem I have with that is that, even if I make a very little change and want to check it on the application, I need to have the whole unit test suite executed for nothing. In addition, I can't get the jar file if all the tests do not succeed which is not very convenient on a developing phase. On the other way, I can accept the responsibility of ensuring that my test suite is fully executed before releasing the application jar file. I have the same comment regarding the site goal which will rerun all the tests, the coverage and so on even though nothing has changed. A very convenient feature should be to have some tunable which will allow me to execute a goal event if some of the dependencies have not been verified. An other solution should be to have some persistence on goals state, for example do not rerun the unit test suite if no source file has changed. Regards Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Try setting the property maven.test.skip=true to skip running the tests and maven.test.failure.ignore=true to ignore failures in testing. Documented on the test plugin page http://maven.apache.org/reference/plugins/test/properties.html -- Erik Husby Team Lead for Software Quality Automation Broad Institute of MIT and Harvard Rm. 2192 320 Charles St Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar goal depending on test goal
Frederic, 1. Configure you POM to invoke a dummy test. 2. Create a testsuit to include all your test cases. 3 Invoke test:single goal against testsuite in step 2 as needed. This might do the trick. -Dan - Original Message - From: Frederic Gedin [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Sent: Friday, June 04, 2004 10:02 AM Subject: jar goal depending on test goal Hi Is there any good reason for having the jar:jar depend on test:test? The problem I have with that is that, even if I make a very little change and want to check it on the application, I need to have the whole unit test suite executed for nothing. In addition, I can't get the jar file if all the tests do not succeed which is not very convenient on a developing phase. On the other way, I can accept the responsibility of ensuring that my test suite is fully executed before releasing the application jar file. I have the same comment regarding the site goal which will rerun all the tests, the coverage and so on even though nothing has changed. A very convenient feature should be to have some tunable which will allow me to execute a goal event if some of the dependencies have not been verified. An other solution should be to have some persistence on goals state, for example do not rerun the unit test suite if no source file has changed. Regards Frédéric - 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]
Re: jar goal depending on test goal
On Fri, 2004-06-04 at 13:02, Frederic Gedin wrote: Hi Is there any good reason for having the jar:jar depend on test:test? Of course, in a default mode of operation why on earth would allow a JAR that might be distributed with running the tests. The problem I have with that is that, even if I make a very little change and want to check it on the application, I need to have the whole unit test suite executed for nothing. maven -Dmaven.test.skip=true and your tests won't be executed. In addition, I can't get the jar file if all the tests do not succeed which is not very convenient on a developing phase. On the other way, I can accept the responsibility of ensuring that my test suite is fully executed before releasing the application jar file. The default mode is that which makes most sense to us which is making sure a JAR doesn't get built that hasn't been tested. If you want to juggle shotguns then you can skip the tests with the simple setting of a property or you can turn the testing off by default and use a property to turn them on. I have the same comment regarding the site goal which will rerun all the tests, the coverage and so on even though nothing has changed. You can customize the reports and configure testing as mentioned above. A very convenient feature should be to have some tunable which will allow me to execute a goal event if some of the dependencies have not been verified. An other solution should be to have some persistence on goals state, for example do not rerun the unit test suite if no source file has changed. Certainly. More conveniences like that could be added. But for the most part all the issues you raised are already dealt with in the current version you are using. Regards Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar goal depending on test goal
Thanks for your answer and also for the others. I promise next time to have a better look on the documentation. The option based on maven.skip.test is fine for me. Regards Frederic Jason van Zyl a écrit : On Fri, 2004-06-04 at 13:02, Frederic Gedin wrote: Hi Is there any good reason for having the jar:jar depend on test:test? Of course, in a default mode of operation why on earth would allow a JAR that might be distributed with running the tests. The problem I have with that is that, even if I make a very little change and want to check it on the application, I need to have the whole unit test suite executed for nothing. maven -Dmaven.test.skip=true and your tests won't be executed. In addition, I can't get the jar file if all the tests do not succeed which is not very convenient on a developing phase. On the other way, I can accept the responsibility of ensuring that my test suite is fully executed before releasing the application jar file. The default mode is that which makes most sense to us which is making sure a JAR doesn't get built that hasn't been tested. If you want to juggle shotguns then you can skip the tests with the simple setting of a property or you can turn the testing off by default and use a property to turn them on. I have the same comment regarding the site goal which will rerun all the tests, the coverage and so on even though nothing has changed. You can customize the reports and configure testing as mentioned above. A very convenient feature should be to have some tunable which will allow me to execute a goal event if some of the dependencies have not been verified. An other solution should be to have some persistence on goals state, for example do not rerun the unit test suite if no source file has changed. Certainly. More conveniences like that could be added. But for the most part all the issues you raised are already dealt with in the current version you are using. Regards Frédéric - 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]
One simple quick question -- timestamp
Hi, What produces the timestamp on the maven website (on the upper left)? Ie: Last published: 20 May 2004 11:25 EDT | Doc for 1.0-rc3 Thanks, Mike -- Mike Sluyter [EMAIL PROTECTED]
Re: One simple quick question -- timestamp
checkout maven.xdoc.date property in maven-xdoc-plugin documentation - Original Message - From: Mike Sluyter [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] Sent: Friday, June 04, 2004 10:05 AM Subject: One simple quick question -- timestamp Hi, What produces the timestamp on the maven website (on the upper left)? Ie: Last published: 20 May 2004 11:25 EDT | Doc for 1.0-rc3 Thanks, Mike -- Mike Sluyter [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multi project
I'm trying the multi-project plugin for the first time and getting this error: BUILD FAILED File.. file:/home/wfausers/wfaoper/.maven/plugins/maven-multiproject-plugin-1.2/plu gin.jelly Element... maven:reactor Line.. 92 Column 9 Unable to obtain goal [site] -- file:/home/wfausers/wfaoper/.maven/plugins/maven-xdoc-plugin-1.6/plugin.jell y:345:54: j:include could not include jelly script : file://home/wfausers/wfaoper/.maven/plugins/maven-xdoc-plugin-1.6/plugin-res ources/site.jsl. Reason: org.apache.commons.jelly.JellyException: null:-1:-1: nul l Could not parse Jelly script Does anyone have an idea about what I need to do to fix this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi project
You have an old version of xdoc plugin and maven aswell.
Try to wipe out your ${user.home}.maven/plugin dir, remove
your maven and install maven 1.0 rc2
hope it helps
-D
- Original Message -
From: STRAYER, JON (SBCSI) [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Friday, June 04, 2004 1:26 PM
Subject: Multi project
I'm trying the multi-project plugin for the first time and getting this
error:
BUILD FAILED
File..
file:/home/wfausers/wfaoper/.maven/plugins/maven-multiproject-plugin-1.2/plu
gin.jelly
Element... maven:reactor
Line.. 92
Column 9
Unable to obtain goal [site] --
file:/home/wfausers/wfaoper/.maven/plugins/maven-xdoc-plugin-1.6/plugin.jell
y:345:54: j:include could not include jelly script
:
file://home/wfausers/wfaoper/.maven/plugins/maven-xdoc-plugin-1.6/plugin-res
ources/site.jsl. Reason: org.apache.commons.jelly.JellyException:
null:-1:-1: nul
l Could not parse Jelly script
Does anyone have an idea about what I need to do to fix this?
-
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]
Problem using Maven jaxb plugin
I am getting the following error when using maven jaxb plugin to generate source code from the xsd files. Any idea? Note that I am trying to use this plgin with JAXB 1.0.2, since i couldn't find a way to download JAXB 1.0.0 from the sun site. Any idea how i can obtain JAXB 1.0.0? Thanks, -Rakesh ;- BUILD FAILED File.. D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly Element... xjc Line.. 34 Column 49 org/relaxng/datatype/ValidationContext com.werken.werkz.UnattainableGoalException: Unable to obtain goal [jaxb:generate ] -- D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationContext at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: D:\Profiles\rakmoh\.maven\plugins\ma ven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationCon text at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.jav a:702) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
Cactus plugin classpath for compilation
I've got a multiproject-based Maven setup. Currently, there's only one EJB
(more coming after I get all the build kinks like this one ironed out), and
that gets built into an EAR.
/
+-root/
+-project.xml
+-project.properties
+-maven.xml
+-EJB/
+-project.xml
+-project.properties
+-maven.xml
+-src/
+-java/
+-mycp/
+-MyBean.java
+-EAR/
+-project.xml
+-project.properties
+-maven.xml
+-src/
+-test-cactus/
+-mycp/
+-test/
+-MyBeanTest.java
I may be misunderstanding how/where to put and run the cactus tests... my
first inclination was to put it in the EJB folder next to the Bean
implementation. However, that project's goal is a .jar file (with the EJB), so
I can't build an EAR there also. But when I run maven cactus:test-ear in the
EAR/ directory, or maven multiproject:site in the / directory (which runs
the cactus:test-ear goal in the EAR/ directory), javac is unable to find the
EJB's jar file, even though I have it configured as a dependency in EAR/
project.xml.
I've got a preGoal on cactus:compile that echos a bunch of classpaths, which
are all empty: ${cactus.classpath}, ${maven.classpath},
${maven.ear.classpath}, ${maven.war.classpath}, ${classpath},
${maven.dependency.classpath}
Is there a way I can explicitly add the EJB's jar file (which is in the local
repository), or is there a way to get cactus to create a correct EAR file for
testing as a goal of the EJB project and still have the normal goal create
the standard EJB jar file?
Thanks!
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Al Robertson is out of the office.
I will be out of the office starting 05/06/2004 and will not return until 14/06/2004. I will respond to your message when I return. div style=width:450px; border-top: 1px solid black; border-bottom: 1px solid black; font-family: Arial; font-size: 8pt pThis email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.nbsp; If you have received this email in error please notify your system administrator. br/br/While attachments are virus checked, Digital Union UK Limited does not accept any liability in respect of any virus which is not detected./p /div
Re: Problem using Maven jaxb plugin
I wrote a patch for the JAXB plugin and submitted it that upgrades the plugin to JAXB 1.0.2. You can find it on the sourceforge site. It does require you to include all the JAXB jars in your project.xml, though, which is a mistake on my part. I should have picked them up in the plugin. Of course, you'll need some of the dependencies to run your code after you've compiled it anyway. I can't remember all the dependencies off the top of my head, but some of them are: relaxngDatatype xml-apis xerces jaxb-api jaxb-impl jaxb-libs jaxb-xjc You can find all these jars and more in the JWSDP. That being said, I have no idea where to find the 1.0.0 version of JAXB, except searching the sun archives. I believe JAXB 1.0.0 files are compatible with 1.0.2, but I know 1.0.2 files can not be used with 1.0.0. Personally, I've moved away from JAXB and towards Castor. Castor generated objects can be easily integrated into web services, while JAXB objects currently can not. Of course, the Castor plugin for maven doesn't work very well either, so pick your poison. HTH, WM PS, I searched high and low on the sun archives and couldn't find the old version of the JWSDP, I've had that problem before, but eventually found it, good luck! --- Rakesh Arora [EMAIL PROTECTED] wrote: I am getting the following error when using maven jaxb plugin to generate source code from the xsd files. Any idea? Note that I am trying to use this plgin with JAXB 1.0.2, since i couldn't find a way to download JAXB 1.0.0 from the sun site. Any idea how i can obtain JAXB 1.0.0? Thanks, -Rakesh ;- BUILD FAILED File.. D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly Element... xjc Line.. 34 Column 49 org/relaxng/datatype/ValidationContext com.werken.werkz.UnattainableGoalException: Unable to obtain goal [jaxb:generate ] -- D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationContext at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: D:\Profiles\rakmoh\.maven\plugins\ma ven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationCon text at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.jav a:702) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at
