Re: Selective Parallel Builds with maven 3
To explain the situation further, I tried building the code bases (in parallel) at the root but didn't work (due to various reasons). However, I figured out parts/modules can be built like this without any modification to the setup. I've never used parallel builds with any real, substantial projects as yet. I'd be curious to know more about the various reasons you ran into problems since you haven't told us anything about them. Realistically I would pick a problem, solve it, then move on to the next, repeat until all problems are solved. ;-) If you have a build graph issue, make sure your dependencies are properly declared across the various pom files. What specific settings were you using for your parallel build? Perhaps you just need to tweak the parameters a bit. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re-Releasing Configured Artifacts, how?
Hi All,
We have decided that we would like to release configured artifacts from our
scm. I am looking at the most suitable way to do this with maven3.
Use Case:
We have released v2.5.1.0 or our webapp. We would like to take v2.5.1.0,
make a change to the configuration (i.e. a property), check that into the
SCM and then release that as v2.5.1.1 (or we could even use
2.5.1.${buildNumber})
Additionally:
We need to release different artifacts for each release for different
target environments LATEST, DEV, UAT, PRODUCTION.
What is the best way to achieve this, and (if possible) are classifiers a
suitable way to distinguish LATEST, DEV, UAT, PRODUCTION configured
artifacts?
Thanks in advance,
Andrew
Re: Re-Releasing Configured Artifacts, how?
On Wed, Apr 18, 2012 at 4:33 PM, Andrew Hughes ahhug...@gmail.com wrote:
Hi All,
We have decided that we would like to release configured artifacts from our
scm. I am looking at the most suitable way to do this with maven3.
Use Case:
We have released v2.5.1.0 or our webapp. We would like to take v2.5.1.0,
make a change to the configuration (i.e. a property), check that into the
SCM and then release that as v2.5.1.1 (or we could even use
2.5.1.${buildNumber})
Additionally:
We need to release different artifacts for each release for different
target environments LATEST, DEV, UAT, PRODUCTION.
What is the best way to achieve this, and (if possible) are classifiers a
suitable way to distinguish LATEST, DEV, UAT, PRODUCTION configured
artifacts?
Have you read the freely available books over at
http://maven.apache.org/articles.html?
classifiers are not meta data about your released artifact.
From http://maven.apache.org/pom.html
The classifier allows to distinguish artifacts that were built from
the same POM but differ in their content
You will need to use some internal mechanism for tracking this meta
data. That's your PMs job.
To make a new build,
Create a branch 2.5.1.1 from the tagged version 2.5.1.0.
Make your changes on the branch.
Check them in.
Run mvn release:prepare and mvn release:perform to generate 2.5.1.1
(or whatever release process you use that originally create 2.5.1.0)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
One thing I would like to add to this discussion is that, in my experience, a lot of Maven users don't understand that Maven is not only about building but also about producing something that can be consumed from a repository. One part of what we often call Maven is the build tool, but a much more important part is having consumable artifacts in a repo. So, IMHO, I doesn't really matter if you can build something if it can't be consumed by other people. Doing clever solutions like producing multiple artifacts from one Maven project most often makes them hard (or even impossible) do consume from a repo in a correct way. But yes, documentation about this could be much better. But as someone very correctly pointed out, there is very likely is a reason for the lack of this. It's all open source and contributions are gladly accepted. Even the Sonatype's book are open source (well, Creative Commons Attribution, Non-Commercial, No Derivative Works 3.0 United States license). If you have suggestions, additions, or whatever, file an enhancement ticket and it will be appreciated and most likely added. Some people do this, but there is always more that can be done and we can all participate. /Anders On Wed, Apr 18, 2012 at 02:00, Graham Leggett minf...@sharp.fm wrote: On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote: Often the wrong foot is simply not knowing how much Maven does for your for free - because it is not obvious - especially when compared to tools like Ant. When the free stuff is not obvious, we naively start trying to solve problems we do not have to. The way I describe this is by getting people to ask the right question: Wrong question: How do I do X? Right question: Does does maven do X? Maven already knows how to do stuff. Find out how maven does it, and let maven get on with the job. As soon as you want maven to work your way, and not maven's way, expect to have loads of your time wasted, and the time of everyone after you too. The next thing is that maven isn't an alternative to ant, rather maven is an alternative to ant's build.xml file. Or to put it another way, maven does what build.xml does. build.xml gets written, rewritten and rewritten again for every single ant project, but there is only one maven. I have to care how your build.xml is different to my build.xml, I have to document how your build.xml is different to my build.xml, but if we both used maven, all this becomes unnecessary, because there is only one maven. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Question about Maven Assembly Plugin
I get several hits with Google. For example:
http://www.sonatype.com/people/2009/08/how-to-make-an-executable-jar-in-maven/
(this one does not talk about useProjectArtifact=false, so I guess it
is not necessary)
If someone has a real example with a link, please provide. I don't.
/Anders
On Wed, Apr 18, 2012 at 00:23, QL 983 fraterql...@gmail.com wrote:
Hi, Anders; thank you for your answer! I tried using useProjectArtifact
false, but it did not work.
Could you please supply me with an example of a executable
jar-with-dependencies?
Kind regards,
QL
On Tue, Apr 17, 2012 at 8:06 AM, Anders Hammar and...@hammar.net wrote:
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the Maven
Assembly Plugin to build a executable jar, with all dependencies inside
it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this
warning:
[WARNING] Cannot include project artifact: com.company.class; it doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the
problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance
merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it has,
but
no code of mine is added in the jar, and I get this output in command
line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial ---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/maven/org.apache.httpcomponents/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added,
Maven for both java and zend
Hi, I have product that is being developed in both java and PHP(using zend framework).I wanted to know if i could use same settings.xml file for both and also if i could use same repository for both java and php.How the assembling would be done for both so that its in deployable format. Thanks in advance, Priya -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476161.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: Assembly plugin plugin
The latter. There is indeed a 'root' module with a pluginManagement section. I do not control its content directly, I can ask that the my assembly plugin be added there. Thanks On Tue, Apr 17, 2012 at 11:39 PM, Wayne Fay wayne...@gmail.com wrote: I suppose I will have to figure out a way to make sure mine gets loaded first. Are there any tricks out there for fooling the reactor? I know of no tricks. You should talk to the owner of the other module(s) using the assembly plugin and convince them to add your handler into their plugindependencies or even better get the owner of the top parent to add a pluginManagement section and specify it there (then it will be inherited down to all the other poms). Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Assembly plugin plugin
Hi Robert, Robert Egan wrote: The latter. There is indeed a 'root' module with a pluginManagement section. I do not control its content directly, I can ask that the my assembly plugin be added there. that's actually the only working solution in M2. Just declare the plugin there in the pluginMgmt without any configuration, but the required dependencies. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for both java and zend
Hi. First of all: You can of course use the same repository for multiple artifacts, packagings and project types. And yes, you can use the same settings.xml file for both. However that depends on the question what is inside the settings.xml. If there is anything inside it that is incompatible you should use profiles (and if you divide the php artifact from java artifact). For example the profile my-java-profile for anything that is only visible to your java artifact and my-php-profile that is visible to your php project. As you say the project depends on both, java and php I assume that the php code is part of a java servlet and is deployed as war file? Am I right? Greetings Martin On Wed, Apr 18, 2012 at 10:16 AM, priya hulekal priyahule...@gmail.comwrote: Hi, I have product that is being developed in both java and PHP(using zend framework).I wanted to know if i could use same settings.xml file for both and also if i could use same repository for both java and php.How the assembling would be done for both so that its in deployable format. Thanks in advance, Priya -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476161.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
Maven for both java and zend
Hi, I have product that is being developed in both java and PHP(using zend framework).I wanted to know if i could use same settings.xml file for both and also if i could use same repository for both java and php.How the assembling would be done for both so that its in deployable format. Regards, Priya -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7475897p7475897.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: Maven for both java and zend
No php code is not a part of java servlet..It will be used for front end to display that is UI. -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476323.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: Maven for both java and zend
And also in what pattern it will be deployed...Like for example web app it will be war files,php it will be .php ..finally what will be the form. -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476336.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: Question about Maven Assembly Plugin
Hi, Anders.
Thank you again.
I think this example works with older plugin's versions, because it is very
like the one I used with Maven 2.2.1. I searched google and read all
documentation in the plugin's site before asking, and, as I could not
resolve the issue, I am trying the mailing list.
Kind regards,
QL
On Wed, Apr 18, 2012 at 4:43 AM, Anders Hammar and...@hammar.net wrote:
I get several hits with Google. For example:
http://www.sonatype.com/people/2009/08/how-to-make-an-executable-jar-in-maven/
(this one does not talk about useProjectArtifact=false, so I guess it
is not necessary)
If someone has a real example with a link, please provide. I don't.
/Anders
On Wed, Apr 18, 2012 at 00:23, QL 983 fraterql...@gmail.com wrote:
Hi, Anders; thank you for your answer! I tried using useProjectArtifact
false, but it did not work.
Could you please supply me with an example of a executable
jar-with-dependencies?
Kind regards,
QL
On Tue, Apr 17, 2012 at 8:06 AM, Anders Hammar and...@hammar.net
wrote:
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the
Maven
Assembly Plugin to build a executable jar, with all dependencies
inside
it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this
warning:
[WARNING] Cannot include project artifact: com.company.class; it
doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the
problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance
merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it
has,
but
no code of mine is added in the jar, and I get this output in command
line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial
---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated
file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already
Re: Re-Releasing Configured Artifacts, how?
Thanks very much :)
I will read up some more. But, I was more wondering in regards to
classifiers if I could release x3 (or more) builds of the same module (at
the moment I have one module per conf, each is a war overlay).
Cheers
On 18/04/2012 4:51 PM, Barrie Treloar baerr...@gmail.com wrote:
On Wed, Apr 18, 2012 at 4:33 PM, Andrew Hughes ahhug...@gmail.com wrote:
Hi All,
We have decided that we would like to release configured artifacts from
our
scm. I am looking at the most suitable way to do this with maven3.
Use Case:
We have released v2.5.1.0 or our webapp. We would like to take v2.5.1.0,
make a change to the configuration (i.e. a property), check that into
the
SCM and then release that as v2.5.1.1 (or we could even use
2.5.1.${buildNumber})
Additionally:
We need to release different artifacts for each release for different
target environments LATEST, DEV, UAT, PRODUCTION.
What is the best way to achieve this, and (if possible) are classifiers a
suitable way to distinguish LATEST, DEV, UAT, PRODUCTION configured
artifacts?
Have you read the freely available books over at
http://maven.apache.org/articles.html?
classifiers are not meta data about your released artifact.
From http://maven.apache.org/pom.html
The classifier allows to distinguish artifacts that were built from
the same POM but differ in their content
You will need to use some internal mechanism for tracking this meta
data. That's your PMs job.
To make a new build,
Create a branch 2.5.1.1 from the tagged version 2.5.1.0.
Make your changes on the branch.
Check them in.
Run mvn release:prepare and mvn release:perform to generate 2.5.1.1
(or whatever release process you use that originally create 2.5.1.0)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Question about Maven Assembly Plugin
OK. If you post your project somewhere I could give it a spin and see
what's wrong.
/Anders
On Wed, Apr 18, 2012 at 11:43, QL 983 fraterql...@gmail.com wrote:
Hi, Anders.
Thank you again.
I think this example works with older plugin's versions, because it is very
like the one I used with Maven 2.2.1. I searched google and read all
documentation in the plugin's site before asking, and, as I could not
resolve the issue, I am trying the mailing list.
Kind regards,
QL
On Wed, Apr 18, 2012 at 4:43 AM, Anders Hammar and...@hammar.net wrote:
I get several hits with Google. For example:
http://www.sonatype.com/people/2009/08/how-to-make-an-executable-jar-in-maven/
(this one does not talk about useProjectArtifact=false, so I guess it
is not necessary)
If someone has a real example with a link, please provide. I don't.
/Anders
On Wed, Apr 18, 2012 at 00:23, QL 983 fraterql...@gmail.com wrote:
Hi, Anders; thank you for your answer! I tried using useProjectArtifact
false, but it did not work.
Could you please supply me with an example of a executable
jar-with-dependencies?
Kind regards,
QL
On Tue, Apr 17, 2012 at 8:06 AM, Anders Hammar and...@hammar.net
wrote:
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the
Maven
Assembly Plugin to build a executable jar, with all dependencies
inside
it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this
warning:
[WARNING] Cannot include project artifact: com.company.class; it
doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the
problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance
merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it
has,
but
no code of mine is added in the jar, and I get this output in command
line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial
---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated
file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO]
Re: Maven for both java and zend
If it is not part of the java servlet and thus not part of the war file you should devide php code from java code. For example you have the following scenario: web browser connects to web server (apache) and php files. php file connects to tomcat/java servlet via SoapClient In this scenario you might have two artifacts: 1) The php artifact building your frontend webpage 2) The java servlet to be deployed in tomcat (or any other servlet container) The php artifact might be built as zip/phar and be deployed into your apache web root. The java artifact will be built as war. As the java servlet is your backend in this scenario the php project might need a dependency to the java servlet during runtime. To perform tests including the java servlet backend you need to tell the test cases to start a java servlet container and run your java artifact within it.
Re: The Maven Way
On 17 Apr 2012, Markku Saarela wrote: Hi, I recommend two books from Sonatype, Maven by Example 1) and Maven Cookbook 2) 1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example 2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook There is also Apache Maven 2: Effective Implementations from Brett Porter [1], which basically describes the maven way most of the time. The disadvantage of this book is, that it's quite old and the maven way sometimes changed over time. hth, - martin [1] http://www.packtpub.com/apache-maven-2-effective-implementation/book signature.asc Description: PGP signature
Re: Maven for both java and zend
Ok so you want to tell that i can use same settings.xml and same repository for both java and php code.Java and PHP should be considered as 2 different module.I will have a parent pom where i will list these sub modules.I will have a war file for java and zip/phar file for php and they should be deployed separately? I cant use maven ear plugin? -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476572.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: Maven for both java and zend
As far as I understood your scenario the one and only call between your php code and java code is some kind of request (maybe via soap?). So the php code does not become part of the java servlet and the java servlet does not know anything of the php code. You can use ear for the java artifact. The java servlet/war file was only one scenario. If you are using maven ear plugin or maven war plugin is not influencing the php artifact. The php frontend will perform a soap request to a soap server. The soap server is realized by java code. Maybe you are not using soap but some other protocol. Am I right? And yes: You should not mix up php code and java code into the same artifact as long as you do not have a direct dependency. There may be situations where you may have a direct dependency. There are several php-java bridges around that allow you to call java classes and instantiate java objects directly within your php code. Even in this case you should have a separate artifact. My suggestion is a three-artifact-scneario. 1) the backend is tested without knowing anything of the frontend (you may use maven-ear-plugin or any other java setup) 2) the frontend is a php project. For testing the backend is mocked. 3) A third artifact is used to tie frontend and backend together. It contains information how to download/extract/setup the frontend and the backend. And it contains some test cases to ensure the frontend is working with a non-mocked backend. On Wed, Apr 18, 2012 at 1:28 PM, priya hulekal priyahule...@gmail.comwrote: Ok so you want to tell that i can use same settings.xml and same repository for both java and php code.Java and PHP should be considered as 2 different module.I will have a parent pom where i will list these sub modules.I will have a war file for java and zip/phar file for php and they should be deployed separately? I cant use maven ear plugin? -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476572.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: Maven for both java and zend
Thanks Martin for your reply..Its bit confusing but i will try out what you suggested otherwise get back to you again :)Finally can you suggest some good book or some link on maven where i could find all these stuffs ..Information related to maven php as well as java. -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476654.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: Maven for both java and zend
hey one last thing need to ask you told that 3) A third artifact is used to tie frontend and backend together. It contains information how to download/extract/setup the frontend and the backend. And it contains some test cases to ensure the frontend is working with a non-mocked backend. what kind of artifact to be used ?Can i have some example where i can find this kind of scenario? -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476734.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 Maven Way
I hope that my comments are not taken as being critical of the person asking for help. Our team was in their position when we started and had to learn the Maven way. We received a lot of help and got a lot of benefit from the free resources provided by the community. We also were working closely with the team from another Apache project that used Maven in their build process and in the build process of customers of their projects like ourselves so they brought us a lot of basic knowledge built into the artifacts that they built for us. Very often my comment about fighting Maven is accompanied by a suggestion that the person try to rephrase their request at a higher level. - what type of artifact are they trying to build? - what is so peculiar about their project or environment that makes their build impossible or extremely complex with Maven. The second question has two purposes a) Get some facts into the discussion that might reach out to someone here who has experience in a similar situation b) Get the person to understand that Maven is successfully used without custom plug-ins or profiles to build a lot of projects everyday so they will ultimately be successful and probably with a lot less pain than they think. I will also confess to sometimes just asking a question in a thread that is not getting any attention because of the way the problem is posed, in order to get the question back in the expert's inboxes with a better or more amplified description of the problem so that the person gets some help. Ron On 17/04/2012 7:35 PM, Eric Kolotyluk wrote: On 2012-04-17 9:48 AM, Curtis Rueden wrote: Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. IMHO - the most valuable single bit of advice one can give a new Maven user is: don't try to master it on your own - ask for help - there are thousands of people with great experience, knowledge and advice who are willing to share it. The Sonatype training has enormous ROI. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven in an unconventional way. After all, the beauty of convention over configuration is that you *can* configure and override behavior as needed. I do not see anyone criticizing someone who tries to use Maven in an unconventional way - rather we are saying - if you are using Maven and you don't want to hurt yourself... My many years of experience tells me that far too much technology is too configurable with too many options and choices - and ultimately that causes more trouble than it is worth. Maven is more than adequately configurable, but collectively we still have a lot to learn about respecting and utilizing convention over configuration and adapting to the common vision that is Maven. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? I think one major difficulty is that as Maven develops, there is an evolving vision and understanding of what works well and what doesn't. And that is OK, and will continue to be the case. That said, someone could
RE: The Maven Way
But yes, documentation about this could be much better. But as someone very correctly pointed out, there is very likely is a reason for the lack of this. It's all open source and contributions are gladly accepted. Even the Sonatype's book are open source (well, Creative Commons Attribution, Non-Commercial, No Derivative Works 3.0 United States license). If you have suggestions, additions, or whatever, file an enhancement ticket and it will be appreciated and most likely added. Some people do this, but there is always more that can be done and we can all participate. /Anders One of the reasons why I think no one has stepped up, or the community at large hasn't stepped up, to create good Maven documentation about its conventions is because it is a extremely daunting task. And I have been thinking about why. Part of the reason, I believe, is because those conventions are not carved in stone. There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary. When I see a question asked here on this list, often the reply to that question is what are you trying to do? Why are you asking this question you are asking? There are general motherhood statements you can make about Maven's conventions. For example, a statement like Maven is designed for build portability. Use caution when creating a profile as this can make your build non-portable. The best way to explain how, from here, is by example. And you'll never be able to capture all scenarios which explain when to create a profile and how to go about doing it. It is too situational. The fact that the conventions are not carved in stone, and is a daunting task to document, I think is GOOD. It has created an ecosystem which does not become stagnant, but instead thrives off the ideas of the community. What can or cannot be done using Maven is constantly changing and the answer differs depending on who you ask. I almost think a better mantra for maven is philosophy over configuration instead of convention over configuration. To be honest, I actually never did have trouble first getting into Maven. In fact, I found it quite refreshing. What got me in the right mind set was this: http://maven.apache.org/what-is-maven.html Then, what solidified it for me was understanding the lifecycle by digesting this here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html So my recommendation to anyone trying maven for the first time is to read the what is maven link. Then think about it, come back, and read it again. You need to get out of the mind set of whatever build tool you were using because when you move to maven, you are getting much more than just a build tool. In all honesty, I don't think we will ever have that one document which explains what all of Maven's convention's are. Now, don't get me wrong. This doesn't mean we shouldn't aim for having that, as there is a lot of room for improved documentation. But I also think we need to set our expectations about what is reasonable to achieve. Todd - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for both java and zend
There is no book available yet. I am writing on a German book (related to maven for php) that will cover some scenarios. Maybe someone wants to translate it ;-) I do not think that anyone covered your scenario via maven. I did not find any scenarios related to apache httpd (which would the preferred webserver for php based websites). Of course there are several samples for artifacts creating compilations of other artifacts. But this depends on the resulting application. Most of the samples I know of are building java web applications by repacking multiple web applications. - sonar does support php analysis but is not focsed on your scenario. - maven for php will support (maybe via documentation or via additional goals) your scenario in future but only in future versions. - Maybe http://portals.apache.org/bridges/index.html will help. On Wed, Apr 18, 2012 at 2:22 PM, priya hulekal priyahule...@gmail.comwrote: hey one last thing need to ask you told that 3) A third artifact is used to tie frontend and backend together. It contains information how to download/extract/setup the frontend and the backend. And it contains some test cases to ensure the frontend is working with a non-mocked backend. what kind of artifact to be used ?Can i have some example where i can find this kind of scenario? -- View this message in context: http://maven-users.828.n2.nabble.com/Maven-for-both-java-and-zend-tp7476161p7476734.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 Maven Way
On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote: Good read. Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone. The guys at Sonatype have done a good job of posting various blogs. If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc. I think it says something that it has not been done yet. While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen. It is more of a very nice to have than a hard and fast requirement. Or, perhaps no one who feels strongly about it also feels he understands it well enough to write something worth reading. I could write reams of misleading rubbish but what purpose would that serve? I've written documentation for other people's code. It's exhausting, incredibly time-consuming, and often unsatisfactory. The whole reason I wanted documentation was because I didn't understand the product -- if I were in a position to document it well, I wouldn't need the documentation so badly! -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpvIm8dwK3Dy.pgp Description: PGP signature
Large artifact is truncated at 2GB
Hello, I've got a 6GB artifact. When I include it as a dependency in a pom.xml file and run 'mvn install' it downloads exactly 2GB. Maven then tells me that the checksum has failed. ... Downloading: http://localhost:8080/artifactory/ext-release-local/data-noarch-novoindex-hg19/nix/data-noarch-novoindex-hg19.nix/2.7/data-noarch-novoindex-hg19.nix-2.7-1.0.0.jar[WARNING] Checksum validation failed, expected 8a5fb3b00f2b31f4a74f33f44f1cbc8c44cc2506 but is 5fb087edb1f31b9e5ed9ea660d3b5250f1bfcc01 for http://localhost:8080/artifactory/ext-release-local/data-noarch-novoindex-hg19/nix/data-noarch-novoindex-hg19.nix/2.7/data-noarch-novoindex-hg19.nix-2.7-1.0.0.jar... If I use wget or a web browser I can download the entire file. The following succeeds: wget http://localhost:8080/artifactory/ext-release-local/data-noarch-novoindex-hg19/nix/data-noarch-novoindex-hg19.nix/2.7/data-noarch-novoindex-hg19.nix-2.7-1.0.0.jar Why does the artifact get truncated at 2GB when using Maven to download it from a repository? How can I make it work? Thanks, Tony $ mvn -version Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: /usr/share/maven Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.3, arch: x86_64, family: mac $ java -version java version 1.6.0_29 Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11D50b) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) Artifactory Version: 2.5.1.1 Tomcat Version: 6.0.35
Deploy issue
Hi When building a project maven create three types of archives - bin, source, javadoc. I have two remote repositories. Is there any way to configure maven so they deploy bin + source + javadoc to first repository and bin + javadoc to seckond repository ? Best regards -- View this message in context: http://maven.40175.n5.nabble.com/Deploy-issue-tp5648895p5648895.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: Deploy issue
If you control the repos, can you deploy to private hosted repos and then construct proxies or repo groups from which people download, so that the artifacts appear to be in multiple repos? Just a thought. Ron On 18/04/2012 8:10 AM, maciejm wrote: Hi When building a project maven create three types of archives - bin, source, javadoc. I have two remote repositories. Is there any way to configure maven so they deploy bin + source + javadoc to first repository and bin + javadoc to seckond repository ? Best regards -- View this message in context: http://maven.40175.n5.nabble.com/Deploy-issue-tp5648895p5648895.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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On 18/04/2012 9:52 AM, Mark H. Wood wrote: On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote: Good read. Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone. The guys at Sonatype have done a good job of posting various blogs. If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc. I think it says something that it has not been done yet. While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen. It is more of a very nice to have than a hard and fast requirement. Or, perhaps no one who feels strongly about it also feels he understands it well enough to write something worth reading. I could write reams of misleading rubbish but what purpose would that serve? I've written documentation for other people's code. It's exhausting, incredibly time-consuming, and often unsatisfactory. The whole reason I wanted documentation was because I didn't understand the product -- if I were in a position to document it well, I wouldn't need the documentation so badly! I feel the same way. I have written some blog posts (http://blog.artifact-software.com/tech) about things that we now understand and would propose our solutions as Best Practices for consideration by others who might be in a similar situation. I have not completely read all of the books and reference materials from Sonatype and the Maven project, so I am not sure that all of the criticism of documentation is justified. The Maven site is not the most friendly place to start as a new Maven user but it is not the only resource. Perhaps the community should try to come to a consensus about the books and recommend one as the best starting point for a new user and one as the best place to find Best Practices. Perhaps some Maven experts might be interested in offering a series of short low cost webinars for new people that run on a regular basis. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
Yeah they are config files, I just wanted a simple way to reference them in my code, i.e: ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); InputStream is = classLoader.getResourceAsStream(config.properties); I think what I should do is reference the file based on an environmental variable, which I will set both locally and on the production server. Plus having an EV let's other projects reference things in a more uniform way. you agree? On Wed, Apr 18, 2012 at 1:26 AM, Barrie Treloar baerr...@gmail.com wrote: On Wed, Apr 18, 2012 at 2:20 PM, Wayne Fay wayne...@gmail.com wrote: I want to exclude the /resources folder from the release so it doesn't get compiled into my .jar If you can't sort out how to do this, you can always make another project, depend on the output of this one, then unpack the assembly, set your excludes there, and repack the assembly minus the files you don't want. Also, why are you putting things in src/main/resources if you dont want them in your jar? Just put them somewhere else and they wont be included. If they are needed for testing it should be src/test/resources. If they are configuration files I put them in src/main/config and then you can tell the assembly plugin to include them in the zip it builds. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: variable to reference parent pom path?
Hi Ahmed,
In a sub-module, I have a assembly.xml file (maven-assembly-plugin) that I
am using to build this module. How can I reference the parent pom's path?
You can do this using the expression ${project.basedir}/../.. or however
many directory levels up you need to go.
Something like this:
!-- Include documents in toplevel directory. --
fileSet
directory${project.basedir}/../../directory
outputDirectory//outputDirectory
includes
includeLICENSE*/include
includeNOTICE*/include
includeREADME*/include
/includes
/fileSet
Of course, this requires the toplevel aggregator/parent project to be
present as part of your working copy. In an ideal world, you would not
include references upstream like this, but rather include everything needed
for the assembly as part of the project in question. Then the build will
function even if only that specific project is available.
Regards,
Curtis
On Wed, Apr 18, 2012 at 10:53 AM, S Ahmed sahmed1...@gmail.com wrote:
I have a multi-maven project.
In a sub-module, I have a assembly.xml file (maven-assembly-plugin) that I
am using to build this module. How can I reference the parent pom's path?
I want to create a folder in the root of the project that will contain some
configuration type files that I want to reference and copy over.
Re: variable to reference parent pom path?
In a sub-module, I have a assembly.xml file (maven-assembly-plugin) that I
am using to build this module. How can I reference the parent pom's path?
You can do this using the expression ${project.basedir}/../.. or however
many directory levels up you need to go.
Curtis is right about this but as he said later:
In an ideal world, you would not
include references upstream like this, but rather include everything needed
IMO this is an anti-pattern in Maven. If someone gets the source code
to build *just* this module, they will be unable to build it
independent of anything else.
Instead, you set up another module that exists solely to contain these
configuration files and then pull it in as a dependency where you need
them. Use dependency:unpack to put the files where you need them or
the proper assembly configuration.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
questions about Apache parent pom (and Commons parent pom)
Hello, We have adapted the Commons parent pom (and by extension the Apache parent pom) with some changes for our internal parent pom. We are running into an issue with a combination of maven release plugin + maven bundle plugin + maven jar plugin for pom packaging projects. Is this the right mailing list for this question? E.g. $ mvn -Prelease install [INFO] [INFO] Building parent 1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @ parent --- [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] [INFO] [INFO] maven-source-plugin:2.1.2:jar (create-source-jar) @ parent [INFO] [INFO] maven-source-plugin:2.1.2:jar (create-source-jar) @ parent [INFO] [INFO] --- maven-source-plugin:2.1.2:jar (create-source-jar) @ parent --- [INFO] [INFO] maven-source-plugin:2.1.2:test-jar (create-source-jar) @ parent [INFO] [INFO] maven-source-plugin:2.1.2:test-jar (create-source-jar) @ parent [INFO] [INFO] --- maven-source-plugin:2.1.2:test-jar (create-source-jar) @ parent --- [INFO] [INFO] --- maven-jar-plugin:2.4:test-jar (default) @ parent --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] [INFO] BUILD FAILURE [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.4:test-jar (default) on project parent: Error assembling JAR: Manifest file: /xxx/parent/target/osgi/MANIFEST.MF does not exist. - [Help 1] First, source and test jars shouldn't be created for a pom packaging project, and second, the jar plugin shouldn't fail if the manifest generated by the bundle plugin isn't present. michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
JNDI? On 18/04/2012 11:39 AM, S Ahmed wrote: Yeah they are config files, I just wanted a simple way to reference them in my code, i.e: ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); InputStream is = classLoader.getResourceAsStream(config.properties); I think what I should do is reference the file based on an environmental variable, which I will set both locally and on the production server. Plus having an EV let's other projects reference things in a more uniform way. you agree? On Wed, Apr 18, 2012 at 1:26 AM, Barrie Treloarbaerr...@gmail.com wrote: On Wed, Apr 18, 2012 at 2:20 PM, Wayne Faywayne...@gmail.com wrote: I want to exclude the /resources folder from the release so it doesn't get compiled into my .jar If you can't sort out how to do this, you can always make another project, depend on the output of this one, then unpack the assembly, set your excludes there, and repack the assembly minus the files you don't want. Also, why are you putting things in src/main/resources if you dont want them in your jar? Just put them somewhere else and they wont be included. If they are needed for testing it should be src/test/resources. If they are configuration files I put them in src/main/config and then you can tell the assembly plugin to include them in the zip it builds. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 2 to 3 migration problem
Hi, I'm moving our project from maven2 to maven3. However I'm getting the following errors: https://gist.github.com/2414962 My pom.xml looks like this: https://gist.github.com/2414936 this confuses me. I was told to put versions into it everywhere but it still didn't help. Does anyone know a solution? Cheers Dan -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2-to-3-migration-problem-tp5649678p5649678.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: Question about Maven Assembly Plugin
Hi QL,
Could you please supply me with an example of a executable
jar-with-dependencies?
We build an executable JAR-with-dependencies using the assembly plugin.
There are two issues:
1) Including all the dependencies in the JAR. In your assembly descriptor,
use:
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
2) Setting the main class for the combined JAR. In your POM, use:
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorsrc/main/assembly/all.xml/descriptor
/descriptors
finalNameimagej-${project.version}/finalName
archive
manifest
mainClassimagej.Main/mainClass
/manifest
/archive
/configuration
If you want a working example, you can check the ImageJ2 codebase here:
https://github.com/imagej/imagej/blob/master/ui/app/pom.xml
https://github.com/imagej/imagej/blob/master/ui/app/src/main/assembly/all.xml
Just be warned there is a fair bit of nastiness and complexity in there
that is very unlikely to be necessary for your use case.
HTH,
Curtis
On Tue, Apr 17, 2012 at 5:23 PM, QL 983 fraterql...@gmail.com wrote:
Hi, Anders; thank you for your answer! I tried using useProjectArtifact
false, but it did not work.
Could you please supply me with an example of a executable
jar-with-dependencies?
Kind regards,
QL
On Tue, Apr 17, 2012 at 8:06 AM, Anders Hammar and...@hammar.net wrote:
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the Maven
Assembly Plugin to build a executable jar, with all dependencies inside
it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this
warning:
[WARNING] Cannot include project artifact: com.company.class; it
doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the
problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance
merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it has,
but
no code of mine is added in the jar, and I get this output in command
line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
Re: Re-Releasing Configured Artifacts, how?
I will read up some more. But, I was more wondering in regards to classifiers if I could release x3 (or more) builds of the same module (at the moment I have one module per conf, each is a war overlay). I am not a huge fan of producing multiple artifacts (thus, your suggestion of classifiers) for these types of purposes. Instead, you should think about what kinds of things you could do that would allow to produce a single artifact and then push it unchanged into your various deployment environments. There are lots of strategies to help with this problem: JNDI, Spring, other DI solutions, etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven 2 to 3 migration problem
I can help get rid of the warnings. You have the maven-antrun-plugin declared 4 times. I think what you want is 4 executions within 1 declaration. You have the maven-releases-plugin declared 2 times in your pluginManagement. As far as the error is concerned, your build doesn't seem to like the dependencyManagement.status field in the commons-httpclient pom for some reason. We use version 3.1 of that dependency with maven 3 no problem. I don't suppose the above issues are causing some kind of Maven parsing issue? Perhaps someone with more knowledge than I will jump in on that one. Matt -Original Message- From: dandart [mailto:dand...@googlemail.com] Sent: Wednesday, April 18, 2012 10:51 AM To: users@maven.apache.org Subject: Maven 2 to 3 migration problem Hi, I'm moving our project from maven2 to maven3. However I'm getting the following errors: https://gist.github.com/2414962 My pom.xml looks like this: https://gist.github.com/2414936 this confuses me. I was told to put versions into it everywhere but it still didn't help. Does anyone know a solution? Cheers Dan -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2- to-3-migration-problem-tp5649678p5649678.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 __ This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 to 3 migration problem
However I'm getting the following errors: https://gist.github.com/2414962 ... Does anyone know a solution? You pom looks like: buildplugins plugin!-- antrun -- plugin!-- antrun -- plugin!-- antrun -- and similar situation with m-exec-p. This is not supported and will make M3 complain. You need to change that into a SINGLE declaration of each plugin, and then use multiple EXECUTION nodes to specify the various configurations. While we're talking about it, how should this error message be changed to help people understand this better in the future -- it is pretty clear to me: [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ line 217, column 21 Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Doxia Sitetools 1.3 Released
The Doxia Sitetools team is pleased to announce the doxia-sitetools-1.3 release! Doxia Sitetools generates sites, consisting of static and dynamic content that was generated by Doxia. http://maven.apache.org/doxia/doxia-sitetools/ Release Notes - Maven Doxia Sitetools - Version 1.3 ** Bug * [DOXIASITETOOLS-54] - site.xml should also have title attribute for all elements that have alt attributes * [DOXIASITETOOLS-59] - Using a relative path to an image in a poweredBylogo generates a wrong src value for HTML img tag * [DOXIASITETOOLS-65] - footer declared in the site.xml is not inherited in multi-module sites * [DOXIASITETOOLS-70] - Html title of generated pages does not include project name ** Improvement * [DOXIASITETOOLS-60] - Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin() * [DOXIASITETOOLS-62] - improve breadcrumbs inheritance: if child defines an item already in parent, remove every breadcrumb item from parent after it * [DOXIASITETOOLS-63] - Make publish date configurable * [DOXIASITETOOLS-64] - Change style for menuitems to recognize the ones with a long name * [DOXIASITETOOLS-66] - Add Velocity Toolmanager support ** New Feature * [DOXIASITETOOLS-71] - Add the version of doxia-site-renderer that is used to the generated site * [DOXIASITETOOLS-72] - Allow declaring Google AdSense in site.xml ** Task * [DOXIASITETOOLS-73] - Update to Doxia base 1.3 Have fun! -Doxia Sitetools team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
The Maven site is not the most friendly place to start as a new Maven user but it is not the only resource. Perhaps the community should try to come to a consensus about the books and recommend one as the best starting point for a new user and one as the best place to find Best Practices. We may need more Maven documentation like this: http://learnpythonthehardway.org/ But no matter what is done along these lines, you will always have some nontrivial percentage of the population that doesn't have time to read all of that and just wants to make their build work right now. We can point people at books all day long but they can (and do) ignore that advice. The reality is that Maven has a bit of a learning curve and most people new to it (mostly coming from Ant) will try to mold Maven to their uses (by applying it to their existing projects and swapping Ant config for Maven plugin config line by line) instead of leveraging the great functionality out of the box (with zero config so long as you stick with those pesky conventions). I'm not sure how to help people short-circuit this learning process even WITH documentation. ESR's essay on asking the right questions is key to getting proper help on this list: http://www.catb.org/~esr/faqs/smart-questions.html#goal Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 to 3 migration problem
I'm more concerned with the parts below the snip - it appears there are two problems. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2-to-3-migration-problem-tp5649678p5649780.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Maven 2 to 3 migration problem
Yes, this will solve some of the warnings. But maybe there is an issue with php-maven too. I am wondering why php-maven complains to understand apache-httpclient dependency. Is one of your dependencies a java project? Maybe this is an issue with php-maven too that it behaves wrong with some types of dependencies. Please send me the debug output (cli option -X) directly to let me check there is nothing wrong with php-maven itself. On Wed, Apr 18, 2012 at 7:18 PM, Wayne Fay wayne...@gmail.com wrote: You pom looks like: buildplugins plugin!-- antrun -- plugin!-- antrun -- plugin!-- antrun -- and similar situation with m-exec-p. This is not supported and will make M3 complain. You need to change that into a SINGLE declaration of each plugin, and then use multiple EXECUTION nodes to specify the various configurations. While we're talking about it, how should this error message be changed to help people understand this better in the future -- it is pretty clear to me: [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-antrun-plugin @ line 217, column 21 Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
On Thu, Apr 19, 2012 at 1:09 AM, S Ahmed sahmed1...@gmail.com wrote: Yeah they are config files, I just wanted a simple way to reference them in my code, i.e: ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); InputStream is = classLoader.getResourceAsStream(config.properties); I think what I should do is reference the file based on an environmental variable, which I will set both locally and on the production server. Plus having an EV let's other projects reference things in a more uniform way. You dont want stuff that changes across different environments baked into your builds. We just add the directory ./config to the classpath and at deploy time swap in what environment settings are needed. (For runnable jars) For web apps, we use an ugly hack where the web server has a global classpath entry pointing to a config dir. The configs then get dropped in there. Both ways allow us to continue to use class loader to avoid knowing the actual location on disk. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Hi everyone, Thanks to all for the robust discussion! To Ron, I apologize if my comments sounded overly critical of you in particular. I get that you are trying to help guide people in the right direction, and it is certainly good for them to question their assumptions, and to understand the Maven basics before they go creating a rat's nest of unnecessary complexity. So I completely agree with your perspective and comments. What concerns me a bit is perhaps nitpickery: sayings like you will lose and Maven will win imply that advanced or unconventional configuration cannot be done with Maven. Of course, we all know that that is not the case. But a newbie doesn't. The ideas I personally would like to see communicated are: 1) When used properly, Maven does a *lot* of heavy lifting for you—much more than Ant. 2) Most projects can be expressed concisely in a POM by following Maven conventions. Many things that required substantial configuration with Ant etc. come largely for free with Maven. 3) When you must stray from conventions and standards, that is OK—but first be sure that you really must. And be aware that by doing so, you pay a *heavy* price. (And consider giving feedback to the maintainers of the standards you didn't use, so they can be improved in the future to encompass your use case.) Unfortunately, I haven't come up with any witty slogans along these lines... Eric Kolotyluk wrote: I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. For sure. The first time I saw that saying I thought it was pretty funny too, because I had already been through the learning curve and understood what it's trying to say. But regarding it being humor rather than fact: there is usually an element of truth in humor. We should keep in mind that newbies are coming in blind, with very little context. Some people, including very experienced developers, might read it more as a statement of fact or at least attitude that what they are trying to do is wrong, and conclude that Maven and/or its community is inflexible and inappropriate for their use, which is a shame, because as I said before Maven is actually extremely flexible and I think should be used whenever possible. :-) Wayne Fay wrote: But no matter what is done along these lines, you will always have some nontrivial percentage of the population that doesn't have time to read all of that and just wants to make their build work right now. We can point people at books all day long but they can (and do) ignore that advice. Yep, writing good documentation is really hard! I would also add: how the docs are organized is just as important as the content itself. We each have our own threshold for reading the docs versus just trying it and how the documentation is laid out will affect whether we find the answers with the limited effort we expend. Regards, Curtis On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay wayne...@gmail.com wrote: The Maven site is not the most friendly place to start as a new Maven user but it is not the only resource. Perhaps the community should try to come to a consensus about the books and recommend one as the best starting point for a new user and one as the best place to find Best Practices. We may need more Maven documentation like this: http://learnpythonthehardway.org/ But no matter what is done along these lines, you will always have some nontrivial percentage of the population that doesn't have time to read all of that and just wants to make their build work right now. We can point people at books all day long but they can (and do) ignore that advice. The reality is that Maven has a bit of a learning curve and most people new to it (mostly coming from Ant) will try to mold Maven to their uses (by applying it to their existing projects and swapping Ant config for Maven plugin config line by line) instead of leveraging the great functionality out of the box (with zero config so long as you stick with those pesky conventions). I'm not sure how to help people short-circuit this learning process even WITH documentation. ESR's essay on asking the right questions is key to getting proper help on this list: http://www.catb.org/~esr/faqs/smart-questions.html#goal Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On 18/04/2012 4:03 PM, Curtis Rueden wrote: Hi everyone, Thanks to all for the robust discussion! To Ron, I apologize if my comments sounded overly critical of you in particular. I get that you are trying to help guide people in the right direction, and it is certainly good for them to question their assumptions, and to understand the Maven basics before they go creating a rat's nest of unnecessary complexity. So I completely agree with your perspective and comments. What concerns me a bit is perhaps nitpickery: sayings like you will lose and Maven will win imply that advanced or unconventional configuration cannot be done with Maven. Of course, we all know that that is not the case. But a newbie doesn't. Point taken. I just want to make them stop long enough to think about their project's real build situation. I know that once they start to describe what they want to build rather than ask how to get past a roadblock, the technical resources here will explain how to get a build that follows Best Practices or at least known successful pattern. The ideas I personally would like to see communicated are: 1) When used properly, Maven does a *lot* of heavy lifting for you—much more than Ant. 2) Most projects can be expressed concisely in a POM by following Maven conventions. Many things that required substantial configuration with Ant etc. come largely for free with Maven. 3) When you must stray from conventions and standards, that is OK—but first be sure that you really must. And be aware that by doing so, you pay a *heavy* price. (And consider giving feedback to the maintainers of the standards you didn't use, so they can be improved in the future to encompass your use case.) Unfortunately, I haven't come up with any witty slogans along these lines... Witty does not always get you loved!!! Eric Kolotyluk wrote: I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. For sure. The first time I saw that saying I thought it was pretty funny too, because I had already been through the learning curve and understood what it's trying to say. But regarding it being humor rather than fact: there is usually an element of truth in humor. We should keep in mind that newbies are coming in blind, with very little context. Some people, including very experienced developers, might read it more as a statement of fact or at least attitude that what they are trying to do is wrong, and conclude that Maven and/or its community is inflexible and inappropriate for their use, which is a shame, because as I said before Maven is actually extremely flexible and I think should be used whenever possible. :-) Wayne Fay wrote: But no matter what is done along these lines, you will always have some nontrivial percentage of the population that doesn't have time to read all of that and just wants to make their build work right now. We can point people at books all day long but they can (and do) ignore that advice. Yep, writing good documentation is really hard! I would also add: how the docs are organized is just as important as the content itself. We each have our own threshold for reading the docs versus just trying it and how the documentation is laid out will affect whether we find the answers with the limited effort we expend. Regards, Curtis On Wed, Apr 18, 2012 at 12:33 PM, Wayne Faywayne...@gmail.com wrote: The Maven site is not the most friendly place to start as a new Maven user but it is not the only resource. Perhaps the community should try to come to a consensus about the books and recommend one as the best starting point for a new user and one as the best place to find Best Practices. We may need more Maven documentation like this: http://learnpythonthehardway.org/ But no matter what is done along these lines, you will always have some nontrivial percentage of the population that doesn't have time to read all of that and just wants to make their build work right now. We can point people at books all day long but they can (and do) ignore that advice. The reality is that Maven has a bit of a learning curve and most people new to it (mostly coming from Ant) will try to mold Maven to their uses (by applying it to their existing projects and swapping Ant config for Maven plugin config line by line) instead of leveraging the great functionality out of the box (with zero config so long as you stick with those pesky conventions). I'm not sure how to help people short-circuit this learning process even WITH documentation. ESR's essay on asking the right questions is key to getting proper help on this list: http://www.catb.org/~esr/faqs/smart-questions.html#goal Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact - when using mvn 3.0.4 (works with mvn 3.0.3!)
Plugin org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its dependencies could not be resolved: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo I'm not sure... but could this be related to one of these JIRAs? http://jira.codehaus.org/browse/MNG-5029 http://jira.codehaus.org/browse/MNG-5181 http://jira.codehaus.org/browse/MNG-5185 Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
The problem I was having was, when on the production server, I had a properties file in my /resources folder, and I modified in on the server but noticed it was still returning the old values. I then realized that the class loader was loading the file from the .jar itself, and not reading from the file (even though the file was updated to reflect production settings). On Wed, Apr 18, 2012 at 3:51 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Apr 19, 2012 at 1:09 AM, S Ahmed sahmed1...@gmail.com wrote: Yeah they are config files, I just wanted a simple way to reference them in my code, i.e: ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); InputStream is = classLoader.getResourceAsStream(config.properties); I think what I should do is reference the file based on an environmental variable, which I will set both locally and on the production server. Plus having an EV let's other projects reference things in a more uniform way. You dont want stuff that changes across different environments baked into your builds. We just add the directory ./config to the classpath and at deploy time swap in what environment settings are needed. (For runnable jars) For web apps, we use an ugly hack where the web server has a global classpath entry pointing to a config dir. The configs then get dropped in there. Both ways allow us to continue to use class loader to avoid knowing the actual location on disk. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
resolver-status.properties read/write warnings
When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see numerous lines of output similar to below. I added a mac box to my build farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build doesn't fail but the log is seriously bloated. If I move the same build to a red hat or windows box in my build farm I don't see any such warnings. In this particular case I am simply running mvn help:effective-settings [WARNING] Failed to read resolution tracking file /Volumes/sharedrepo/repository/org/codehaus/sonar/resolver-status.properties java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileManager.java:209) at org.sonatype.aether.impl.internal.TrackingFileManager.read(TrackingFileManager.java:62) at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:478) at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkMetadata(DefaultUpdateCheckManager.java:244) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:299) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:177) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveMetadata(DefaultRepositorySystem.java:338) at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolveFromRepository(DefaultPluginPrefixResolver.java:185) at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:90) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:262) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:222) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Any pointers appreciated Thanks
Re: The Maven Way
On 2012-04-18 1:03 PM, Curtis Rueden wrote: Hi everyone, Thanks to all for the robust discussion! To Ron, I apologize if my comments sounded overly critical of you in particular. I get that you are trying to help guide people in the right direction, and it is certainly good for them to question their assumptions, and to understand the Maven basics before they go creating a rat's nest of unnecessary complexity. So I completely agree with your perspective and comments. What concerns me a bit is perhaps nitpickery: sayings like you will lose and Maven will win imply that advanced or unconventional configuration cannot be done with Maven. Of course, we all know that that is not the case. But a newbie doesn't. The ideas I personally would like to see communicated are: 1) When used properly, Maven does a *lot* of heavy lifting for you—much more than Ant. 2) Most projects can be expressed concisely in a POM by following Maven conventions. Many things that required substantial configuration with Ant etc. come largely for free with Maven. 3) When you must stray from conventions and standards, that is OK—but first be sure that you really must. And be aware that by doing so, you pay a *heavy* price. (And consider giving feedback to the maintainers of the standards you didn't use, so they can be improved in the future to encompass your use case.) Unfortunately, I haven't come up with any witty slogans along these lines... Eric Kolotyluk wrote: I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. For sure. The first time I saw that saying I thought it was pretty funny too, because I had already been through the learning curve and understood what it's trying to say. But regarding it being humor rather than fact: there is usually an element of truth in humor. We should keep in mind that newbies are coming in blind, with very little context. Some people, including very experienced developers, might read it more as a statement of fact or at least attitude that what they are trying to do is wrong, and conclude that Maven and/or its community is inflexible and inappropriate for their use, which is a shame, because as I said before Maven is actually extremely flexible and I think should be used whenever possible. :-) Humor is in fact 'art' and we all experience art differently - but the community we hang out with influences how we experience it. Thank goodness there are many people in the Maven community with a sense of humor or I could have gone insane %-) Maven is in fact a lot about attitude, and learning this was perhaps the hardest thing for me to understand. Coming from a background of 'make' and then 'ant' I simply had the wrong attitude about developing software. I mean the word 'wrong' sincerely because Maven is what I always wanted in the end, and 'make' and 'ant' are simply tools I used and attitudes about software development were the state-of-the-art at the time. I also mean the word 'wrong' personally because it is not for me to tell other people not to use make, ant, or any other tool they are most comfortable with. But I will evangelize Maven as much as I can until something better comes along. I started out hating Maven vehemently - it was because I was trying to learn various new technologies such as Hibernate, and I simply could not find any simple hello world examples of how to get started that did not require having to first learn to use Maven. There are just too many people who casually assume everyone should learn to use Maven - be dammed if you can't - and I still find that terribly offensive. Weeks later after I had finished my research and assessment of new technologies, and I had calmed down, I decided to investigate Maven simply because of the ubiquitous evangelizing I found in my travels - if Maven has so many fans I simply have to see what all the hype is about. After choosing to adopt Maven for a new project I then spent 6 months hurting myself because I was convinced I could simply learn Maven on my own - my own arrogance that I could figure it out on my own - and taking shortcuts was ok. After finally taking the Sonatype training courses suddenly most of the pain went away and I was left with a Maven I can now rave about - and still complain about (but more articulately now). Maven is one of the most powerful software development tools I have ever come across - and one thing I know about 'power tools' is that for the untrained then can be very painful. Maven is also a club, a culture a community - a very welcoming community - and the first thing beginners should learn about Maven, is to engage the community. The single most important thing about Maven is users@maven.apache.org Wayne Fay wrote: But no matter what is done along these lines, you will always have some nontrivial percentage of
Re: The Maven Way
Part of the reason, I believe, is because those conventions are not carved in stone. There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary And over time these conventions (or philosophies) change as we gain more experience. There is stuff you can do in profiles that is considered exceptionally bad practice. There is some move at apache to get the web sites onto some CMS system. I really don't know the details. I think at the moment it can be backed by SVN. This may make it easier for people to make changes without having to checkout the website first, etc. So the barrier to creating some of this great advice may become lower. I think another reason that the information isn't available is that people don't recognise what is wrong with their mental model and when they have that aha moment can no longer articulate how they went from the wrong to correct mental model to explain to other people. And there is less incentive to do so because they know it now. You only have to look at all the threads on the internet that have a question, answers from other people, and either no response from the original poster to say whether they worked or they reply with thanks, works now with no bloody details! I know that in six months time I will eventually be revisiting this piece of knowledge so I try to ensure it gets put back on the internet somewhere for google to find. Because I can guarantee I will be searching for it again at some later point. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On Thu, Apr 19, 2012 at 9:02 AM, Barrie Treloar baerr...@gmail.com wrote: Part of the reason, I believe, is because those conventions are not carved in stone. There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary And over time these conventions (or philosophies) change as we gain more experience. Added this into JIRA https://jira.codehaus.org/browse/MNG-5277 If you are tracking the dev list as well it should pop up in the weekly [jira] Subscription: Design Best Practices email. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Eric, I remember when you first started visiting the forum. As you described, you came with some pretty strong views about how Maven should work. I do remember how carefully and well, you sought out advice from the people here. In spite of your strong feelings that you were an experienced developer, you actively sought out advice from the forum and were extremely flexible in adopting the advice that you got. It was fun to watch your progress as you advanced through your conversion. Ron On 18/04/2012 6:59 PM, Eric Kolotyluk wrote: On 2012-04-18 1:03 PM, Curtis Rueden wrote: Hi everyone, Thanks to all for the robust discussion! To Ron, I apologize if my comments sounded overly critical of you in particular. I get that you are trying to help guide people in the right direction, and it is certainly good for them to question their assumptions, and to understand the Maven basics before they go creating a rat's nest of unnecessary complexity. So I completely agree with your perspective and comments. What concerns me a bit is perhaps nitpickery: sayings like you will lose and Maven will win imply that advanced or unconventional configuration cannot be done with Maven. Of course, we all know that that is not the case. But a newbie doesn't. The ideas I personally would like to see communicated are: 1) When used properly, Maven does a *lot* of heavy lifting for you—much more than Ant. 2) Most projects can be expressed concisely in a POM by following Maven conventions. Many things that required substantial configuration with Ant etc. come largely for free with Maven. 3) When you must stray from conventions and standards, that is OK—but first be sure that you really must. And be aware that by doing so, you pay a *heavy* price. (And consider giving feedback to the maintainers of the standards you didn't use, so they can be improved in the future to encompass your use case.) Unfortunately, I haven't come up with any witty slogans along these lines... Eric Kolotyluk wrote: I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. For sure. The first time I saw that saying I thought it was pretty funny too, because I had already been through the learning curve and understood what it's trying to say. But regarding it being humor rather than fact: there is usually an element of truth in humor. We should keep in mind that newbies are coming in blind, with very little context. Some people, including very experienced developers, might read it more as a statement of fact or at least attitude that what they are trying to do is wrong, and conclude that Maven and/or its community is inflexible and inappropriate for their use, which is a shame, because as I said before Maven is actually extremely flexible and I think should be used whenever possible. :-) Humor is in fact 'art' and we all experience art differently - but the community we hang out with influences how we experience it. Thank goodness there are many people in the Maven community with a sense of humor or I could have gone insane %-) Maven is in fact a lot about attitude, and learning this was perhaps the hardest thing for me to understand. Coming from a background of 'make' and then 'ant' I simply had the wrong attitude about developing software. I mean the word 'wrong' sincerely because Maven is what I always wanted in the end, and 'make' and 'ant' are simply tools I used and attitudes about software development were the state-of-the-art at the time. I also mean the word 'wrong' personally because it is not for me to tell other people not to use make, ant, or any other tool they are most comfortable with. But I will evangelize Maven as much as I can until something better comes along. I started out hating Maven vehemently - it was because I was trying to learn various new technologies such as Hibernate, and I simply could not find any simple hello world examples of how to get started that did not require having to first learn to use Maven. There are just too many people who casually assume everyone should learn to use Maven - be dammed if you can't - and I still find that terribly offensive. Weeks later after I had finished my research and assessment of new technologies, and I had calmed down, I decided to investigate Maven simply because of the ubiquitous evangelizing I found in my travels - if Maven has so many fans I simply have to see what all the hype is about. After choosing to adopt Maven for a new project I then spent 6 months hurting myself because I was convinced I could simply learn Maven on my own - my own arrogance that I could figure it out on my own - and taking shortcuts was ok. After finally taking the Sonatype training courses suddenly most of the pain went away and I was left with a Maven I can now rave about - and still complain
Re: resolver-status.properties read/write warnings
It seems you are using a shared local repository which is not supported Jeff Le 18 avr. 2012 23:56, Bracewell, Robert rbrac...@qualcomm.com a écrit : When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see numerous lines of output similar to below. I added a mac box to my build farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build doesn't fail but the log is seriously bloated. If I move the same build to a red hat or windows box in my build farm I don't see any such warnings. In this particular case I am simply running mvn help:effective-settings [WARNING] Failed to read resolution tracking file /Volumes/sharedrepo/repository/org/codehaus/sonar/resolver-status.properties java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileManager.java:209) at org.sonatype.aether.impl.internal.TrackingFileManager.read(TrackingFileManager.java:62) at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:478) at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkMetadata(DefaultUpdateCheckManager.java:244) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:299) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:177) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveMetadata(DefaultRepositorySystem.java:338) at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolveFromRepository(DefaultPluginPrefixResolver.java:185) at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:90) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:262) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:222) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Any pointers appreciated Thanks
Re: The Maven Way
Thanks - it has been one of the more interesting adventures in my professional life :-) Cheers, Eric On 2012-04-18 4:37 PM, Ron Wheeler wrote: Eric, I remember when you first started visiting the forum. As you described, you came with some pretty strong views about how Maven should work. I do remember how carefully and well, you sought out advice from the people here. In spite of your strong feelings that you were an experienced developer, you actively sought out advice from the forum and were extremely flexible in adopting the advice that you got. It was fun to watch your progress as you advanced through your conversion. Ron On 18/04/2012 6:59 PM, Eric Kolotyluk wrote: On 2012-04-18 1:03 PM, Curtis Rueden wrote: Hi everyone, Thanks to all for the robust discussion! To Ron, I apologize if my comments sounded overly critical of you in particular. I get that you are trying to help guide people in the right direction, and it is certainly good for them to question their assumptions, and to understand the Maven basics before they go creating a rat's nest of unnecessary complexity. So I completely agree with your perspective and comments. What concerns me a bit is perhaps nitpickery: sayings like you will lose and Maven will win imply that advanced or unconventional configuration cannot be done with Maven. Of course, we all know that that is not the case. But a newbie doesn't. The ideas I personally would like to see communicated are: 1) When used properly, Maven does a *lot* of heavy lifting for you—much more than Ant. 2) Most projects can be expressed concisely in a POM by following Maven conventions. Many things that required substantial configuration with Ant etc. come largely for free with Maven. 3) When you must stray from conventions and standards, that is OK—but first be sure that you really must. And be aware that by doing so, you pay a *heavy* price. (And consider giving feedback to the maintainers of the standards you didn't use, so they can be improved in the future to encompass your use case.) Unfortunately, I haven't come up with any witty slogans along these lines... Eric Kolotyluk wrote: I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. For sure. The first time I saw that saying I thought it was pretty funny too, because I had already been through the learning curve and understood what it's trying to say. But regarding it being humor rather than fact: there is usually an element of truth in humor. We should keep in mind that newbies are coming in blind, with very little context. Some people, including very experienced developers, might read it more as a statement of fact or at least attitude that what they are trying to do is wrong, and conclude that Maven and/or its community is inflexible and inappropriate for their use, which is a shame, because as I said before Maven is actually extremely flexible and I think should be used whenever possible. :-) Humor is in fact 'art' and we all experience art differently - but the community we hang out with influences how we experience it. Thank goodness there are many people in the Maven community with a sense of humor or I could have gone insane %-) Maven is in fact a lot about attitude, and learning this was perhaps the hardest thing for me to understand. Coming from a background of 'make' and then 'ant' I simply had the wrong attitude about developing software. I mean the word 'wrong' sincerely because Maven is what I always wanted in the end, and 'make' and 'ant' are simply tools I used and attitudes about software development were the state-of-the-art at the time. I also mean the word 'wrong' personally because it is not for me to tell other people not to use make, ant, or any other tool they are most comfortable with. But I will evangelize Maven as much as I can until something better comes along. I started out hating Maven vehemently - it was because I was trying to learn various new technologies such as Hibernate, and I simply could not find any simple hello world examples of how to get started that did not require having to first learn to use Maven. There are just too many people who casually assume everyone should learn to use Maven - be dammed if you can't - and I still find that terribly offensive. Weeks later after I had finished my research and assessment of new technologies, and I had calmed down, I decided to investigate Maven simply because of the ubiquitous evangelizing I found in my travels - if Maven has so many fans I simply have to see what all the hype is about. After choosing to adopt Maven for a new project I then spent 6 months hurting myself because I was convinced I could simply learn Maven on my own - my own arrogance that I could figure it out on my own - and taking shortcuts was ok. After
Re: exclude folders during mvn assembly
On Thu, Apr 19, 2012 at 6:44 AM, S Ahmed sahmed1...@gmail.com wrote: The problem I was having was, when on the production server, I had a properties file in my /resources folder, and I modified in on the server but noticed it was still returning the old values. I then realized that the class loader was loading the file from the .jar itself, and not reading from the file (even though the file was updated to reflect production settings). Read up on classpath resolution rules. Your file in the *.jar is trumping the one in the directory. The other sin to commit is including a log4j settings file in your jar. :) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: resolver-status.properties read/write warnings
farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build ... It seems you are using a shared local repository which is not supported Agreed on this point. You must use a local repo cache on each machine. And you should ensure that you only have 1 Maven instance access eaching local repo cache at once as well. If you're using Jenkins/Hudson, this is simple to configure. When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see What version of Java are you running? java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileManager.java:209) This stacktrace suggests to me that your OS does not support file locking over NFS? Look at sun.nio.ch.FileChannelImpl for more info. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re-Releasing Configured Artifacts, how?
I have looked into several options.
Assembly with Qualifiers (new module):
Looks good because I can run multiple executions, each with a unique
filtersomefile.property/filter. However I can't re-use the same
assembly description because the classifier is now obatined from the id
in the assembly descriptor :'( . That kinda sucks, it means I would have to
duplicate the assembly xml for each target classified artifact (or
copy/filter/rename the assembly xml during a gererate-sources or similar).
IMHO, this is not the best solution.
Profiles:
Only allow one build property set to exist, and thus each build can't use
filtering on the config. For this reason the resulting duplication and
deviation on each build would introduce bloat and increase the likelyhood
of breakage.
War Overlays :
This is (unfortunately) the best solution I have.
+acme (pom)
++acme-webapp (war) --- all config options remain as ${someProperty} (ie.
No Filtering here!)
++acme-webapp-overlay (pom)
++acme-webapp-overlay-dev (war)
++acme-webapp-overlay-uat (war)
++acme-webapp-overlay-prod (war)
The acme-webapp-overlay will configure the
plugin...artifactIdmaven-war-plugin/artifactIdoverlays... (as well
as configure a dependecy too acme-webapp) the and each child module
(dev,uat,prod) provides their properties, which will filter selected
parts of acme-webapp (war) as it is overlayed.
This works, but I'm over it :)~
Thanks for all the advice
On Thu, Apr 19, 2012 at 2:38 AM, Wayne Fay wayne...@gmail.com wrote:
I will read up some more. But, I was more wondering in regards to
classifiers if I could release x3 (or more) builds of the same module (at
the moment I have one module per conf, each is a war overlay).
I am not a huge fan of producing multiple artifacts (thus, your
suggestion of classifiers) for these types of purposes.
Instead, you should think about what kinds of things you could do that
would allow to produce a single artifact and then push it unchanged
into your various deployment environments. There are lots of
strategies to help with this problem: JNDI, Spring, other DI
solutions, etc.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: resolver-status.properties read/write warnings
I wasn't aware that a shared local repo wasn't supported. I just switched over all nodes to a local repo throughout the build farm and the warnings did indeed disappear. Version of Java used on this particular OSX node is java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) Thanks, Robert On 4/18/12 6:44 PM, Wayne Fay wayne...@gmail.com wrote: farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build ... It seems you are using a shared local repository which is not supported Agreed on this point. You must use a local repo cache on each machine. And you should ensure that you only have 1 Maven instance access eaching local repo cache at once as well. If you're using Jenkins/Hudson, this is simple to configure. When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see What version of Java are you running? java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileM anager.java:209) This stacktrace suggests to me that your OS does not support file locking over NFS? Look at sun.nio.ch.FileChannelImpl for more info. 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: resolver-status.properties read/write warnings
Separate repos work. If you absolutely needed a concurrent safe local repo there's one here: https://github.com/etesla/tesla-concurrent-localrepo On Apr 18, 2012, at 10:03 PM, Bracewell, Robert wrote: I wasn't aware that a shared local repo wasn't supported. I just switched over all nodes to a local repo throughout the build farm and the warnings did indeed disappear. Version of Java used on this particular OSX node is java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) Thanks, Robert On 4/18/12 6:44 PM, Wayne Fay wayne...@gmail.com wrote: farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build ... It seems you are using a shared local repository which is not supported Agreed on this point. You must use a local repo cache on each machine. And you should ensure that you only have 1 Maven instance access eaching local repo cache at once as well. If you're using Jenkins/Hudson, this is simple to configure. When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see What version of Java are you running? java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileM anager.java:209) This stacktrace suggests to me that your OS does not support file locking over NFS? Look at sun.nio.ch.FileChannelImpl for more info. 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare
Re: Re-Releasing Configured Artifacts, how?
I am not sure that these were the options suggested by Wayne.
It appears that you are building a very common type of application that
hundreds of people build with Maven.
A lot of people use Spring which has dynamic configuration.
Web services have endpoint definitions.
Most applications have some sort of database that has run-time information.
The problem of injecting run-time information into webapps is well known
and Wayne gave you some Best Practices.
One of the key principles of building reliable systems is that you
should take what you have tested in your test environment and run it
unaltered in production.
Rebuilding the artifact after testing it, puts you in the position of
putting something into production that is new and untested.
Wayne suggested some alternatives.
We used JNDI and I documented this in 2 blog articles:
http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58
Your approach is not a Best Practice.
Part of the reason that it is difficult to do under Maven is that it
should not be done this way.
The developers should not have any interest in the run-time environment
and should produce code that runs unaltered in any properly setup
environment.
If the system administrator changes an IP address or a database
password, he should be able to change the information in the system in
one place without having to ask the developer to produce a new application.
This should be well documented in the applications installation and
system administration procedures.
Database passwords, IP addresses, hostnames, etc. are not the concern of
a developer. These are under the control of the system administrator.
If the developer builds run-time environment information into the
application, the system administrator's changes will get overwritten
with each new release.
This could result in a nasty surprise when the application restarts.
If you are wearing both hats, you need to be aware of which role you are
performing at any given time and build your application so that it
respects the roles.
This is a universal problem and Wayne identified several ways to fix
this easily.
As you may be able to gather from my notes, we also went through the
process that you are grappling with before we got some good advice and
did the right thing.
It was very easy to do it right and once we had the first run-time stuff
into JNDI, it was easy to see how to handle each new issue.
We started with database and then added web services endpoints and other
properties.
I hope that this helps.
Ron
On 19/04/2012 12:33 AM, Andrew Hughes wrote:
I have looked into several options.
Assembly with Qualifiers (new module):
Looks good because I can run multipleexecutions, each with a unique
filtersomefile.property/filter. However I can't re-use the same
assembly description because the classifier is now obatined from theid
in the assembly descriptor :'( . That kinda sucks, it means I would have to
duplicate the assembly xml for each target classified artifact (or
copy/filter/rename the assembly xml during a gererate-sources or similar).
IMHO, this is not the best solution.
Profiles:
Only allow one build property set to exist, and thus each build can't use
filtering on the config. For this reason the resulting duplication and
deviation on each build would introduce bloat and increase the likelyhood
of breakage.
War Overlays :
This is (unfortunately) the best solution I have.
+acme (pom)
++acme-webapp (war)--- all config options remain as ${someProperty} (ie.
No Filtering here!)
++acme-webapp-overlay (pom)
++acme-webapp-overlay-dev (war)
++acme-webapp-overlay-uat (war)
++acme-webapp-overlay-prod (war)
The acme-webapp-overlay will configure the
plugin...artifactIdmaven-war-plugin/artifactIdoverlays... (as well
as configure a dependecy too acme-webapp) the and each child module
(dev,uat,prod) provides theirproperties, which will filter selected
parts of acme-webapp (war) as it is overlayed.
This works, but I'm over it :)~
Thanks for all the advice
On Thu, Apr 19, 2012 at 2:38 AM, Wayne Faywayne...@gmail.com wrote:
I will read up some more. But, I was more wondering in regards to
classifiers if I could release x3 (or more) builds of the same module (at
the moment I have one module per conf, each is a war overlay).
I am not a huge fan of producing multiple artifacts (thus, your
suggestion of classifiers) for these types of purposes.
Instead, you should think about what kinds of things you could do that
would allow to produce a single artifact and then push it unchanged
into your various deployment environments. There are lots of
strategies to help with this problem: JNDI, Spring, other DI
solutions, etc.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software
