Integration/Acceptance testing with already installed/deployed artifacts
How can you run integration or acceptance tests separately from the compile and package lifecycle phases using maven? In other words - given that all my artifacts have already been generated and are available in my local maven cache (from a prior run of mvn install) or in the remote repository after a deploy - is it possible to run something like mvn verify or even mvn failsafe:verify but WITHOUT running the earlier lifecycle phases again? We want to test on other platforms using the prior generated artifacts. It would be ok to recompile the test classes again, but not the artifact sources. There are a few pages up already about how to write integration tests - and a few solutions and a few JIRA issues filed, but I've not found anything that explicitly looks at the desire to avoid doing the compilation and packaging again - and only to rely on currently installed or deployed artifacts for testing. http://jira.codehaus.org/browse/SUREFIRE-142 SUREFIRE-142 http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html maven-failsafe-plugin http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing Maven and Integration Testing -- View this message in context: http://old.nabble.com/Integration-Acceptance-testing-with-already-installed-deployed-artifacts-tp28111786p28111786.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Integration/Acceptance testing with already installed/deployed artifacts
Thanks, Ron - Jesse- our integration tests are mostly in separate modules - though there is some internal pressure to keep the test code closer to the source code - this is probably a clincher argument to put them in separate modules. I've tended to have bad experiences running child projects separately from their place in the reactor - but I can experiment and see how it goes. ronatartifact wrote: shinsato wrote: How can you run integration or acceptance tests separately from the compile and package lifecycle phases using maven? In other words - given that all my artifacts have already been generated and are available in my local maven cache (from a prior run of mvn install) or in the remote repository after a deploy - is it possible to run something like mvn verify or even mvn failsafe:verify but WITHOUT running the earlier lifecycle phases again? We want to test on other platforms using the prior generated artifacts. It would be ok to recompile the test classes again, but not the artifact sources. There are a few pages up already about how to write integration tests - and a few solutions and a few JIRA issues filed, but I've not found anything that explicitly looks at the desire to avoid doing the compilation and packaging again - and only to rely on currently installed or deployed artifacts for testing. http://jira.codehaus.org/browse/SUREFIRE-142 SUREFIRE-142 http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html maven-failsafe-plugin http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing Maven and Integration Testing One simple way would be to create a test project (or set of test projects) that has your libraries as dependencies so that they are pulled in from your repository as a compiled jar. You may have a few artifacts that can not be put into dependent libraries but that should be a small compile step with only a few classes. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://old.nabble.com/Integration-Acceptance-testing-with-already-installed-deployed-artifacts-tp28111786p28112159.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Forcing maven-site-plugin to override/replace distributionManagement
I'm having a heck of a time with our build since we've been required to use a parent pom.xml that has it's own distributionManagement section. The plan is to not allow us to define our own distributionManagement - but relying on the parent for our site definition seems to have wreaked all kinds of havoc. I'd hope that the -DstagingDirectory=c:\whatever would enable us to force the build there, but it seems to keep tacking on the site directory, but not as a whole - rather in pieces, and not reliably. Is there some trick to doing a mvn site:stage or mvn site:stage-deploy where I can have complete control over where the site is - overriding the entire site definition in the distributionManagement section of the pom.xml??? -- View this message in context: http://old.nabble.com/Forcing-maven-site-plugin-to-override-replace-distributionManagement-tp27854110p27854110.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module site is not working
This might be useful to others in the same quandry. When I deleted the url tag in the pom.xml files of the sub-projects, the generated URL's would work. But they did not point to the correct locations. I suspect it might be something you can fix with the site descriptor, but the site mojo documentation is incomplete. -- View this message in context: http://www.nabble.com/Multi-module-site-is-not-working-tf2555610s177.html#a9796675 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2][javadoc-plugin] currentYear, inceptionYear
Here's an answer for anyone else who may have stumbled around unnecessarily
for this one, as did I. The unclear documentation in the javadoc-mojo is
only really clarified if you look at the source code. The {x} items
referenced are place holders for different things, they are not standard
${x} property values. The organizationName is converted to
MavenProject.getOrganization, which is set in the project's pom.xml.
organization/ is an object right under the top level project/ root. The
same is true for inceptionYear, for example...
project
...
organization
nameCodehaus Mojo/name
urlhttp://mojo.codehaus.org/url
/organization
inceptionYear2006/inceptionYear
...
/project
The {currentYear} is a placeholder for the current Calendar year which the
javadoc mojo programmatically looks up. You can't set that one.
Harold
--
View this message in context:
http://www.nabble.com/-m2--javadoc-plugin--currentYear%2C-inceptionYear-tf2507450s177.html#a9800936
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to configure ArchiveManager
No response? I've not found any enlightenment about this topic, is this a bug in the documentation - because there is no ArchiveManager that can be configured? -- View this message in context: http://www.nabble.com/How-to-configure-ArchiveManager-tf2600362s177.html#a9684778 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How is CruiseControl compare to Continuum?
CruiseControl works pretty well with Maven2, we picked it instead of Continuum last year because there were some reports that Continuum might be immature still. There are lots of opinions on the internet about Continuum and CruiseControl, it would be interesting to hear what the Maven2 users here think about Continuum. -- View this message in context: http://www.nabble.com/How-is-CruiseControl-compare-to-Continuum--tf3468344s177.html#a9684871 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Maven-buildnumber plugin
The maven-buildnumber-plugin seems to have disappeared from the ucalgary site. http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/index.html Any hints of where it might have gone? I don't see it on codehaus. -- View this message in context: http://www.nabble.com/Maven-buildnumber-plugin-tf2322368s177.html#a9190056 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subproject dependency copy trips up release plugin?
We have a project with a few sub-projects. One of those subprojects uses the
maven-dependency-plugin, copying the jar file artifact from one of the
sibling sub-projects. The dependency plugin has worked fine in another
multi-project m2 buld and release when the dependency copy was only
referencing projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with
the dependency plugin causes the mvn release:prepare step to fail, because
it can't find the released version in the release repository. It doesn't
care about referencing sibling project dependencies from the regular pom
dependencies, it only chokes for the dependency:copy.
Is this a bug or a usage issue?
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
scm, distributionManagement, and other content from the poms that were not
necessary to communicate the basic issue. Any ideas or workaround would be
appreciated.
superproject/
A/ - no dependencies
B/ - dependency:copy A
//superproject/pom.xml (abbrieviated)
project
artifactIdsuperproject/artifactId
packagingpom/packaging
version1.0.0.1-SNAPSHOT/version
modules
moduleA/module
moduleB/module
/modules
/project
// superproject/A/pom.xml (abbrievated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdA/artifactId
version1.0.0.1-SNAPSHOT/version
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/project
// superproject/B/pom.xml (abbreviated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdB/artifactId
packagingwar/packaging
version1.0.0.1-SNAPSHOT/version
build
finalNameFooWar/finalName
plugins
plugin
groupIdorg.apache.maven/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
artifactIdA/artifactId
version${pom.version}/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/${pom.build.finalName}/jars/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
artifactIdA/artifactId
version${pom.version}/version
/dependency
/dependencies
/project
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO]task-segment: [clean, integration-test]
[INFO]
[INFO] [clean:clean] skip deleting directories
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: groupId:A:null:1.0.0.1:jar
Downloading: details/1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle (our repository
details)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: groupId
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to download the artifact from any repository
--
View this message in context:
http://www.nabble.com/Subproject-dependency-copy-trips-up-release-plugin--tf3215460s177.html#a8929542
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 release plugin snapshot version does not handle new development d
I don't understand the logic here. I'm not releasing independent projects.
I'm releasing a multi-module project. All the modules are renamed from
snapshot to release and then back to snapshot again. But suddenly the
multi-module project, after the release is completed, is no longer building
cohesive artifacts.
I just don't see a useful use-case where someone would actually want their
multi-module project (which almost certainly will have modules that are
depending on each other) to require a manual and potentially error prone
conversion. The only valid scenario I see for a multi-module project is for
the submodule interdependencies to be kept in step with each other, and that
not doing so in fact does break things, as opposed to the reverse.
Am I missing a useful use-case scenario here? It sounds like the
${pom.version} might be a solution. When I ran the archetype creation for
subprojects, I actually wondered why it didn't make it possible to set the
version only in the parent pom, so all sub-projects inherit the parent
version number.
- Harold
Hi,
This is not a bug - the release plugin just updates the module you're
releasing.
Dependencies should be updated manually, since changing versions might break
things.
What you could do though is specify ${pom.version} for the version in your
dependencies.
-- Kenney
--
View this message in context:
http://www.nabble.com/M2-release-plugin-snapshot-version-does-not-handle-new-development-depency-version-correctly-in-multimodule-project-tf2152810.html#a6607157
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any way to release with snapshot dependency?
I fully respect the intention here. This is not something I would want to do in general. But retrotranslator itself is not beta software. I could have rolled our own Ant plugin to use retrotranslator or retroweaver, which as a new person to maven2 was not going to be that feasible, and would have likely meant we would have been forced to drop the use of maven2 altogether. We're months away from our final release date, and we are needing to do an internal build release for QA, not to the public. Craig McClanahan-3 wrote: On 9/28/06, shinsato [EMAIL PROTECTED] wrote: We're using the retrotranslator plugin, which unfortunately isn't released yet. It's still in the sandbox. Which breaks the release plugin (which we discover the day before we have to get our first ever maven executed release out). Is there any way around this at all? I'm a bit new to maven2 still, and when I tried to do an internal release of retrotranslator, it was an exercise in frustration. Hopefully someone knows some possible way around this. If not, does anyone have an idea how to get such a release accomplished. There were snapshot dependencies as well. Is this going to require releasing every transitive dependency too? Please say there's a short cut around this... The most important question here is not about your dependencies ... it is about your own desires. Why would you want to release something of your own, based on a snapshot dependency, that might be broken if the dependency developers later release an updated snapshot that is not compatible with your own product? The only reasonable alternatives are: * Convince the developers of the packages you are dependent on to release a non-snapshot version of whatever you are depending on, so you can declare a dependency on that version. * Remove the dependency on the snapshot code by providing equivalent functionality in some other manner. If you wish to choose a different approach, you are guaranteeing that people like me will *never* *ever* trust any software you produce as being something that can be depended on, because there is no way *you* can guarantee that the snapshot based dependencies will not change in incompatible ways after your release. Note that this is not an issue specific to Maven -- it's all about how serious you are about providing a stable (over time) ability to rebuild your software from its sources. Thanks in advance, Harold Shinsato Craig McClanahan -- View this message in context: http://www.nabble.com/Any-way-to-release-with-snapshot-dependency--tf2354831.html#a6567170 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any way to release with snapshot dependency?
Thanks! I did try to do that for several days until I was able to get some help from the retrotranslator developers. It seemed that there were enough dependencies on other sandbox items that I just couldn't get this approach to work. So the developer said I needed to include a pointer to the snapshot plugin repository. Which I am very eager to take out when and if retrotranslator is taken out of the sandbox. Am I needing to trace all the transitive sandbox dependencies and install them as well? It seems that plugins get pulled from a different repository by default, since they do seem to get their own POM entry. Given the way things work, I probably won't ever point to the snapshot plugin repository ever again! I wasn't comfortable with it when the developer recommended it, and now I know why it's not terribly functional unless you don't plan to do a release. Harold dan tran wrote: a release of retrotranslator plugin is imminent it has all the votes to be released last week. Now it is up the owner to put time in. In the mean while, you can cut a release of this plugin yourself , by deploying it to your yr internal remote repo using a unique version of your own. I usually append the current svn revision number to the version so that I can refer back. (ie 1.0-alpha-1-2422 ) Strongly suggest that you get used to this, since expecting an immediate release of public plugin is quite impossible. -D On 9/28/06, shinsato [EMAIL PROTECTED] wrote: We're using the retrotranslator plugin, which unfortunately isn't released yet. It's still in the sandbox. Which breaks the release plugin (which we discover the day before we have to get our first ever maven executed release out). Is there any way around this at all? I'm a bit new to maven2 still, and when I tried to do an internal release of retrotranslator, it was an exercise in frustration. Hopefully someone knows some possible way around this. If not, does anyone have an idea how to get such a release accomplished. There were snapshot dependencies as well. Is this going to require releasing every transitive dependency too? Please say there's a short cut around this... Thanks in advance, Harold Shinsato -- View this message in context: http://www.nabble.com/Any-way-to-release-with-snapshot-dependency--tf2354831.html#a6558929 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Any-way-to-release-with-snapshot-dependency--tf2354831.html#a6567307 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Failure [SOLVED]
This may or not be a bug in the code (though I think the nullpointerexception is clearly a bug from a user perspective - the failure should be more informative - I've submitted a bug about it in JIRA, MRELEASE-167). But if it isn't a bug, it should be more clearly described in the online documentation. This was an unnecessary waste of several hours, and I can see from the other posts to the nabble forum, I wasn't the first. I'll submit a JIRA issue about this. Cheers, Harold Hi, I've found the reason why release:prepare fails for my project (it's an issue from Chas Douglass' post). The scm section of my pom.xml was like this: scm developerConnectionscm:svn:file:///usr/local/svnrep/xxx/trunk/ developerConnection /scm I downloaded the release plugin sources and checked the write method in the PropertiesReleaseConfigurationStore.java class (this is where the process fails). And I've found, that the method assumes that a connection tag is mandatory inside the scm section. So the (temporary?) solution to this problem is to include both, the connection and developerConnection in the scm section, eg: scm connectionscm:svn:file:///usr/local/svnrep/xxx/trunk/connection developerConnectionscm:svn:file:///usr/local/svnrep/xxx/trunk/ developerConnection /scm I think that this is a bug. The developerConnection should be mandatory, but connection should be optional, because the developerConnection is needed to perform the release:perform. Or at least the process should stop and an apropriate message should send to console. If it's a bug, I will file a JIRA issue and send a patch. What do you think? Regards, Jakub -- View this message in context: http://www.nabble.com/Release-Failure-tf1624778.html#a6574232 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use latest snapshot of assembly plugin?
Just be forewarned, if you add any kind of snapshot dependency to your build, you will be unable to run the release plugin. I just learned that today. Harold -- View this message in context: http://www.nabble.com/How-to-use-latest-snapshot-of-assembly-plugin--tf2358332.html#a6574270 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 release plugin snapshot version does not handle new development d
Did you find a solution? I'm noticing the same problem. The POM version is changed from 1.0.0.1-SNAPSHOT to 1.0.0.1 for the release, and then up to 1.0.0.2-SNAPSHOT for the next development. But the internal project dependencies are not changed from 1.0.0.1 to 1.0.0.2-SNAPSHOT. It seems like a definite bug, unless I'm missing something in the way that the POM was supposed to be written. Harold Markku Saarela wrote: Hi, After release:perform snapshot version project pom.xml include dependency versions for dependent projects remains to new release version ex. 1.0a not new development version ex 1.0-SNAPSHOT. I couldn't find anything from google concerning this issue. Is there any way to avoid this. It's annoying because there are over 40 modules in project. Regards, Markku Saarela - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/M2-release-plugin-snapshot-version-does-not-handle-new-development-depency-version-correctly-in-multimodule-project-tf2152810.html#a6575828 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any way to release with snapshot dependency?
We're using the retrotranslator plugin, which unfortunately isn't released yet. It's still in the sandbox. Which breaks the release plugin (which we discover the day before we have to get our first ever maven executed release out). Is there any way around this at all? I'm a bit new to maven2 still, and when I tried to do an internal release of retrotranslator, it was an exercise in frustration. Hopefully someone knows some possible way around this. If not, does anyone have an idea how to get such a release accomplished. There were snapshot dependencies as well. Is this going to require releasing every transitive dependency too? Please say there's a short cut around this... Thanks in advance, Harold Shinsato -- View this message in context: http://www.nabble.com/Any-way-to-release-with-snapshot-dependency--tf2354831.html#a6558929 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Way to run surefire against 1.4 AND 1.5
Is there a way to run tests through the surefire plugin against both a 1.4.2 and a 1.5.0 runtime? This doesn't seem likely, but I had trouble finding the full listing of parameters fore surefire on the website. A related question, if I make the source 1.5 and use the retrotranslator to backgrade it to 1.4 compatibility (which works just great), surefire will still run the tests against 1.5. Changing the target to 1.4 causes a compiler complaint, but perhaps there is some other trick to get around this? I can submit a request for this feature against surefire, but if the demand is small, what would be the right way to do this? Modify the current surefire plugin? Use ant? Thanks! Harold -- View this message in context: http://www.nabble.com/Way-to-run-surefire-against-1.4-AND-1.5-tf2179752.html#a6027767 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
