Oddness with release:prepare
This is with maven 2.0.9 on Solaris 10 with Java 1.6.0_11 I have a project laid out thusly: myproject/pom.xml myproject/myproject-pom/pom.xml myproject/myproject-api/pom.xml myproject/myproject-common/pom.xml myproject/myproject-console/pom.xml The top-level pom is a minimal parent pom whose only module is myproject/myproject-pom. myproject/myproject-pom/pom.xml exists because Eclipse doesn't like nested projects. So this pom has things that would typically need to be changed. All of the other myproject/myproject-*/pom.xml are modules of myproject/myproject-pom/pom.xml. When I execute 'mvn release:prepare' things go well until it begins invoking subversion. Here is the relevant bit of output from the process: (sorry for the long lines) [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive commit --file /var/tmp/maven-scm-1461319678.commit --targets /var/tmp/maven-scm-7441525038114668907-targets [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom svn --non-interactive commit --file /var/tmp/maven-scm-1292675052.commit --targets /var/tmp/maven-scm-6618196211309587095-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-api svn --non-interactive commit --file /var/tmp/maven-scm-1794995489.commit --targets /var/tmp/maven-scm-2050429634740604341-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-api [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-common svn --non-interactive commit --file /var/tmp/maven-scm-786958246.commit --targets /var/tmp/maven-scm-636982206221127-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-common [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-console svn --non-interactive commit --file /var/tmp/maven-scm-637551884.commit --targets /var/tmp/maven-scm-3757207476498104603-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-console [INFO] Tagging release with the label myproject-1.0... [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive copy --file /var/tmp/maven-scm-1862162340.commit . http://my-svn-server:/svn/myrepo/myprojects/tags/myproject-1.0 [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: File '/svn/myrepo/myprojects/tags/myproject-1.0/myproject-common/pom.xml' already exists After investigating a while and trying to reproduce the process manually, I discovered that the error message is somewhat misleading. If I do an 'svn update' prior to the 'svn copy' then the process completes successfully. I put a shell script named 'svn' in my path in front of /usr/local/bin and had that script do an 'svn update' when it sees an 'svn copy' request. Invoking 'mvn release:prepare' with that in place will succeed. Has anybody else seen this kind of behavior? Is there a better solution than my hack of a workaround: $ cat ~/bin/svn #!/bin/bash echo $@ ~/svn.log if [ $1 = --non-interactive -a $2 = copy -a $3 = --file ] then /usr/local/bin/svn update fi exec /usr/local/bin/svn $@ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Oddness with release:prepare
(Forgive me if this is a double-post. I had to re-subscribe to the list.) This is with maven 2.0.9 on Solaris 10 with Java 1.6.0_11 I have a project laid out thusly: myproject/pom.xml myproject/myproject-pom/pom.xml myproject/myproject-api/pom.xml myproject/myproject-common/pom.xml myproject/myproject-console/pom.xml The top-level pom is a minimal parent pom whose only module is myproject/myproject-pom. myproject/myproject-pom/pom.xml exists because Eclipse doesn't like nested projects. So this pom has things that would typically need to be changed. All of the other myproject/myproject-*/pom.xml are modules of myproject/myproject-pom/pom.xml. When I execute 'mvn release:prepare' things go well until it begins invoking subversion. Here is the relevant bit of output from the process: (sorry for the long lines) [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive commit --file /var/tmp/maven-scm-1461319678.commit --targets /var/tmp/maven-scm-7441525038114668907-targets [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom svn --non-interactive commit --file /var/tmp/maven-scm-1292675052.commit --targets /var/tmp/maven-scm-6618196211309587095-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-api svn --non-interactive commit --file /var/tmp/maven-scm-1794995489.commit --targets /var/tmp/maven-scm-2050429634740604341-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-api [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-common svn --non-interactive commit --file /var/tmp/maven-scm-786958246.commit --targets /var/tmp/maven-scm-636982206221127-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-common [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-console svn --non-interactive commit --file /var/tmp/maven-scm-637551884.commit --targets /var/tmp/maven-scm-3757207476498104603-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-console [INFO] Tagging release with the label myproject-1.0... [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive copy --file /var/tmp/maven-scm-1862162340.commit . http://my-svn-server:/svn/myrepo/myprojects/tags/myproject-1.0 [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: File '/svn/myrepo/myprojects/tags/myproject-1.0/myproject-common/pom.xml' already exists After investigating a while and trying to reproduce the process manually, I discovered that the error message is somewhat misleading. If I do an 'svn update' prior to the 'svn copy' then the process completes successfully. I put a shell script named 'svn' in my path in front of /usr/local/bin and had that script do an 'svn update' when it sees an 'svn copy' request. Invoking 'mvn release:prepare' with that in place will succeed. Has anybody else seen this kind of behavior? Is there a better solution than my hack of a workaround: $ cat ~/bin/svn #!/bin/bash echo $@ ~/svn.log if [ $1 = --non-interactive -a $2 = copy -a $3 = --file ] then /usr/local/bin/svn update fi exec /usr/local/bin/svn $@ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Oddness with release:prepare
You nailed it. That box has the 1.5.3 svn client. So I can leave my workaround in place until SVN gets fixed or roll back to 1.4. The server is still 1.4.x so rolling back the client wouldn't be any big thing. Thanks for the quick info! -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 What version of SVN are you using? I'm betting it's 1.5.1+. There's a bug where the release plugin can't run with SVN 1.5.1+. 1.4.x works fine, as does 1.5.0 (but I hear that has some other bad bugs). This is a real bummer, since I would love to update to SVN 1.5, but I'm stuck on 1.4. I've been following the bug here: http://jira.codehaus.org/browse/SCM-406 Apparently it's an SVN thing, not an scm plugin one, but the scm bug has a thorough discussion and links to more relevant places. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Oddness with the site plugin
Not sure if it'd work, but you could try to move the contents of util/pom.xml into util/build/pom.xml. This would make build your parent project. Then you would eliminate util/pom.xml. Yes, that's a good idea. But I need util/pom.xml because I have another layer above that and I want it to be able to build the whole tree. That is, my full tree looks something like: /myCo /myCo/common /myCo/common/build /myCo/common/build/pom.xml /myCo/common/util /myCo/common/util/... /myCo/common/tools /myCo/common/tools/... /myCo/common/build/pom.xml is, ultimately, my ancestral pom that holds all of my common build configuration. e.g. -- configuration of common plugins, commonly used dependencies and properties, etc... Every project extends that either directly or indirectly. I need to point my continuous integration to /myCo/common to build my common world and the resulting site should, ideally, reflect all of the subprojects. I *think* I can rearrange the lineage such that it all works out without too much pain. I was just a bit surprised to discover that the modules-parent linkage is bi-directional. In fact, now that I know that, I'm a little surprised that maven didn't throw an exception because I had, effectively, project A with child (module) B which had parent C. James CE Johnson wrote: Apparently I have something of an odd use-case in the way I'm structuring my projects. I'm open to advice... I have the following project structure: .../util/pom.xml .../util/build/pom.xml .../util/lang/pom.xml .../util/io/pom.xml .../util/misc/pom.xml .../util/build/pom.xml defines my common dependencies, properties, etc. Every other pom.xml in .../util (including .../util/pom.xml) extends this one. In .../util/pom.xml I have a modules tag that defines build, lang, io and misc so that everything is built. All good so far. Now, when I do 'mvn site' it will happily build target/site in all of the modules but when I point my browser to .../util/target/site/index.html I have a 'Modules' heading but no links to modules. After playing around a bit I realized that the only way to get the modules into .../util/target/site/index.html is for each one to extend .../util/pom.xml instead of .../util/build/pom.xml. FWIW: I use .../util/build/pom.xml because Eclipse is stupid and won't let me setup a project at .../util as well as each of .../util/(lang|io|misc). Is there a way to leverage the goodness of inheritance without loosing the multi-project site functionality? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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]
Oddness with the site plugin
Apparently I have something of an odd use-case in the way I'm structuring my projects. I'm open to advice... I have the following project structure: .../util/pom.xml .../util/build/pom.xml .../util/lang/pom.xml .../util/io/pom.xml .../util/misc/pom.xml .../util/build/pom.xml defines my common dependencies, properties, etc. Every other pom.xml in .../util (including .../util/pom.xml) extends this one. In .../util/pom.xml I have a modules tag that defines build, lang, io and misc so that everything is built. All good so far. Now, when I do 'mvn site' it will happily build target/site in all of the modules but when I point my browser to .../util/target/site/index.html I have a 'Modules' heading but no links to modules. After playing around a bit I realized that the only way to get the modules into .../util/target/site/index.html is for each one to extend .../util/pom.xml instead of .../util/build/pom.xml. FWIW: I use .../util/build/pom.xml because Eclipse is stupid and won't let me setup a project at .../util as well as each of .../util/(lang|io|misc). Is there a way to leverage the goodness of inheritance without loosing the multi-project site functionality? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writting mojos in Groovy?
Hey guys, thanks for the help! I was able to create a simple groovy plugin with just a little bit of effort. From there it should be possible to crank up the complexity to create something truly useful. It would be cool to see the javalike tools go mainstream! I documented the process in case anyone else might find it useful: http://pteropus.blogspot.com/2007/04/from-maven-to-mvn-part-7-groovier.html I have just noticed that the earlier reply was talking about the groovy-maven-plugin. This is different from the groovy maven tools plugin, in that it is ideal for compiling and running groovy but not for making mojos. There has also been some chat about making mojos in Maven on the Groovy mailing list. - Original message - From: Martin Gilday [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 20:39:00 +0100 Subject: Re: Writting mojos in Groovy? Things have improved since I wrote it but I made an article about an earlier version of the plugin and detailed some of its limitations http://www.martingilday.org/articles/Groovy+Maven+Mojos Hope that is some help. Thanks, Martin. - Original message - From: Dennis Lundberg [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 21:17:10 +0200 Subject: Re: Writting mojos in Groovy? James CE Johnson wrote: Thanks Dennis! That's cool and I managed to get hooked up with version 1.0-alpha-2. Is that the latest / correct version? So now I have MyMojo.groovy that is compiling happily. Thank sounds good. However, the plugin plugin generates plugin.xml. I need to either (a) tell it not to do that so that I can create it by hand or (b) tell it to generate it from MyMojo.groovy. I'm afraid that I can't help you this, as I'm not familiar with how the plugin works, or Groovy for that matter. If you don't get an answer to your question on this list you could join the mojo-user mailing list and ask there. That's where this plugin is being developed. More info can be found here: http://mojo.codehaus.org/mail-lists.html James CE Johnson wrote: Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James You're in luck! The Groovy Maven Plugin has just been released. Check it out here: http://mojo.codehaus.org/groovy-maven-plugin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Writting mojos in Groovy?
Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writting mojos in Groovy?
Thanks Dennis! That's cool and I managed to get hooked up with version 1.0-alpha-2. Is that the latest / correct version? So now I have MyMojo.groovy that is compiling happily. However, the plugin plugin generates plugin.xml. I need to either (a) tell it not to do that so that I can create it by hand or (b) tell it to generate it from MyMojo.groovy. James CE Johnson wrote: Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James You're in luck! The Groovy Maven Plugin has just been released. Check it out here: http://mojo.codehaus.org/groovy-maven-plugin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloader issue? -- Solved
Problem Solved!
It was, of course, a classloader issue. To solve the problem I created my
own URLClassLoader instance and gave it the URLs in of my MoJo's
classloader. Then it was a simple matter to load and instantiate my
utility class from there.
Because I also need access to the project's classpath I also used
${project.runtimeClasspathElements} to import that list.
The relevant solution bits are shown at: http://rafb.net/p/TmK9TL26.html
rafb.net is a short-term paste... Here are those relevant bits in case
somebody needs them in the future:
public class GenerateSqlMojo extends AbstractMojo
{
...
/**
* The classpath elements of the project.
* We need this so that we can get the JDBC driver for the project.
*
* @parameter expression=${project.runtimeClasspathElements}
* @required
* @readonly
*/
private ListString classpathElements;
public void execute() throws MojoExecutionException
{
final URL[] urls = buildUrls();
final URLClassLoader cl =
new URLClassLoader(urls, ClassLoader.getSystemClassLoader());
Thread.currentThread().setContextClassLoader(cl);
final Class clazz =
cl.loadClass(UtilityExecutor.class.getName());
final Constructor ctor =
clazz.getConstructor(new Class[] { String.class,
String.class });
ctor.newInstance(new Object[] { inputDirectory, outputPrefix });
}
/**
* Combine the MoJo URLS with the project's classpath elements.
* We need the classpath elements because the JDBC driver will be
* specified there.
*
* @return
* @throws MalformedURLException
*/
private URL[] buildUrls() throws MalformedURLException
{
final URL[] mojoUrls =
((URLClassLoader) getClass().getClassLoader()).getURLs();
final URL[] urls =
new URL[mojoUrls.length + classpathElements.size()];
int ndx = 0;
for (final URL url : mojoUrls) { urls[ndx++] = url; }
for (final String cpe : classpathElements) {
urls[ndx++] = new URL(file:/ + cpe); }
return urls;
}
}
UtilityExecutor is a simple wrapper to execute my utility's main class:
public UtilityExecutor(final String inputDirectory,
final String outputDirectory)
{
final MyUtility main = new MyUtility();
main.setSaveOnlyMode(true);
main.setSaveTarget(outputDirectory);
main.execute(new String[] { inputDirectory });
}
Thanks for the pointers Jerome. I would still be beating my head on the
desk without your help!
On 4/4/07, James CE Johnson [EMAIL PROTECTED] wrote:
Hi Jerome,
My latest nohup.out is http://rafb.net/p/seMDUu17.html. I've dumped the
classloader of my app as well as the system classloader. It appears
that I have a RealmClassloader loading my classes and it has everything
it needs.
However, http://rafb.net/p/qC12GT63.html captures my execution from
within Eclipse. Here we see that all of the dependencies are in the
system classloader.
Perhaps Spring is looking to the (mostly empty) system classloader in
the case where it fails?
Any insights would be appreciated.
In the xfire maven plugin, i've had to override the class loader,
otherwise Spring would not find the appropriate classes/resources. See
http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/xfire-maven-plugin/src/main/java/org/codehaus/mojo/xfire/WsdlgenMojo.java
I would guess that you need to do something similar in your plugin.
Cheers,
J
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloader issue?
Hi Jerome, My latest nohup.out is http://rafb.net/p/seMDUu17.html. I've dumped the classloader of my app as well as the system classloader. It appears that I have a RealmClassloader loading my classes and it has everything it needs. However, http://rafb.net/p/qC12GT63.html captures my execution from within Eclipse. Here we see that all of the dependencies are in the system classloader. Perhaps Spring is looking to the (mostly empty) system classloader in the case where it fails? Any insights would be appreciated. Thanks! James On 4/3/07, James CE Johnson [EMAIL PROTECTED] wrote: I'm writting a MoJo that uses a utility Iwhich, in turn, uses Spring. When I invoke the utility (with the correct classpath) from the command line everything works fine. When I invoke the MoJo from Eclipse everything still works fine. However, when I invoke the MoJo from mvn it tells me: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [com/myco/foo/util/myUtility/engine.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.springframework.beans.factory.xml.SimplePropertyNamespaceHandler] does not implement the NamespaceHandler interface Caused by: java.lang.IllegalArgumentException: Class [org.springframework.beans.factory.xml.SimplePropertyNamespaceHandler] does not implement the NamespaceHandler interface A capture of the mvn invocation is at http://rafb.net/p/fOEW5I52.html It smells like a classloader issue but I'm too new to m2 to know which way to jump. Any ideas? Sounds like a classpath issue. If you can, try to see what classpath the following code sees: at com.myco.foo.util.myUtility.ContextLoader.load(ContextLoader.java:14) at com.myco.foo.util.myUtility.Main.execute(Main.java:47) You may need to override the classpath given by maven to achieve your needs. See also http://forum.springframework.org/showthread.php?t=35232 J - 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: Classloader issue? -- Solved
Problem Solved!
It was, of course, a classloader issue. To solve the problem I created my
own URLClassLoader instance and gave it the URLs in of my MoJo's
classloader. Then it was a simple matter to load and instantiate my utility
class from there.
Because I also need access to the project's classpath I also used
${project.runtimeClasspathElements} to import that list.
The relevant solution bits are shown at: http://rafb.net/p/TmK9TL26.html
Thanks for the pointers Jerome. I would still be beating my head on the desk
without your help!
On 4/4/07, James CE Johnson [EMAIL PROTECTED] wrote:
Hi Jerome,
My latest nohup.out is http://rafb.net/p/seMDUu17.html. I've dumped the
classloader of my app as well as the system classloader. It appears that
I have a RealmClassloader loading my classes and it has everything it
needs.
However, http://rafb.net/p/qC12GT63.html captures my execution from
within Eclipse. Here we see that all of the dependencies are in the
system classloader.
Perhaps Spring is looking to the (mostly empty) system classloader in
the case where it fails?
Any insights would be appreciated.
In the xfire maven plugin, i've had to override the class loader,
otherwise Spring would not find the appropriate classes/resources. See
http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/xfire-maven-plugin/src/main/java/org/codehaus/mojo/xfire/WsdlgenMojo.java
I would guess that you need to do something similar in your plugin.
Cheers,
J
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Classloader issue?
I'm writting a MoJo that uses a utility Iwhich, in turn, uses Spring. When I invoke the utility (with the correct classpath) from the command line everything works fine. When I invoke the MoJo from Eclipse everything still works fine. However, when I invoke the MoJo from mvn it tells me: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [com/myco/foo/util/myUtility/engine.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.springframework.beans.factory.xml.SimplePropertyNamespaceHandler] does not implement the NamespaceHandler interface Caused by: java.lang.IllegalArgumentException: Class [org.springframework.beans.factory.xml.SimplePropertyNamespaceHandler] does not implement the NamespaceHandler interface A capture of the mvn invocation is at http://rafb.net/p/fOEW5I52.html It smells like a classloader issue but I'm too new to m2 to know which way to jump. Any ideas? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using containing project's classpath within mojo...
James, Johan,
Please copy me on this if it goes off-list. I'm trying to write a MoJo that
uses a utility that uses Spring and I'm getting what I think is a
classloader issue. If you solve it for your case I suspect I can use the
same solution for my own issue: http://rafb.net/p/fOEW5I52.html
Thanks!
James
Sorry, forget exactly what it is but if you can wait 12 hours I can look
it up ;)
Found it in some of the maven APIs if that helps.
And no, not on every list ;)
Johan
I forget what it is - not at work an
James Carman wrote:
Johan,
What kind of objects should I expect in that list?
James
p.s. Are you on every mailing list? :-)
On 4/3/07, Johan Lindquist [EMAIL PROTECTED] wrote:
Hi James,
Try using the following property in you Mojo.
/**
* The classpath elements of the project.
*
* @parameter expression=${project.runtimeClasspathElements} *
@required
* @readonly
*/
private List classpathElements;
I think in this case, you would have to provide your own classloader
for spring - the classloader for the Mojo does (as far as I understand)
not see the project dependencies.
cheers,
Johan
James Carman wrote:
Franz,
Thanks for replying. Let me explain it a bit more. I was trying to
gloss
over things a bit. Basically, I'm using Spring to instantiate the
bean:
public class RunLoaderMojo extends AbstractMojo
{
/**
* @parameter property=loaderBean expression=${loaderBean} *
@required
*/
private String loaderBean;
public void execute() throws MojoExecutionException
{
// Load all META-INF/beans.xml files on classpath!
ClassPathXmlApplicationContext ctx = new
ClassPathXmlApplicationContext(classpath*:META-INF/beans.xml);
getLog().info(Running loader ' + loaderBean + '...); final
Loader loader = ( Loader )ctx.getBean(loaderBean,
Loader.class
);
loader.execute();
}
public String getLoaderBean()
{
return loaderBean;
}
public void setLoaderBean(String loaderBean)
{
this.loaderBean = loaderBean;
}
}
That's my mojo class. Then, I want to use it in a project like this:
plugin
groupIdcom.myco.myproj/groupId
artifactIdmaven-loader-plugin/artifactId
/plugin
Then, I try executing the plugin like this (from the project dir):
mvn loader:run -DloaderBean=exampleLoader
If I try to use a beans.xml file that's defined within my project, it
doesn't even see it on the classpath. If I put it into one of my
project's
dependencies (another module of mine), then it sees it fine. It just
doesn't see anything within the enclosing project. Does that make
sense?
James
On 4/3/07, franz see [EMAIL PROTECTED] wrote:
Good day to you, James,
Not sure how you're instantiating those classes. Anyway, try adding
those
classes in your plugin's dependency ( see [1] ). And if you need the
path
to
those binaries, see Getting dependency artifact path of [2].
Cheers,
Franz
[1]
http://maven.apache.org/ref/current/maven-model/maven.html#class_plugin
[2] http://docs.codehaus.org/display/MAVENUSER/
James Carman-3 wrote:
All,
I am developing a simple mojo which needs to access classes
defined
within
the project in which it is used. But, they don't seem to be
visible. I
am
writing a mojo that can execute a loader (loads data into our
database)
object. It takes a parameter that tells which loader class to
use. Anyway,
I now want to use that mojo within another project to run a loader
defined
within that project. When I try to instantiate that class, it's
not available. Is there something special I need to do to tell
Maven to include
the current project's classpath in my mojo's environment?
James
--
View this message in context:
http://www.nabble.com/Using-containing-project%27s-classpath-within-mojo...-tf3519722s177.html#a9821549
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
you too?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
you too?
- 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]
How to invoke a plugin from within a plugin?
To be fair, my question is based on an implementation I have in mind for a more abstract problem. If you will indulge me a moment I'll describe that issue and maybe you will tell me my implementation is all wrong... Consider the hypothetical project: myProject myProject/appserver myProject/database myProject/webapp Let's assume I have created a plugin (org.tragus:appserver-plugin) which I can specify in myProject/appserver/pom.xml. Further assume that if I do that I then have a goal (org.tragus:appserver-plugin:configure-appserver) which will configure my running appserver in some way (e.g. -- create connection pools and datasources and such). Similarly, pretend that I have a plugin (org.tragus:database-plugin) with a goal (...:update-schema) which will bring my live schema up-to-date with whatever recent changes I've made. This would, of course, be used by myProject/database. Finally, myProject/webapp may use org.tragus:appserver-plugin:deploy-war to deploy a war to the running appserver. These are all hypothetical plugins -- I know there exist some which already do some of these things. My question is this: How can I invoke mvn at 'myProject' such that it will recurse into each subproject and invoke the appropriate update my live environment goal for each one? That is, how can I invoke mvn at the top-level and have it fire org.tragus:appserver-plugin:configure-appserver within appserver, org.tragus:database-plugin:update-schema within database and org.tragus:appserver-plugin:deploy-war within webapp? FWIW I've been using maven 1 since the 0.4 days and long ago solved this with a pile of jelly-script there. I just can't seem to wrap my head around the m2 way of solving this. Now to the question in my subject line... It seems to me that if there was a maven-plugin-invoker-plugin which would invoke a property-specified plugin name my problem would be solved. I would simply set the plugin-to-execute-property appropriately in each subproject's pom.xml and then fire maven-plugin-invoker-plugin from the top level. Trouble is... I cannot find a maven-plugin-invoker-plugin :-( So, can anyone comment on my problem(s)? Am I missing something obvious and making the whole thing harder than it really is? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Plugin For Weblogic
[EMAIL PROTECTED] wrote: Hi, I was wondering, if there is a Maven Plugin for Weblogic? I have a plugin that does deployment using WebLogic's deployer. Email me off the list if you'd like a copy. Thanks in advance, -Conrad - 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: Using jelly script in project.xml
We use the user's home build.properties to insert values into
project.xml, so these are obviously available as well.
[~/build.properties]
my.cvs.userid=matt
my.cvs.server=cvs
my.cvs.root=/cvsroot
[project.xml]
repository
developerConnectionscm:cvs:ext:[EMAIL
PROTECTED]:${my.cvs.root}:/my/module/developerConnection
/repository
I don't imagine it would be difficult (although I haven't tested it) to
do something similar with the version element of dependencies.
Yeabut...
I don't want every developer on the team to have to maintain the version
numbers in their own ~/build.properties.
What I would really like to do is use property or j:set in project.xml
to set the version numbers of dependencies that are listed in several
subprojects' project.xml. I've tried everything I can think of but it just
doesn't work. (Even better... set those versions in the top-level
project.properties when said file becomes inherited by subprojects!)
Matt
[EMAIL PROTECTED] wrote:
The project.xml can use variables defined in the pom, like you have
mentioned below.
I'm not sure which other properties are available at interpolation
time. --
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Stephen McConnell [EMAIL PROTECTED] wrote on 31/10/2003 07:48:00
AM:
James CE Johnson wrote:
The project.xml file isn't executed as a jelly script. It's treated
as an expression.
Drat.
I guess that also explains why I can't set properties/variables in
maven.xml and have them evaluated in project.xml:
maven.xml:
...
property name=foo.version value=1.2.3/
project.xml:
dependency
idfoo/id
version${foo.version}/version
/dependency
This (parameterized versions) would be *so* helpful!
Steve.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell
mailto:[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]
- 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]
Using jelly script in project.xml
This bit from project.xml:
dependencies
maven:pom var=pom
projectDescriptor=${basedir}/../view/project.xml/
j:forEach var=dep items=${pom.dependencies}
j:if test=${dep.getProperty('war.bundle')=='true'}
dependency
id${dep.id}/id
groupId${dep.groupId}/groupId
version${dep.version}/version
/dependency
/j:if
/j:forEach
/dependencies
And this bit from maven.xml:
goal name=foo
j:forEach var=dep items=${pom.dependencies}
echo message=${dep.id}/
/j:forEach
/goal
Doesn't produce what I was hoping for. That is, I want this project's
project.xml to include in its dependencies everything marked 'war.bundle'
in ../view/project.xml. The 'foo' goal doesn't show any such thing.
Is a completely stupid thing to do or am I just doing it the wrong way?
Thanks,
J
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using jelly script in project.xml
Hi James,
can you tell me if you succeeded with this approach?!
No luck so far :-(
I can't quite figure out when the jelly script is executed in the
project.xml lifecycle. From what I can tell, though, its after the ${pom}
has already been populated because my script below had absolutely no
effect on the actual list of dependencies.
I actually
thought of using JELLY scripting to pull in dependencies but you end up
with a non-XML file. In my case we thought of autogenerating the WSAD
(Websphere Application Studio) project files based on the POM similar
to that what MEVENIDE does (or should do)
Thanks in advance,
Siegfried Goeschl
On 30 Oct 2003 at 8:56, James CE Johnson wrote:
This bit from project.xml:
dependencies
maven:pom var=pom
projectDescriptor=${basedir}/../view/project.xml/
j:forEach var=dep items=${pom.dependencies}
j:if test=${dep.getProperty('war.bundle')=='true'}
dependency
id${dep.id}/id
groupId${dep.groupId}/groupId
version${dep.version}/version
/dependency
/j:if
/j:forEach
/dependencies
And this bit from maven.xml:
goal name=foo
j:forEach var=dep items=${pom.dependencies}
echo message=${dep.id}/
/j:forEach
/goal
Doesn't produce what I was hoping for. That is, I want this project's
project.xml to include in its dependencies everything marked
'war.bundle' in ../view/project.xml. The 'foo' goal doesn't show any
such thing.
Is a completely stupid thing to do or am I just doing it the wrong
way?
Thanks,
J
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
Siegfried Goeschl
CTO
=
IT20one GmbH
mail: [EMAIL PROTECTED]
phone: +43-1-9900046
fax: +43-1-52 37 888
www.it20one.at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using jelly script in project.xml
The project.xml file isn't executed as a jelly script. It's treated as
an expression.
Drat.
I guess that also explains why I can't set properties/variables in
maven.xml and have them evaluated in project.xml:
maven.xml:
...
property name=foo.version value=1.2.3/
project.xml:
dependency
idfoo/id
version${foo.version}/version
/dependency
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Usability issues general ranting
Sounds like a good idea. Volunteering to write it? I once wrote a perl script to convert a maven b4 repository to b5 format. It should still work and I'm certainly happy to donate it (again) to the cause :-) -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Paul Libbrecht [EMAIL PROTECTED] wrote on 10/09/2003 11:04:13 PM: I would like to insist that this is very good practice to my opinion and a special paragraph on that should be made in the manual. We basically have a local-repository containing private stuffs (e.g. things we can't distribute) and a shared .maven. And things seem to go well. Paul On Mercredi, sept 10, 2003, at 14:54 Europe/Paris, [EMAIL PROTECTED] wrote: I eventually gave up on using lib and jar overrides, and generated a local repository out of my library using a batch file. And that took how long? How many jar files do you have?? - 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]
Re: Could a goal defined in maven.xml overwrite a plugin's goal?
Why not preGoal on the distribution goal and set the extra things up. -- That might work for some things but I had one case (can't remember it now) where I needed to entirely replace the existing goal's functionality with my own. Due to other goals' prerequisites I couldn't just create a new goal with a new name and use it. Once, long ago, things were such that a goal in maven.xml with the same name as a plugin goal would override. Then that quit working. Dunno if how it works today. dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Nelson Arapé [EMAIL PROTECTED] wrote on 05/09/2003 08:45:35 AM: Hello to all I want to know if I could a goal defined in maven.xml overwrite a plugin's goal?. I have a multiproject configuration and I want to make a customized distribution (subprojects jar, plus parent project docs, plus subprojects javadocs, etc). I guess that I could just define a new goal with name:my-dist, but I would prefer call it just dist Thanks in advance Nelson Arapé - 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]
Re: maven mockdoclet
Sorry, I should be more precise:
Mockdoclet is part of XDoclet. They provide a XDoclet plugin for maven
and I'm just wondering if somebody ever worked with the mockobject part
of it.
This is what we've done:
taskdef name=mockdoclet
classname=org.mockmaker.doclet.MockObjectDocletTask
classpath refid=maven.dependency.classpath/
/taskdef
preGoal name=test:compile
available property=generate_mocklet
file=${maven.build.dir}/xdoclet/
j:if test=${generate_mocklet}
mkdir dir=${maven.build.dir}/xdoclet/test/
echoGenerating Mock Object Source/echo
mockdoclet destdir=${maven.build.dir}/xdoclet/test
fileset dir=${maven.build.dir}/xdoclet/java
include name=**/*.java/
/fileset
mockobject/
/mockdoclet
path id=mock.doclet.gen.src
location=${maven.build.dir}/xdoclet/test/
maven:addPath id=maven.test.compile.src.set
refid=mock.doclet.gen.src/
/j:if
/preGoal
Dom
On Mon, 2003-08-25 at 03:12, [EMAIL PROTECTED] wrote:
There isn't a mockdoclet plugin shipped with maven.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Dominik Dahlem [EMAIL PROTECTED] wrote on 23/08/2003 02:23:53
AM:
Hi all,
I wanna use mockdoclets with maven. However, the mockdoclet seems to
be in early development stages in terms of maven integration. In the
maven plugin no default properties for mockdoclet are set.
Has anyone been using it with maven or can anyone give me directions
on how to use it?
Any help is greatly appreciated.
Thx,
Dominik
-
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]
Re: Fixes and changes for maven 1.0
I can't seem to find the reactor Is that the problem where some funky sequence of reactor usage causes maven to forget what goals it has? I agree that's critical. Most of my reactor-based goals now have to exec a new maven instance in order for the build to proceed :-( console problems in jira, but I know we have talked about it a million times here on the list. I think that bug fix it crucial for 1.0. -James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: install not working with reactor
I think this is a known problem, dunno if it's in jira. I know I've
experienced something very similar if not out right identical and I
*think* there was some discussion of it here a week or two ago. As I
recall it has something to do with the goals getting lost when the
reactor is invoked the second time around.
My workaround is gross and nasty but it'll work until the bug finds
itself squashed.
goal name=install-all
...
m:reactor ... goals=reactor-ejb-install .../
...
/
Here comes the gross part:
goal name=reactor-ejb-install
exec executable=${maven.command}
failonerror=true
arg value=ejb:install/
/exec
/goal
You might need this also:
condition property=maven.script value=maven.bat
and
os family=windows /
equals arg1=${maven.script} arg2=$${maven.script} /
/and
/condition
condition property=maven.script value=maven
equals arg1=${maven.script} arg2=$${maven.script} /
/condition
property name=maven.command value=${maven.home}/bin/${maven.script}/
Boris Ekelchik wrote:
I meant ejb:install, jar:install works fine.
-Original Message-
From: Boris Ekelchik
Sent: Thursday, July 31, 2003 5:16 PM
To: '[EMAIL PROTECTED]'
Subject: install not working with reactor
Top level maven.xml has:
goal name=install-all
!-- Install non-EJB jars --
m:reactor basedir=${basedir}
includes=*/project.xml
excludes=application/ejb/project.xml
goals=jar:install
banner=Installing JAR files
ignoreFailures=false/
!-- Install EJB jar --
m:reactor basedir=${basedir}
includes=application/ejb/project.xml
goals=ejb:install
banner=Installing EJB JAR file
ignoreFailures=false/
/goal
Everything up to and including ejb:ejb goal completes fine, but
ejb:install fails:
[. . .]
ejb:ejb:
[echo] Building ejb application.ejb-1.0
[jar] Building jar: C:\cvsroot\v5\target\application.ejb-1.0.jar
BUILD FAILED
File.. file:/c:/cvsroot/v5/
Element... m:reactor
Line.. 36
Column 37
Unable to obtain goal [install] --
file:/c:/cvsroot/v5/application/ejb/:13:37: m:reactor Unable to obtain
goal [ejb:install] -- file:/C:/Documents and
Settings/boek2827/.maven/plugins/maven-ejb-plugin-1.1-SNAPSHOT/:119:27:
artifact:install null
ejb:install works just fine when invoked directly:
[. . .]
Copying: from
'c:\cvsroot\v5\application\ejb\..\..\target\application.ejb-1.0.jar' to:
'C:\Documents and
Settings\boek2827\.maven\repository\application\ejbs\application.ejb-1.0.jar
'
BUILD SUCCESSFUL
Is there a workaround for this?
Thanks in advance.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: couple of questions
Joshua Spiewak wrote: Hi there, I just started using Maven and had a couple of questions. I am using version 1.0-beta-10 on Windows XP with Cygwin tools and Emacs (with JDEE). The first question is why are the plugins and local repository created in C:\Documents and Settings\Joshua\.maven when %HOME% is set to c:\jss? I get around this by setting %MAVEN_HOME_LOCAL%, but it doesn't seem like that should be necessary. The second question is a bit more complex. I am used to building from Emacs, using JDEE, so I figured I would extend JDEE to be able to run Maven in a similar fashion to how it runs Ant. Initially this went pretty easily, but I am now stuck wrestling with the --dir and --pom command line options of Maven. If I am one directory down from the top level of my project, I can successfully run maven with --pom ../project.xml. However, I cannot seem to specify an absolute path (with either tcsh or cmd), and trying to use --dir doesn't seem to help. Any ideas what I am doing wrong? I have tried d:/work/project and /cygdrive/d/work/project and d:\work\project, all unsuccessfully. You can use 'maven -f' to find the project.xml much like ant finds build.xml Thanks in advance, and keep up the work on what looks like a very promising project! -- Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.0 beta 10 : Repositories
Jason van Zyl wrote:
On Tue, 2003-07-15 at 15:39, Andy Jefferson wrote:
Trying to use the Beta 10 and having problems with repositories. I've
changed nothing in the configs and if I now do a 'maven clean' I get
failure to download for all dependencies.
I have maven installed on Linux in /usr/local/maven and have installed
the JAR's in the repository there. I heard something about using a
$user/.maven directory. On the only dependency that it managed to
download, it decided to put that in the users own space.
Anyone got a definitive statement on what is the policy with local
repositories ?
What I would expect would be to try the users home, and then
$MAVEN_HOME, and then complain. What it *seems* to do is just check the
users space. If this is correct, this would be no good for group
working. I have a centralised repository and users shouldn't need to
duplicate this (or even put in symlinks to the ones they need).
Any clues ?
The default value for maven.repo.local is now defined in the
default.properties file and it has a value of:
${maven.home.local}/repository
This will default to
~/.maven/repository
So you can override the value of maven.repo.local to set it to whatever
you desire but it now defaults to ~/.maven/repository to enable to use
of shared repositories.
So tell me if I'm getting this right...
I set $MAVEN_HOME to /usr/local/maven and maven.repo.local to
/usr/local/maven/repository then I build b10. Now all of the users on
the system can add $MAVEN_HOME/bin to their path and set
maven.repo.local in their ~/build.properties and by doing so everyone
will use the same, shared maven binary and 3rd party jars.
Yes?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
b10 installation question
Hi all, After quite some time on b9 I'm making the jump to b10. I notice that after bootstrapping I have things in ~/.maven. I understand this is to support the concept of a shared (read-only) installation. That's exactly what I need to create. Is it enough to simply set maven.repo.local to /usr/local/maven during my build process? Will others' ~/.maven then be populated as necessary? Thanks, J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Example project.xml for J2EE project
Hey Chad, At http://www.tragus.org/~jcej/maven-examples/ are project.xml and maven.xml files that build both an ear and a war. In the top-level directory are files that are used in the subprojects. The 'service' subproject builds an ear of EJBs. The 'view' subproject builds a war for a webapp (which uses the EJBs). Eventually I'll have a third subproject that will create an ear of the stuff in the service earfile *and* the warfile but I'm not there yet. These files are cut from a project we're currently developing so I know they work. But... I had to strip out anything pointing back to the name of the project, company, etc... so I may have broken something during that process. I rolled my own ear- and war-building goals because the ones included in the 0.9 candidate just didn't work for me. I know folks are currently working on making those better and I look forward to using them when 1.0 comes 'round. It seems to me, though, that what folks need from these kinds of goals tends to vary quite a bit so I don't know if we can ever have a build me an ear/war file goal that will work for everyone. Hope this helps, J Stansbury, Chad wrote: Hello all - I've downloaded and played around w/ Maven for simple projects, but would like to begin using it for several J2EE-based projects. The basic documentation only covers the basics, and I was wondering if someone could save me a lot of time by sending me an example J2EE project.xml that generates a WAR, and/or EAR file? Thanks in advance, Chad Stansbury Carlson Hospitality Worldwide [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]
RE: Sharing goals between maven.xml files w/o a plugin
I find plugins so easy to create, I would argue in favor of them. Epecially since the plugin plugin makes them easy to install and deploy! No argument there at all! But, as I said, these shared goals are very specific to this project and I really don't want to pollute the global plugin space with 'em. Eric -Original Message- From: James CE Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 8:52 AM To: [EMAIL PROTECTED] Subject: Sharing goals between maven.xml files w/o a plugin Heya, I've got a project with a half-dozen sub-projects. Several of those (not all) need to share some common custom goals. I don't really want to create a plugin because the goals are specific to this one project. Is there another way to make shared goals available? Thanks, J - 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: Sharing goals between maven.xml files w/o a plugin
On Wed, 2003-03-26 at 09:14, [EMAIL PROTECTED] wrote: Hi James, See my proposal of this morning for sharing maven.xml. That would allow you to share common custom goals. I don't think he wants to inherit anything, he just wants to share a set of goals. A plugin is the way to go. It turns out that extend solves the problem nicely. All of my subprojects share a subset of dependencies and other things so having their project.xml extend a top-level project.xml is the way to go. The fact that that also brings in the top-level maven.xml is icing on the cake! In case I haven't said it lately: You guys Rock! -Vincent Quoting James CE Johnson [EMAIL PROTECTED]: Heya, I've got a project with a half-dozen sub-projects. Several of those (not all) need to share some common custom goals. I don't really want to create a plugin because the goals are specific to this one project. Is there another way to make shared goals available? Thanks, J - 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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]
