[
http://jira.codehaus.org/browse/MEXEC-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135199#action_135199
]
Joshua Pollak commented on MEXEC-43:
------------------------------------
you are correct, we have a shell script called mvnrun (and mvnrun.bat too)
which do:
mvn compile exec:java $MVNOPT -Dexec.mainClass="$CLASSNAME" -Dexec.args="$ARG"
failIfNoClass is enabled in the parent pom's exec-plugin config.
I'm not sure we are doing 'weird things', but I suppose its possible. What I'm
trying to provide for our developers is a single location from which to run
maven which allows them to build and test our code, without having to worry
about multi-module component development.
Specifically, we have a project like this:
trunk
+------moduleA
+------moduleB
+------moduleC
C depends on B which depends on A.
I don't want 'regular' developers to have to worry about installing changes to
A so that these changes can be reflected in C, which is what we would need to
do if I told everyone to compile from the module directories.
By having an aggregator pom in trunk, I can get everyone to compile and run
unit tests without having to install. In the surefire plugin, there is
failIfNoTests, which we set to false. This lets us do:
mvn -Dtest="FooTest" test
from trunk, even though FooTest is only implemented in moduleC, not moduleA (or
B).
We need to be able to do the same with exec, hence this patch.
I have noticed one problem with this patch, which is that since exec:java
doesn't fork a new jvm, the base directory is trunk, rather than moduleC (or
whichever).
You wrote: "by asking maven to run from the parent-pom, you're obvisouly asking
the wrong thing. maven is going to try to run the class in all modules which is
not what you want. This could cause all sort of problems: what about a C module
depending on B, thus having B in the classpath ?"
In our case all of our modules depend on the one below it, so I'm not worried
about having B on C's classpath, because it should be, but I gather you are
worried about situations where C doesn't depend on B? In that case, wouldn't
Maven's internal structure prevent B from being on the classpath? If not,
perhaps exec:java could be modified to fork the jvm? That would solve my
basedir issue and allow other features, like specifying the amount of heap
space the JVM needs.
I tried to use exec:exec to spawn a JVM, but I had trouble, part of which was
that the %classpath% tag seemed to not work, I think the tag to use changed and
the documentation on the website is out of date, also it was really clunky and
I had some other issues. I know thats vague, but I'm off-topic already
> Patch: failIfNoClass adds the ability to disable failing if no class was
> found, as well as a better error message
> -----------------------------------------------------------------------------------------------------------------
>
> Key: MEXEC-43
> URL: http://jira.codehaus.org/browse/MEXEC-43
> Project: Maven 2.x Exec Plugin
> Issue Type: New Feature
> Components: java
> Affects Versions: 1.1-beta-1
> Reporter: Joshua Pollak
> Fix For: future
>
> Attachments: failIfNoClass.patch, it001.tar
>
>
> exec:java is pretty much useless to execute main classes in multi-module
> projects (without first installing) because the exec:java command can't be
> run from the top level pom because it will fail with class not found, and
> when run from the correct module it will fail because it can't locate the
> dependancies.
> This patch adds the ability to disable the 'fail if class not found' behavior
> via the 'failIfNoClass' property. If set to false the plugin will NOT fail if
> the Java class specified is not found. This is useful in a multi-module
> project where you might want to exec a class in one module which won't be
> found in other modules.
> The default value of failIfNoClass is TRUE, which preserves the current
> behavior.
> This patch also adds a constructive error in the case where failIfNoClass is
> true, and no class is found. In the past, just the string "null" was
> displayed.
--
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 from this list, please visit:
http://xircles.codehaus.org/manage_email
