AW: How to test with multiple versions
Well in the Flexmojos Project we have a testsuite that tests a plugin against several Versions of SDK (Compiler + Libs). The trick is that in the tests, we generate poms with different Versions and spawn different child maven builds for each of These using the maven-invoker-plugin. You can have a look at the Setup here: https://github.com/chrisdutz/flexmojos/blob/flexmojos-6.x/flexmojos-testing/flexmojos-test-harness/pom.xml Hope this is somehow what you are looking for. Chris Von: Marshall Schor [m...@schor.com] Gesendet: Dienstag, 12. November 2013 16:15 An: Maven Users List Betreff: How to test with multiple versions Hi, We would like to run tests that test for compatibility between newer releases and older versions, for a client-server kind of application. The main idea here is that the tests would be run with the client running one version of things, and the server running another. Is there a suggested approach for doing this using Maven? The main issue I see is that the test case would depend on multiple versions of the same artifacts - some version being assigned to the client, and some to the server. But I don't think Maven allows that? It would be good to hear from others who have previously faced down this kind of issue :-) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Name of a new Apache plugin for maven?
Hi, I am part of the Apache Flex Team and am currently working on Setting up a new Maven plugin for building Apache Flex applications. This will be an official Apache maven plugin, so would I be allowed to Name it maven-flex-plugin or should flex-maven-plugin be used instead? I would prefer maven-flex-plugin by far, but don't want to have to rename everything in the case this is not allowed. Chris
AW: Name of a new Apache plugin for maven?
Ok ... well I did read that naming info, I was just confused how to actually read it :-) Apache Maven plugin or Apache Maven plugin ... you see there are two semantics on how you could understand this. In my case it would actually be a Maven plugin from an Apache Project, but it's not a plugin from the Apache Maven Project ;-) But I the Definition regarding the Location of the sources is far less ambiguous. I'll stick to flex-maven-plugin then. Chris Von: Barrie Treloar [baerr...@gmail.com] Gesendet: Dienstag, 6. August 2013 09:02 An: Maven Users List Betreff: Re: Name of a new Apache plugin for maven? Further googling shows http://apache-felix.18485.x6.nabble.com/DISCUSS-rename-maven-bundle-plugin-to-bnd-maven-plugin-td5002248.html Since your plugin isn't hosted inside the Apache Maven source repository flex-maven-plugin looks like the correct choice. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: mvn release:prepare does not update parent version
Hi, is there actually a reason why only the artifacts in the build are updated? I would agree that without providing versions for artifacts manually, this could cause problems, but when using the feature described here: http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html It is possible to provide separate versions for every module. In my release I provided release and development versions for all modules (also ones not in the reactor), but the release:prepare simply skipped those not in the build. I had to create a patched version for this, but it was a pretty unsatisfying solution. If the plugin would for example update all those versions in the reactor plus all those I manually provided a version for, might solve Markus' problems. Chris -Ursprüngliche Nachricht- Von: jieryn [mailto:jie...@gmail.com] Gesendet: Montag, 22. Juli 2013 20:36 An: Maven Users List Betreff: Re: mvn release:prepare does not update parent version Greetings, On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg k...@quipsy.de wrote: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Maven and JPA/EclipseLink Configuration...
You could have a look at my Wiki article about multiple persistence.xml files: https://dev.c-ware.de/confluence/display/PUBLIC/Multiple+persistence.xml+in+a+multi-module+application Here you could separate your JPA entities from the platform dependent Options. In your case you could create your persistence.xml files without any db and application-server specific Settings and then simply add an additional persistence.xml to your deployment ... the merging persistence unit Manager would then merge those properties in automatically without having to update all of the individual persistence.xml files. Don't quite know why my confluence is so slow at the Moment ... will have a look at this tonight. Chris Von: John Patrick [nhoj.patr...@gmail.com] Gesendet: Dienstag, 9. Juli 2013 18:50 An: Maven Users List Betreff: Maven and JPA/EclipseLink Configuration... I'm working on a project that uses JPA EclipseLink, everything started of fine with Jetty for developers development and WebLogic and Oracle proper ear deployments. EclipseLink has two values that need to be set in persistence.xml depending upon your Application Server and Database; eclipselink.target-server eclipselink.target-database This mean we have two profiles, Jetty and Release. Now we support WebSphere and DB2, so have gone to 5 profiles and the need to rebuild the ear 4 times which each profile. Profiles Jetty WLSOracle WLSDB2 WASOracle WASDB2 I feel I'm doing something wrong... Does someone have any suggestions on what to look at so i could potentially build it once and get all the 4 ears build in one command? I've thought about types or classifiers but unsure if that is just another hack... Thoughts? As we soon might also need to support MySQL and Glassfish so their is another 5 profiles and 5 more builds for a release. John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Maven and JPA/EclipseLink Configuration...
Well it should be possible as the PersistenceUnitManager is more a JPA Thing and not restricted to Spring. In my example it is just configured using Spring. Think it should be possible to do this an a JavaEE application (Perhaps I should find this out somehow and extend my tutorial). If someone here knows how to do so, I would be glad for some Input on this ;-) Chris Von: Stephen Connolly [stephen.alan.conno...@gmail.com] Gesendet: Donnerstag, 11. Juli 2013 11:14 An: Maven Users List Betreff: Re: Maven and JPA/EclipseLink Configuration... That looks like a Spring only solution I wonder is there a pure JavaEE counterpart On 11 July 2013 09:56, christofer.d...@c-ware.de christofer.d...@c-ware.dewrote: You could have a look at my Wiki article about multiple persistence.xml files: https://dev.c-ware.de/confluence/display/PUBLIC/Multiple+persistence.xml+in+a+multi-module+application Here you could separate your JPA entities from the platform dependent Options. In your case you could create your persistence.xml files without any db and application-server specific Settings and then simply add an additional persistence.xml to your deployment ... the merging persistence unit Manager would then merge those properties in automatically without having to update all of the individual persistence.xml files. Don't quite know why my confluence is so slow at the Moment ... will have a look at this tonight. Chris Von: John Patrick [nhoj.patr...@gmail.com] Gesendet: Dienstag, 9. Juli 2013 18:50 An: Maven Users List Betreff: Maven and JPA/EclipseLink Configuration... I'm working on a project that uses JPA EclipseLink, everything started of fine with Jetty for developers development and WebLogic and Oracle proper ear deployments. EclipseLink has two values that need to be set in persistence.xml depending upon your Application Server and Database; eclipselink.target-server eclipselink.target-database This mean we have two profiles, Jetty and Release. Now we support WebSphere and DB2, so have gone to 5 profiles and the need to rebuild the ear 4 times which each profile. Profiles Jetty WLSOracle WLSDB2 WASOracle WASDB2 I feel I'm doing something wrong... Does someone have any suggestions on what to look at so i could potentially build it once and get all the 4 ears build in one command? I've thought about types or classifiers but unsure if that is just another hack... Thoughts? As we soon might also need to support MySQL and Glassfish so their is another 5 profiles and 5 more builds for a release. John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Is there any generic Maven code generator?
Well I guess, I will eventually whip up such a plugin myself, cause I really
need to cleanup quite a code-generation mess.
Eventually based upon the GraniteDS libs, as does the Flexmojos plugin.
Chris
-Ursprüngliche Nachricht-
Von: bmat...@gmail.com [mailto:bmat...@gmail.com] Im Auftrag von Baptiste MATHUS
Gesendet: Freitag, 1. März 2013 08:02
An: Maven Users List
Betreff: Re: Is there any generic Maven code generator?
The following is not going to really help you, but I just wanted to point out
that a plugin was recently initiated at mojo (still in the sandbox) dedicated
to templating (called templating-maven-plugin).
It's currently only supporting Maven sources filtering, but the plan is to
support different templating engines like velocity or mustache for example.
Cheers
Le 28 févr. 2013 12:17, Anders Hammar and...@hammar.net a écrit :
I haven't seen any generator plugin that does what you're looking for.
Wearing a Maven hat, I don't think that having these stub classes
generated to src/main/java belongs to the build lifecycle. It's a
separate process that should be executed outside of a Maven build. SO
you would then have a separate goal for that is not bound to a phase by
default.
/Anders
On Thu, Feb 28, 2013 at 10:57 AM, christofer.d...@c-ware.de
christofer.d...@c-ware.de wrote:
Ahem ... this wasn't quite the path I was indenting to go with my
question.
What I am looking for is a generator-plugin that uses a template
engine (such as Velocity) to generate code, and uses as input an
pojo-object
model
representing the details of a Java class that it should generate
code
for.
Now I would like to have (or create, if I have to) a plugin, that
allows me to specify which classes I am addressing using some
include/exclude config.
I could configure different include/exclude groups, each one in one
execution and for each I could provide a set of:
- resourceTemplates
- testResourceTemplates
- sourceStubTemplates
- sourceTemplates
- testSourceStubTemplates
- testSourceTemplates
- ...
So for each matched class, I could generage:
- resources into the target/generated-resources directory using the
resourceTemplates (could be more than one)
- testResources into the target/generates-test-resources directory
using the testResourceTemplates, ...
- source code into target/generated-sources ...
- test source code into target/generated-test-sources ...
One speciality I liked with GraniteDS was the ability to have
auto-generated stub-classes generated in src/main/java ... if a
class allready existed, no code would be generated, but if a class
didn't
exist,
it would be generated. This was great for creating classes that
extend other generated classes and to allow customization. Something
simple as
this:
public class MyClass extends MyClassBase { }
And MyClassBase is generated to target/generated-sources.
With such a plugin I could be able to generate my JPA MetaModel
classes, my DTOs, SQL scripts, ... and wouldn't have to configure
thousands of different generators. People could develop
best-practice templates for general purpose tasks.
Hope this clarified, what I was looking for.
If nothing similar exists, I would like to start developing
something
like
this, because I think it would make my life a lot easier.
Chris
Von: Stadelmann Josef [josef.stadelm...@axa-winterthur.ch]
Gesendet: Donnerstag, 28. Februar 2013 09:52
An: Maven Users List
Betreff: AW: Is there any generic Maven code generator?
A code generator needs input. Hence some generic formal language
is
used
to specify the input to the genric code generator? UML?
Visualization of
a
generic language could mean - speak UML, UML is a reality today. UML
modells can says much more then 1000 words? Hence I opt for better
integration of modelling tools with maven. Also roundtrip
engineering is
a
must. Enterprise Architect (EA) is able to generate code from UML
and
other
diagrams for many target compiler and it helps you to have code,
modell
and
documentation in sync. And EA can be feed with code and generates
your diagramms. A task which only ends when the modells become to complex.
Maven
is much about geting and nailing dependent components together. If
maven finds the dependecies, a tool like EA could use input to draw
i.e. the component diagram, maybe a maven plugin can pave the way
for EA. Other whise, in my mind, there are far too many tools around
and I get to often the feeling that each time a problem developes,
folk starts to seek a
tool
to avoid some brain work. So if one knows in which aspects maven
poms
could
be used toward EA to get ceratin artiacs visualized for better
understanding, that would be almost a very good step into proper
direction.
Josef
AW: Is there any generic Maven code generator?
Ahem ... this wasn't quite the path I was indenting to go with my question.
What I am looking for is a generator-plugin that uses a template engine (such
as Velocity) to generate code, and uses as input an pojo-object model
representing the details of a Java class that it should generate code for.
Now I would like to have (or create, if I have to) a plugin, that allows me to
specify which classes I am addressing using some include/exclude config.
I could configure different include/exclude groups, each one in one execution
and for each I could provide a set of:
- resourceTemplates
- testResourceTemplates
- sourceStubTemplates
- sourceTemplates
- testSourceStubTemplates
- testSourceTemplates
- ...
So for each matched class, I could generage:
- resources into the target/generated-resources directory using the
resourceTemplates (could be more than one)
- testResources into the target/generates-test-resources directory using the
testResourceTemplates, ...
- source code into target/generated-sources ...
- test source code into target/generated-test-sources ...
One speciality I liked with GraniteDS was the ability to have auto-generated
stub-classes generated in src/main/java ... if a class allready existed, no
code would be generated, but if a class didn't exist, it would be generated.
This was great for creating classes that extend other generated classes and to
allow customization. Something simple as this:
public class MyClass extends MyClassBase {
}
And MyClassBase is generated to target/generated-sources.
With such a plugin I could be able to generate my JPA MetaModel classes, my
DTOs, SQL scripts, ... and wouldn't have to configure thousands of different
generators. People could develop best-practice templates for general purpose
tasks.
Hope this clarified, what I was looking for.
If nothing similar exists, I would like to start developing something like
this, because I think it would make my life a lot easier.
Chris
Von: Stadelmann Josef [josef.stadelm...@axa-winterthur.ch]
Gesendet: Donnerstag, 28. Februar 2013 09:52
An: Maven Users List
Betreff: AW: Is there any generic Maven code generator?
A code generator needs input. Hence some generic formal language is used to
specify the input to the genric code generator? UML? Visualization of a generic
language could mean - speak UML, UML is a reality today. UML modells can says
much more then 1000 words? Hence I opt for better integration of modelling
tools with maven. Also roundtrip engineering is a must. Enterprise Architect
(EA) is able to generate code from UML and other diagrams for many target
compiler and it helps you to have code, modell and documentation in sync. And
EA can be feed with code and generates your diagramms. A task which only ends
when the modells become to complex. Maven is much about geting and nailing
dependent components together. If maven finds the dependecies, a tool like EA
could use input to draw i.e. the component diagram, maybe a maven plugin can
pave the way for EA. Other whise, in my mind, there are far too many tools
around and I get to often the feeling that each time a problem developes, folk
starts to seek a tool to avoid some brain work. So if one knows in which
aspects maven poms could be used toward EA to get ceratin artiacs visualized
for better understanding, that would be almost a very good step into proper
direction. Josef
-Ursprüngliche Nachricht-
Von: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
Gesendet: Mittwoch, 27. Februar 2013 12:31
An: users@maven.apache.org
Betreff: Is there any generic Maven code generator?
I just posted this to Stackoverflow, but after posting I realized, that I
should have come here first :-(
I am currently working on a project, that makes intense usage of code
generation for various purposes. One generator generates SQL scripts from jpa
entities. Another generates DTOs from pojos, another generates the JPA2.0 meta
model, jet another generates some xml and schema files based on Java classes
... each generator works completely different needs to be configured
differently.
My question now is ... is there any generic maven code generator plugin out
there with the following attributes:
*
Creates a pojo model of a Java class (Names, Properties, Annotation, Methods
...)
*
Uses templates for defining the output that uses the pojo model to generate any
output.
*
Allows me to specify multiple templates for one class
*
Allows me to generate code and resources
*
Allows me to generate a base class to target/generated-sources and a dummy
implementation to src/main/java which simply extends the base class (If the
dummy class in src/main/java exists, nothing happens, if it doesn't it
generates such a dummy class. This code is checked in to the SCM and allows
extending the generated classes manually)
I am using the Flexmojos GraniteDS plugin for generating my
Is there any generic Maven code generator?
I just posted this to Stackoverflow, but after posting I realized, that I should have come here first :-( I am currently working on a project, that makes intense usage of code generation for various purposes. One generator generates SQL scripts from jpa entities. Another generates DTOs from pojos, another generates the JPA2.0 meta model, jet another generates some xml and schema files based on Java classes ... each generator works completely different needs to be configured differently. My question now is ... is there any generic maven code generator plugin out there with the following attributes: * Creates a pojo model of a Java class (Names, Properties, Annotation, Methods ...) * Uses templates for defining the output that uses the pojo model to generate any output. * Allows me to specify multiple templates for one class * Allows me to generate code and resources * Allows me to generate a base class to target/generated-sources and a dummy implementation to src/main/java which simply extends the base class (If the dummy class in src/main/java exists, nothing happens, if it doesn't it generates such a dummy class. This code is checked in to the SCM and allows extending the generated classes manually) I am using the Flexmojos GraniteDS plugin for generating my ActionScript model code, but it's pretty specialized for that particular purpose. I think such a generic generator would make things a lot easier ... is there something like that available out there, or do I have to start implementing it myself? Chris
[ANN] Flexmojos 6.0.0 Relesed
Flexmojos, the maven plugin for building applications using Adobe Flex / Apache Flex, has just been released in version 6.0.0. The main difference to older Flexmojos releases, is that this version is able to use Flex SDKs generated by the Apache Mavenizer tool. This way you can use Flexmojos to build applications with any Flex version starting with Adobe Flex 2.0 up to Apache Flex 4.9. The plugin has been deployed to: https://oss.sonatype.org/content/groups/public/net/flexmojos/oss/ If migrating from earlier versions, please have a look at the migration how-to page: https://flexmojos.atlassian.net/wiki/display/FLEXMOJOS/Migrating+to+6.x The Flexmojos wiki should also provide enough information for new users to get up to speed pretty fast: https://flexmojos.atlassian.net/wiki/display/FLEXMOJOS
Strange plugin dependency problem
Hi, I am currently confronted with a strange problem. I am trying to get a Maven project using AspectJ Compile Time Weaving in IntelliJ. The source code level is set to 1.7 and uses some 1.7 language features. The aspectjtools-1.6.11 which is used by the aspectj-maven-plugin per default can't deal with this, therefore we changed the aspectjtools version to 1.7.1. The build is building nicely using maven. The pom fragments look like this: pluginManagement plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.4/version dependencies dependency groupIdorg.aspectj/groupId artifactIdaspectjrt/artifactId version1.7.1/version /dependency dependency groupIdorg.aspectj/groupId artifactIdaspectjtools/artifactId version1.7.1/version /dependency /dependencies configuration avoidFinaltrue/avoidFinal Xlintignore/Xlint complianceLevel1.7/complianceLevel showWeaveInfotrue/showWeaveInfo source1.7/source target1.7/target encodingISO-8859-1/encoding aspectLibraries aspectLibrary groupIdcom.acme/groupId artifactIdmyaspects/artifactId /aspectLibrary /aspectLibraries /configuration /plugin /plugins /pluginManagement and: profile idaspectj-weaving/id activation activeByDefaultfalse/activeByDefault /activation build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId executions execution goals goalcompile/goal /goals /execution /executions /plugin /plugins /build /profile When importing the project to IntelliJ the compiler is automatically set to ajc but the compiler from 1.6.1 is detected and used automatically and I have to manually change this to 1.7.1 (and repeat this now and then after updating the Maven settings). When issueing the following command on the commandline: mvn -P aspectj-weaving dependency:resolve-plugins I can see: [INFO] Plugin Resolved: aspectj-maven-plugin-1.4.jar [INFO] Plugin Dependency Resolved: plexus-utils-2.0.5.jar [INFO] Plugin Dependency Resolved: maven-artifact-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-model-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-project-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-reporting-api-2.2.0.jar [INFO] Plugin Dependency Resolved: maven-plugin-api-2.2.0.jar [INFO] Plugin Dependency Resolved: doxia-site-renderer-1.1.2.jar [INFO] Plugin Dependency Resolved: maven-reporting-impl-2.1.jar [INFO] Plugin Dependency Resolved: aspectjtools-1.6.11.jar There is no mention of a 1.7.1 version ... why and how can I configure Maven to display the 1.7.1 version (I think this is the reason why IntelliJ is automatically detecting 1.7.1 Chris
AW: Way to limit the projects in the reactor of a maven build started with the invoker plugin
Thanks for your responses. Even if your profile solution should work, I guess the maintenance effort would be enormous (The project I should implement my release tool for has about 80 independent Artifacts, so I would end up with 80+ profiles). Well I guess I'll simply start by taking the current release Plugin as a basis and simply whip up a patched one, as I have to admit I'm completely fed-up with all the problems I am having with the ones available. I know that You don't do sub-releases in Maven but in my case I am working my ass off to satisfy my customer and I simply want this finished. So if the default stuff doesn't do it, I'll make it do it ... perhaps I should call it the pandoras-box-release-plugin or something like that ;-) So I'm finally giving up using standard stuff ... from now I'll go the custom path. Hopefully that will lead me out of this release jungle soon ;-) Chris -Ursprüngliche Nachricht- Von: Lyons, Roy [mailto:roy.ly...@cmegroup.com] Gesendet: Mittwoch, 13. Februar 2013 23:16 An: Maven Users List Betreff: Re: Way to limit the projects in the reactor of a maven build started with the invoker plugin I have a method which will summarily be poked at... but it works for the one team that uses it here... They put the [modules] section in profiles... and set a profile to determine which set of modules are included. In general the advice you will get is to never have a profile make a difference in the binaries being built... but it is kind of handy if its an internal project that is well documented. Thanks, Roy Lyons Senior Configuration Engineer On 2/13/13 2:40 PM, christofer.d...@c-ware.de christofer.d...@c-ware.de wrote: Hi, I'm currently trying to use the invoker plugin to start a maven build and to pass the list of projects that should be in the reactor of that build. Unfortunately I couldn't find a way to do so ... so is there a way and if not, how could I start a second maven build from a maven build? Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: How to tell release:perform only to deploy specific modules
First of all ... thank you for replying. Hopefully I will be able to post some stuff that doesn't scare the crap out of normal Maven users one day ;-) Well I doubt that I will be able to convince them. This build is a very special case and they do have valid reasons for this. I do know that I will probably never have to setup a build like this again, but in this case the solution is the best solution for that particular case. They are aware of the problems that come with this and are sort of begging me to finish automating the build-system for them. I already had the Idea of creating a custom deploy mojo, inspired by the maven release:perform mojo, but would really like to automate this without a custom plugin. I did do some research but couldn't find a way to actually do a checkout of a tag to some place and then trigger a Maven build there. I know the checkout is not the problem here, but more the triggering of a separate Maven build ... how could I configure such a thing from the Maven commandline? And thanks again for your help ... it's greatly appreciated. Chris -Ursprüngliche Nachricht- Von: Robert Scholte [mailto:rfscho...@apache.org] Gesendet: Dienstag, 12. Februar 2013 17:36 An: Maven Users List Betreff: Re: How to tell release:perform only to deploy specific modules Hi Chris, Since you're well aware that you're fighting the release procedure as expected by the maven-release-plugin, I'd suggest not to use release:perform As described on the perform a release-page[1] this goal does just 2 things: - Checkout from an SCM URL with optional tag - Run the predefined Maven goals to release the project (by default, deploy site-deploy) These are steps you can do with or without Maven. Robert ps. Maybe you can convince your team if you can show them how easy a release:perform is when the structure better fits the release cycle. btw. additionalArguments is filled with arguments[2] [1] http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html [2] http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#arguments Op Sat, 09 Feb 2013 19:13:23 +0100 schreef christofer.d...@c-ware.de christofer.d...@c-ware.de: Hi, this is a relatively special case and I am sort of running out of options. I am trying to setup a build that it allows minor releases of individual projects (I don't want to get into a discussion about if this is a good thing ... please). Now I am using release:prepare to prepare the release by providing version numbers for all modules in the project. This is working great. Unfortunately I would like to invoke release:perform and use mavens -projects property to limit the reactor to a specific subset of artifacts. Otherwise the build would try to deploy artifacts that have been previously released and would instantly fail. Unfortunately the -projects is only picked up by the main maven process, the setting is not passed to the spawned deploy maven build in the checkout-directory. How could I configure the build to act as I want? I have noticed the additionalArguments property in the release.properties, and was thinking about putting my -projects in there, but I guess this would be applied to several executions and not only the deploy build in the separate checkout. Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to tell release:perform only to deploy specific modules
Hi, this is a relatively special case and I am sort of running out of options. I am trying to setup a build that it allows minor releases of individual projects (I don't want to get into a discussion about if this is a good thing ... please). Now I am using release:prepare to prepare the release by providing version numbers for all modules in the project. This is working great. Unfortunately I would like to invoke release:perform and use mavens -projects property to limit the reactor to a specific subset of artifacts. Otherwise the build would try to deploy artifacts that have been previously released and would instantly fail. Unfortunately the -projects is only picked up by the main maven process, the setting is not passed to the spawned deploy maven build in the checkout-directory. How could I configure the build to act as I want? I have noticed the additionalArguments property in the release.properties, and was thinking about putting my -projects in there, but I guess this would be applied to several executions and not only the deploy build in the separate checkout. Chris
AW: Maven release:prepare
Hi Sundeep,
I doubt you can skip the last 2 steps, but you could configure the plugin to
change the development version to exactly the same version as the release
version. Haven't tried this though:
mvn release:prepare -DreleaseVersion={release-version}
-DdevelopmentVersion={release-version}
The result should be the same as if the last two steps were skipped.
As I mentioned ... haven't actually tried this :-)
Chris
-Ursprüngliche Nachricht-
Von: Sundeep Reddy [mailto:sundeep.i...@gmail.com]
Gesendet: Samstag, 5. Januar 2013 13:30
An: users@maven.apache.org
Betreff: Maven release:prepare
Hi All,
The maven release:prepare does the following things:
release: prepare - Performs a number of operations
- Checks to make sure that there are no uncommitted changes.
- Ensures that there are no SNAPSHOT dependencies in the POM file,
- Changes the version of the application and removes SNAPSHOT from the
version. ie 1.0.3-SNAPSHOT becomes 1.0.3
- Run project tests against modified POMs
- Commit the modified POM
- Tag the code in Subversion
- Increment the version number and append SNAPSHOT. ie 1.0.3 becomes
1.0.4-SNAPSHOT
- Commit modified POM
Is there way where we could skip the last 2 steps i,e increment of the version
number and appending the SNAPSHOT . In a way just want to convert the snapshot
to a release,no further development version.
Thanks
Sundeep
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
AW: Release plugin ${project.version} dependencies
Actually the release plugin allows you to specify a release and a development
version for any module in your build:
http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html
Even if this means you have to configure a comandline that is insanely long.
I recently built a Jenkins plugin for Volkswagen and they allowed me to publish
that. It's main goal is to allow to configure that commandline by selecting
checkboxes and suggesting version.
https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
It allows to do a Major release (All modules are set to the same version) or
a minor release, in which you check a checkbox for the modules you want to
release. The tool automatically queries a repo for existing versions and
suggests a new version number for that minor release. I did do quite some work
on that plugin in the last 2 Weeks and am planning on updating my documentation
and publishing the code at github as soon as I have the time to cleanup the
code and strip out the VW-specifics.
Chris
-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org]
Gesendet: Donnerstag, 13. Dezember 2012 21:38
An: Maven Users List
Betreff: Re: Release plugin ${project.version} dependencies
Hi,
the maven-release-plugins only accepts ${project.version} for reactor-projects,
i.e. projects being part of a multi-module project.
The fact that your projects are separated also means that they both have their
own release-cycle. As you describe, they often(!) will be the same, but if your
MSI config is changed, does that require a new project-main?
So I understand why it was implemented like this.
You could change the value for allowTimestampedSnapshots[1] to true, but then
you've lost the check for all snapshots.
What you could probably do is combine this with the enforcer rule called
RequireReleaseDependencies[2] (have never done this myself though).
Robert
[1]
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots
[2] http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
Op Thu, 13 Dec 2012 13:51:06 +0100 schreef Dan Godfrey
daniel.godf...@gmail.com:
Hi,
I'm having trouble using the release-plugin on a project as it is
complaining that it has snapshot dependencies, even though those
dependencies are actually set to ${project.version}. So when the
dependency check phase runs they are indeed SNAPSHOT dependencies, if
it were to continue then they would be updated to non-SNAPSHOT
dependencies in a later phase.
I was wondering if anybody knows of anyway to get around this?
To explain why: I have 2 separate projects project-main
project-windows.
project-main is a jar (well multiple jars)which are deployed to our
local repo. project-windows then takes that deployed jar and packages
it up as an MSI. Both of these projects are kept in lockstep with
regards version numbers and have separate CI jobs. I've split the 2
projects up in different SCM repos like this as we have have other CI
jobs depending on project-main for testing, and potentially in the
future a project-linux, etc.
Thanks,
Dan.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Implementing a Maven plugin with alternate mojo/component implementations?
Hi, I am currently setting up a new Maven plugin project and am currently faced with the following problem: I have fefined a dafaultLifecycle which defines which mojos should generally be invoked in which phase. My problem now is that I would like to have different implementations used for performing the tasks. There should allways be a default mojo/component that is used if the user doesn't specify which implementation he wants to use, but should offer a way to tell the build to use a different implementation. Would it be good to have some sort of proxy-mojo that is allways called and then relays to an implementation component based upon the configuration, or would it be better do define completely independent Mojos? The Internet seems to be full of tutorials on creating Maven plugins, but I haven't found a single one dealing with this particular problem. Help greatly appreciated, Chris
AW: Implementing a Maven plugin with alternate mojo/component implementations?
Hi Robert, I managed to actually get something working in the meanwhile. Here's what I did: - I created an API artifact containing the interface of my modules. - I created several Implementations of the Interfaces each one annotated with @Component with the Role set to the Interface class and each one with an individual hint-name. - I create one Mojo with a map property with MapHintName, ModuleType and a String property to select the desired implementation (defaulting to a default string) - Now in the execute method of my Mojo I simply read the desired implementation name, fetch that instance from the map and use the Module interface to relay the call to that particular instance. Semms to be doing the jobe nicely ... is this a valid approch or would a best practice do it differently? Chris -Ursprüngliche Nachricht- Von: Robert Scholte [mailto:rfscho...@apache.org] Gesendet: Sonntag, 2. Dezember 2012 15:57 An: Maven Users List Betreff: Re: Implementing a Maven plugin with alternate mojo/component implementations? Here are some plugins which you should have a look at: maven-compiler-plugin ( compilerId ) maven-release-plugin ( mavenExecutorId ) Now you need to do some Plexus-stuff, since that's the DI-framework for Maven. Every task-implementation needs to have the same interface (plexus role) and a specific id (role-hint) In your manager you can let Plexus fill a map based on the plexus role. So now you can add a parameter to your plugin with a default taskId, and users can overrule it. I think this meets your requirements. Good luck, Robert Op Sun, 02 Dec 2012 12:33:43 +0100 schreef christofer.d...@c-ware.de christofer.d...@c-ware.de: Hi, I am currently setting up a new Maven plugin project and am currently faced with the following problem: I have fefined a dafaultLifecycle which defines which mojos should generally be invoked in which phase. My problem now is that I would like to have different implementations used for performing the tasks. There should allways be a default mojo/component that is used if the user doesn't specify which implementation he wants to use, but should offer a way to tell the build to use a different implementation. Would it be good to have some sort of proxy-mojo that is allways called and then relays to an implementation component based upon the configuration, or would it be better do define completely independent Mojos? The Internet seems to be full of tutorials on creating Maven plugins, but I haven't found a single one dealing with this particular problem. Help greatly appreciated, Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Excluding a Plugin dependency
Hi, I am currently having a really stupid problem, that I am currently stuck on: The thing I am currently working on is a maven plugin (Flexmojos). As Flex is now an Apache project, I am working on supporting Apache FDKs in the project, The problem is that the compiler is a direct dependency of the plugin. This was not a problem as long as all compilers had the groupId com.adobe.flex. But now I have the Apache compilers org.apache.flex. I would now need to tell Flexmojos not to depend on the com.adobe.flex:compiler package, but include org.apache.flex:compiler instead. I know how to exclude the dependency of a plugin dependency, but I couldn't find a way to exclude a direct dependency. Currently I'm thinking about setting the compiler dependency to provided and hoping everybody has configured the compiler artifact. This is the last issue preventing me from finishing the new Flexmojos6 and I would really love to have this off my table ... so help is greatly appreciated :) Chris
AW: Maven Dependency Type
Hi John, the problem is that Eclipse doesn't know any difference between the normal classpath of an application and a test classpath that includes tests. For eclipse everything (application and test classes) are thrown into one basket. That's why you are able to build in Eclipse. As Jörg mentioned, in maven there is no such thing as a test-jar type dependency. I guess you are refering to the test-jar goal of the jar plugin. Unfortunately these test jars are usually not deployed in the local or any remote maven reposiories, so they only exist in your projects target directory. One way to achieve what you want, would be to create an ordinary maven artifact containing the classes you want to share and to add a reference to that wherever you need it. We usually have some artifacts, that we use only for testing. In order to use these classes in several artifacts tests, we usually strip out those shared resources into an artifact with a special suffix test-support. Then all we need to do is to add an ordinary test-scoped dependency to that jar. hope that helps, Chris Von: John Kramer [jkra...@mojiva.com] Gesendet: Donnerstag, 25. Oktober 2012 22:09 An: Maven Users List Betreff: Maven Dependency Type Hey guys, I have a question regarding the maven dependencies section. In order to put a dependency on a test jar, is it correct to specify typetest-jar/type or typetest/type? I specified a dependency on project bar from project foo using typetesttest in a dependency section and the maven eclipse plugin ran successfully and eclipse set up my projects so that the module recognizes, but mvn package gives the following error: [ERROR] Failed to execute goal on project statistics: Could not resolve dependencies for project com.mojiva:foo:jar:1.9.0-SNAPSHOT: Could not find artifact com.mojiva:bar:test:1.9.0-SNAPSHOT in mojiva If I change it, to test-jar, the error goes away. I know I have used typetest/type in the past and not had an issue. Did it change? Also, I can't find the documentation on this. A pointer to the docs would be helpful. Thanks to all! John Kramer email: jkra...@mojiva.commailto:jkra...@mojiva.com mobile: 314.435.2370 skype: kramer.mojiva twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech 0xCAFEBABE0032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Independent module release strategies
Well after quite a lot of digging in the code of the release plugin, I think that I will use a different strategy: - in the release.properties or using the commandline, I am able to set individual versions of my modules and the release plugin will use them http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html which is basically what I wanted in the first place. - In order to release only individual projects, using the advanced reactor otions of maven seems ideal: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/ So in order to have exactly what I wanted, all I need to do, is create a release.properties file to tell the plugin the versions and then limit the maven reactor to only the modules I want to release and use the normal release:prepare and release:perform targets. As creating the properties and commandline arguments I a little uncomfortable, I'm currently wokring on a jenking plugin for my client to select which modules to release and to provide versions for them ... hopefully this way releasing a new version is just a number of clicks and providing version numbers. What do you think about this solution? Any Kittens in danger this time? ;-) Chris Von: Stephen Connolly [stephen.alan.conno...@gmail.com] Gesendet: Dienstag, 16. Oktober 2012 11:06 An: Maven Users List Cc: rwhee...@artifact-software.com Betreff: Re: Independent module release strategies On 16 October 2012 07:45, christofer.d...@c-ware.de christofer.d...@c-ware.de wrote: As described in my other response. Simply keeping the versions in sync is not an option for us due to the donwtime this would mean for our clients and the load this would generate on the central servers. Well currently the approach to release a new version was to have all modules defined in the master pom modules-section as well as a dependencyManagement-section that defines the versions of all the modules. Now if a new build was to be made that updates only some of the modules, the other modules (the ones that should stay the same) were commented out of the master poms modules-section and then the releaseplugin was used to release the desired artifacts. After the release was finished the versions hat do be manually updated. This process really sucked and caused a lot of problems. Now my approach was not to use the release plugin at all and to define all of the versions used throughout the entire project in the master pom using properties. So all I had to do was to increase the versions in the release profile to the versions I want and commit that. Now in jenkins I was able to define some jobs to run mvn deploy for individual projects with turned on release profile. well first off, in my experience, the use of profiles to modify the dependencies is bad karma. many kittens will die if you follow that use of profiles. no matter how clean you think it is, with the current versions of Maven and their current behaviour, attempts to follow this path will result in many dead kittens underfoot. To me this seems a lot cleaner than all other approaches, but as I don't want to kill too many kittens (As stephen on the dev-list called it). So I'm open for other suggestions or explanationy WHY this is bad. Stephen claimed that if I re-define my properties in child modules, I would have really big trouble, but we are developing the entire project and this is a thing we could fefinitely rule out because it should be really easy to enforce such a constraint (Versions are defines solely in the master pom). And as I mentioned, to me it looks more like a highly restricted feature than a bug in maven that I was able to use a variable in the version. Not quite, I fear it is loosing something in translation for you. In an ideal world, before deploying the pom into the local cache (i.e. install:install) or remote repository (i.e. deploy:deploy) Maven would compute a resolved effective pom. Such a pom would strip out a lot of the stuff that is in a pom at present, e.g. it would probably only consist of /project/groupId /project/artifactId /project/version /project/packaging /project/dependencies/* and maybe /project/build/extensions/* (but it gets tricky deciding exactly how much to prune out) Such a pom would be capturing the dependency tree of the built artifact after inheritance from the parent, and any active profiles, etc had been applied. [Let's ignore the problem of “magic” profiles that alter the dependencies when building on JDK1.5 vs JDK1.6 vs JDK1.7 vs JDK1.8] *IF* we did something like that *THEN* it could be valid to try what you want to do (Note: I say ‘could be’ not ‘would be’) This is because anyone depending on the artifact would have a consistent classpath. Now for packagingpom/packaging projects we would have to deploy the raw pom to the repository so that inheritance would continue to work
AW: integration-test, testNG, and a CI server
Hi, I guess what you want to do, is to have the daily build job build and deploy the latest jars without running the integration tests, am I correct? You then want to be able to run the integration tests without deploying first, am I correct? Well in that case I would suggest to tell the surefire plugin that is probably executing your integration tests to skipTests and have the jars deployed in the normal deploy phase of maven (Not using custom deploy code hidden in a Testcase). Then if you want to run the integration tests but don't want to deploy, you simply execute the mvn package without diabling the tests. So maven would execute the entire build (including integration tests) but stop at the package phase and not install or deploy anything. Chris Von: Baptiste Mathus [bmat...@gmail.com] Gesendet: Donnerstag, 18. Oktober 2012 08:50 An: Maven Users List Betreff: Re: integration-test, testNG, and a CI server Hi, Currently offline so I can't give you precise links now, but search Google for maven lifecycle. What you encounter is normal and it's basically not possible to change it easily (I mean having the pre-integration-test not running before integration-test phase). Goals are things you can bind to phases. And some goals are actually bound by default to some phases of the different standard lifecycle. So I guess what you could do is running explicitly the goals you're interested in. But then you should be aware that explicitly running goals in the Maven world is actually not the typical case. Maven is about build standardization. People who want to build your project should not have to know the different necessary goals you need. If what you want is having a way to disable some parts of the build by default (or the contrary), then look at Maven profiles. Cheers Le 17 oct. 2012 15:40, mlandman99 mlandma...@gmail.com a écrit : Hi, I have a maven project (Project 1) which is intended for executing integration tests. Inside this project is an additional class that helps me automate the deployment of various jars to a nexus repo. Project 1 is dependent on those jars (SNAPSHOT). Project 2 is dependent on those jars (SNAPSHOT). Project 1 is also dependent on project 2. (SNAPSHOT). STEP 1: My CI server (TeamCity) runs a daily build config called Deploy Jars @ 4:00 AM on Project 1, with Maven phase: pre-integration-test. pre-integration-test runs a testNG suite that has the class for deploying those jars to the repo. Works fine. Only that class runs. STEP 2: Next, my CI server has a build trigger for project 2 (to compile and deploy) to occur anytime Deploy Jars is successfully built. This works -- project 2 is built (and project 2 updated its SNAPSHOT dependencies on those Jars that were sent to the repo in step 1). Project 2 is compiled and it's .jar deployed to the repo as well. STEP 3: Back to Project 1. Now that all the .jars have been uploaded to the repo (various jars, including the .jar for project 2, as described in step 2), A Maven build is run with phase integration-test. THE PROBLEM: Unfortunately when I do STEP 3, Maven ends up also RE-RUNNING pre-integration test prior to integration-test, which basically reruns the actions that already occurred in STEP 1. (i.e. all those jars are sent to the repo again). That probably makes sense, in that Maven is probably hardwired to run pre-integration-test any time I ask it to run integration-test. I'd like to find a way out of this -- any suggestions? Is there another maven phase I can take advantage of here, to accomplish my objective? Basically, I don't want step 3 (integration-test) to re-copy those jars to the repo, it's a waste of time, etc. Thanks in advance! Bonus question -- am I getting 'phase' and 'goal' mixed up? My POM file says that pre-integration-test and integration-test are phases. They both have a goal of test. But in my CI server, I have pre-integration-test and integration-test listed as GOALS the maven build configuration on the CI server, and that seems to be working (for the most part). In other words the build configuration for STEP 1 only lists pre-integration-test for a goal, and that works, but the POM file only lists pre-integration-test as a phase... -- View this message in context: http://maven.40175.n5.nabble.com/integration-test-testNG-and-a-CI-server-tp5726939.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Independent module release strategies
Well as soon as a major release is out the door, in that branch only bugfixes are added that have agreat effect on the application. So I am sure that mostly 2-3 Modules change. I know that in general updating a client with about 20mb doesn't sound that bad in our days, but imagine the load on the servers if hundreds of clients all over the worls start updating simultaneously. And there are quite some uses with analog modems ... updating them every time would mean a downtime of hours for them (I was told). So the company tries to keep the number of updated modules to a minimum. Chris Von: Wayne Fay [wayne...@gmail.com] Gesendet: Dienstag, 16. Oktober 2012 01:26 An: Maven Users List Betreff: Re: Independent module release strategies The project consists of about 50 Maven artifacts. A lot of people are using this project all over the world. The client is distributed by some web-start similar solution. The problem is whenever a bugfix-release is done, we don’t want to release all modules in a new version because then all of these would have to be downloaded by the clients. Have you performed any analysis of previous changes to give you an indication of the relative stability of one module vs the rest? Is it true that most changes are happening in one or two modules while the rest is stable -- or are changes found in most any module with no obvious pattern? I would expect that suggested approaches for solving your problem may depend a bit on the answers to these questions. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Independent module release strategies
Hi,
I am currently working on finetuning the workflows on a large application that
was migrated from an Ant based build to one based upon Maven.
The build itself is running smoothly but, what I'm currently working on is
getting the release workflow optimized.
The project consists of about 50 Maven artifacts. A lot of people are using
this project all over the world. The client is distributed by some web-start
similar solution.
The problem is whenever a bugfix-release is done, we don't want to release all
modules in a new version because then all of these would have to be downloaded
by the clients.
So we have a project with a lot of modules and a parent pom that configures the
plugins.
Using the regular maven-release-plugin involves a lot of manual adjusting of
version numbers and I would like to eliminate this.
That's why I setup the master pom to have two profiles develop (active by
default) and release activated during a release. In both profiles a lot of
properties are configured to be used for setting the artifact versions.
No comes the part where I was told on the dev-list that I was tempted by the
dark side of the force ;-)
In my master pom, I defined one major dependencyManagement section fixing the
version of each artifact to the versions in the properties. Ok ... so this is
normal and this is not dark side magic. But in order to have the parent
version automatically configured the right way I wanted to have the version of
the parent link configured by these properties too. Ok so maven doesn't allow
this. But it seems that this is not entirely true:
If I configre the version of the artifact I want to use as parent with the same
variable as I am using in the parent definition of the child module. Maven
seems to work fine with that. The only thing that I was not quite satisfied
with, was that the install plugin installed the raw poms into my local repo.
The directory it was installed to contained the correct version so the
resolution must have worked. That's why I thought this was a bug in the deploy
plugin and that's why I filed an issue (which was immediately closed because I
was doing bad magic) http://jira.codehaus.org/browse/MNG-5358
I attached an example project containing an example configuration demonstrating
what I was doing.
What I find particularly strange is that Maven claims not to resolve properties
in project.version and project.parent.version and in 90% of the cases this is
true:
Let me illustrate thsi a little. Assuming I have only two projects ... one
master and one module.
If I define two properties in my master pom: my.cool.master.version and
my.cool.alternate.master.version and set both to the same value of
1.2-SNAPSHOT.
In szenario 1: I hard code the version of the master to 1.2-SNAPSHOT but use
the property to reference the parent from the moule ... when running a build,
maven tries to download
de/mycompany/test/${my.cool.master.version}/mycoolmaster-${my.cool.master.version}.pom
-- Failure, because the property is not resolved
In szenario 2: I use the same variable for defining the masters version. This
time the maven build runs fine and the parent version is correctly resolved.
In szenario 3: I use the first property to define the version of the master and
the second one for referncing the parent from the module ... when running a
build, maven tries to download
de/mycompany/test/${my.cool.alternate.master.version}/mycoolmaster-${my.cool.alternate.master.version}.pom
-- Failure, because the property is not resolved
So to me it looks as if there was some sort of intention behind everything and
not a bug in the system as I was told on the dev-list. To me it looks like one
teeniewienie loophole allowing properies in versions while closing the usage
range so much that possible harm is reduced to it's absolute minimum. So it
seems that my usecase seems to be the onlly one allowed. After all ... this is
a problem users are begging for maven to provide a solution since maven 2.0
(When looking at the forums).
Ok ... and now to finish the loop back to my topic:
If I am doing bad sourcery ... how would I setup one maven build to allow
simple releases of individual modules with individual versions?
Chris
[ C h r i s t o f e r D u t z ]
C-Ware IT-Service
Inhaber
Dipl. Inf. Christofer Dutz
Karlstraße. 104, 64285 Darmstadt
[cid:image001.gif@01CDAB2D.00AD5550]http://www.benchpark.com/788335/kundenzufriedenheit.htm
IT- und Systemhäuserhttp://www.benchpark.com/it_und_systemhaeuser.htm
fon: 0 61 51 / 27315 - 61
fax: 0 61 51 / 27315 - 64
mobil: 0171 / 7 444 2 33
email: christofer.d...@c-ware.demailto:christofer.d...@c-ware.de
http://www.c-ware.dehttp://www.c-ware.de/
UStId-Nr. DE195700962
Implementing ModelValidators for Plugins
Hi, I am currently working on a way to report common configuration problems of the flexmojos plugin. Which extensionpoints does Maven offer to implement something like this? I found the ModelValidator interface together with its DefaultModelValidator class, but could not find any way to provide custom validation code. It even seems that the normal builder only suports a single instance of a ModelValidator. Help greatly appreciated. Chris [ C h r i s t o f e r D u t z ] C-Ware IT-Service Inhaber Dipl. Inf. Christofer Dutz Karlstraße. 104, 64285 Darmstadt fon: 0 61 51 / 27315 - 61 fax: 0 61 51 / 27315 - 64 mobil: 0171 / 7 444 2 33 email: christofer.d...@c-ware.demailto:christofer.d...@c-ware.de http://www.c-ware.dehttp://www.c-ware.de/ UStId-Nr. DE195700962
