Configuring plugins in custom lifecycle
Hi,
I'd like to write a custom packaging to add some javascript-tooling. As part of
this, it should be packaged with maven-assembly-plugin.
I wrote the components.xml and lifecycle.xml mapping the package-phase to
org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single and tried to
configure it in lifecycle.xml:
lifecycle
idjszip/id
phases
phase
idpackage/id
executions
execution
goals
goalsingle/goal
/goals
/execution
/executions
configuration
descriptorRefs
descriptorRefjszip/descriptorRef
/descriptorRefs
/configuration
/phase
/phases
/lifecycle
According to lifecycle-1.0.0.xsd this is valid.
When I try to package my test-project, the new lifecycle is successfully used,
but I get an error because no assembly descriptor found. If I configure the
assembly-plugin this way in my project-pom (including the plugins additional
dependencies) the assembly-descriptor is successfully retrieved from the
repository.
Debugging maven-core and maven-plugin, it looks like nothing of my
configuration of maven-assembly-plugin is applied (breakpoint in
DefaultLifecycleExecutor, viewing mojoExecution for lifecycleMapping package,
the configuration of mojoExecution is null and mojoConfiguration of
mojoDescriptor contains lots of variables (${descriptor}, etc., but nothing of
descriptorRefs)).
Is it not possible (at least with Maven 2.2.1) to configure a lifecycle-mapped
plugin as part of the lifecycle-definition?
Thanks in advance,
Stefan
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Cobertura and Surefire
Jeff Jensen wrote: Sounds nice, but this doesn't meet my requirement, that the tests with coverage-checks (and only one time, not twice) should run, when the developers do mvn test. There is no acceptable solution to this requirement. Many of us would like to not run them twice, and in actuality running them twice is not a problem for things like site gen. Thank you for this information, that it's currently simply not possible. I think that's a shortcoming of cobertura-maven-plugin. It should be possible to overwrite the default surefire-configuration within the cobertura-configuration. But for now I have to look for another way (thank you and the others for the suggestions) we unfortunately don't use a regular CI-server but a bunch of shellscripts and cron-jobs. So it's not as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline. Looks like it is time to invest a couple of days and set it up! Your work life will be easier and maintenance cheaper. I completely aggree with you and I'd love to replace the scripts by a neat Hudson-installation. But the only way to do this (or the only way I can imagine) is to create a buildjob which simply calls our current master-buildscript. But I don't think I improved anything by doing this. We can't use the most of hudson out of the box. Even the updating of the working-copy is not trivial: not only that we use CM Synergy (little support for it in Hudson and no public Java-API), but we need a combination of CM Synergy and Change Synergy to calculate the tasks to update. I would really appreciate to migrate the build of the last 100 modules to Maven without the need of specialized builds for each target-stage, using a mainstream SCM-tool and so on... Unfortunately I think the client wouldn't pay for this work (not to forget the QA of the whole application). But I think, I go off on a tangent. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cobertura and Surefire
Stephen Connolly wrote: Because people who have not read and understood concurrency in practice often do not understand how the synchronization points affect jvm sequencing, people often wrongly suspect that result of instrumented and non-instrumented code is the same. I'm not sure, why caring about concurrency is important in this context. I'm not using Maven 3 (so no concurrent builds) and I'm not using concurrent tests with JUnit. But it's quite plain to me it is possible, that instrumented code behaves different to uninstrumented code, so testing the instrumented code can pass the tests while uninstrumented fail. (i.e. because of attributes added by instrumentation, which are unexpected when working with reflection on these attributes) But I think it doesn't happen on a regular basis, that the instrumented code pass or fails the tests, where the uninstrumented doesn't. But sadly it's more regular in our team, that the Cobertura-step fails (not because failing tests but because of too low coverage). Wayne Fay wrote: Perhaps bind something to your scm commit hook so the code simply can't make it into your SCM tool without meeting certain standards for coverage? That would mean, that during the commit we should run all the tests? I'm not sure, I want the commit to last about two minutes. Beside this, we have to use Synergy/CM as SCM tool, which is not capable of pre-commit-hooks (as far as I know). Hilco Wijbenga wrote: A normal unit test should run once, more is just a waste of time. The fact that Maven will run unit tests multiple times is a bug that we apparently have to live with. It is not a feature. If this bug were fixed and you still wanted to run your unit tests twice then you could configure that quite easily in your POM. Everybody happy I don't really like that Maven needs to run tests twice (or more often), too. But I see it is neccessary regarding Cobertura, because -- as stated to Stephen -- it can't be guaranteed, that the instrumented code behaves the same as the uninstrumented. Because of this it is not sufficient to run the tests only on the instrumented code. So this is not a bug in Maven but a problem with Cobertura. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cobertura and Surefire
Stephen Connolly wrote: [...] Run the damn tests at least twice. Ok, I see your point. But I never tried to run the tests only instrumented. I just want to execute the more-likely-failing tests earlier in the lifecycle and the not-so-likely-failing tests later. So of course I want to execute both uninstrumented _and_ instrumented tests. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cobertura and Surefire
Jeff Jensen wrote: Perhaps a different CI job structuring? This has worked well for me at many customers: Have a CI job for only compile and unit tests - this maintains the most important very fast turnaround. Have a second CI job for (longer running) IT tests that only runs with success of the first. Have a third job for coverage, standalone or as part of a full system site gen or using Sonar or other... Sounds nice, but this doesn't meet my requirement, that the tests with coverage-checks (and only one time, not twice) should run, when the developers do mvn test. We have a quite small difference between coverage-threshold and actual coverage, so I think it's important, that the developers check their coverage during development, so they can react early. Another problem to your solution is, that we unfortunately don't use a regular CI-server but a bunch of shellscripts and cron-jobs. So it's not as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Cobertura and Surefire
Hi, In our project, the tests take some time - more than the developers are willing to execute twice (Surefire and Cobertura) over and over again. First I bound Cobertura to verify-phase, but because the developers only run test to run the tests only once, they never go through the coverage-checks and the build on the buildserver breaks regularly because of too less coverage. Because usually the result of instrumented and non-instrumented code is the same, I would like to bind Cobertura on the test-phase and Surefire on the verify-phase. But I can't get it work. Maven always executes either both plugins in the test-phase or successfully skips Surefire but effectivly skips Cobertura, too, because of skipped Surefire. Currently (both are skipped) I tried to use the following plugin-configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.4/version configuration instrumentation excludes exclude**/*Exception.class/exclude /excludes /instrumentation check totalLineRate80/totalLineRate haltOnFailuretrue/haltOnFailure /check /configuration executions execution phasetest/phase goals goalclean/goal goalcheck/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration skiptrue/skip /configuration executions execution phaseverify/phase goals goaltest/goal /goals configuration skipfalse/skip /configuration /execution /executions /plugin Does anybody know how to configure this? -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Moving cobertura-profile to parent-pom
Hi, in my current build I have some projects with a common parent-pom. In the parent-pom I defined the cobertura-plugin in the pluginManagement-section to define some common thing: version, some basic configuration, binding to phases. In the most of the child-poms I have an profile (activation on !skipTests) to define some detailed configuration (exclusions,check-thresholds). I think it's not too bad this way, but it bugs me, that I still have duplicate parts of the definition (the profile-stuff and activation-definition). Is it possible to move the profiles to to parent-pom while giving the child-poms the ability to define exclusions and totalLineRates and to disable cobertura completely (for this project)? Thanks, Stefan -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
Nayan Hajratwala wrote: On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) I think these processes are just the smaller part of the problem. The big one is the integration with the SCM, I think. Maven is a great tool to fullfill the first requirement, but the SCM is another important tool. And this is, what I'm worried about. :-) Stefan -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Buildmanagement-Strategy
Hi, My problem is not really only about Maven, but more about a general buildmanagement-strategy using Maven. I didn't found a mailinglist or newsgroup dedicated for general buildmanagement-topics, so try to post my issue in this list. I'm quite new to buildmanagement and have to think about a concept to support the evolutionary architecture (or better evolutionary development of the architecture) we want to employ in the future of our product. After hours and days of considering and contemplating we found two possible solutions. Because both has serious drawbacks, I hope that anybody of you already knows this scenario/requirements (I think it's not too unusual) or has any suggestions to improve our solutions. The requirements: 1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in different versions: For example, first we developed a module booking in version 1. Some common stuff is implemented in core (version 1, too), where booking-1 depends on. Some time after release our customer wants to have an reporting-module, so wie develop reporting-1 and implement some improvements to core (because during the last project and in the meantime we saw, that there some decisions weren't ideal). So reporting-1 depends on core-2. We do not want to upgrade booking-1 to use core-2, because in this case, booking would have to pass QA again (and the customer wouldn't pay this - there is no new feature). 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a bug in booking-1 is in core-1, in truth), although core-2 is the current version of core and booking-1 wouldn't even compile against core-2. The infrastructure: 1) We use Synergy/CM for version-control. For this case it's similar to Subversion with release-branch strategy. In opposite to Subversion, cheap and/or history-preserving copies are not supported. 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and Nexus just to serve third-party-libs and to give the developers the possibility not to have to checkout the full source, but only these parts, they work with. So the repository isn't really part of releasing a new version of our system - we not even create a Release-version of our snapshots. The (possible) solutions: 1) In each module are additional directories for the different versions. Each version-directory contains quite the same code (differing only in the changes made between the versions): core- |-1-src-... |-2-src-... ... This doesn't feel rights. It's somehow ugly, we copy code and we have to merge bugfixes manually from one version to all others. But it's a quite simple solution to solve both requirements. 2) Each release-branch contains only the current version of code. The other versions are taken from the Maven-repository (in this case we have to use release-version and all the stuff). If a bugfix is core-1 is neccessary, a developer check-out the release-branch 1, implement the bugfix, start the build and calls a build- or release-manager to deploy the release-version to the repository. If it's time to go live with a new version, an appropriate assembly is built, which contains in parts of fresh compiled code and in parts of artifacts out of the the Maven-repository. At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. If any of you has some experience with similar requirements, has an idea for a different solution or an suggestion to improve the one or the other solution, I would really appreciate your ideas and comments. Thanks for reading all of this quite long mail. :-) Stefan -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
Ron Wheeler wrote: This is a common problem and when you quote the cost of reporting-1, you need to include the cost of releasing booking-1 with the new core library. You can reduce the cost by breaking core onto multiple smaller libraries that are less susceptible to change. With small changes to large systems, the cost of the release of a new system can be larger than the programming and testing of the actual change. I'll talk with the architect tomorrow or on monday about this issue, but I think this isn't an option. The Java-parts of our system are growing since about ten years and contains ~100 modules. Our team is relatively new at this occupation, but it's obvious, that in the last ten years nobody had the heart to touch the existing infrastructure, because it would cost huge amounts of money (I'm not familiar to details, but we heard numbers with more than five digits) just for QA. This results in adding here something and there around the infrastructural components or duplication with slight changes - uncontrolled growing... As a consequence we want to establish a new architecture beside the old one and learning from these issues. So the evolutionary development of the architecture is somehow crucial. You create releases that you store in Nexus (or some other repository). In your SCM, you store your software with properly named branches so that you can patch and rebuild anything that you If I understand you right, this is the way we thought about. Is it correct, that your suggestion would lead to the same goal: we wouldn't have the One release-branch containing the complete currently released code-base? In our approach the current released code-base is splitted across multiple branches. Stefan -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Buildmanagement-Strategy
Nayan Hajratwala wrote: At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. This would all be resolved by using the proper maven strategy. I planned to do it similarly to the approach you described above. Thank you for the detailed description of the procedure. I've never worked with releasing in Maven before, so I didn't knew exactly what to do. I just had a rough conception. :) Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( For the beginning, I would be happy if I could integrate this maven strategy cleanly with the SCM. Stefan -- GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
