RE: [m2] Problem: How to run some tests only sometimes
So, what is the syntax for excludes/excludes? Am I correct that this goes in a plugin..configuration/configuration section? And am I also correct that I will need to include the defaults (i.e., exclude Abstract*? I'm finding the documentation not quite clear on this. Dave -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 8:18 PM To: Maven Users List Subject: Re: [m2] Problem: How to run some tests only sometimes Dave is right that profiles are the right way to go about this. You can change the includes/excludes of the test plugin (or even skip them all for a project) based on the profile in use. - Brett On 11/3/05, Brill Pappin [EMAIL PROTECTED] wrote: I used to do this with a special goal in the maven.xml but since it no longer graces m2, I would love to hear a solution as well. - Brill Pappin On 11/2/05, Dave Neuer [EMAIL PROTECTED] wrote: So, here's my situation, I really hope someone can help figure out how to do this. I have currently got 2 projects, one's a library, the other is more like an application, and depends on the library. The lib project tests only use Mocks, because they're common objects not tied to a product or database instance. The app project depends on both the lib jar and the lib-test jar (in order to reuse abstract test logic. This has been working great since the test-jar feature was added in beta 3. Now, unfortunately, some of our tests in the app take a LOG time to run (i.e., tests that insert hundreds of thousands of rows into the DB). We really don't want to be in a situation where the tests take so long to run that developers don't run them, thereby checking in buggy code. So, the idea was we'd separate out the horrendously long ones and run them nightly or something. Problem is, I can't figure out a good way to do this. Lib and app are both modules in a top level project, normally we do mvn install from the top-level directory to run all of the tests. So, if I add another project long tests as a module, the long tests will be run each time by the developers. If I don't add it as a module in the top-level project, running it in its own directory requires that the other modules' jars are installed -- which is fine except that once that is done once, it won't automatically be done again, and so changes in the other projects won't be picked up. So is there a way, either with profiles w/ a different test name pattern, or declaring the top-level pom as a parent in the long running test project, to ensure that the other projects are built fresh when the long tests are run? Thanks in advance. Dave - 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]
[m2] Problem: How to run some tests only sometimes
So, here's my situation, I really hope someone can help figure out how to do this. I have currently got 2 projects, one's a library, the other is more like an application, and depends on the library. The lib project tests only use Mocks, because they're common objects not tied to a product or database instance. The app project depends on both the lib jar and the lib-test jar (in order to reuse abstract test logic. This has been working great since the test-jar feature was added in beta 3. Now, unfortunately, some of our tests in the app take a LOG time to run (i.e., tests that insert hundreds of thousands of rows into the DB). We really don't want to be in a situation where the tests take so long to run that developers don't run them, thereby checking in buggy code. So, the idea was we'd separate out the horrendously long ones and run them nightly or something. Problem is, I can't figure out a good way to do this. Lib and app are both modules in a top level project, normally we do mvn install from the top-level directory to run all of the tests. So, if I add another project long tests as a module, the long tests will be run each time by the developers. If I don't add it as a module in the top-level project, running it in its own directory requires that the other modules' jars are installed -- which is fine except that once that is done once, it won't automatically be done again, and so changes in the other projects won't be picked up. So is there a way, either with profiles w/ a different test name pattern, or declaring the top-level pom as a parent in the long running test project, to ensure that the other projects are built fresh when the long tests are run? Thanks in advance. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Surefire doesn't discover new tests
Does this go for abstract base classes too? I.e.,
Will surefire find tests defined in a superclass whose name doesn't look
like that?
Dave
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 05, 2005 7:29 PM
To: users@maven.apache.org
Subject: Re: [m2] Surefire doesn't discover new tests
On Wed, 2005-10-05 at 11:53 -0400, Daniel Krisher wrote:
I believe that the surefire plugin only includes classes with names
ending in Test by default. If this is your problem, you can modify
this behavior with a configuration section for the surefire
plugin...
The defaults are as follows now:
includes = new ArrayList( Arrays.asList( new String[] { **/Test*.java,
**/*Test.java, **/*TestCase.java } ) );
Dan
On 10/5/05, Michael Deck [EMAIL PROTECTED] wrote:
I've just installed Maven 2.0 beta-3 and I'm walking through some
simple exercises to get a feel for the app. I've used the archetype
plugin to create a simple java project and it seems to build fine.
However, if I add another test class to the src/test/java directory m2
doesn't seem to detect the new test. When I run m2 test this is the out
put I get:
[INFO] [compiler:testCompile]
Compiling 2 source files to
C:\sandbox\eclipse\Roberto\Maven2\my-app\target\test
-classes
[INFO] [surefire:test]
[INFO] Setting reports dir:
C:\sandbox\eclipse\Roberto\Maven2\my-app\target/sure
fire-reports
---
T E S T S
---
[surefire] Running com.mycompany.app.AppTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec
What's interesting is that 2 classes are compiled, but only 1 of the
tests is run. Has anyone else experienced this behavior? Am I doning
something wrong, or is this the expected behavior?
Thanks in advance,
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Daniel Krisher
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
-
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: Cross-project dependencies on unit test code
-Original Message-
From: Tim Dysinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 28, 2005 12:39 PM
To: [EMAIL PROTECTED]; Brett Porter
Cc: Maven Users List
Subject: Re: Cross-project dependencies on unit test code
Ok. Let's say we did it that way. We are still faced with the same
problem with the maven-eclipse-plugin. Maven-eclipse-plugin does not
like having your source and test directories the same.
sourceDirectory${basedir}/src/java/sourceDirectory
unitTestSourceDirectory${basedir}/src/java/unitTestSourceDirectory
snip
Putting the junit code in src/java is the only way I know that maven
will publish your jar so other projects can depened on it. If you just
put your tests in src/test, maven will publish an empty jar and the
dependant project will fail to compile.
For the scheme outlined by Raphael to work, you *cannot* have tests in
src/main/java. You must factor out the test code that is common to the test
subclasses in those projects which reuse them as abstract classes in
src/main/java, but these are *not* tests which get run.
The actual tests are subclasses of the common test, and would go in
src/test/java in project core-impl, and whatever other projects have subclasses
which depend on them.
As Trygve pointed out, there is a bug/enhancement request filed for this
already to allow for test-jars to be publishable. Given how many people need
something like this I was surprised Maven2 didn't already support it. IMHO the
test project idea is fragile. Though, by forcing you to have API in a
Separate project, it also forces you to very loosely couple your code by
programming to interfaces and using factories and the like, which is a positive
side effect (but something you should be doing anyway w/out being forced into
it by the build tool).
Dave
-Tim
On Wed, 2005-09-28 at 08:42 +1000, Brett Porter wrote:
This has been asked 2 or 3 times this week. IIRC someone was going to
write up their experience doing it? Would anyone like to volunteer to
add it to the wiki?
- Brett
On 9/28/05, Raphaël Piéroni [EMAIL PROTECTED] wrote:
Hi Tim,
May you try with something like this :
wrapper
+- core-api
+- core-test (depend only on api)
+- core-impl (with some test cases - depends on core-api and core-test
the later with scope test)
+- use-core-1 (depend on core-impl, depends on core-test at scope test -
the test cases must not depend on core-impl's tests)
+- use-core-2 (...)
Then you move all the common test practices to the core-test project.
May that helps.
Regards,
Raphaël.
Tim Dysinger a écrit :
I have a best practices question.
I have a multi-project setup with three sub-projects. Two of the
sub-projects have tests which subclass tests in the core project.
However, just having the sub-projects depend on core does not expose
the unit test code and the build fails with a compilation error.
If I put the unit tests into the src/java directory, then the eclipse
plugin generates duplicate source directories src/java in
the .classpath file.
I imagine that I could break out all the tests into other sub-projects
but that seems clumsy and would double the number of projects in my
multi-project setup.
How do I deal with this elegantly?
-Tim
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cross-project dependencies on unit test code
Answers:
1) There needs to be an API package so that the Impl and Test packages can both
depend on it (otherwise your base tests would depend on the impl classes, but
your impl depends on the base tests, creating a circular dependancy).
2) How do you ensure that any factory returns any kind of specific
implementation of an interface in general? You have some configuration which
specifies which impl to return at runtime (the config would probably be stored
w/ your tests i.e., src/test/resources). I find Spring quite handy for this
type of setup.
Also, you'd want to define your Mocks in Proj a-test in src/main/java, rather
than src/test/java otherwise they won't get exported.
Dave
-Original Message-
From: Allison, Bob [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 28, 2005 1:37 PM
To: Maven Users List; [EMAIL PROTECTED]; Brett Porter
Subject: RE: Cross-project dependencies on unit test code
Here is the pattern I was going to build:
Project proj-a creates a.jar which contains:
-- Interface A which is the API for the jar
-- Class AImpl which implements the API
-- Class AFactory which creates implementations of interface A
Project a-test creates a-test.jar which contains a MockObjects version of class
AFactory which allows unit tests to preload the factory with a mock-object
implementation of interface A to be returned by the factory
Project proj-b uses a.jar, so needs to define a dependency on a.jar with
compile scope and a-test.jar with test scope.
My questions:
1) Is there a reason why the API class (interface A) needs to be in a separate
project from the implementation classes (AImpl and AFactory)?
2) How do I define the dependencies in project proj-b to ensure that the
mock-objects version of AFactory gets used during unit tests?
-Original Message-
From: Tim Dysinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 28, 2005 12:39
To: [EMAIL PROTECTED]; Brett Porter
Cc: Maven Users List
Subject: Re: Cross-project dependencies on unit test code
Ok. Let's say we did it that way. We are still faced with the same
problem with the maven-eclipse-plugin. Maven-eclipse-plugin does not
like having your source and test directories the same.
sourceDirectory${basedir}/src/java/sourceDirectory
unitTestSourceDirectory${basedir}/src/java/unitTestSourceDirectory
I can't do this without using eclipse. The plugin, in this case, would
generate a bogus .classpath file.
Putting the junit code in src/java is the only way I know that maven
will publish your jar so other projects can depened on it. If you just
put your tests in src/test, maven will publish an empty jar and the
dependant project will fail to compile.
-Tim
On Wed, 2005-09-28 at 08:42 +1000, Brett Porter wrote:
This has been asked 2 or 3 times this week. IIRC someone was going to
write up their experience doing it? Would anyone like to volunteer to
add it to the wiki?
- Brett
On 9/28/05, Raphaël Piéroni [EMAIL PROTECTED] wrote:
Hi Tim,
May you try with something like this :
wrapper
+- core-api
+- core-test (depend only on api)
+- core-impl (with some test cases - depends on core-api and core-test
the later with scope test)
+- use-core-1 (depend on core-impl, depends on core-test at scope test -
the test cases must not depend on core-impl's tests)
+- use-core-2 (...)
Then you move all the common test practices to the core-test project.
May that helps.
Regards,
Raphaël.
Tim Dysinger a écrit :
I have a best practices question.
I have a multi-project setup with three sub-projects. Two of the
sub-projects have tests which subclass tests in the core project.
However, just having the sub-projects depend on core does not expose
the unit test code and the build fails with a compilation error.
If I put the unit tests into the src/java directory, then the eclipse
plugin generates duplicate source directories src/java in
the .classpath file.
I imagine that I could break out all the tests into other sub-projects
but that seems clumsy and would double the number of projects in my
multi-project setup.
How do I deal with this elegantly?
-Tim
-
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]
-
To unsubscribe,
RE: [m2] reasons for sticking with maven
John, I appreciate your thoughful and reasonable responses to
questions/issues like this. I have to second Ashley on this one. Please
try not to take the following personally, but consider it one person's
bad experience w/ trying to use m2 to do what seems like a simple
thing...
I really like being able to do m2 clean:clean compile test install.
However, I don't like having no ability to reuse test code from one
project in another project which depends on it. Example: project A has
interface Blah and interface BlahDAO to persist blahs. I have
AbstractBlahDAOTest which has testXXX methods which test *interface
invariant* conditions of BlahDAO. Project B has a new subclass of Blah
and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
interface invariant constraints. So I want to have ProjectBBlahDAOTest
which extends AbstractBlahDAOTest from project A, but I can't because I
can't generate another (test) artifact in maven.
So, I spent between 3 days and a week reading the source and the (mostly
absent) documentation for plugin development, and developed
maven-test-artfiact plugin. Finally got it to generate the
${artifactId}-test.jar AND install it, but it turns out surefire won't
run tests where some of the testXXX methods are in an abstract base
class in another jar, apparently (even though it loads the class).
To which I have to say: why the hell did someone develop surefire in the
first place? There's already a perfectly good Ant junit task? And why
their own microcontainer? What the heck was wrong w/ Spring (which lots
of people already use).
It seems to me to be a codehaus thing: a propensity to eschew reuse of
other people's code.
So, the upshot is, my plugin doesn't work. It wouldn't work outside of
m2 anyway (since m2 plugins don't rely on normal Java mechanisms -- like
setter injection, to set their properties) so it's not really general as
I've heard claimed by some here as an argument why maven plugins are
good - loosely coupled to maven. And to make it work, I might have to
hack surefire. And plexus. And whatever other 20 wheels have been
reinvented rather than reused.
I realise that some of the above may be perceived as somewhat
inflammatory, but it's really just born out of the frustration of seeing
what seems like it should be an easy task -- one which I *can't imagine*
I'm the only one requiring -- be so difficult.
And since I don't really have more time to steal from my project to
devote to the maven plugin development task, I'm left looking for
alternatives, or reluctantly planning to rewrite the build process in
Ant buildfiles in the not too distant future.
Respectfully but w/ frustration and confusion,
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] reasons for sticking with maven
Yes, that's a workaround I'm not OK with, so a developer cannot be in
/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and think
that everything is OK and check in a bunch of broken code because no
tests
were run -- since the tests for A don't live in A.
Again, I did write a maven-test-artfiact plugin which has a compile and
install target; it *does* generate a test artifact (default name
${artifactId}-test.${packaging}, but it's configurable.
However, it doesn't generate a POM, and even w/ a manually generated
one, and a declared dependancy on A's test artifact in project B,
surefire doesn't run the tests in the baseclasses which reside in the
test.jar.
That's where I got, and where I ran out of patience and time to keep
going. I'd be happy to ask my manager if we can release this code if
someone else were interested in running w/ it.
Dave
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 20, 2005 2:05 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven
Dave Neuer wrote:
However, I don't like having no ability to reuse test code from one
project in another project which depends on it. Example: project A has
interface Blah and interface BlahDAO to persist blahs. I have
AbstractBlahDAOTest which has testXXX methods which test *interface
invariant* conditions of BlahDAO. Project B has a new subclass of Blah
and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
interface invariant constraints. So I want to have ProjectBBlahDAOTest
which extends AbstractBlahDAOTest from project A, but I can't because
I
can't generate another (test) artifact in maven.
We experienced similar problems in Cocoon - our workaround is to add
another
project A-test which contains the all test classes as its source. Then B
can depend on A-test with scope test. But I think this is only a
workaround. It would be great if this could be solved somehow in m2
without any tricks.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
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: [m2] reasons for sticking with maven
Created: Today 08:00 AM.
That is exactly what I'm talking about.
I would have been happy to ask about donating my code, but it's unclear
to me from the referenced JIRA entry whether they're talking about
making the regular compile and install plugins do the test artifact
generation (plus making sure that surefire can run the tests -- as I
said, it didn't seem to be able to run tests from a base class in a
separate jar).
Personally, I think that this would be a common enough feature that it
really belongs in the compile and install plugins, rather than a
standalone plugin like the one I developed.
e.g.
groupIdmy.project/groupId
artifactIdmain-artifact/artifactId
testArtifactIdmain-test-artifact/testArtifactId
and then depend on it in the manner John specified.
Dave
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 20, 2005 3:02 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yeah, that looks like it. I wasn't aware of that issue...too new, I
guess :)
Thanks, Mark.
john
Mark Hobson wrote:
| Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
|
| Mark
|
| On 20/09/05, John Casey [EMAIL PROTECTED] wrote:
|
| Another solution might be an attached artifact (logically attached to
| the main .jar in the repository via the metadata) that would be
| available to other projects...so producing project A might also
produce:
|
| a-version-tests.jar
|
| and you could then depend on it like such:
|
| dependency
| ~ groupIdsome.group/groupId
| ~ artifactIda/artifactId
| ~ versionsomeVersion/version
| ~ typetest-jar/type
| ~ scopetest/scope
| /dependency
|
| would that solve the problem?
|
| -john
|
| Carsten Ziegeler wrote:
| | Dave Neuer wrote:
| |
| |Yes, that's a workaround I'm not OK with, so a developer cannot be
in
| |/masterProject/projectA and do m2 test, see BUILD SUCCESSFUL and
think
| |that everything is OK and check in a bunch of broken code because no
| |tests
| |were run -- since the tests for A don't live in A.
| |
| |
| | Oh no, they are still in A - that's trick :) (ok, one could call it
| | hack). You have the correct pom for A containing the tests. You make
a
| | sub directory in project A: tests-for-b, add a pom.xml there
| | referencing the tests of A as src (using ../) and then it works.
| |
| |
| |Again, I did write a maven-test-artfiact plugin which has a compile
and
| |install target; it *does* generate a test artifact (default name
| |${artifactId}-test.${packaging}, but it's configurable.
| |
| |However, it doesn't generate a POM, and even w/ a manually generated
| |one, and a declared dependancy on A's test artifact in project B,
| |surefire doesn't run the tests in the baseclasses which reside in
the
| |test.jar.
| |
| |That's where I got, and where I ran out of patience and time to keep
| |going. I'd be happy to ask my manager if we can release this code if
| |someone else were interested in running w/ it.
| |
| |
| | It would be interesting to hear what the m2 developers say about
this
| | problem :)
| |
| | Carsten
| |
- -
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]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFyrK3h2CZwO/4URAmdkAJ9EtnA8+4q/E1y9vFW/qCzlrPueRgCeJ2Ho
OImXL7E2wJ3HxevjML4egXg=
=F56A
-END PGP SIGNATURE-
-
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: [m2] whether to use ant
This is kind of like saying: we don't have the spare cycles for unit testing; we're spending all of our time fixing bugs. Fact is, taking a few cycles off of frantic coding to do some decent documentation would allow more developers to contribute, which *could* give everyone more spare cycles. Good documentation would also help developers reason about the software. Dave PS - Sorry for the top-posting: Outlook Hell. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 14, 2005 10:54 AM To: Maven Users List Subject: Re: [m2] whether to use ant We know that documentation is currently inhibiting adoption of Maven 2, to say nothing of attracting developers to do work on the core (where the Ant language adaptor will have to be coded)...however, we don't currently have the spare cycles needed to write the doco! It's unfortunate, but we're only human... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Finding a plugin we wrote?
Hi, In order to be able to reuse test code (see http://mail-archives.apache.org/mod_mbox/maven-users/200508.mbox/%3cD1BD [EMAIL PROTECTED]), I've written a plugin which will create a test artifact so that other projects can depend on that. However, I'm only able to invoke the plugin if it's in my local repository and I use the -no-plugin-updates option. Without that option, I get the following stacktrace: java.lang.NullPointerException at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolv eVersion(AbstractVersionTransformation.java:133) at org.apache.maven.artifact.transform.ReleaseArtifactTransformation.transf ormForResolve(ReleaseArtifactTransformation.java:51) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(Defau ltArtifactResolver.java:84) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveRelea seVersion(DefaultPluginVersionManager.java:566) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:99) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM anager.java:192) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycl e(DefaultLifecycleExecutor.java:314) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa ppings(DefaultLifecycleExecutor.java:242) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:128) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:103) at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:261) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:180) at org.apache.maven.cli.MavenCli.main(MavenCli.java:269) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) This, despite the fact that we have our own maven repo set up, and I am pointing to it in the pluginRepositories / section of the POM for the project that wants to use this. Can anyone tell me what I need to do to use the plugin without having to have it hosted at the Apache maven repo? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Finding a plugin we wrote?
Sorry to waste bandwidth, fixed this myself (needed a RELEASE.version.txt file). Thanks anyway. Dave -Original Message- From: Dave Neuer Sent: Monday, August 29, 2005 4:55 PM To: users@maven.apache.org Subject: [m2] Finding a plugin we wrote? Hi, In order to be able to reuse test code (see http://mail-archives.apache.org/mod_mbox/maven-users/200508.mbox/%3cD1BD [EMAIL PROTECTED]), I've written a plugin which will create a test artifact so that other projects can depend on that. However, I'm only able to invoke the plugin if it's in my local repository and I use the -no-plugin-updates option. Without that option, I get the following stacktrace: java.lang.NullPointerException at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolv eVersion(AbstractVersionTransformation.java:133) at org.apache.maven.artifact.transform.ReleaseArtifactTransformation.transf ormForResolve(ReleaseArtifactTransformation.java:51) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(Defau ltArtifactResolver.java:84) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveRelea seVersion(DefaultPluginVersionManager.java:566) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:99) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM anager.java:192) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycl e(DefaultLifecycleExecutor.java:314) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa ppings(DefaultLifecycleExecutor.java:242) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:128) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:103) at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:261) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:180) at org.apache.maven.cli.MavenCli.main(MavenCli.java:269) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) This, despite the fact that we have our own maven repo set up, and I am pointing to it in the pluginRepositories / section of the POM for the project that wants to use this. Can anyone tell me what I need to do to use the plugin without having to have it hosted at the Apache maven repo? Thanks, Dave - 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]
[m2] Test reuse: fundamental design flaw or RTFM?
Hi,
I have a project A, and a project B that depends on A. A has test code which
includes both abstract, invariant-checking base classes and regular tests under
src/test. Project B would like to reuse the base classes from project A's
src/test.
Searching for a way to do this in maven2 without creating a nightmare forest of
projects and dependencies, I stumbled upon the following in the ML archives:
http://marc.theaimsgroup.com/?l=turbine-maven-userm=105056155702138w=2
Needless to say, it had occurred to me to create a project A-Test, and have B
depend on both A and A-Test. However, as the respondent in the message at the
link above states, this is problematic for the reason that now, either there
are circular dependencies between A-Test and A, or A contains no tests
(allowing naïve developers to do m2 clean:clean test and have things appear
to be OK, then check in a bunch of broken code). Said respondent also states
that maven1 requires special hackery to produce multiple artifacts and
additionally that multiple artifacts per project are not encouraged.
This seems to me to be a design flaw in maven, which hopefully wouldn't be
repeated in maven2.
By default, maven produces an artifact containing the contents of src/main. It
seems odd that you cannot easily produce an artifact for src/*, or at the very
least for src/test - since it's already handled magically by the test-plugin -
and be able to specify dependencies on both A{artifact} and A{test-artifact} in
related projects.
So my question is, a) is there an easy way to do this that I've just missed and
if not b) do other people agree that this would be highly desirable (something
like artifact / testArtifactId /, and c) if b, is someone else going to add
it, or do I have to ;-) ?
Thanks,
Dave
