Re: Creating a .wsr file artifact
Eric, I'm getting to this a little late as it appears you've already created the plugin, but there are the jboss-sar and jboss-packaging plugins over at mojo.codehaus.org that, more or less, do what you have done. The jboss-packaging plugin is intended to supercede the jboss-sar plugin and support SAR, HAR, PAR, .spring, etc JBoss deployable packagings. It would be nice to combine your WSR code into that plugin. There is currently a problem with the jboss-packaging plugin though. Since all these packagings are JBoss-specific, I've been trying to use packaging values jboss-sar, jboss-har, etc. instead of simply sar, har, etc to denote their specific usage. Unfortunately, the packaging appears to be coupled to the deployed artifact extension (e.g., deploying a jboss-sar packaged project, uses jboss-sar as the dpelyed artifact extension), which makes a bit of sense, but is limitting. Since all these packagings are just jar files with a specific deployment descriptor and file extension, perhaps they all should be considered attached artifacts with the promary artifact being the jar. This would at least solve the packaging/deploy extension coupling "problem". Sorry some of this is OT to maven-dev, but I'd really like to see the jboss-packaging mojo inherit your WSR code, and be stablized for a release. Regards, Doug On 10/7/06, Swenson, Eric <[EMAIL PROTECTED]> wrote: Thanks very much, Wendell. I finally have everything working correctly. I actually had two things wrong -- I didn't have the in my project's pom and the life-cycle () in my plugin had a couple mistakes. Thanks again for your help. -- Eric -Original Message- From: Wendell Beckwith [mailto:[EMAIL PROTECTED] Sent: Saturday, October 07, 2006 3:09 AM To: Maven Developers List Subject: Re: Creating a .wsr file artifact IIRC those are "standard" mappings and they are defined inside the components.xml defined in the maven-core plugin in your /lib directory. Because your plugin is not a "standard" plugin you have to use the element with your plugin declaration in the pom of the project that uses the maven-wsr-plugin so that maven knows to look for lifecycle enahncements in the plugin. Wb On 10/7/06, Swenson, Eric <[EMAIL PROTECTED]> wrote: > > I looked in both the maven-jar-plugin and the maven-war-plugin and don't > see any components.xml. Yet these both appear to define a default life > cycle mapping (somehow). -- Eric > > -Original Message- > From: Swenson, Eric > Sent: Friday, October 06, 2006 11:56 PM > To: Maven Developers List > Subject: RE: Creating a .wsr file artifact > > Thanks Nathan. But I'm still not getting anywhere. I assume what > you're saying is that I need to add a META-INF/plexus/components.xml to > my plugin jar. I've done that (but perhaps the contents is still not > right), but I still get the error message, upon doing an "mvn compile" > or "mvn package" that says: > > [INFO] Cannot find lifecycle mapping for packaging: 'wsr'. > Component descriptor cannot be found in the component repository: > org.apache.maven.lifecycle.mapping.LifecycleMappingwsr. > > If I do see the META-INF/plexus/components.xml in my maven-wsr-plugin > jar file. > > Also, I modeled my maven-wsr-plugin after maven-war-plugin (I started > with the same codebase and removed the web.xml-related stuff and > replaced with web-service.xml-related stuff). And maven-war-plugin > doesn't have a components.xml in it. So why does maven-war-plugin allow > me to do "mvn compile" and "mvn package" but maven-wsr-plugin doesn't? > Is there some other registry that needs updating? When I install the > plugin in the repository, do I need any special steps or is the "mvn > install" (on the maven-wsr-plugin project) enough? > > Thanks. -- Eric > > -Original Message- > From: Nathan Beyer [mailto:[EMAIL PROTECTED] > Sent: Friday, October 06, 2006 9:43 PM > To: Maven Developers List > Subject: Re: Creating a .wsr file artifact > > Check out the CustomArtifactHandler part of this guide [1]. I think > what you're missing is an "extension" [2] element in your POM. > > -Nathan > > [1] > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl > e.html > [2] > http://maven.apache.org/ref/current/maven-model/maven.html#class_extensi > on > > On 10/6/06, Swenson, Eric <[EMAIL PROTECTED]> wrote: > > Well, I've made progress since my post. However, I still have an > issue. > > I now have a maven-wsr-plugin, which I based on maven-war-plugin and > I'm > > able to compile my project with: > > > > mvn compiler:compile > > > > and package my project (into a .wsr file) with: > > > > mvn wsr:wsr > > > > However, what I can't do is perform the compile/package/install > > automatically by simply doing: > > > > mvn install > > > > This works for jar and war files. But for my wsr files, it doesn't. > > When I attempt either an: > > > > mvn compile > > > > or > > > > mvn install > > > > I get the
Re: Classloading problem with Maven2 plugin
See the mojo API spec. [1], specifically the requiresDependencyResolution annotation. Doug [1] http://maven.apache.org/developers/mojo-api-specification.html On 9/5/06, Joost den Boer <[EMAIL PROTECTED]> wrote: I have created a plugin to run an application. The plugin needs the classes of the Pom project and dependencies to run. When I first run the plugin I noticed Maven hadn't put the current project and all dependencies on the classpath. Why not? Is this a bug ? I searched all over the maven.apache site, but I can't find anything which would enable Maven to do this. I tried several solutions with a custom classloader or ClassWorld, but the application will still not run. I now get a NoClassDefException for org.apache.log4j.Logger, but I can also see that my custom classloader has loaded it. Please, I already waisted 2 days on this. I could really need some help. Regards, Joost
Re: [PATCH] add correct ejb-client to war if configured in dependency
Andreas,
I responded. My only advice is that you attach this patch to one of the war
plugin JIRA issues that you cited. Add a comment to the other issue for
completeness. Patches sent to the mailing list(s) will probably get little
reaction.
Just my .02$,
Doug
On 8/10/06, Andreas Wüst <[EMAIL PROTECTED]> wrote:
Hello,
since nobody responded on the user mailing list i am trying it with the
dev
list. the patch is related to the following ones :
http://jira.codehaus.org/browse/MWAR-59
http://jira.codehaus.org/browse/MWAR-38
Attached you will find a patch that will allow the maven-war-plugin
to add a ejb-client created by the maven-ejb-plugin. With the
latest cvs snapshot it is not possible to add the ejb client to the
war, always the ejb.jar will be added to the war file what is not
really inteded. the project looks like :
Parent
- Project A (Ejb)
- Project B (War)
this dependency will only add the ejb(server).jar to the war file.
What i really want is that the created ejb-client.jar is added to the
war.
adding the ejb(server).jar to the war file does not make sense for the
war file.
(the maven-ejb-plugin created a server and client version for the
de.blubb.project_name.ejb projekt,
which is actually another module of my project)
de.blubb.project_name
ejb
1.0
ejb-client
If the patch is obsolete, i was wondering if there is anybody out
there who is using the maven-ejb-plugin in combination with
the maven-war-plugin and is actually adding the
created ejb-client to the created war file successfully.
As far as i can tell the maven-ejb-plugin creates a client (if
requested) with the name --client.jar. however
the maven-war-plugin does not respect the "-client" in the client's
name. even if i set the "type" of the dependency to "ejb-client"
it is still getting the "ejb.jar", not the "ejb-client.jar". My
patch fixes this problem.
i can provide a testcase that shows the current problem, if requested.
feedback is really appreciated.
regards,
Andy
Index:
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
===
---
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
(revision
430070)
+++
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
(working
copy)
@@ -478,7 +478,7 @@
File expectedWebSourceFile = new File( webAppDirectory, "
pansit.jsp" );
File expectedWebSource2File = new File( webAppDirectory,
"org/web/app/last-exile.jsp" );
// final name form is -.
-File expectedEJBArtifact = new File( webAppDirectory,
"WEB-INF/lib/ejbclientartifact-0.0-Test.jar" );
+File expectedEJBArtifact = new File( webAppDirectory,
"WEB-INF/lib/ejbclientartifact-0.0-Test-client.jar" );
assertTrue( "source files not found: " +
expectedWebSourceFile.toString(), expectedWebSourceFile.exists() );
assertTrue( "source files not found: " +
expectedWebSource2File.toString(), expectedWebSource2File.exists() );
@@ -488,7 +488,7 @@
expectedWebSourceFile.delete();
expectedWebSource2File.delete();
expectedEJBArtifact.delete();
-}
+}
Index:
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
===
---
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(revision
430070)
+++
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(working
copy)
@@ -1022,8 +1022,15 @@
*/
private String getDefaultFinalName( Artifact artifact )
{
-return artifact.getArtifactId() + "-" + artifact.getVersion() +
"." +
-artifact.getArtifactHandler().getExtension();
+String type = artifact.getType();
+if ("ejb-client".equals( type )) {
+ return artifact.getArtifactId() + "-" + artifact.getVersion() +
"-" + "client" +
+ "." +
+ artifact.getArtifactHandler().getExtension();
+} else {
+ return artifact.getArtifactId() + "-" + artifact.getVersion() +
"." +
+ artifact.getArtifactHandler().getExtension();
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] How to deploy snapshots of plugins to internal repositories?
I typically just make a copy of the pom and modify it for our repositorier, then use mvn -f my-new-pom.xml. Not elegant, but effective. HTH, Doug On 7/20/06, Barrie Treloar <[EMAIL PROTECTED]> wrote: On 7/21/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: > You don't seem to have specified a (custom) repositoryId, which needs to map to the id in your > settings.xml, which contains the credentials of your scp connection (like username and private key > or password). Hmm, seems fair. However once I created a server for apache.snapshots in settings.xml to point to our internal repository I was still getting the same error. I'm wondering whether I can override the deploymentRepository on the command line. In the end I hacked the pom to point to it instead... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1] Status of 1.1 release
Arnaud, I'm trying to produce a failing test for MAVEN-1549 using maven 1.0.2. Unfortunately, like Bretts comment to MAVEN-1321 (which 1549 duplicates), I'm unable to reproduce the problem. I'll poke at it some more, but if I can't reproduce it, I'll have nothing to add to the touchstone tests. Doug Arnaud HERITIER wrote: Hi Doug, Thanks a lot for your help. Your testcases are very useful for us to close the issues. Can you try (when possible) to create your tests in the touchstone-build : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/ It will help us to ensure that these issues never come back. For example for the issue MAVEN-1691 I created a testcase : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/overlappedCalls/ When this issue will be fix, I'll activate it. What you need to do it's to automate your test to fail if the issue exists. Can you try to do it for example for MAVEN-1549 ? Thanks Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1] Status of 1.1 release
Hi Arnaud, Sure thing, that does seem a much better place to put these things. I presume I should then do an svn diff and attach the patch to the issue, or is there another way for the test case to get committed? Cheers, Doug Arnaud HERITIER wrote: Hi Doug, Thanks a lot for your help. Your testcases are very useful for us to close the issues. Can you try (when possible) to create your tests in the touchstone-build : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/ It will help us to ensure that these issues never come back. For example for the issue MAVEN-1691 I created a testcase : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/overlappedCalls/ When this issue will be fix, I'll activate it. What you need to do it's to automate your test to fail if the issue exists. Can you try to do it for example for MAVEN-1549 ? Thanks Arnaud -- Norman "Doug" Douglass Director of Engineering Denver Data Systems, Inc. Office: (303) 534-1745 Fax: (303) 534-2745 E-mail: mailto:[EMAIL PROTECTED] Web: http://www.denverdata.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1626) j:file not allowing in its body
[ http://jira.codehaus.org/browse/MAVEN-1626?page=comments#action_5 ] Doug Douglass commented on MAVEN-1626: -- working with Lukas via irc on this...It appears to be a JDK issue. I originally was testing with sun jdk1.5.0_04, switched to sun j2sdk1.4.2_08 and the test project failed as per Lukas' observation. Note I tested with jdk1.5.0_04 on both Red Hat Linux Workstation 3, Windows XP -- project works on both. Only tested j2sdk1.4.2_8 on RH > j:file not allowing in its body > --- > > Key: MAVEN-1626 > URL: http://jira.codehaus.org/browse/MAVEN-1626 > Project: Maven > Type: Bug > Versions: 1.1-beta-1 > Environment: maven-1.1-b1 > Reporter: Dan Tran > Fix For: 1.1-rc1 > Attachments: MAVEN-1626-test-propject.tar.gz > > > This code (in my maven.xml) works in 1.0.2. See like a conflict with > maven.xml's project element. No problem when rename project to someelse. > I also try to ecsape it ( use < and >, etc). got parsing error > xmlns="dummy"> > Maven generated file, do not checkin > > > > > here is the error > BUILD FAILED > File.. C:\Documents and > Settings\dtran\.maven\cache\maven-multiproject-plugi > n-1.4.1\plugin.jelly > Element... maven:reactor > Line.. 104 > Column -1 > Unable to obtain goal [site] -- > M:\dtran_everest_int\OpCenter\eclipse\plugins\co > mmon\maven.xml:60:-1: > M:\dtran_everest_int\OpCenter\eclipse\plugins\com > mon\maven.xml:63:-1: This tag does not understand the 'name' > attribute -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-1626) j:file not allowing in its body
[ http://jira.codehaus.org/browse/MAVEN-1626?page=all ] Doug Douglass updated MAVEN-1626: - Attachment: MAVEN-1626-test-propject.tar.gz > j:file not allowing in its body > --- > > Key: MAVEN-1626 > URL: http://jira.codehaus.org/browse/MAVEN-1626 > Project: Maven > Type: Bug > Versions: 1.1-beta-1 > Environment: maven-1.1-b1 > Reporter: Dan Tran > Fix For: 1.1-rc1 > Attachments: MAVEN-1626-test-propject.tar.gz > > > This code (in my maven.xml) works in 1.0.2. See like a conflict with > maven.xml's project element. No problem when rename project to someelse. > I also try to ecsape it ( use < and >, etc). got parsing error > xmlns="dummy"> > Maven generated file, do not checkin > > > > > here is the error > BUILD FAILED > File.. C:\Documents and > Settings\dtran\.maven\cache\maven-multiproject-plugi > n-1.4.1\plugin.jelly > Element... maven:reactor > Line.. 104 > Column -1 > Unable to obtain goal [site] -- > M:\dtran_everest_int\OpCenter\eclipse\plugins\co > mmon\maven.xml:60:-1: > M:\dtran_everest_int\OpCenter\eclipse\plugins\com > mon\maven.xml:63:-1: This tag does not understand the 'name' > attribute -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1626) j:file not allowing in its body
[ http://jira.codehaus.org/browse/MAVEN-1626?page=comments#action_57763 ] Doug Douglass commented on MAVEN-1626: -- unable to duplicate this issue with latest 1.1-beta-3 built from trunk. See attached project to test the issue > j:file not allowing in its body > --- > > Key: MAVEN-1626 > URL: http://jira.codehaus.org/browse/MAVEN-1626 > Project: Maven > Type: Bug > Versions: 1.1-beta-1 > Environment: maven-1.1-b1 > Reporter: Dan Tran > Fix For: 1.1-rc1 > Attachments: MAVEN-1626-test-propject.tar.gz > > > This code (in my maven.xml) works in 1.0.2. See like a conflict with > maven.xml's project element. No problem when rename project to someelse. > I also try to ecsape it ( use < and >, etc). got parsing error > xmlns="dummy"> > Maven generated file, do not checkin > > > > > here is the error > BUILD FAILED > File.. C:\Documents and > Settings\dtran\.maven\cache\maven-multiproject-plugi > n-1.4.1\plugin.jelly > Element... maven:reactor > Line.. 104 > Column -1 > Unable to obtain goal [site] -- > M:\dtran_everest_int\OpCenter\eclipse\plugins\co > mmon\maven.xml:60:-1: > M:\dtran_everest_int\OpCenter\eclipse\plugins\com > mon\maven.xml:63:-1: This tag does not understand the 'name' > attribute -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-1549) Excution of pregoals twice.
[ http://jira.codehaus.org/browse/MAVEN-1549?page=all ] Doug Douglass updated MAVEN-1549: - Attachment: MAVEN-1549-test-multiproject.tar.gz > Excution of pregoals twice. > --- > > Key: MAVEN-1549 > URL: http://jira.codehaus.org/browse/MAVEN-1549 > Project: Maven > Type: Bug > Components: core > Versions: 1.0.2 > Environment: Windows NT4, SDK1.4.2-04 > Reporter: Kihn M. Jensen > Fix For: 1.1-beta-3 > Attachments: MAVEN-1549-test-multiproject.tar.gz > > > When definig pregoals in a maven.xml, which is inherited through the > project.xml in more than one level, the pregoals are executed twice. > If the pregoals are defined in the first level of inheritence the goals are > only executed once. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M1] Status of 1.1 release
Hey gang, What's the status of a 1.1 release? I thought a release or rc was eminent, but I may have confused that with all the recent plugin discussions. I've got some free time and would really like to assist, but in reviewing JIRA issues for 1.1-beta-3 and 1.1-rc1 I'm finding it hard to jump in. Many issues appear to either be in progress or comments indicate some resolution but the issue is still open. Any quick pointers are appreciated, plugin issues qualify too. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m1] status of MPPLUGIN-21: Autogenerate plugin.properties and properties documentation
Carlos, What's the status of http://jira.codehaus.org/browse/MPPLUGIN-21 ? Is the patch going to be applied/is the plugin-properties.xml going to be the future? I ask because I was just about to create a new issue and submit a patch to allow the plugin:generate-properties to properly generate the properties.xml file for all (and only) the properties in plugin.properties, not just those that begin with 'maven.'. I like the plugin-properties.xml as proposed by the current patch. If it will document plugin properties regardless of the 'maven.' prefix, then I'll hold off on creating the issue and test the existing patch. TIA, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] source plugin
Stephane Nicoll wrote: Once this is done, you'll be able to download On 1/15/06, Doug Douglass <[EMAIL PROTECTED]> wrote: Sure that works, presuming you have the source in a local project in which you can run source:install. But, if the source jar is in a remote repo already, I don't currently see a way to download that jar to the local repo via either the eclipse or the source plugin. You need to take the latest version of the eclipse plugin (1.11-SNAPSHOT). I don't think it's deployed so you'll have to rebuild it from SVN. Running the eclipe goal with this version will download the sources from the remote repository. Thanks, Stéphane AH! There it is. Appears to work very well. Nicely done, a good addition to m1. Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] source plugin
Stephane Nicoll wrote: On 1/14/06, Doug Douglass <[EMAIL PROTECTED]> wrote: The only problem I see is that the eclipse plugin does not install the sources in the local repository, thus making it appear that it does not work. Perhaps this is the reason it's not working for you Arnaud? What do you mean? To install the source in the local repo, source:install Sure that works, presuming you have the source in a local project in which you can run source:install. But, if the source jar is in a remote repo already, I don't currently see a way to download that jar to the local repo via either the eclipse or the source plugin. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] source plugin
Arnaud, Stéphane, Install and deploy of sources appears to work well. Setup of the eclipse .classpath sourcepath attributes looks good, also. The only problem I see is that the eclipse plugin does not install the sources in the local repository, thus making it appear that it does not work. Perhaps this is the reason it's not working for you Arnaud? HTH, Doug Arnaud HERITIER wrote: Did you see my comment about your commit on the eclipse plugin (some hours ago) It doesn't work at all for me. Arnaud On 1/14/06, Stephane Nicoll <[EMAIL PROTECTED]> wrote: Hi, I've just deployed a snapshot of the maven one source plugin (1.0-SNAPSHOT). Web site is located here http://people.apache.org/~snicoll/maven-source-plugin/ Could you please review it? I'd like to call for a vote to release the plugin. Note that the eclipse plugin has been updated to fully integrate java sources archives (e.g. download them from the repo). See MPECLIPSE-60 for more details. Thanks, Stéphane -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPANNOUNCEMENT-20) Fatal Error [line 31, row 37]: Attribute "ant" bound to namespace "http://www.w3.org/2000/xmlns/" was already specified for element "project"
Fatal Error [line 31, row 37]: Attribute "ant" bound to namespace "http://www.w3.org/2000/xmlns/"; was already specified for element "project" - Key: MPANNOUNCEMENT-20 URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-20 Project: maven-announcement-plugin Type: Bug Versions: 1.4 Environment: Linux otis 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux java version "1.5.0_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing) __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-2 Reporter: Doug Douglass There are duplicate xmlns declarations for ant on the project element in the plugin.jelly (e.g., xmlns:ant="jelly:ant") Removing one declaration fixes the fatal error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m1 plugin.resources when using tags across plugins
Thanks for the tip Lukas, I haven't explored the maven tags much, except the reactor and copyResources. seems appropriate in your case where you need access to another plugins resources, but it smells funny for a plugin to have to go to extra means to access it's own resources because it's being called indirectly (via a tag it defines)...that's essentially saying that a plugin should not rely on the value of plugin.resources pointing to it's own resources. Perhaps I've designed/separated my plugins incorrectly. plugin-A is providing the means to "compile" a resource via both a goal (a:compile) and a tag (also a:compile). The reason for the tag is so that different input and output directories, along with a compilation "strategy" can be passed as attributes instead of relying on properties, which may have different values depending on the plugin calling the tag. For example, plugin-A defaults to pom.build.sourceDirectory as the input directory, while plugin-B defaults to pom.build.unitTestSourceDirectory. My current plugin functionality is close enough for now that I might just forego this problem and begin the move to Mojo. doug Lukas Theussl wrote: In the pdf plugin I use this to access some resources from the xdoc plugin: var="xdoc.plugin.resources" /> HTH -Lukas Doug Douglass wrote: I know, m1 (1.0.2) and plugin.jelly is old hat, but I need a little help. Here's the scenario... 1) plugin-A defines tag a:foo which uses resources provided with the plugin. 2) plugin-B uses tag a:foo to do some work. 3) plugin-B fails with error from within plugin-A saying that the resources "local" to plugin-A cannot be found. It's obvious that the plugin.resources property is being set once for the currently executing plugin. Therefore, in the scenario above plugin.resources is providing the path to plugin-Bs resources. So, how should such a situation be handled (besides re-writing in a Mojo and moving to m2 ;) ? TIA, Doug - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m1 plugin.resources when using tags across plugins
I know, m1 (1.0.2) and plugin.jelly is old hat, but I need a little help. Here's the scenario... 1) plugin-A defines tag a:foo which uses resources provided with the plugin. 2) plugin-B uses tag a:foo to do some work. 3) plugin-B fails with error from within plugin-A saying that the resources "local" to plugin-A cannot be found. It's obvious that the plugin.resources property is being set once for the currently executing plugin. Therefore, in the scenario above plugin.resources is providing the path to plugin-Bs resources. So, how should such a situation be handled (besides re-writing in a Mojo and moving to m2 ;) ? TIA, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m2 plugin developement/testing Qs
In house we've got some pretty simple m1 plugins that deal with PHP webapps/source files: * phpdoc reporting plugin * php compiler/optimizer/obfuscater plugin * some general file/resource copying goals that build a WAR-like structure Not that I'm a huge fan of PHP, but if a customer wants me/us to use it, then I want a stable, repeatable build/test/deploy procedure ;) These plugins require some enhancements so I figured I'd move the logic to Mojos, with the understanding that I could wrap the Mojos with jelly for continued use on m1 projects. My questions are: 1) To test a plugin, other than Mojo unit testing, is it required that the plugin be installed first (like m1)? Or, is there a way to instantiate a project programmatically using a test POM and call a goal to be tested from within the plugin development project? 2) Any pointers to an example of a wrapping a Mojo with jelly for use with m1? 3) Are there any "gotchas" to avoid when attempting to write a single plugin for m1 and m2? Or, should I just maintain two versions? Also, I'm considering the possibility of adding support for a new dependency type (phar or pear) to keep this cruft out of our SCM. Is type support added via plugins? Oh, most importantly, anyone know of any existing efforts such as the above? I'd hate to reinvent the wheel. Thanks always, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-685) FAQ about compiling with Java 1.5 are incomplete.
[ http://jira.codehaus.org/browse/MNG-685?page=comments#action_46536 ] Doug Douglass commented on MNG-685: --- DOXIA-16 fix appears to have resolved this issue. The example http://maven.apache.org/maven2/general.html#Compiling-J2SE-5 now appears complete. > FAQ about compiling with Java 1.5 are incomplete. > - > > Key: MNG-685 > URL: http://jira.codehaus.org/browse/MNG-685 > Project: Maven 2 > Type: Bug > Components: documentation > Versions: 2.0-alpha-3 > Reporter: Ken Weiner > Priority: Minor > Fix For: 2.0-beta-2 > > > The example on how to compile with Java 1.5 is incomplete. > http://maven.apache.org/maven2/general.html#Compiling-J2SE-5 > The HTML renders the following: > > ... > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > It should actually render: > > ... > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > > > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
