Re: Custom multi module packaging/removing default lifecycle plugins
Phil Housley wrote at Sonntag, 14. März 2010 22:41: On 11 March 2010 16:49, Phil Housley undeconstruc...@gmail.com wrote: Hi, I am (yet again) trying to subvert Maven with a custom plugin and finding that the special cases in the core are causing problems. What I'm aiming for is the ability to have a project which combines a couple of modules as a single release, and then deploys their artifacts together, along with some metafiles. The modules also have custom packaging types, and the deployment means a custom process over some webservices. The issue is that only pom package projects are allowed to have modules, and the pom lifecycle includes the standard install and deploy plugin, which will fail as there is no distributionManagement section. Is it possible to either completely inhibit the plugins in the pom lifecycle, or to create another packaging type which allows multi-module? To partly answer my own question, it seems that the checks for multi module and parent allowed are coded as simply if (pom.equals(project.getPackaging()), so it doesn't look like I can use another packaging type there. I'm still looking into a way to get the install and deploy plugins out of the pom lifecycle, but without too much hope. I guess I will have to resort to specifying a specific goal and ignoring the lifecycle altogether... Why do you want this deployment happening at the parent? Just create another modules with your custom packaging and declare all the other modules as dependencies. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn archetype:create breaks on js file
Hi, I'm building an archetype using mvn archetype:create-from-project. In my project there are several javascript files. Installing the generated archetype works fine. The moment I try to create a project from this archetype on the command-line using mvn archetype:create, I get an error, which seems to indicate Velocity cannot handle the javascript files in the project. Which is actually a problem of Velocity, but the files should not be touched by Velocity in the first place. I tried to disable filtering them: fileSet filtered=false encoding=UTF-8 directorysrc/main/webapp/directory includes include**/*.png/include include**/*.js/include include**/*.css/include /includes /fileSet and tried several alternatives, but none of them seems to be working: it does not stop Velocity from touching the files, and then choking on them. Any ideas if I'm doing something wrong? Version used: maven 2.0.9 and maven-archetype-plugin 2.0-alpha-4. However, the interactive mvn archetype:generate seems to work perfectly, which makes me believe this is a bug. Thanks, Antoine. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
On 15 March 2010 06:46, Jörg Schaible joerg.schai...@gmx.de wrote: Phil Housley wrote at Sonntag, 14. März 2010 22:41: On 11 March 2010 16:49, Phil Housley undeconstruc...@gmail.com wrote: Hi, I am (yet again) trying to subvert Maven with a custom plugin and finding that the special cases in the core are causing problems. What I'm aiming for is the ability to have a project which combines a couple of modules as a single release, and then deploys their artifacts together, along with some metafiles. The modules also have custom packaging types, and the deployment means a custom process over some webservices. The issue is that only pom package projects are allowed to have modules, and the pom lifecycle includes the standard install and deploy plugin, which will fail as there is no distributionManagement section. Is it possible to either completely inhibit the plugins in the pom lifecycle, or to create another packaging type which allows multi-module? To partly answer my own question, it seems that the checks for multi module and parent allowed are coded as simply if (pom.equals(project.getPackaging()), so it doesn't look like I can use another packaging type there. I'm still looking into a way to get the install and deploy plugins out of the pom lifecycle, but without too much hope. I guess I will have to resort to specifying a specific goal and ignoring the lifecycle altogether... Why do you want this deployment happening at the parent? Just create another modules with your custom packaging and declare all the other modules as dependencies. It's for convenience of the users mostly. Hopefully people will be able to create these projects from an archetype, and then run deploy from the root to push several modules together as a release. Using a separate meta module is extra work for the users, but is the plan I'm currently working at. The main problem is that if the modules are not in the reactor when deploy is run, I have to add an install phase to be able to pick them up (which doesn't make much sense for the custom packaging I'm using); while to get them into reactor, I would need to run mvn deploy from the root, which would invoke the standard deploy plugin on the root pom. I'm thinking currently of a goal custom-stuff:deploy which can be invoked on the root, will force a package phase in each module, and then when invoked (automatically) on each module will ignore all those without some special packaging type. This adds a requirement for a new meta project with dependencies on the others, but that isn't too much overhead to my mind - will have to see how it goes down with others. Thanks for your input. - Jörg -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Get Model object of an Artifact object
Hi. If I have the org.apache.maven.artifact.Artifact object of a given artefact is there a way to access the org.apache.maven.model.Model object of the given artifact if the pom.xml file of the artifact is there in the local repository? Thanks in advance. Pubudu
maven site generation woes - striped table edition
I'd like to choose between tables in the usual striped boxy format and tables with white backgrounds and simple line borders. I'm actually using the docbkx plugin to generate html from DocBook, which I then run through JTidy to make XHTML-compatible. I generate this to the target/generated-site/xhtml directory. Because I want the version number substituted *and* to be able to edit the DocBook with XMLMind, I actually write *.xhtml.vm files so that Velocity does variable substitution. This is all working great, given the limits of Doxia, but is there a way to specify different table styles? I'm guessing the answer is no. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven site generation woes - striped table edition
I'd like to choose between tables in the usual striped boxy format and tables with white backgrounds and simple line borders. I'm actually using the docbkx plugin to generate html from DocBook, which I then run through JTidy to make XHTML-compatible. I generate this to the target/generated-site/xhtml directory. Because I want the version number substituted *and* to be able to edit the DocBook with XMLMind, I actually write *.xhtml.vm files so that Velocity does variable substitution. This is all working great, given the limits of Doxia, but is there a way to specify different table styles? I'm guessing the answer is no. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Phil Housley wrote: On 15 March 2010 06:46, Jörg Schaible joerg.schai...@gmx.de wrote: Phil Housley wrote at Sonntag, 14. März 2010 22:41: On 11 March 2010 16:49, Phil Housley undeconstruc...@gmail.com wrote: Hi, I am (yet again) trying to subvert Maven with a custom plugin and finding that the special cases in the core are causing problems. What I'm aiming for is the ability to have a project which combines a couple of modules as a single release, and then deploys their artifacts together, along with some metafiles. The modules also have custom packaging types, and the deployment means a custom process over some webservices. The issue is that only pom package projects are allowed to have modules, and the pom lifecycle includes the standard install and deploy plugin, which will fail as there is no distributionManagement section. Is it possible to either completely inhibit the plugins in the pom lifecycle, or to create another packaging type which allows multi-module? To partly answer my own question, it seems that the checks for multi module and parent allowed are coded as simply if (pom.equals(project.getPackaging()), so it doesn't look like I can use another packaging type there. I'm still looking into a way to get the install and deploy plugins out of the pom lifecycle, but without too much hope. I guess I will have to resort to specifying a specific goal and ignoring the lifecycle altogether... Why do you want this deployment happening at the parent? Just create another modules with your custom packaging and declare all the other modules as dependencies. It's for convenience of the users mostly. Hopefully people will be able to create these projects from an archetype, and then run deploy from the root to push several modules together as a release. Using a separate meta module is extra work for the users, but is the plan I'm currently working at. It is still not clear as to how your situation is so radically different from any other team of developers. What are you building that is so different from a normal application? The main problem is that if the modules are not in the reactor when deploy is run, I have to add an install phase to be able to pick them up (which doesn't make much sense for the custom packaging I'm using); while to get them into reactor, I would need to run mvn deploy from the root, which would invoke the standard deploy plugin on the root pom. In the higher level projects, you just need to declare your dependencies and maven will make sure that the right stuff is included automatically. It is not clear what you are trying to include that is so odd that the standard Maven lifecycle will not assemble properly. Maven out-of-the-box supports multiple developers building a multi-module application with all the essential housekeeping. I'm thinking currently of a goal custom-stuff:deploy which can be invoked on the root, will force a package phase in each module, and then when invoked (automatically) on each module will ignore all those without some special packaging type. This adds a requirement for a new meta project with dependencies on the others, but that isn't too much overhead to my mind - will have to see how it goes down with others. Unless you have a really odd setup, you should be able to greatly simplify life for everyone without having to resort to odd-ball procedures. Each library module gets built and deployed into your artifact repository (really need one if you are multiple developers) as SNAPSHOTS or releases and when you build an executable its dependencies are picked up automatically and incorporated into the build of the executable. This is the normal Maven way - nothing special needed. Ron Thanks for your input. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Checkstyle reports different issues on different runs
I'm seeing something strange with the checkstyle plugin.
We are using Checkstyle plugin 2.5 and configure it using a checkstyle
file in a jar that is an extension of our pom.
Thus:
project
properties
checkstyle-maven-plugin.version2.5/checkstyle-maven-plugin.version
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version${checkstyle-maven-plugin.version}/version
configuration
includeTestSourceDirectorytrue/includeTestSourceDirectory
configLocationiris_checks.xml/configLocation
/configuration
/plugin
/plugins
extensions
extension
groupIdorg.example/groupId
artifactIdbuild-resources/artifactId
version1.0.4/version
/extension
/extensions
/build
/project
When I run the following command line:
mvn clean checkstyle:checkstyle cp target/checkstyle-result.xml .
mvn clean checkstyle:checkstyle diff checkstyle-result.xml
target/checkstyle-result.xml
I sometimes see differences like:
error line=12 column=5 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
279a281,286
error line=122 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=123 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=124 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=125 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=126 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=127 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
I don't change code between runs, so I assume this may never happen.
What could cause this?
With regards,
Nick Stolwijk
~Java Developer~
IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
On 15 March 2010 12:05, Ron Wheeler rwhee...@artifact-software.com wrote: Phil Housley wrote: On 15 March 2010 06:46, Jörg Schaible joerg.schai...@gmx.de wrote: Phil Housley wrote at Sonntag, 14. März 2010 22:41: On 11 March 2010 16:49, Phil Housley undeconstruc...@gmail.com wrote: Hi, I am (yet again) trying to subvert Maven with a custom plugin and finding that the special cases in the core are causing problems. What I'm aiming for is the ability to have a project which combines a couple of modules as a single release, and then deploys their artifacts together, along with some metafiles. The modules also have custom packaging types, and the deployment means a custom process over some webservices. The issue is that only pom package projects are allowed to have modules, and the pom lifecycle includes the standard install and deploy plugin, which will fail as there is no distributionManagement section. Is it possible to either completely inhibit the plugins in the pom lifecycle, or to create another packaging type which allows multi-module? To partly answer my own question, it seems that the checks for multi module and parent allowed are coded as simply if (pom.equals(project.getPackaging()), so it doesn't look like I can use another packaging type there. I'm still looking into a way to get the install and deploy plugins out of the pom lifecycle, but without too much hope. I guess I will have to resort to specifying a specific goal and ignoring the lifecycle altogether... Why do you want this deployment happening at the parent? Just create another modules with your custom packaging and declare all the other modules as dependencies. It's for convenience of the users mostly. Hopefully people will be able to create these projects from an archetype, and then run deploy from the root to push several modules together as a release. Using a separate meta module is extra work for the users, but is the plan I'm currently working at. It is still not clear as to how your situation is so radically different from any other team of developers. What are you building that is so different from a normal application? Sorry, I really don't seem to be doing a great job of explaining things. The situation is that we have some custom packaging types, call them bundles, which we generate using Maven and a custom plugin/packaging type, and are basically tarballs with some special files, plus some attached artifacts, made in the normal way. Several of these bundles, plus some common meta files (release notes, etc) make up a release of a project, which should be deployed at once. Because each bundle individually isn't complete by itself, there is no particular sense in which it can be deployed, other than just pushing it into a Maven repo as a temporary holding place. The ideal situation would be to have all bundle projects inside another project, giving roughly /project/ pom.xml (with custom packaging, and modules) bundle-1/ /pom.xml (with bundle-x packaging) bundle-2/ /pom.xml (with bundle-y packaging) src/releaseinfo/... Then mvn deploy at the root would do the packaging, merge any common stuff, and push the whole lot together to the release location. Unfortunately, only pom packaged projects can have modules, and running deploy on a pom project will always invoke the maven-deploy-plugin, which is not appropriate here. My next plan was to add a meta module, which would depend on the bundles in the reactor. On running mvn custom-plugin:deploy directly from the command line, the bundles would be packaged, and the meta project would be detected as meaning the deployment should be done using meta-data contained within it. That plan is awkward, as you can't run maven deploy, but works - excepting some issues, mainly that you can't access the bundle artifacts unless you run install on them, which renames the files. The main problem is that if the modules are not in the reactor when deploy is run, I have to add an install phase to be able to pick them up (which doesn't make much sense for the custom packaging I'm using); while to get them into reactor, I would need to run mvn deploy from the root, which would invoke the standard deploy plugin on the root pom. In the higher level projects, you just need to declare your dependencies and maven will make sure that the right stuff is included automatically. It is not clear what you are trying to include that is so odd that the standard Maven lifecycle will not assemble properly. Maven out-of-the-box supports multiple developers building a multi-module application with all the essential housekeeping. An alternative to my above plan is to skip the project aggregation entirely, build and install the bundles separately, and then use a similar meta project with a real deploy phase, which is neater in some ways, but means you can't do a one step release. Now that I've found you have to run the
Re: Checkstyle reports different issues on different runs
It seems I found it.
I had 2 configurations of JavadocVariableCheck in my checkstyle file.
I guess it was dependent on the moon which entry checkstyle used. ;)
With regards,
Nick Stolwijk
~Java Developer~
IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl
On Mon, Mar 15, 2010 at 1:33 PM, Nick Stolwijk nick.stolw...@gmail.com wrote:
I'm seeing something strange with the checkstyle plugin.
We are using Checkstyle plugin 2.5 and configure it using a checkstyle
file in a jar that is an extension of our pom.
Thus:
project
properties
checkstyle-maven-plugin.version2.5/checkstyle-maven-plugin.version
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version${checkstyle-maven-plugin.version}/version
configuration
includeTestSourceDirectorytrue/includeTestSourceDirectory
configLocationiris_checks.xml/configLocation
/configuration
/plugin
/plugins
extensions
extension
groupIdorg.example/groupId
artifactIdbuild-resources/artifactId
version1.0.4/version
/extension
/extensions
/build
/project
When I run the following command line:
mvn clean checkstyle:checkstyle cp target/checkstyle-result.xml .
mvn clean checkstyle:checkstyle diff checkstyle-result.xml
target/checkstyle-result.xml
I sometimes see differences like:
error line=12 column=5 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
279a281,286
error line=122 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=123 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=124 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=125 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=126 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
error line=127 column=9 severity=warning message=Missing a Javadoc
comment.
source=com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocVariableCheck/
I don't change code between runs, so I assume this may never happen.
What could cause this?
With regards,
Nick Stolwijk
~Java Developer~
IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven site generation woes - striped table edition
With doxia-1.1 (site-plugin-2.1), you should be able to specify a class attribute on your xdoc table, which will override the default maven style. I'm not sure if/how this works with docbook though. HTH, -Lukas Kathryn Huxtable wrote: I'd like to choose between tables in the usual striped boxy format and tables with white backgrounds and simple line borders. I'm actually using the docbkx plugin to generate html from DocBook, which I then run through JTidy to make XHTML-compatible. I generate this to the target/generated-site/xhtml directory. Because I want the version number substituted *and* to be able to edit the DocBook with XMLMind, I actually write *.xhtml.vm files so that Velocity does variable substitution. This is all working great, given the limits of Doxia, but is there a way to specify different table styles? I'm guessing the answer is no. -K - 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: Custom multi module packaging/removing default lifecycle plugins
Sounds like you need a custom archetype. It's worth the investment. On Mar 15, 2010, at 8:38 AM, Phil Housley undeconstruc...@gmail.com wrote: On 15 March 2010 12:05, Ron Wheeler rwhee...@artifact-software.com wrote: Phil Housley wrote: On 15 March 2010 06:46, Jörg Schaible joerg.schai...@gmx.de wr ote: Phil Housley wrote at Sonntag, 14. März 2010 22:41: On 11 March 2010 16:49, Phil Housley undeconstruc...@gmail.com wrote: Hi, I am (yet again) trying to subvert Maven with a custom plugin and finding that the special cases in the core are causing problems. What I'm aiming for is the ability to have a project which combines a couple of modules as a single release, and then deploys their artifacts together, along with some metafiles. The modules also have custom packaging types, and the deployment means a custom process over some webservices. The issue is that only pom package projects are allowed to have modules, and the pom lifecycle includes the standard install and deploy plugin, which will fail as there is no distributionManagement section. Is it possible to either completely inhibit the plugins in the pom lifecycle, or to create another packaging type which allows multi-module? To partly answer my own question, it seems that the checks for multi module and parent allowed are coded as simply if (pom.equals(project.getPackaging()), so it doesn't look like I can use another packaging type there. I'm still looking into a way to get the install and deploy plugins out of the pom lifecycle, but without too much hope. I guess I will have to resort to specifying a specific goal and ignoring the lifecycle altogether... Why do you want this deployment happening at the parent? Just create another modules with your custom packaging and declare all the other modules as dependencies. It's for convenience of the users mostly. Hopefully people will be able to create these projects from an archetype, and then run deploy from the root to push several modules together as a release. Using a separate meta module is extra work for the users, but is the plan I'm currently working at. It is still not clear as to how your situation is so radically different from any other team of developers. What are you building that is so different from a normal application? Sorry, I really don't seem to be doing a great job of explaining things. The situation is that we have some custom packaging types, call them bundles, which we generate using Maven and a custom plugin/packaging type, and are basically tarballs with some special files, plus some attached artifacts, made in the normal way. Several of these bundles, plus some common meta files (release notes, etc) make up a release of a project, which should be deployed at once. Because each bundle individually isn't complete by itself, there is no particular sense in which it can be deployed, other than just pushing it into a Maven repo as a temporary holding place. The ideal situation would be to have all bundle projects inside another project, giving roughly /project/ pom.xml (with custom packaging, and modules) bundle-1/ /pom.xml (with bundle-x packaging) bundle-2/ /pom.xml (with bundle-y packaging) src/releaseinfo/... Then mvn deploy at the root would do the packaging, merge any common stuff, and push the whole lot together to the release location. Unfortunately, only pom packaged projects can have modules, and running deploy on a pom project will always invoke the maven-deploy-plugin, which is not appropriate here. My next plan was to add a meta module, which would depend on the bundles in the reactor. On running mvn custom-plugin:deploy directly from the command line, the bundles would be packaged, and the meta project would be detected as meaning the deployment should be done using meta-data contained within it. That plan is awkward, as you can't run maven deploy, but works - excepting some issues, mainly that you can't access the bundle artifacts unless you run install on them, which renames the files. The main problem is that if the modules are not in the reactor when deploy is run, I have to add an install phase to be able to pick them up (which doesn't make much sense for the custom packaging I'm using); while to get them into reactor, I would need to run mvn deploy from the root, which would invoke the standard deploy plugin on the root pom. In the higher level projects, you just need to declare your dependencies and maven will make sure that the right stuff is included automatically. It is not clear what you are trying to include that is so odd that the standard Maven lifecycle will not assemble properly. Maven out-of-the-box supports multiple developers building a multi- module application with all the essential housekeeping. An alternative to my above plan is to skip the project aggregation entirely, build and install the bundles separately, and then
Maven AntTasks - Forcing updating of cached repo artifacts
I'm having a discussion with some folks that are using the Maven Ant Tasks. They are migrating to Maven, but are bridging the time with some projects consuming those of the Maven-produced artifacts with Ant projects. They have a need to, and thus are wondering if there there is a means to pass the -U flag to the Maven Ant tasks such that it will check remotely for artifacts again? We've tried: artifact:mvn mavenHome=/usr/local/apache/maven/2.0.9 arg value=-U/ /artifact:mvn At first, this documentation led us to believe it might work... http://maven.apache.org/ant-tasks/examples/mvn.html But in the end, it just throws an exception. -Matthew McCullough - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and WTP integration
Hi I have the same issue, have you found a solution or reported a bug ? Thank you in advance Martin Schayna-2 wrote: Hi all, we have pretty large project, successfully mavenized with Maven 2, split into several module projects under one parent pom. We are using m2eclipse plugin in Eclipse 3.5. Project tree looks like: parent/ (pom project) +-- lib-core/ (jar project) +-- lib-web/ (jar project, with shared webapp folder) +-- app1/ (war project) +-- app2/ (war project) +-- app3/ (war project) parent project serves as agregator, its pom.xml defines common settings. lib-web project depends on lib-core project, application projects depend on both lib projects. All projects share same version, we are releasing all applications at once through parent pom. For everyday develepment we use SNAPSHOT postfix in version, dependecies on module projects are specified as project dependencies, so changes in library projects in Eclipse cause rebuild dependent application projects. Snapshots are disabled in our repository (Archiva). But when I try setup WTP support through maven-eclipse-plugin goal eclipse:eclipse and some necessary changes in Eclipse, publishing to Tomcat creates only WEB-INF/lib folder with (correct) out-of-project jar dependencies and WEB-INF/classes folder with CURRENT project classes. No binaries from project dependencies lib-core and lib-web. I have tried to change org.eclipse.wst.common.component file in many ways, e.g. dependent-module, but without success. Another weird thing: when I try to include resources from shared webapp folder from lib-web project and use relative source-path like this: wb-resource deploy-path=/ source-path=../lib-web/src/main/webapp/ publish can't copy subfolders content to Tomcat. Must explicitly specified: wb-resource deploy-path=/btns source-path=../lib-web/src/main/webapp/btns/ wb-resource deploy-path=/icons source-path=../lib-web/src/main/webapp/icons/ wb-resource deploy-path=/imgs source-path=../lib-web/src/main/webapp/imgs/ ... Please, what is the right WTP setup for multi modules configuration with project dependencies and shared resources? Or is there any documentation for file org.eclipse.wst.common.component? I'm going little bit crazy... thank God debugging with Jetty works like a charm, either with shared resources (must hack with WebAppContext.setResourceBase() in starter class). Thanks a lot. Martin Schayna -- View this message in context: http://old.nabble.com/Maven-and-WTP-integration-tp27403219p27906717.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: Custom multi module packaging/removing default lifecycle plugins
Sounds like you need a custom archetype. Sounds like a custom lifecycle might be in order: http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-custom-lifecycle.html http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and WTP integration
Hi, after some by-hand editing of configuration files, that have been mentioned here, it works. But when I try to run eclipse:eclipse goal of maven-eclipse-plugin again, it breaks and I have to revert changes. We can live with that :) Martin On 15.3.2010 17:23, Michel Pawlak wrote: Hi I have the same issue, have you found a solution or reported a bug ? Thank you in advance Martin Schayna-2 wrote: Hi all, we have pretty large project, successfully mavenized with Maven 2, split into several module projects under one parent pom. We are using m2eclipse plugin in Eclipse 3.5. Project tree looks like: parent/ (pom project) +-- lib-core/ (jar project) +-- lib-web/ (jar project, with shared webapp folder) +-- app1/ (war project) +-- app2/ (war project) +-- app3/ (war project) parent project serves as agregator, its pom.xml defines common settings. lib-web project depends on lib-core project, application projects depend on both lib projects. All projects share same version, we are releasing all applications at once through parent pom. For everyday develepment we use SNAPSHOT postfix in version, dependecies on module projects are specified as project dependencies, so changes in library projects in Eclipse cause rebuild dependent application projects. Snapshots are disabled in our repository (Archiva). But when I try setup WTP support through maven-eclipse-plugin goal eclipse:eclipse and some necessary changes in Eclipse, publishing to Tomcat creates only WEB-INF/lib folder with (correct) out-of-project jar dependencies and WEB-INF/classes folder with CURRENT project classes. No binaries from project dependencies lib-core and lib-web. I have tried to change org.eclipse.wst.common.component file in many ways, e.g.dependent-module, but without success. Another weird thing: when I try to include resources from shared webapp folder from lib-web project and use relative source-path like this: wb-resource deploy-path=/ source-path=../lib-web/src/main/webapp/ publish can't copy subfolders content to Tomcat. Must explicitly specified: wb-resource deploy-path=/btns source-path=../lib-web/src/main/webapp/btns/ wb-resource deploy-path=/icons source-path=../lib-web/src/main/webapp/icons/ wb-resource deploy-path=/imgs source-path=../lib-web/src/main/webapp/imgs/ ... Please, what is the right WTP setup for multi modules configuration with project dependencies and shared resources? Or is there any documentation for file org.eclipse.wst.common.component? I'm going little bit crazy... thank God debugging with Jetty works like a charm, either with shared resources (must hack with WebAppContext.setResourceBase() in starter class). Thanks a lot. Martin Schayna - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and WTP integration
Just a note so that folks know what's coming. The maven-eclipse-plugin will not work with M2Eclipse anymore. If M2Eclipse sees projects generated with the maven-eclipse-plugin it won't import them. M2Eclipse works by creating the necessary projects files by inspecting the POM and doesn't expect the Eclipse project files to have been created by an external third party. If you use the maven-eclipse-plugin your projects will not be supported in M2Eclipse. You will need to pick one mode, either use the maven-eclipse-plugin and stock Eclipse or import your projects using M2Eclipse. Just a heads up. On Mar 15, 2010, at 12:58 PM, Martin Schayna wrote: Hi, after some by-hand editing of configuration files, that have been mentioned here, it works. But when I try to run eclipse:eclipse goal of maven-eclipse-plugin again, it breaks and I have to revert changes. We can live with that :) Martin On 15.3.2010 17:23, Michel Pawlak wrote: Hi I have the same issue, have you found a solution or reported a bug ? Thank you in advance Martin Schayna-2 wrote: Hi all, we have pretty large project, successfully mavenized with Maven 2, split into several module projects under one parent pom. We are using m2eclipse plugin in Eclipse 3.5. Project tree looks like: parent/ (pom project) +-- lib-core/ (jar project) +-- lib-web/ (jar project, with shared webapp folder) +-- app1/ (war project) +-- app2/ (war project) +-- app3/ (war project) parent project serves as agregator, its pom.xml defines common settings. lib-web project depends on lib-core project, application projects depend on both lib projects. All projects share same version, we are releasing all applications at once through parent pom. For everyday develepment we use SNAPSHOT postfix in version, dependecies on module projects are specified as project dependencies, so changes in library projects in Eclipse cause rebuild dependent application projects. Snapshots are disabled in our repository (Archiva). But when I try setup WTP support through maven-eclipse-plugin goal eclipse:eclipse and some necessary changes in Eclipse, publishing to Tomcat creates only WEB-INF/lib folder with (correct) out-of-project jar dependencies and WEB-INF/classes folder with CURRENT project classes. No binaries from project dependencies lib-core and lib-web. I have tried to change org.eclipse.wst.common.component file in many ways, e.g.dependent-module, but without success. Another weird thing: when I try to include resources from shared webapp folder from lib-web project and use relative source-path like this: wb-resource deploy-path=/ source-path=../lib-web/src/main/webapp/ publish can't copy subfolders content to Tomcat. Must explicitly specified: wb-resource deploy-path=/btns source-path=../lib-web/src/main/webapp/btns/ wb-resource deploy-path=/icons source-path=../lib-web/src/main/webapp/icons/ wb-resource deploy-path=/imgs source-path=../lib-web/src/main/webapp/imgs/ ... Please, what is the right WTP setup for multi modules configuration with project dependencies and shared resources? Or is there any documentation for file org.eclipse.wst.common.component? I'm going little bit crazy... thank God debugging with Jetty works like a charm, either with shared resources (must hack with WebAppContext.setResourceBase() in starter class). Thanks a lot. Martin Schayna - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --
RE: Test fail for release:perform only - no failure info
Hello, Still can't get this bugger to work. I've locked down the version of the surefire plugin to the latest (2.5), using Maven 2.2.1 and found a thread (http://jira.codehaus.org/browse/MRELEASE-140) thinking that perhaps something with the site plugin might be screwing up the release:perform so I tried taking out anything site related (site plugin config, etc) - but still no luck. Just to recap... Mvn test works fine, mvn release:prepare works fine (all tests pass) Tests fail with mvn release:perform, except there aren't any test failures! [INFO] Running com.x.exception.XExceptionTest [INFO] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec [INFO] [INFO] -- -- [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] -- -- [INFO] [INFO] There are test failures. [INFO] [INFO] Please refer to D:\Project\Code\Library\x_3.0.0\target\c heckout\target\surefire-reports for the individual test results. [INFO] [INFO] -- -- [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] -- -- [INFO] [INFO] Total time: 10 seconds [INFO] [INFO] Finished at: Mon Mar 15 10:14:29 MST 2010 [INFO] [INFO] Final Memory: 20M/39M [INFO] [INFO] -- -- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Maven execution failed, exit code: '1' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 46 seconds You can see from above that the build fails, but there are no summary stats, such as Tests: 506 Failures: 17 Errors:7, it's as if the surefire plugin just stopped. Failure seemed to occur with one particular test, I removed that test and the problem just moved to another test, so doensn't appear to be test dependent. Tried using Windows/Linux machines (just to ensure it wasn't something machine dependent), still no joy. I also tried changing surefire forkmode to pretest, but that didn't change anything. This project normally takes more than 10m to run, notice the total time is 1m 46s, some something is very screwy, just can't figure out what changed. This same project was running release:perform fine with Maven 2.0.9 a few months ago (this same project does get the same error with Maven 2.0.9, btw... I only upgraded to 2.2.1 to try and resolve this issue). Any suggestions/insight is greatly appreciated. Thanks! Randall -Original Message- From: Randall Fidler [mailto:randall.fid...@testadvantage.com] Sent: Friday, March 12, 2010 10:37 AM To: Maven Users List Subject: RE: Test fail for release:perform only - no failure info Hmm... just tried with Maven 2.2.1 and surefire plugin vesion 2.5. Still none of the tests are failing but the build fails because there are test errors. I thought it was one particular test, but I removed it from the project and same result. All tests pass on release:prepare but I get the build failed due to test failures with no failing tests when I do release:perform. Ideas? Thanks! Randall -Original Message- From: Randall Fidler [mailto:randall.fid...@testadvantage.com] Sent: Thursday, March 11, 2010 3:18 PM To: Maven Users List Subject: RE: Test fail for release:perform only - no failure info I'm downloading Maven 2.2.1 right now. I'm on a 'loaner' laptop as mine is in the shop so I think not having MAVEN_OPTS set for memory settings could be an option. Maybe it runs out of memory under the release:perform and not release:prepare? Anyhow, I'll give both a try. Thanks! Any other ideas are welcome. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, March 11, 2010 3:08 PM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info I'm using Maven 2.0.9. Any ideas? Where to start looking? Did you try Maven 2.0.10? Or 2.0.11 that was recently released? Or 2.2.1 for that matter if you don't need to use JDK 1.4? 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 - To
Re: Maven AntTasks - Forcing updating of cached repo artifacts
Try this: artifact:mvn mavenHome=/usr/local/apache/maven/2.0.9 arg value=-U/ arg value=validate/ /artifact:mvn Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Test fail for release:perform only - no failure info
[INFO] Please refer to D:\Project\Code\Library\x_3.0.0\target\c heckout\target\surefire-reports for the individual test results. Any info here that might help? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Test fail for release:perform only - no failure info
Wayne, All the test reports/output show no errors - all the test reports who each test passing. I spent the time and went through each one, there are no errors. I had one test which required line arguments to be set to increase the amount of memory and set the perm size (the one thing that seems to have changed since release:perform last worked). I removed that test and the line arguments from the surefire configuration, same result. It seems like the surefire 'thread' is just bailing out. One other thing to note just to be complete, I also tried running with Java 1.6 (thinking maybe somebody else put a 1.6 specific test case in the project) but it gets the same result as using 1.5. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Monday, March 15, 2010 10:29 AM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info [INFO] Please refer to D:\Project\Code\Library\x_3.0.0\target\c heckout\target\surefire-reports for the individual test results. Any info here that might help? 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
Re: Maven and WTP integration
Thank you for your insight into the future. Well, then the best solution will be removing all references to maven-eclipse-plugin from pom.xml and relaying on M2Eclipse. It clears all my concerns about this, thanks again. Martin On 15.3.2010 18:07, Jason van Zyl wrote: Just a note so that folks know what's coming. The maven-eclipse-plugin will not work with M2Eclipse anymore. If M2Eclipse sees projects generated with the maven-eclipse-plugin it won't import them. M2Eclipse works by creating the necessary projects files by inspecting the POM and doesn't expect the Eclipse project files to have been created by an external third party. If you use the maven-eclipse-plugin your projects will not be supported in M2Eclipse. You will need to pick one mode, either use the maven-eclipse-plugin and stock Eclipse or import your projects using M2Eclipse. Just a heads up. On Mar 15, 2010, at 12:58 PM, Martin Schayna wrote: Hi, after some by-hand editing of configuration files, that have been mentioned here, it works. But when I try to run eclipse:eclipse goal of maven-eclipse-plugin again, it breaks and I have to revert changes. We can live with that :) Martin On 15.3.2010 17:23, Michel Pawlak wrote: Hi I have the same issue, have you found a solution or reported a bug ? Thank you in advance Martin Schayna-2 wrote: Hi all, we have pretty large project, successfully mavenized with Maven 2, split into several module projects under one parent pom. We are using m2eclipse plugin in Eclipse 3.5. Project tree looks like: parent/ (pom project) +-- lib-core/ (jar project) +-- lib-web/ (jar project, with shared webapp folder) +-- app1/ (war project) +-- app2/ (war project) +-- app3/ (war project) parent project serves as agregator, its pom.xml defines common settings. lib-web project depends on lib-core project, application projects depend on both lib projects. All projects share same version, we are releasing all applications at once through parent pom. For everyday develepment we use SNAPSHOT postfix in version, dependecies on module projects are specified as project dependencies, so changes in library projects in Eclipse cause rebuild dependent application projects. Snapshots are disabled in our repository (Archiva). But when I try setup WTP support through maven-eclipse-plugin goal eclipse:eclipse and some necessary changes in Eclipse, publishing to Tomcat creates only WEB-INF/lib folder with (correct) out-of-project jar dependencies and WEB-INF/classes folder with CURRENT project classes. No binaries from project dependencies lib-core and lib-web. I have tried to change org.eclipse.wst.common.component file in many ways, e.g.dependent-module, but without success. Another weird thing: when I try to include resources from shared webapp folder from lib-web project and use relative source-path like this: wb-resource deploy-path=/ source-path=../lib-web/src/main/webapp/ publish can't copy subfolders content to Tomcat. Must explicitly specified: wb-resource deploy-path=/btns source-path=../lib-web/src/main/webapp/btns/ wb-resource deploy-path=/icons source-path=../lib-web/src/main/webapp/icons/ wb-resource deploy-path=/imgs source-path=../lib-web/src/main/webapp/imgs/ ... Please, what is the right WTP setup for multi modules configuration with project dependencies and shared resources? Or is there any documentation for file org.eclipse.wst.common.component? I'm going little bit crazy... thank God debugging with Jetty works like a charm, either with shared resources (must hack with WebAppContext.setResourceBase() in starter class). Thanks a lot. Martin Schayna - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --
Re: Test fail for release:perform only - no failure info
It seems like the surefire 'thread' is just bailing out. One other thing to note just to be complete, I also tried running with Java 1.6 (thinking maybe somebody else put a 1.6 specific test case in the project) but it gets the same result as using 1.5. You may need to bundle things up into something you can share (assuming this is even possible) that has the problem so others can take a look at it. Otherwise you'll need to get it into a runtime debugger and see where things go wrong yourself. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven site generation woes - striped table edition
Thanks! That gives me some hope. Moving forward, the issue is, how do I get the docbkx plugin to pass the class through. Currently, it likes to remove the class from the table and surround the table with a div with the class. I suspect that I'll be digging into the XSL files. -K On Mar 15, 2010, at 8:12 AM, Lukas Theussl wrote: With doxia-1.1 (site-plugin-2.1), you should be able to specify a class attribute on your xdoc table, which will override the default maven style. I'm not sure if/how this works with docbook though. HTH, -Lukas Kathryn Huxtable wrote: I'd like to choose between tables in the usual striped boxy format and tables with white backgrounds and simple line borders. I'm actually using the docbkx plugin to generate html from DocBook, which I then run through JTidy to make XHTML-compatible. I generate this to the target/generated-site/xhtml directory. Because I want the version number substituted *and* to be able to edit the DocBook with XMLMind, I actually write *.xhtml.vm files so that Velocity does variable substitution. This is all working great, given the limits of Doxia, but is there a way to specify different table styles? I'm guessing the answer is no. -K - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Test fail for release:perform only - no failure info
Wayne, I read somewhere that you can hook a debugger to the surefire plugin, is that what you're talking about? I believe that plugin has a parameter that tells it to wait until the debugger has connected and then it proceeds to run the tests. Can you give me suggestions on setup/environment to do that? Thanks for your help by the way. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Monday, March 15, 2010 11:26 AM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info It seems like the surefire 'thread' is just bailing out. One other thing to note just to be complete, I also tried running with Java 1.6 (thinking maybe somebody else put a 1.6 specific test case in the project) but it gets the same result as using 1.5. You may need to bundle things up into something you can share (assuming this is even possible) that has the problem so others can take a look at it. Otherwise you'll need to get it into a runtime debugger and see where things go wrong yourself. 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
Can release:perform please not deploy the site?
I'm using Sonatype's hosting to stage my releases and sometimes need to drop back. It's annoying to have it deploy the site docs when they don't conform to the actual released-on-central latest version. I can't see an argument to stop this. I suppose I could deploy to some bogus location by default, such as a different directory in target, and then have a profile that I can use to manually deploy, but it seems silly. Any ideas? BTW, in general, I like the release plugin a lot. You folks have done very good work on it. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can release:perform please not deploy the site?
On 2010-03-15 20:02, Kathryn Huxtable wrote: I'm using Sonatype's hosting to stage my releases and sometimes need to drop back. It's annoying to have it deploy the site docs when they don't conform to the actual released-on-central latest version. I can't see an argument to stop this. You need this: http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals Set it to deploy if you only want to deploy the artifact during release. I suppose I could deploy to some bogus location by default, such as a different directory in target, and then have a profile that I can use to manually deploy, but it seems silly. Any ideas? BTW, in general, I like the release plugin a lot. You folks have done very good work on it. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can release:perform please not deploy the site?
Ah. I missed that. Thanks much! -K On Mar 15, 2010, at 2:35 PM, Dennis Lundberg wrote: On 2010-03-15 20:02, Kathryn Huxtable wrote: I'm using Sonatype's hosting to stage my releases and sometimes need to drop back. It's annoying to have it deploy the site docs when they don't conform to the actual released-on-central latest version. I can't see an argument to stop this. You need this: http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals Set it to deploy if you only want to deploy the artifact during release. I suppose I could deploy to some bogus location by default, such as a different directory in target, and then have a profile that I can use to manually deploy, but it seems silly. Any ideas? BTW, in general, I like the release plugin a lot. You folks have done very good work on it. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - 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: Test fail for release:perform only - no failure info
I read somewhere that you can hook a debugger to the surefire plugin, is that what you're talking about? I believe that plugin has a parameter that tells it to wait until the debugger has connected and then it proceeds to run the tests. Googling maven surefire debugger brought the proper results to the top... give it a try. ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Test fail for release:perform only - no failure info
Thank you, I appreciate it. I'll let ya know what I find. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Monday, March 15, 2010 1:14 PM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info I read somewhere that you can hook a debugger to the surefire plugin, is that what you're talking about? I believe that plugin has a parameter that tells it to wait until the debugger has connected and then it proceeds to run the tests. Googling maven surefire debugger brought the proper results to the top... give it a try. ;-) 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
RE: Test fail for release:perform only - no failure info
Wayne, One issue... how do you get the maven.surefire.debug option to the surefire plugin since it's running via the release plugin? For instance, if I try to tell it just to skip tests, (i.e. -Dmaven.test.skip=true) it won't because the release plugin has it's own surefire config (I'm guessing). So even if I want to debug it using Eclipse to attach to the test jvm, I don't see how can I get that parameter to the surefire instance that the release plugin is firing up. I'll try anyhow, but think this will be a problem. Regards, Randall -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Monday, March 15, 2010 1:14 PM To: Maven Users List Subject: Re: Test fail for release:perform only - no failure info I read somewhere that you can hook a debugger to the surefire plugin, is that what you're talking about? I believe that plugin has a parameter that tells it to wait until the debugger has connected and then it proceeds to run the tests. Googling maven surefire debugger brought the proper results to the top... give it a try. ;-) 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
compile from multiple source directories
Hi, I have source code in multiple directories that I want to compile. How can I do that? I can't change the location. I have read about build-helper-maven-plugin, but I have not managed to get it to work, e.g.: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest-build-helper/artifactId packagingjar/packaging version1.0-SNAPSHOT/version nametest-build-helper/name urlhttp://maven.apache.org/url dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId version1.5/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId version1.5/version executions execution idadd-source/id phasegenerate-sources/phase goals goaladd-source/goal /goals configuration sources sourcefile:/somewhere/src/source /sources /configuration /execution /executions /plugin /plugins /build /project In src/main there is java that uses the classes that would be compiled from /somewhere/src. If I run: mvn package, the compile fails saying it can't find the class that would have been compiled from /somewhere/src. What do I need to do? Kendall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn archetype:create breaks on js file
archetype:create is deprecated in favour of archetype:generate, so try archetype:generate. See its interactiveMode setting for a non-interactive option. Brett On 3/15/10, Antoine van Wel antoine.van@gmail.com wrote: Hi, I'm building an archetype using mvn archetype:create-from-project. In my project there are several javascript files. Installing the generated archetype works fine. The moment I try to create a project from this archetype on the command-line using mvn archetype:create, I get an error, which seems to indicate Velocity cannot handle the javascript files in the project. Which is actually a problem of Velocity, but the files should not be touched by Velocity in the first place. I tried to disable filtering them: fileSet filtered=false encoding=UTF-8 directorysrc/main/webapp/directory includes include**/*.png/include include**/*.js/include include**/*.css/include /includes /fileSet and tried several alternatives, but none of them seems to be working: it does not stop Velocity from touching the files, and then choking on them. Any ideas if I'm doing something wrong? Version used: maven 2.0.9 and maven-archetype-plugin 2.0-alpha-4. However, the interactive mvn archetype:generate seems to work perfectly, which makes me believe this is a bug. Thanks, Antoine. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Sent from my mobile device - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Test fail for release:perform only - no failure info
Finally! As suspected... it was some stupid trivial item. I'm posting this
just so the thread on the mail archive will be complete.
Effectively what was causing the issue was some of surefire reports got checked
into the scm under the target directory {project}/target/surefire-reports.
This is what caused surefire via release plugin to fail on the perform goal and
not the prepare goal. Reason being is that prepare runs a clean (and I usually
run mvn clean release:prepare anyhow) as it's first step. When the release
goal was running, it would check out the entire project again to
{project}/target/checkout/ in which those same surefire reports that were in
the scm, would be placed into
{project}/target/checkout/target/surefire-reports. As a consequence, the
surefire plugin would bomb on perform and not prepare (because prepare deleted
them via it's own clean execution). Perform would does not run a clean so when
it checked out the entire project again, the reports were in the target
directory which throws surefire for a loop.
I wish surefire would give you more information, such as it had a problem with
a report file already existing, that would have saved SO much time, oh well.
Lesson learned: Make sure you don't check anything into your projects target
directory on your SCM, IT'S NOT A GOOD IDEA! ;)
Regards,
Randall
-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com]
Sent: Monday, March 15, 2010 1:32 PM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info
Wayne,
One issue... how do you get the maven.surefire.debug option to the
surefire plugin since it's running via the release plugin? For instance, if I
try to tell it just to skip tests, (i.e. -Dmaven.test.skip=true) it won't
because the release plugin has it's own surefire config (I'm guessing). So
even if I want to debug it using Eclipse to attach to the test jvm, I don't see
how can I get that parameter to the surefire instance that the release plugin
is firing up. I'll try anyhow, but think this will be a problem.
Regards,
Randall
-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Monday, March 15, 2010 1:14 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info
I read somewhere that you can hook a debugger to the surefire plugin,
is that what you're talking about? I believe that plugin has a parameter
that tells it to wait until the debugger has connected and then it proceeds
to run the tests.
Googling maven surefire debugger brought the proper results to the
top... give it a try. ;-)
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Test fail for release:perform only - no failure info
Nice one. Adding an svn:ignore to a new project/module's target
directory is about the first thing I do for a new artifact.
Brett
On 3/16/10, Randall Fidler randall.fid...@testadvantage.com wrote:
Finally! As suspected... it was some stupid trivial item. I'm posting this
just so the thread on the mail archive will be complete.
Effectively what was causing the issue was some of surefire reports got
checked into the scm under the target directory
{project}/target/surefire-reports. This is what caused surefire via release
plugin to fail on the perform goal and not the prepare goal. Reason being
is that prepare runs a clean (and I usually run mvn clean release:prepare
anyhow) as it's first step. When the release goal was running, it would
check out the entire project again to {project}/target/checkout/ in which
those same surefire reports that were in the scm, would be placed into
{project}/target/checkout/target/surefire-reports. As a consequence, the
surefire plugin would bomb on perform and not prepare (because prepare
deleted them via it's own clean execution). Perform would does not run a
clean so when it checked out the entire project again, the reports were in
the target directory which throws surefire for a loop.
I wish surefire would give you more information, such as it had a problem
with a report file already existing, that would have saved SO much time, oh
well.
Lesson learned: Make sure you don't check anything into your projects target
directory on your SCM, IT'S NOT A GOOD IDEA! ;)
Regards,
Randall
-Original Message-
From: Randall Fidler [mailto:randall.fid...@testadvantage.com]
Sent: Monday, March 15, 2010 1:32 PM
To: Maven Users List
Subject: RE: Test fail for release:perform only - no failure info
Wayne,
One issue... how do you get the maven.surefire.debug option to the
surefire plugin since it's running via the release plugin? For instance, if
I try to tell it just to skip tests, (i.e. -Dmaven.test.skip=true) it won't
because the release plugin has it's own surefire config (I'm guessing). So
even if I want to debug it using Eclipse to attach to the test jvm, I don't
see how can I get that parameter to the surefire instance that the release
plugin is firing up. I'll try anyhow, but think this will be a problem.
Regards,
Randall
-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Monday, March 15, 2010 1:14 PM
To: Maven Users List
Subject: Re: Test fail for release:perform only - no failure info
I read somewhere that you can hook a debugger to the surefire plugin,
is that what you're talking about? I believe that plugin has a parameter
that tells it to wait until the debugger has connected and then it
proceeds
to run the tests.
Googling maven surefire debugger brought the proper results to the
top... give it a try. ;-)
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Sent from my mobile device
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Best practices
Am I missing something? There seem to be a lot of people who try to incorporate jar projects into master projects and deploy with the Big Bang Theory - Get everything all right and deploy the whole mess. They seem to generate a lot of problems for themselves. Is it not a better idea to build projects for your libraries separately, test them, deploy them on their own and then use them as dependencies in the same way that one uses dependencies from third parties? This leaves open the question of versions since your libraries can have their own versions and you have to identify the version in the pom of your WAR files but that is not a big issue. You can use parent POMs with the version properties for all your libraries that you share if you want to keep everyone on the same version. We really need to look at a Best Practices document to reduce the amount of traffic in this forum from people who are trying to reinvent the software development lifecycle when it is completely unnecessary. There are not that many ways to build applications. I can think of : 1) Portals with portlets 2) Web application 3) Web Services 4) Standalone clients. Have I missed anything? It appears to me that Maven can build all of these in pretty much the same way. How many useful ways are there to build each one of these things? Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Test fail for release:perform only - no failure info
I wish surefire would give you more information, such as it had a problem with a report file already existing, that would have saved SO much time, oh well. Please file a JIRA so this can possibly be addressed in a future surefire release. Lesson learned: Make sure you don't check anything into your projects target directory on your SCM, IT'S NOT A GOOD IDEA! ;) This is Maven 101. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-aar-plugin] was not found.
I'm having the same problem, even after having read the maven plugin prefix mapping link. MThe relevant portion of my POM is: build plugins plugin groupIdorg.apache.axis2/groupId artifactIdaxis2-aar-maven-plugin/artifactId version1.5.1/version configuration goalPrefixaar/goalPrefix /configuration /plugin /plugins /build Here's the result: [/Users/dave/projects/gpsdata/webservice] mvn aar:exploded [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/axis2/axis2-aar-maven-plugin/1.5.1/axis2-aar-maven-plugin-1.5.1.pom Downloading: http://repo1.maven.org/maven2/org/apache/axis2/axis2-aar-maven-plugin/1.5.1/axis2-aar-maven-plugin-1.5.1.jar [INFO] Searching repository for plugin with prefix: 'aar'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue Mar 16 12:38:18 NZDT 2010 [INFO] Final Memory: 3M/5M [INFO] So even though maven locates the plugin and installs it into the repo, it cannot find it for use. Obviously I've missed something obvious. --Dave Wendy Smoak-3 wrote: On Mon, Jan 5, 2009 at 12:49 PM, Martin Gainty mgai...@hotmail.com wrote: Page Not Found What page is not found? The one Justin mentioned is there: http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html (Watch wrapping, you may have to reconstruct the url if your mail client breaks it.) -- Wendy - 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/The-PluginDescriptor-for-the-plugin-Plugin--org.apache.maven.plugins%3Amaven-aar-plugin--was-not-found.-tp21296536p27911807.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: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-aar-plugin] was not found.
Interestingly, everything works correctly if I use a prefix of axis2-aar.
Not quite sure why.
[/Users/dave/projects/gpsdata/webservice] mvn help:describe
-Dplugin=axis2-aar
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building webservice
[INFO]task-segment: [help:describe] (aggregator-style)
[INFO]
[INFO] [help:describe {execution: default-cli}]
[INFO] org.apache.axis2:axis2-aar-maven-plugin:1.5.1
Name: Apache Axis2 - tool - AAR Maven Plugin
Description: A Maven 2 plugin for creating Axis 2 service archives (aar
files)
Group Id: org.apache.axis2
Artifact Id: axis2-aar-maven-plugin
Version: 1.5.1
Goal Prefix: axis2-aar
This plugin has 4 goals:
axis2-aar:aar
Description: Build a aar.
Deprecated. No reason given
axis2-aar:deployaar
Description: Deploys an AAR to the Axis2 server.
Deprecated. No reason given
axis2-aar:exploded
Description: Generate the exploded aar
Deprecated. No reason given
axis2-aar:inplace
Description: Generates aar in the source directory
Deprecated. No reason given
For more information, run 'mvn help:describe [...] -Ddetail'
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Mar 16 12:48:11 NZDT 2010
[INFO] Final Memory: 7M/13M
[INFO]
[/Users/dave/projects/gpsdata/webservice]
nw31304 wrote:
I'm having the same problem, even after having read the maven plugin
prefix mapping link. MThe relevant portion of my POM is:
build
plugins
plugin
groupIdorg.apache.axis2/groupId
artifactIdaxis2-aar-maven-plugin/artifactId
version1.5.1/version
configuration
goalPrefixaar/goalPrefix
/configuration
/plugin
/plugins
/build
Here's the result:
[/Users/dave/projects/gpsdata/webservice] mvn aar:exploded
[INFO] Scanning for projects...
Downloading:
http://repo1.maven.org/maven2/org/apache/axis2/axis2-aar-maven-plugin/1.5.1/axis2-aar-maven-plugin-1.5.1.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/axis2/axis2-aar-maven-plugin/1.5.1/axis2-aar-maven-plugin-1.5.1.jar
[INFO] Searching repository for plugin with prefix: 'aar'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-aar-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Mar 16 12:38:18 NZDT 2010
[INFO] Final Memory: 3M/5M
[INFO]
So even though maven locates the plugin and installs it into the repo, it
cannot find it for use. Obviously I've missed something obvious.
--Dave
Wendy Smoak-3 wrote:
On Mon, Jan 5, 2009 at 12:49 PM, Martin Gainty mgai...@hotmail.com
wrote:
Page Not Found
What page is not found? The one Justin mentioned is there:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
(Watch wrapping, you may have to reconstruct the url if your mail
client breaks it.)
--
Wendy
-
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/The-PluginDescriptor-for-the-plugin-Plugin--org.apache.maven.plugins%3Amaven-aar-plugin--was-not-found.-tp21296536p27911879.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
Overwriting Dependencies
Hello All, Sorry if this has been covered and re-covered but I'm just not finding it in my searching: I have a Maven2 project that has a packaged dependency included (Zip that is unpacked) and then a pile of local includes. Somehow I need to ensure that the local files always take precedence (overwrite) the files in the zipped package. Unfortunately this is not what I'm getting. Any help is appreciated. Here's my assembly xml: assembly idbin/id formats formatdir/format formatzip/format /formats fileSets fileSet includes includeREADME*/include includeLICENSE*/include includeNOTICE*/include /includes /fileSet fileSet directorysrc/etc/directory outputDirectoryetc/outputDirectory fileMode774/fileMode includes include*.xml/include include*.conf/include include*.properties/include /includes /fileSet fileSet directorysrc/bin/directory outputDirectory/outputDirectory fileMode774/fileMode includes include*.bat/include include*.sh/include include*.cmd/include /includes /fileSet fileSet directorytarget/directory outputDirectorylib/outputDirectory fileMode774/fileMode includes include*.jar/include /includes /fileSet fileSet directorysrc/docs/directory outputDirectorydocs/outputDirectory fileMode664/fileMode /fileSet /fileSets dependencySets dependencySet outputDirectorylib/outputDirectory scoperuntime/scope excludes excludecom.identix:migrate/exclude /excludes /dependencySet dependencySet outputFileNameMapping/outputFileNameMapping unpacktrue/unpack scoperuntime/scope useProjectArtifactfalse/useProjectArtifact useProjectAttachmentsfalse/useProjectAttachments useTransitiveDependenciestrue/useTransitiveDependencies useTransitiveFilteringfalse/useTransitiveFiltering useStrictFilteringfalse/useStrictFiltering useDefaultExcludestrue/useDefaultExcludes includes includecom.identix:migrate/include /includes outputDirectory/outputDirectory /dependencySet /dependencySets includeBaseDirectorytrue/includeBaseDirectory /assembly Thanks -Nate
Re: Best practices
On 15 March 2010 22:29, Ron Wheeler rwhee...@artifact-software.com wrote:
Am I missing something?
There seem to be a lot of people who try to incorporate jar projects into
master projects and deploy with the Big Bang Theory - Get everything all
right and deploy the whole mess.
They seem to generate a lot of problems for themselves.
Is it not a better idea to build projects for your libraries separately,
test them, deploy them on their own and then use them as dependencies in the
same way that one uses dependencies from third parties?
Hi Ron,
This sounds like it might be slightly influenced by my thread from
yesterday, or at least is related to it.
You are generally right about the best practice - modular development
is almost always a good idea, but I doubt you would find a way to
significantly cut down on the traffic here, as there are definitely a
lot of special cases, as I know only too well.
Also, managing lots of completely independent pieces of code is hard
work. Even Maven itself is several modules combined into a project,
so that a single command can build/deploy lots of pieces at once.
When synchronizing releases across modules, this is really an obvious
win.
There are some definite patterns that Maven makes work well, and maybe
collecting these together would be help to people. For example, the
pattern of project/{core,web-app,cli-app}, or
project/{ejbs,utils,web-app,ear-app}.
And indeed considering these patterns can help with abstracting out
some other cases, but there will always be some things that will be
more complicated. My case involves something like one of the above
patterns, but with custom deployment requirements, and several new
packaging types, it can't be made to map neatly into a simple build
the parts, then assemble pattern - so I came here and asked for help.
snip
Ron
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-eclipse-plugin] Spring dependencies omitted
On Thu, Mar 11, 2010 at 6:39 PM, Pascal Kesseli pascal_kess...@hotmail.comwrote: Hi everyone Being a typical maven fan, I tried to manage our eclipse plugins using maven. To do so, I configured the maven-eclipse-plugin as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration pdetrue/pde manifestMETA-INF/MANIFEST.MF/manifest spring version2.5.6/version file-patternspring.cfg.xml/file-pattern basedirsrc/main/resources/basedir /spring /configuration /plugin First off, I am not even sure what exactly the spring-tag in here is good for? What does the plugin do with that information? Secondly, as described on the apache website, the plugin is supposed to copy all the dependencies as jars to my project root. While that works well with almost any dependency, the plugin constantly ignores any Spring dependency I have added to my project, such as spring-aspects, spring-core or spring-test. Does anybody know where that behavior evolves from? I'm not sure that the pde mode does what you think it does. See http://maven.apache.org/plugins/maven-eclipse-plugin/pde.html Note that the scope of the *maven-eclipse-plugin* is to synchronise the Eclipse *.project* and *.classpath* files with the configuration found in the pom file. Once you have finished configuring the Eclipse plugin as below, and once you have run the *eclipse:eclipse* goal, you will be in a position to build your plugin code with the Eclipse IDE, or the Eclipse headless PDE buildhttp://www.eclipse.org/articles/Article-PDE-Automation/automation.html. The Eclipse headless PDE build can be triggered from within Maven using the pde-maven-plugin http://mojo.codehaus.org/pde-maven-plugin/ To get maven to build PDE projects I have used (3 years ago) the plugin (now unmaintained) http://mojo.codehaus.org/pde-maven-plugin/ You may also be able to use Tycho http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview I also cant see any documentation about using the configuration section as you have done - which tends to indicate its not supported.
Re: compile from multiple source directories
Kendall Shaw ks...@kendallshaw.com writes:
Hi,
I have source code in multiple directories that I want to compile. How
can I do that? I can't change the location.
I have read about build-helper-maven-plugin, but I have not managed to
get it to work, e.g.:
[snip]
It appears to work if I use antrun plugin to copy the sources below the
project directory,
e.g. ${project.build.directory}/generated-sources/main/java. And, then
add that directory using build-helper plugin.
Is there a way around that? I'd rather not be copying source files.
Kendall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
New snapshots versus the local repo
I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven ear plugin -- add files into META-INF folder
Dear all, During ear packaging, is there any way to add my personal files into the ear/META-INF folder if I don't put it in the default source folder src\main\application\META-INF. For example, I have weblogic specific file weblogic-application.xml, it dost't lie in the default folder src\main\application\META-INF, what could I do in this case? I am using maven 2.1.0-M1. any idea would be appreciated. Thanks, Thunder -- Listen to Your Heart Follow Your Heart
Re: Best practices
Phil Housley wrote:
On 15 March 2010 22:29, Ron Wheeler rwhee...@artifact-software.com wrote:
Am I missing something?
There seem to be a lot of people who try to incorporate jar projects into
master projects and deploy with the Big Bang Theory - Get everything all
right and deploy the whole mess.
They seem to generate a lot of problems for themselves.
Is it not a better idea to build projects for your libraries separately,
test them, deploy them on their own and then use them as dependencies in the
same way that one uses dependencies from third parties?
Hi Ron,
This sounds like it might be slightly influenced by my thread from
yesterday, or at least is related to it.
I am not sure that I could identify an individual request that prompted
my comments.
You are generally right about the best practice - modular development
is almost always a good idea, but I doubt you would find a way to
significantly cut down on the traffic here, as there are definitely a
lot of special cases, as I know only too well.
I would like to know what they are.
Also, managing lots of completely independent pieces of code is hard
work. Even Maven itself is several modules combined into a project,
so that a single command can build/deploy lots of pieces at once.
When synchronizing releases across modules, this is really an obvious
win.
We have to manage about 80 3rd part libraries and we have started to
accumulate our own libraries into projects that we have to manage and
synchronize with deliverables.
It requires a bit of brain power(self discipline) but does not require a
special maven plug-in.
We use proper version control with snapshots and releases.
There are some definite patterns that Maven makes work well, and maybe
collecting these together would be help to people. For example, the
pattern of project/{core,web-app,cli-app}, or
project/{ejbs,utils,web-app,ear-app}.
I was hoping to get a comprehensive list of standard products based on
my initial list.
There can not be too many things that people want to build.
And indeed considering these patterns can help with abstracting out
some other cases, but there will always be some things that will be
more complicated. My case involves something like one of the above
patterns, but with custom deployment requirements, and several new
packaging types, it can't be made to map neatly into a simple build
the parts, then assemble pattern - so I came here and asked for help.
What sort of custom deployment and package types. Can you elaborate a
bit further?
This is a good place to ask for help since the quality and depth of
expertise is a very good.
I just have this nagging feeling that a lot of the responses are direct
responses to the question asked rather than guidance towards Best
Practices that might be much better answers in the long run.
snip
Ron
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: compile from multiple source directories
configuration
sources
source${basedir}/../../relative to your project
directory/source
/sources
/configuration
is there a reason why you want to do this way? can you just do multi
modules build?
-D
On Mon, Mar 15, 2010 at 6:00 PM, Kendall Shaw ks...@kendallshaw.com wrote:
Kendall Shaw ks...@kendallshaw.com writes:
Hi,
I have source code in multiple directories that I want to compile. How
can I do that? I can't change the location.
I have read about build-helper-maven-plugin, but I have not managed to
get it to work, e.g.:
[snip]
It appears to work if I use antrun plugin to copy the sources below the
project directory,
e.g. ${project.build.directory}/generated-sources/main/java. And, then
add that directory using build-helper plugin.
Is there a way around that? I'd rather not be copying source files.
Kendall
-
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: New snapshots versus the local repo
Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron - 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: Maven ear plugin -- add files into META-INF folder
Hi, As in http://maven.apache.org/plugins/maven-ear-plugin/examples/filtering-sources.html noted use earSourcesDirectory. Rgds, Markku On 16.3.2010 5:06, Thunder Farmer wrote: Dear all, During ear packaging, is there any way to add my personal files into the ear/META-INF folder if I don't put it in the default source folder src\main\application\META-INF. For example, I have weblogic specific file weblogic-application.xml, it dost't lie in the default folder src\main\application\META-INF, what could I do in this case? I am using maven 2.1.0-M1. any idea would be appreciated. Thanks, Thunder
Re: Can release:perform please not deploy the site?
Yep. Released and dropped and no site deploy! Again, thanks! -K On Mar 15, 2010, at 2:37 PM, Kathryn Huxtable wrote: Ah. I missed that. Thanks much! -K On Mar 15, 2010, at 2:35 PM, Dennis Lundberg wrote: On 2010-03-15 20:02, Kathryn Huxtable wrote: I'm using Sonatype's hosting to stage my releases and sometimes need to drop back. It's annoying to have it deploy the site docs when they don't conform to the actual released-on-central latest version. I can't see an argument to stop this. You need this: http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals Set it to deploy if you only want to deploy the artifact during release. I suppose I could deploy to some bogus location by default, such as a different directory in target, and then have a profile that I can use to manually deploy, but it seems silly. Any ideas? BTW, in general, I like the release plugin a lot. You folks have done very good work on it. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
