Re: exclude folders during mvn assembly
I am deploying artifacts with configuration files as well. I have different config files for each production server, so I am creating a different artifact for each production server with the proper config files. I create a generic war and then overlay it, adding the config files for each production site. Just a thought for you. On Wed, Apr 18, 2012 at 2:14 PM, 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). 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
maven-invoker-plugin with groovy pre/post build scripts results in The pre-build script did not succeed. PermGen space
Hi I have a setup with a bunch of integration tests where each test has a pre- and post-build script in groovy. During the maven-invoker-plugin:run a number of first tests runs ok and then it starts to produce error with the The pre-build script did not succeed. PermGen space message. I am using -XX:MaxPermSize option to run the Maven with a bigger PermGen, but it is somewhat cumbersome to remember to use it during integration tests. Is there some way to embed the -XX:MaxPermSize option inside the pom that declares maven-invoker-plugin? Or is there some way to ask maven-invoker-plugin or groovy to unload/gc pre/post scripts from the already run tests? Oleg - 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
Is one of your dependencies a java project? Yes - we use: net.java.dev.jets3t/jets3t net.java.dev.jets3t/synchronize 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. Hi, Here is the affected portion with -X: https://gist.github.com/2419599 Cheers Dan -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2-to-3-migration-problem-tp5649678p5651187.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: Re-Releasing Configured Artifacts, how?
My app uses CDI (Weld), I know all about DI. I agree with you both :)
We would rather re-release (a new) version (not snapshot). If we want to we
can always change a deployment at runtime if we choose.
Cheers
On 19/04/2012 3:22 PM, Ron Wheeler rwhee...@artifact-software.com wrote:
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=150http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.**com/tech/?p=58http://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/artifactId**overlays...
(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
Re: exclude folders during mvn assembly
Barrie, Yes I noticed both of those issues :) So what do you suggest? Should I create a new maven module called Config and drop my properties, log4net properties files there? I then add that module as a dependancy. Also, during my production build, I will just make sure I have that folder to my classpath right? In my java code, since I was assuming it was in my /resources before, and now it is in a seperate maven module, will I need to change anything or since it is still in my classpath all is good, the ONLY difference now is that it won't be embedded in my .jar right? I am really getting confused by this, I need someone to clarify this as its confusing me :) On Wed, Apr 18, 2012 at 8:19 PM, Barrie Treloar baerr...@gmail.com wrote: 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: variable to reference parent pom path?
Since this module just has files in it, what kind of packaging type should
it be?
I'm getting b/c it is currently set as a packaging type of jar, what should
it be?
On Wed, Apr 18, 2012 at 12:34 PM, Wayne Fay wayne...@gmail.com wrote:
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
Re: Re-Releasing Configured Artifacts, how?
On 19/04/2012 6:40 AM, Andrew Hughes wrote:
My app uses CDI (Weld), I know all about DI. I agree with you both :)
We would rather re-release (a new) version (not snapshot). If we want to we
can always change a deployment at runtime if we choose.
I am not sure what you mean by this.
Cheers
On 19/04/2012 3:22 PM, Ron Wheelerrwhee...@artifact-software.com wrote:
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=150http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.**com/tech/?p=58http://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/artifactId**overlays...
(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
Re: Maven 2 to 3 migration problem
I see. You are using the java dependencies for build plugins? Otherwise this won't make any sense. Dependencies for build plugins should be defined alongside the build plugin itself and not at the regular dependencies. The top level dependencies tag is used for the project dependencies. See http://maven.apache.org/pom.html#Plugins for details. Although I will try to fix php-maven you should change this in your pom file and retry. Some other remarks: jar dependencies are working with php-maven 2.0 but you may change them to phar dependencies of the php-maven repository. For example: http://nexus.php-maven.org/index.html#nexus-search;gav~de.phpunit~PHPUnitkw,versionexpand(synchronized fdaily with official phpunit pear channel) http://nexus.php-maven.org/index.html#nexus-search;gav~com.zend.framework~frameworkkw,versionexpand(synchronized daily with zend homepage) On Thu, Apr 19, 2012 at 10:21 AM, dandart dand...@googlemail.com wrote: Is one of your dependencies a java project? Yes - we use: net.java.dev.jets3t/jets3t net.java.dev.jets3t/synchronize 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. Hi, Here is the affected portion with -X: https://gist.github.com/2419599 Cheers Dan -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2-to-3-migration-problem-tp5649678p5651187.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: exclude folders during mvn assembly
On Thu, Apr 19, 2012 at 8:26 PM, S Ahmed sahmed1...@gmail.com wrote: So what do you suggest? Should I create a new maven module called Config and drop my properties, log4net properties files there? I then add that module as a dependancy. Also, during my production build, I will just make sure I have that folder to my classpath right? In my java code, since I was assuming it was in my /resources before, and now it is in a seperate maven module, will I need to change anything or since it is still in my classpath all is good, the ONLY difference now is that it won't be embedded in my .jar right? I am really getting confused by this, I need someone to clarify this as its confusing me :) Read http://maven.40175.n5.nabble.com/Re-Releasing-Configured-Artifacts-how-tp5648372p5650944.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
goal to check snapshot dependencies
hello everybody, I want to check if my project contain snapshot dependencies exactly like in the release:prepare goal. This goal is bind with a phase called check-dependency-snapshots. How can i only do that ? Must I make a specific mojo with the class CheckDependencySnapshotsPhase ? thanks for your answers... arnaud -- View this message in context: http://maven.40175.n5.nabble.com/goal-to-check-snapshot-dependencies-tp5651614p5651614.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: goal to check snapshot dependencies
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html On 19 April 2012 13:33, kenito a...@sneda.fr wrote: hello everybody, I want to check if my project contain snapshot dependencies exactly like in the release:prepare goal. This goal is bind with a phase called check-dependency-snapshots. How can i only do that ? Must I make a specific mojo with the class CheckDependencySnapshotsPhase ? thanks for your answers... arnaud -- View this message in context: http://maven.40175.n5.nabble.com/goal-to-check-snapshot-dependencies-tp5651614p5651614.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: goal to check snapshot dependencies
oh yes I forgot the renforcer plugin. thanks! -- View this message in context: http://maven.40175.n5.nabble.com/goal-to-check-snapshot-dependencies-tp5651614p5651710.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: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact - when using mvn 3.0.4 (works with mvn 3.0.3!)
Hey, I'm not exactly sure I'll take a look at the tickets, But I know the problem is definitely related to Aether version, I checked out maven trunk and changed Aether from ver 1.13.1 to 1.12 and everything works just fine! that means it's probably a bug introduced in Aether 1.13 and above. How do I proceed ? Thanks, Asaf. On Thu, Apr 19, 2012 at 12:01 AM, Wayne Fay wayne...@gmail.com wrote: 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
mvn release:prepare maven-scm-provider-javasvn fails with SVN 1.7.3 Subversion Server
Hello to all, i have a question concerning creating releases via the maven-scm-provider-javasvn: I have the following configuration in a pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId version1.6/version configuration providerImplementations svnjavasvn/svn /providerImplementations /configuration dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.15/version /dependency dependency groupIdorg.tmatesoft.svnkit/groupId artifactIdsvnkit/artifactId version1.3.5/version /dependency /dependencies /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.2.2/version configuration autoVersionSubmodulestrue/autoVersionSubmodules providerImplementations svnjavasvn/svn /providerImplementations /configuration dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.15/version /dependency dependency groupIdorg.tmatesoft.svnkit/groupId artifactIdsvnkit/artifactId version1.3.5/version /dependency /dependencies /plugin The point is this configuration worked with a 1.6.17 Subversion server but after an update to 1.7.3 it produces problem and didn't work. The tagging of the release:prepare goal fails.. We have configured the scm part with developerConnection/connnection like this: scm:svn:http://server:port/svn/repo/Project/path/trunk The url which is shown during the failure of the tagging looks like the following: /Project/path/trunk/Project/path/trunk We are using 1.6 working copies. This is done by a build server but i have tested that as well with SVN 1.6.17 on command line on Windows ...with the same result... I know the entry http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/issues/detail?id=9 but the problem here is that svnkit 1.7.4 is currently not available in Maven Central..(Already asked the SVNKit people).. Does someone have any idea about that problem ? Many thanks in advance... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Aggregate changelog of dependencies
We are looking into an automated way to get a changelog of all our libraries between releases. Clearly, the maven-changelog-plugin is great for that on an individual project (perhaps coupled with maven-changes-plugin, if only it supported a Bugzilla report...). Has there ever been any talk of deploying the changelog as a separate artifact so that a dependent project can include those changes in its own changelog? Our company has many internal libraries that are shared across many projects (hence most are not multi-module monoliths where a single changelog is possible). For our purposes, we would likely only want to have a changelog of our internal dependencies (easy to filter based on groupId). Would anyone else be interested in such a feature, if we were to implement it either as a submission to the maven-changelog-plugin or as a separate plugin? The trick, of course, is keeping track of what dependency versions have changed, and handling that multiple versions of a library may have been released in between a release of the top-level project. I imagine getting the previous release pom from Nexus, parsing the dependency versions, and then fetching all the changelogs for those intermediate versions. I suspect most projects do this sort of thing by using the maven-changes-plugin and each bug being cross-listed, if it affects multiple projects. And new features are also listed as issues, which are completed in a version as well. So perhaps that is the direction we should head, but I thought I would ask about changelog's too. -Ben -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
Re: exclude folders during mvn assembly
Barrie, I see, ok I'm looking into the JNDI method. I'm hosting this app in both tomcat and jetty. Could I put this dndi file in my class path so I don't have to hard code the location, or does it have to be in the servlet container? i.e. jetty or tomcat My jetty instance is an embedded instance... On Thu, Apr 19, 2012 at 8:16 AM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Apr 19, 2012 at 8:26 PM, S Ahmed sahmed1...@gmail.com wrote: So what do you suggest? Should I create a new maven module called Config and drop my properties, log4net properties files there? I then add that module as a dependancy. Also, during my production build, I will just make sure I have that folder to my classpath right? In my java code, since I was assuming it was in my /resources before, and now it is in a seperate maven module, will I need to change anything or since it is still in my classpath all is good, the ONLY difference now is that it won't be embedded in my .jar right? I am really getting confused by this, I need someone to clarify this as its confusing me :) Read http://maven.40175.n5.nabble.com/Re-Releasing-Configured-Artifacts-how-tp5648372p5650944.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Zero configuration? Really?
mwood@mhw ~ $ mkdir testmvn
mwood@mhw ~ $ cd testmvn
mwood@mhw ~/testmvn $ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [install]
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot execute mojo: resources. It requires a project with an
existing pom.xml, but the build is not using one.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Apr 19 08:48:32 EDT 2012
[INFO] Final Memory: 5M/75M
[INFO]
So I need to write a POM. I hear that Maven can do that for me:
mwood@mhw ~/testmvn $ mvn archetype:generate
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [archetype:generate] (aggregator-style)
[INFO]
[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [archetype:generate {execution: default-cli}]
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
[long list]
Choose a number:
(1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41)
15: :
[It doesn't know which archetype I want. Fair enough.]
[INFO] artifact
org.apache.maven.archetypes:maven-archetype-quickstart: checking for
updates from central
Define value for groupId: : edu.iupui.ulib
Define value for artifactId: : testmvn
Define value for version: 1.0-SNAPSHOT: :
[Maven does not supply GAV coordinates. I have to configure them. Of
course I do -- how could it possibly know them until I tell it?]
Define value for package: edu.iupui.ulib: :
[A reasonable guess.]
Confirm properties configuration:
groupId: edu.iupui.ulib
artifactId: testmvn
version: 1.0-SNAPSHOT
package: edu.iupui.ulib
Y: : y
[INFO]
[INFO] Using following parameters for creating OldArchetype:
maven-archetype-quickstart:RELEASE
[INFO]
[INFO] Parameter: groupId, Value: edu.iupui.ulib
[INFO] Parameter: packageName, Value: edu.iupui.ulib
[INFO] Parameter: package, Value: edu.iupui.ulib
[INFO] Parameter: artifactId, Value: testmvn
[INFO] Parameter: basedir, Value: /home/mwood/testmvn
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] * End of debug info from resources from
generated POM ***
[INFO] OldArchetype created in dir: /home/mwood/testmvn/testmvn
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 minute 48 seconds
[INFO] Finished at: Thu Apr 19 08:51:33 EDT 2012
[INFO] Final Memory: 14M/173M
[INFO]
That's quite a bit more than zero:
mwood@mhw ~/testmvn/testmvn $ ls -l pom.xml
-rw-r--r-- 1 mwood mwood 750 Apr 19 08:51 pom.xml
You could try doing it yourself:
mwood@mhw ~/testmvn/testmvn $ echo project/ pom.xml
but you'll generate a FATAL ERROR. Not a v4.0.0 POM. It must be
configured.
Returning to the generated configured POM, 'mvn deploy' chugs along
quite well for a bit and then dies because it doesn't know where the
repository is. Of course it doesn't. You have to configure it. It's
nice enough to give you ten lines of POM template XML, but it can't
know what goes between the tags.
'mvn site:deploy' also doesn't know how to distribute the site. You
have to configure it. In two different files. In two
Re: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact - when using mvn 3.0.4 (works with mvn 3.0.3!)
But I know the problem is definitely related to Aether version, I checked out maven trunk and changed Aether from ver 1.13.1 to 1.12 and everything works just fine! that means it's probably a bug introduced in Aether 1.13 and above. Aether is produced by Sonatype so I would report the issue in their bug tracker: https://issues.sonatype.org/browse/AETHER But that page says Aether is now under Eclipse Foundation, and to use their Bugzilla: https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specificorder=relevance+descbug_status=__open__product=Aether So, I guess that is where to go next... Wayne - 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?
Since this module just has files in it, what kind of packaging type should it be? In all likelihood, it should be a jar packaged project. But if it is a parent, then you should leave the parent as a pom and make a new module under the parent of type jar that holds these files. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Why Maven is looking for maven-surefire-plugin:2.10?
[WARNING] The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.10 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 12.407s [INFO] Finished at: Thu Apr 19 10:57:17 EDT 2012 [INFO] Final Memory: 9M/512M [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-surefire-plugin:2.10 or one of its dependencies could not be resolved: Failed to read artifact descripto r for org.apache.maven.plugins:maven-surefire-plugin:jar:2.10: Could not find artifact org.apache.maven.plugins:maven-surefire-plugin:pom:2.10 in nexu s (http://axddarep01.npr.bngf.local:8080/nexus/content/groups/max-public/) - [Help 1] [ERROR] Below is my POM, and we don't have that version in our company repository. Please tell me why Maven is looking for that particular version. Why other project is fine. ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.nbfg.max.maven/groupId artifactIdmax-wesb-pom/artifactId version0.0.4-SNAPSHOT/version /parent groupIdcom.nbfg.max.wesb/groupId artifactIdCDIPubSubMgmtBOLib/artifactId version0.0.1-SNAPSHOT/version nameCDIPubSubMgmtBOLib Mediation/name dependencies /dependencies /project -- View this message in context: http://maven.40175.n5.nabble.com/Why-Maven-is-looking-for-maven-surefire-plugin-2-10-tp5652018p5652018.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
After reading this thread and the embedded references I believe much of this information should be captured and added to http://maven.apache.org - in particular under Learning About Maven the very first topic should be The Maven Way. As well, if you go to http://maven.apache.org/what-is-maven.html then one of the first things you should see is a link to The Maven Way. Newbies in particular should be guided as soon as possible to this philosophical discussion about Maven, and how to best learn and master Maven, before anything else. People need to be clear about Convention over Configuration - they may not agree with the pattern, but it should be made clear to them that by embracing this pattern they will likely find Maven a much more satisfying experience. The surrounding text should catch the newbie's attention right away and guide them to this philosophical discussion with phrases like If you are new to Maven please read 'The Maven Way' to get the most satisfying Maven experience. Maybe some humor is also appropriate I fought Maven, and Maven won - maybe we can revise the original Clash lyrics Pulling hair cause my build's not done I fought Maven and Maven won [x2] I need a break cause my build's not done I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and Swear'n like a son of a gun I fought Maven and Maven won [x2] I miss my Ant and I miss my fun I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and I fought Maven and Maven won [x7] I fought Maven and Chad's article http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html has some really valuable insight, especially about patterns. Too few people understand the importance of patterns - myself included - and we need to be reminded of this. Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal on how to ask questions is also valuable - to both the person trying to learn Maven, but more importantly to the people trying to document and explain Maven. In my own job we struggle with documenting our products because users often complain that our documentation is only a reference that is useful if you mostly know how to do something, but terrible at identifying common goals and the processes to achieve them. Many kudos to Barrie for taking the pragmatic step to open a JIRA issue on this. My own pet peeve with Maven is that when something goes wrong - the diagnostics you get can be exceedingly hard to fathom (especially for newbies) - and often very misleading to what the actual cause of the problem is. In many cases when I quoted the diagnostic messages on users@maven.apache.org I got back all kinds of bizarre answers and suggestions because other people also were mislead by the diagnostics. If someone is looking for an idea for a PhD or postdoc project - please build an Intelligent System to figure out why my Maven build is hosed and explain it to me with some meaningful diagnostics - even better - suggest possible fixes the way m2e does (but just better). This has been great discussion - thanks to all who participated :-) Special thanks to Wolf who got this discussion started. Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Just my two cents. I did not fully ready every post on this topic but the most of them. If anyone mentioned it before please forgive me :) Please do think of the target audience before planning this type of documentation section. And do think of the way they are usually learning things. The maven way won't be a site full of plain explanations and documentations. It is focused on newbies and focused on teach them the right way. Some things are not mentioned and some things are not explained but linked to more detailed documents. Let me tell some nice story. A friend of mine reviewed a project homepage. What was the first thing he said? Ugh - no screenshots. I told him that there are not that many screenshots because I did not plan to simply screenshot a windows CLI where maven prints SUCCESS. I would not expect it myself on a maven homepage. But after a while I began to think about it. Why aren't there any screenshots in my documentation? I do not think thousands of documentation variants are clever but pick up two or three of them. A small example: - Video tutorial explaining the maven way - Practical tutorial for maven java projects and the maven way - Textual explanation of the maven way. The first newbie likes videos, shares them at youtube and twitter. The second newbie likes books (from sonatype). The third developer likes to view at screenshots or 5-minute-cookbooks without too many explanations and tries to directly follow the tutorial instructions and play with maven live. etc. Someone already said it (did not find the post, maybe I deleted it...) that the maven homepages are mainly focused on plugin developers. The typical newbie maybe a xxx developer (java or any other programming language we have a plugin for). But the newbie is not the typical plugin developer. The typical newbie does not need the detailed explanation of how to control the Jvm parameters of JUnit invocations. He will indeed need it after some weeks or as soon as running into trouble because of OutOfMemory.
Re: Why Maven is looking for maven-surefire-plugin:2.10?
[WARNING] The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.10 is missing, no dependency information available ... Below is my POM, and we don't have that version in our company repository. Please tell me why Maven is looking for that particular version. Why other project is fine. What version of Maven are you running? If you want Maven to use a SPECIFIC version of a plugin, you must instruct it to do so via a plugin declaration or pluginManagement tag. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Excluding Properties From Resource Filter
I was wondering if there was a way to exclude specific properties (not
files) from getting filtered? The dilemma is that I am filtering on a
logback.xml file for a bunch of needed properties, but I want the
${user.home} system variable to remain as-is in logback.xml so when the
application is ran it will use the actual user directory for the user
running the application- not the developer that used Maven to build the
project. Any ideas on how this can be accomplished?
Re: maven-invoker-plugin with groovy pre/post build scripts results in The pre-build script did not succeed. PermGen space
Is there some way to embed the -XX:MaxPermSize option inside the pom that declares maven-invoker-plugin? Set it in the MAVEN_OPTS environment variable and it will automatically be used every time Maven is run. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding Properties From Resource Filter
Never mind... I found the answer at
http://maven.apache.org/plugins/maven-resources-plugin/examples/escape-filtering.html
Sorry for the noise!
On Thu, Apr 19, 2012 at 11:53 AM, Will Hoover java.whoo...@gmail.com wrote:
I was wondering if there was a way to exclude specific properties (not
files) from getting filtered? The dilemma is that I am filtering on a
logback.xml file for a bunch of needed properties, but I want the
${user.home} system variable to remain as-is in logback.xml so when the
application is ran it will use the actual user directory for the user
running the application- not the developer that used Maven to build the
project. Any ideas on how this can be accomplished?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding Properties From Resource Filter
Never mind... I found the answer at
http://maven.apache.org/plugins/maven-resources-plugin/examples/escape-filtering.html
That is one way to do it.
You can also change the tokens that Maven is looking for such that
instead of ${xyz} and @abc@ it only looks for @abc@, or another series
of tokens altogether.
You probably also want to set useDefaultDelimiters to false so Maven
does not look for ${...}.
http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#delimiters
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Thank you all for the ideas hints the fruitful discussion and special thanks to Eric for summing it up! I very much appreciate your time and efforts. Regards, Wolf Am 19.04.2012 17:15, schrieb Eric Kolotyluk: After reading this thread and the embedded references I believe much of this information should be captured and added to http://maven.apache.org - in particular under Learning About Maven the very first topic should be The Maven Way. As well, if you go to http://maven.apache.org/what-is-maven.html then one of the first things you should see is a link to The Maven Way. Newbies in particular should be guided as soon as possible to this philosophical discussion about Maven, and how to best learn and master Maven, before anything else. People need to be clear about Convention over Configuration - they may not agree with the pattern, but it should be made clear to them that by embracing this pattern they will likely find Maven a much more satisfying experience. The surrounding text should catch the newbie's attention right away and guide them to this philosophical discussion with phrases like If you are new to Maven please read 'The Maven Way' to get the most satisfying Maven experience. Maybe some humor is also appropriate I fought Maven, and Maven won - maybe we can revise the original Clash lyrics Pulling hair cause my build's not done I fought Maven and Maven won [x2] I need a break cause my build's not done I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and Swear'n like a son of a gun I fought Maven and Maven won [x2] I miss my Ant and I miss my fun I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and I fought Maven and Maven won [x7] I fought Maven and Chad's article http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html has some really valuable insight, especially about patterns. Too few people understand the importance of patterns - myself included - and we need to be reminded of this. Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal on how to ask questions is also valuable - to both the person trying to learn Maven, but more importantly to the people trying to document and explain Maven. In my own job we struggle with documenting our products because users often complain that our documentation is only a reference that is useful if you mostly know how to do something, but terrible at identifying common goals and the processes to achieve them. Many kudos to Barrie for taking the pragmatic step to open a JIRA issue on this. My own pet peeve with Maven is that when something goes wrong - the diagnostics you get can be exceedingly hard to fathom (especially for newbies) - and often very misleading to what the actual cause of the problem is. In many cases when I quoted the diagnostic messages on users@maven.apache.org I got back all kinds of bizarre answers and suggestions because other people also were mislead by the diagnostics. If someone is looking for an idea for a PhD or postdoc project - please build an Intelligent System to figure out why my Maven build is hosed and explain it to me with some meaningful diagnostics - even better - suggest possible fixes the way m2e does (but just better). This has been great discussion - thanks to all who participated :-) Special thanks to Wolf who got this discussion started. Cheers, Eric - 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: The Maven Way
On Thu, Apr 19, 2012 at 05:49:32PM +0200, martin.eisengardt wrote: [snip] Please do think of the target audience before planning this type of documentation section. And do think of the way they are usually learning things. The maven way won't be a site full of plain explanations and documentations. It is focused on newbies and focused on teach them the right way. Some things are not mentioned and some things are not explained but linked to more detailed documents. [good advice snipped] Yes. I would suggest that the Maven Way won't actually say much about doing any specific thing with Maven, but will focus more on good ways to think about and organize what you want to achieve, which map well into Maven's capabilities and assumptions oops I mean conventions. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpQk07W7D28n.pgp Description: PGP signature
RE: Excluding Properties From Resource Filter
Thanks for the info Wayne!
I will keep that in mind for future reference. For now, it may be better to use
the escape filtering so I won't have to change all my existing ${*}s to
something else... very handy though :)
-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Thursday, April 19, 2012 12:42 PM
To: Maven Users List
Subject: Re: Excluding Properties From Resource Filter
Never mind... I found the answer at
http://maven.apache.org/plugins/maven-resources-plugin/examples/escape-filtering.html
That is one way to do it.
You can also change the tokens that Maven is looking for such that
instead of ${xyz} and @abc@ it only looks for @abc@, or another series
of tokens altogether.
You probably also want to set useDefaultDelimiters to false so Maven
does not look for ${...}.
http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#delimiters
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: The Maven Way
One of the things that I think would be helpful is a description of how to construct some common artifacts with Maven - standalone java executable - multi-module webapp for Tomcat and other containers - webapp with CI integration The handling of deployment variables with JNDI or other means should be described in the context of deploying what you have tested. Another big source of trouble is people trying to use Maven without a repo. There needs to be a discussion about the important role that repos play in building with Maven. We used Maven for 2 for 2 years without a repo and wasted a lot of time and energy. I lot of the silliness that comes to the forum is from people that do not have a repo. A brief discussion about the most common plug-ins would also be helpful. I would not want to see all plug-ins treated as equal. The common list should be restricted to 5 or less These seem to be very common issues that newbees bring almost daily to the forum. A lot of the discussion has to be about policy rather than Maven technical issues since most of the time the technical aspects of Maven are very easy to describe and are not the source of the problem. Ron On 19/04/2012 12:49 PM, Wolf Geldmacher wrote: Thank you all for the ideas hints the fruitful discussion and special thanks to Eric for summing it up! I very much appreciate your time and efforts. Regards, Wolf Am 19.04.2012 17:15, schrieb Eric Kolotyluk: After reading this thread and the embedded references I believe much of this information should be captured and added to http://maven.apache.org - in particular under Learning About Maven the very first topic should be The Maven Way. As well, if you go to http://maven.apache.org/what-is-maven.html then one of the first things you should see is a link to The Maven Way. Newbies in particular should be guided as soon as possible to this philosophical discussion about Maven, and how to best learn and master Maven, before anything else. People need to be clear about Convention over Configuration - they may not agree with the pattern, but it should be made clear to them that by embracing this pattern they will likely find Maven a much more satisfying experience. The surrounding text should catch the newbie's attention right away and guide them to this philosophical discussion with phrases like If you are new to Maven please read 'The Maven Way' to get the most satisfying Maven experience. Maybe some humor is also appropriate I fought Maven, and Maven won - maybe we can revise the original Clash lyrics Pulling hair cause my build's not done I fought Maven and Maven won [x2] I need a break cause my build's not done I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and Swear'n like a son of a gun I fought Maven and Maven won [x2] I miss my Ant and I miss my fun I fought Maven and Maven won [x2] I left my Ant and it feels so bad Guess my build won't run It's the best tool that I ever had I fought Maven and Maven won I fought Maven and I fought Maven and Maven won [x7] I fought Maven and Chad's article http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html has some really valuable insight, especially about patterns. Too few people understand the importance of patterns - myself included - and we need to be reminded of this. Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal on how to ask questions is also valuable - to both the person trying to learn Maven, but more importantly to the people trying to document and explain Maven. In my own job we struggle with documenting our products because users often complain that our documentation is only a reference that is useful if you mostly know how to do something, but terrible at identifying common goals and the processes to achieve them. Many kudos to Barrie for taking the pragmatic step to open a JIRA issue on this. My own pet peeve with Maven is that when something goes wrong - the diagnostics you get can be exceedingly hard to fathom (especially for newbies) - and often very misleading to what the actual cause of the problem is. In many cases when I quoted the diagnostic messages on users@maven.apache.org I got back all kinds of bizarre answers and suggestions because other people also were mislead by the diagnostics. If someone is looking for an idea for a PhD or postdoc project - please build an Intelligent System to figure out why my Maven build is hosed and explain it to me with some meaningful diagnostics - even better - suggest possible fixes the way m2e does (but just better). This has been great discussion - thanks to all who participated :-) Special thanks to Wolf who got this discussion started. Cheers, Eric - To unsubscribe,
Re: Why Maven is looking for maven-surefire-plugin:2.10?
I figured I am using 3.0.3 while the project is using 3.0.4. No more error after changed to 3.0.3. They don't have that version of jar in Nexus. Thanks Jirong -- View this message in context: http://maven.40175.n5.nabble.com/Why-Maven-is-looking-for-maven-surefire-plugin-2-10-tp5652018p5652683.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: mvn release:prepare maven-scm-provider-javasvn fails with SVN 1.7.3 Subversion Server
Hi, svnkit 1.7.4 is available here: http://maven.tmatesoft.com/content/repositories/releases 2012/4/19 Karl Heinz Marbaise khmarba...@gmx.de: Hello to all, i have a question concerning creating releases via the maven-scm-provider-javasvn: I have the following configuration in a pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId version1.6/version configuration providerImplementations svnjavasvn/svn /providerImplementations /configuration dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.15/version /dependency dependency groupIdorg.tmatesoft.svnkit/groupId artifactIdsvnkit/artifactId version1.3.5/version /dependency /dependencies /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.2.2/version configuration autoVersionSubmodulestrue/autoVersionSubmodules providerImplementations svnjavasvn/svn /providerImplementations /configuration dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.15/version /dependency dependency groupIdorg.tmatesoft.svnkit/groupId artifactIdsvnkit/artifactId version1.3.5/version /dependency /dependencies /plugin The point is this configuration worked with a 1.6.17 Subversion server but after an update to 1.7.3 it produces problem and didn't work. The tagging of the release:prepare goal fails.. We have configured the scm part with developerConnection/connnection like this: scm:svn:http://server:port/svn/repo/Project/path/trunk The url which is shown during the failure of the tagging looks like the following: /Project/path/trunk/Project/path/trunk We are using 1.6 working copies. This is done by a build server but i have tested that as well with SVN 1.6.17 on command line on Windows ...with the same result... I know the entry http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/issues/detail?id=9 but the problem here is that svnkit 1.7.4 is currently not available in Maven Central..(Already asked the SVNKit people).. Does someone have any idea about that problem ? Many thanks in advance... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Compilation failure: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject
I got this error during Maven compile, but it compiles no problem within my WID 7.0.0.4. The project is depends on ESB server 7.0 libraries. How can I find what's missing and what shall I do? Ask repository manager to add ESB server libraries? Thanks Jirong [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building CDIPubSubMgmtMed Mediation 0.0.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ CDIPubSubMgmtMed --- [INFO] Deleting C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\..\build\target\CDIPubSubMgmtMed [INFO] [INFO] --- build-helper-maven-plugin:1.7:regex-property (regex-property) @ CDIPubSubMgmtMed --- [INFO] Setting property 'portable.artifact.path' to 'C:/DEV/WIDWS/MDM/CDIPubSubMgmtMed/../build/target/CDIPubSubMgmtMed/CDIPubSubMgmtMed-0.0.1-SNAPSHOT.ear'. [INFO] [INFO] --- build-helper-maven-plugin:1.7:add-source (add-source) @ CDIPubSubMgmtMed --- [INFO] Source directory: C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\gen\src added. [INFO] [INFO] --- build-helper-maven-plugin:1.7:add-resource (add-resource) @ CDIPubSubMgmtMed --- [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ CDIPubSubMgmtMed --- [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\resources [INFO] Copying 20 resources [INFO] Copying 1 resource [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ CDIPubSubMgmtMed --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Compiling 2 source files to C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\..\build\target\CDIPubSubMgmtMed\classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\java\com\nbfg\cdi\pubsub\HeaderUtil.java:[28,33] cannot find symbol symbol : method getRootObject() location: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject [INFO] 1 error [INFO] - [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.984s [INFO] Finished at: Thu Apr 19 12:03:24 EDT 2012 [INFO] Final Memory: 31M/512M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project CDIPubSubMgmtMed: Compilation failure [ERROR] \DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\java\com\nbfg\cdi\pubsub\HeaderUtil.java:[28,33] cannot find symbol [ERROR] symbol : method getRootObject() [ERROR] location: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject [ERROR] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException This is my POM.xml: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.nbfg.max.maven/groupId artifactIdmax-wesb-pom/artifactId version0.0.4-SNAPSHOT/version /parent groupIdcom.nbfg.max.wesb/groupId artifactIdCDIPubSubMgmtMed/artifactId version0.0.1-SNAPSHOT/version nameCDIPubSubMgmtMed Mediation/name dependencies dependency groupIdcom.nbfg.max.wesb/groupId artifactIdClientServicesBOLib/artifactId version0.0.1-SNAPSHOT/version /dependency dependency groupIdcom.nbfg.max.wesb/groupId artifactIdClientInfoMgmtLib/artifactId version0.0.1-SNAPSHOT/version /dependency dependency groupIdcom.nbfg.max.wesb/groupId artifactIdCDIPubSubMgmtLib/artifactId version0.0.1-SNAPSHOT/version /dependency dependency
RE: Compilation failure: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject
Yes, you probably should get the libraries added to your repository. If you are in a situation where this might take some time, then you might look into adding the dependencies to your pom.xml (temporally) using system scope dependencies. This would allow you to move forward until the required dependencies are available in your repository. Regards, Dave Wolf Java Architect Gorilla Logic -Original Message- From: hujirong [mailto:jirong...@gmail.com] Sent: Thu 4/19/2012 4:15 PM To: users@maven.apache.org Subject: Compilation failure: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject I got this error during Maven compile, but it compiles no problem within my WID 7.0.0.4. The project is depends on ESB server 7.0 libraries. How can I find what's missing and what shall I do? Ask repository manager to add ESB server libraries? Thanks Jirong [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building CDIPubSubMgmtMed Mediation 0.0.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ CDIPubSubMgmtMed --- [INFO] Deleting C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\..\build\target\CDIPubSubMgmtMed [INFO] [INFO] --- build-helper-maven-plugin:1.7:regex-property (regex-property) @ CDIPubSubMgmtMed --- [INFO] Setting property 'portable.artifact.path' to 'C:/DEV/WIDWS/MDM/CDIPubSubMgmtMed/../build/target/CDIPubSubMgmtMed/CDIPubSubMgmtMed-0.0.1-SNAPSHOT.ear'. [INFO] [INFO] --- build-helper-maven-plugin:1.7:add-source (add-source) @ CDIPubSubMgmtMed --- [INFO] Source directory: C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\gen\src added. [INFO] [INFO] --- build-helper-maven-plugin:1.7:add-resource (add-resource) @ CDIPubSubMgmtMed --- [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ CDIPubSubMgmtMed --- [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\resources [INFO] Copying 20 resources [INFO] Copying 1 resource [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ CDIPubSubMgmtMed --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Compiling 2 source files to C:\DEV\WIDWS\MDM\CDIPubSubMgmtMed\..\build\target\CDIPubSubMgmtMed\classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\java\com\nbfg\cdi\pubsub\HeaderUtil.java:[28,33] cannot find symbol symbol : method getRootObject() location: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject [INFO] 1 error [INFO] - [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.984s [INFO] Finished at: Thu Apr 19 12:03:24 EDT 2012 [INFO] Final Memory: 31M/512M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project CDIPubSubMgmtMed: Compilation failure [ERROR] \DEV\WIDWS\MDM\CDIPubSubMgmtMed\src\main\java\com\nbfg\cdi\pubsub\HeaderUtil.java:[28,33] cannot find symbol [ERROR] symbol : method getRootObject() [ERROR] location: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject [ERROR] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException This is my POM.xml: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.nbfg.max.maven/groupId artifactIdmax-wesb-pom/artifactId version0.0.4-SNAPSHOT/version /parent groupIdcom.nbfg.max.wesb/groupId artifactIdCDIPubSubMgmtMed/artifactId version0.0.1-SNAPSHOT/version nameCDIPubSubMgmtMed Mediation/name dependencies dependency groupIdcom.nbfg.max.wesb/groupId
Re: exclude folders during mvn assembly
On Thu, Apr 19, 2012 at 11:48 PM, S Ahmed sahmed1...@gmail.com wrote: Barrie, I see, ok I'm looking into the JNDI method. I'm hosting this app in both tomcat and jetty. Could I put this dndi file in my class path so I don't have to hard code the location, or does it have to be in the servlet container? i.e. jetty or tomcat My jetty instance is an embedded instance... Have a look around at some of the recent similar posts. I thought Ron's blog gave some details on how to use JNDI. Yes, putting things on the class path is the best way to load resource files. Then you don't have to worry about physical locations on disk. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
how to resolve missing maven-junction-plugin dependency: junction.exe?
Hi there,
I'm trying to set up clean phase to use maven-junction-plugin as I'm
building the project from both Linux and Windows.
Here is my pom.xml section for junction plugin:
plugin
groupIdcom.pyx4j/groupId
artifactIdmaven-junction-plugin/artifactId
version1.0.3/version
executions
execution
idunlink/id
phaseclean/phase
goals
goalunlink/goal
/goals
/execution
/executions
configuration
links
link
dst${basedir}/src/main/webapp/WEB-INF/dst
src${WEB-INF}/src
/link
/links
/configuration
/plugin
But I got an error when I run mvn clean: Failed to execute goal
com.pyx4j:maven-junction-plugin:1.0.3:unlink (unlink) on project webapp:
Execution unlink of goal com.pyx4j:maven-junction-plugin:1.0.3:unlink
failed: Plugin com.pyx4j:maven-junction-plugin:1.0.3 or one of its
dependencies could not be resolved: Failure to find
sysinternals:junction:exe:1.04 in
http://myserver.com:8080/archiva/repository/internal was cached in the local
repository, resolution will not be reattempted until the update interval of
archiva.default has elapsed or updates are forced - [Help 1]
I'm using an internal archiva server for maven repository, and it does have
maven-junction-plugin in the repository, but missing junction-1.04.exe, is
there a way that I can add the downloaded junction-1.04.exe in archiva or
.m2 cache for the junction plugin to work?
Another question, I got the same error when I run mvn clean in Linux, I
thought junction plugin would use ln -s in Linux, why it's still looking for
junction.exe?
Thanks in advance!
David
--
View this message in context:
http://maven.40175.n5.nabble.com/how-to-resolve-missing-maven-junction-plugin-dependency-junction-exe-tp5653047p5653047.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: Re-Releasing Configured Artifacts, how?
NOTE: For many situations, this is not appropriate we are an exception.
1. Check Out the revision / tag you want to re-configure.
2. Alter appropriate properties file(s), commit.
3. Do release:prepare release:perform
This utilizes the SCM as a configuration management tool (in addition to
source control). There are several advantages to this and several drawbacks.
I now use a pom module, with several war executions to overlay a war. This
works well.
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
parent
artifactIdacme-project/artifactId
groupIdcom.acme/groupId
version0.1.0.0-SNAPSHOT/version
relativePath../relativePath
/parent
artifactIdacme-project-webapp-env/artifactId
packagingpom/packaging
dependencies
dependency
groupId${project.groupId}/groupId
artifactIdacme-project-webapp/artifactId
typewar/type
/dependency
/dependencies
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.2/version
configuration
overlays
overlay
groupId${project.groupId}/groupId
artifactIdacme-project-webapp/artifactId
includes
includeWEB-INF/*.properties/include
includeWEB-INF/*.props/include
/includes
filteredtrue/filtered
/overlay
overlay
groupId${project.groupId}/groupId
artifactIdacme-project-webapp/artifactId
filteredfalse/filtered
/overlay
/overlays
/configuration
/plugin
/plugins
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
executions
!-- build with dev config --
execution
iddev/id
phasepackage/phase
goals
goalwar/goal
/goals
configuration
classifierdev/classifier
filters
filter${basedir}/env-dev.properties/filter
/filters
/configuration
/execution
!-- build with staging config --
execution
idstaging/id
phasepackage/phase
goals
goalwar/goal
/goals
configuration
classifierstaging/classifier
filters
filter${basedir}/env-staging.properties/filter
/filters
/configuration
/execution
!-- build with prod config --
execution
idprod/id
phasepackage/phase
goals
goalwar/goal
/goals
configuration
classifierprod/classifier
filters
filter${basedir}/env-prod.properties/filter
/filters
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
On Thu, Apr 19, 2012 at 9:26 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:
On 19/04/2012 6:40 AM, Andrew Hughes wrote:
My app uses CDI (Weld), I know all about DI. I agree with you both :)
We would rather re-release (a new) version (not snapshot). If we want to
we
can always change a deployment at runtime if we choose.
I am not sure what you mean by this.
Cheers
On 19/04/2012 3:22 PM, Ron
Wheelerrwheeler@artifact-**software.comrwhee...@artifact-software.com
wrote:
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=150http://blog.**
artifact-software.com/tech/?p=**150http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58http://blog.**
artifact-software.com/tech/?p=**58http://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
Re: Compilation failure: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject
cannot find symbol symbol : method getRootObject() location: interface com.ibm.websphere.sibx.smobo.ServiceMessageObject Any time you have this problem, it means you are missing a dependency. Figure out which dependency that is and add it to your pom file. Then if your repo doesn't have it, ask the repo owner to add it. That is a separate matter. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to resolve missing maven-junction-plugin dependency: junction.exe?
plugin groupIdcom.pyx4j/groupId artifactIdmaven-junction-plugin/artifactId version1.0.3/version This list primarily supports Maven itself (core) and plugins published under groupId org.apache.maven.plugins. We could not possibly support every plugin ever created on this list. Your question is very specific and about a plugin published under groupId com.pyx4j. Realistically you need to find the users forum or developers for this plugin and ask these questions there. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn release with perforce
Hi Ste, I'm facing issues with maven release plugin and perforce, I've followed the steps as given by you in your post, I'm still getting the following error, I'll be obliged if you can spare some thoughts on this. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.2:rollback (default-cli) on project mule-example-echo: Error restoring from backup POM: Unable to open file C:\perforce\hostname\test \echo\trunk\pom.xml for writing. - [Help 1] Kind Regards -- View this message in context: http://maven.40175.n5.nabble.com/mvn-release-with-perforce-tp103605p5651585.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: EAR project produces application.xml, but EJB module is missing
On Tue, Mar 6, 2012 at 6:24 PM, Markus KARG mar...@headcrashing.eu wrote: What do you mean with maps to? An EJB is a .jar file. If you don't specify any type, jar is the default and since they share the same extension, Maven is able to resolve the dependency. One improvement would be to look at the pom file and realize the packaging is set to ejb and issue a warning in this case. Feel free to open a Jira for this. Thanks, S. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Sonntag, 4. März 2012 13:01 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing Because ejb type maps to jar extension On Sunday, 4 March 2012, Markus KARG mar...@headcrashing.eu wrote: You are right, when adding typeejb/type it is working! I missed the fact that maven coordinates include the packaging, while the default packaging is typejar/type. The odd thing is that dependency resolution is working without that. So it actually seems, module resolution is working correctly while dependency resolution ignores type. Thanks a lot! Markus -Original Message- From: Stephen Coy [mailto:st...@resolvesw.com] Sent: Sonntag, 4. März 2012 09:44 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing The number one reason I've had this problem in the past is forgetting to specify: typeejb/type in the dependency declarations for EJB jars. On 04/03/2012, at 2:33 AM, Markus KARG wrote: Maven 3.0.4 is producing application.xml containing module entries for some dependencies (RAR modules), but which is missing module entries for other dependencies (EJB modules). This is weird as the pom more or less is empty. It just contains the dependencies (RAR modules and EJB modules) and Java EE version (6). So I assume one cannot do wrong. Is that a bug in Maven or what the heck is the trick to get module entries for EJB modules? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: EAR project produces application.xml, but EJB module is missing
On Fri, Apr 20, 2012 at 2:06 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, Mar 6, 2012 at 6:24 PM, Markus KARG mar...@headcrashing.eu wrote: What do you mean with maps to? An EJB is a .jar file. If you don't specify any type, jar is the default and since they share the same extension, Maven is able to resolve the dependency. One improvement would be to look at the pom file and realize the packaging is set to ejb and issue a warning in this case. Feel free to open a Jira for this. Don't forget the patch and tests please. That will improve the chances of being included. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
