Re: Reactor doesn't build parent poms first?
if the versions do not match, then the reactor does not have a constraint. when relative path is set, you get a warning of a version mismatch (or maybe an error, cannot remember exactly) it is perfectly legal to have a reactor with C depending on the previous release of B - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 21 Aug 2011 22:14, "Laird Nelson" wrote: > This is probably some sort of misunderstanding on my part, but I thought I'd > check. > > When executing a multi-module build, it appears that Maven will not detect > that certain parent POMs in the project need to be built before an effective > project scan can be completed. > > That is, suppose that you have a project structure with an aggregator, A, a > module that is a parent pom, B, and a module that is a child of B (C). > > So A aggregates B and C; C extends from B. > > Assume also that (deliberately) the stanza does not have its > set. (This is because in a large team with moderately > skilled developers, there are all sorts of problems if the developer forgets > to svn update B--the relative path of C's parent will pick up the workspace > copy of B, not the most recent copy in the Maven repository.) > > If you run the reactor here it will use the repository copy of B, rather > than realizing (as I think it should) that B is something that it can build > to get a more recent copy. > > I would expect there to be a two-part scanning algorithm: first scan all > modules and see if their parents are modules in the build. If so, then > build those modules first. Then build the other projects in dependency > order. > > Am I missing something? My apologies if so. > > Best, > Laird > > -- > http://about.me/lairdnelson
Re: Packaging JAX-WS service implementation and client API
You could even separate out the wsdl/xsd in its own artifact(s). That's what I normally recommend as it will then allow the client to use whatever ws service and xml binding technology they like. /Anders On Mon, Aug 22, 2011 at 06:50, Asplund Marko wrote: > > Anders Hammar wrote: >> separate modules! > > Yes, that's how i ended up solving it. > I created X-service API (XSD, WSDL, JAXB classes) and X-service > implementation modules. > The service implementation module only contains the implementation code > and it depends on the service API module and gets the service contract > definition from there. The API module is distributed via an artifact > repository to allow module development lifecycles to be more effectively > separated. > > > marko > > > > - > 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
Re: Packaging JAX-WS service implementation and client API
Anders Hammar wrote: > separate modules! Yes, that's how i ended up solving it. I created X-service API (XSD, WSDL, JAXB classes) and X-service implementation modules. The service implementation module only contains the implementation code and it depends on the service API module and gets the service contract definition from there. The API module is distributed via an artifact repository to allow module development lifecycles to be more effectively separated. marko - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Reactor doesn't build parent poms first?
This is probably some sort of misunderstanding on my part, but I thought I'd check. When executing a multi-module build, it appears that Maven will not detect that certain parent POMs in the project need to be built before an effective project scan can be completed. That is, suppose that you have a project structure with an aggregator, A, a module that is a parent pom, B, and a module that is a child of B (C). So A aggregates B and C; C extends from B. Assume also that (deliberately) the stanza does not have its set. (This is because in a large team with moderately skilled developers, there are all sorts of problems if the developer forgets to svn update B--the relative path of C's parent will pick up the workspace copy of B, not the most recent copy in the Maven repository.) If you run the reactor here it will use the repository copy of B, rather than realizing (as I think it should) that B is something that it can build to get a more recent copy. I would expect there to be a two-part scanning algorithm: first scan all modules and see if their parents are modules in the build. If so, then build those modules first. Then build the other projects in dependency order. Am I missing something? My apologies if so. Best, Laird -- http://about.me/lairdnelson
[ANN] Jar Plugin version 2.3.2 and maven-archiver version 2.4.2
The Maven team is pleased to announce the release of the Maven jar Plugin, version 2.3.2 and maven-archiver 2.4.2 in a combined release. This plugin provides the capability to build jars, and the maven archiver is used to create custom archives that are configured from the POM. You can find more information at: http://maven.apache.org/plugins/maven-jar-plugin/ http://maven.apache.org/shared/maven-archiver/ Specific news for this release is the support for java7 file attributes, which can give a noticeable performance boost on linux and mac running java7. Certain performance improvements can also be expected on Java1.5/Java6 on linux and mac. Both releases require java 1.5 or newer. Java7 users of other plugins such as maven-ear-plugin, maven-rar-plugin, maven-war-plugin and maven-source-plugin may consider adding the updated maven-archiver as a dependency to these plugins until new versions are released. You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jar-plugin 2.3.2 org.apache.maven maven-archiver 2.4.2 Release Notes - Maven 2.x JAR Plugin - Version 2.3.2 ** Bug * [MJAR-140] - Performance degredation * [MJAR-144] - need to update dependency of maven-archiver to 2.5 Release Notes - Maven Shared Components - Version maven-archiver-2.4.2 ** Bug * [MSHARED-131] - Maven archiver does not manage empty classifier correctly in manifest.mf classpath * [MSHARED-160] - Replace pom.* properties with project.* properties in all maven-archiver website examples ** Improvement * [MSHARED-202] - Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
