Re: maven-eclipse-plugin Does not resolve workspace project name
john.vint wrote: This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. Lets assume a person is working on two different version (two releases being developed in parallel). They will both have the same artifact ID but eclipse forces a different project name. I don't think asking m-e-p to offer this functionality is really an isnane request. An alternative: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse- mojo.html#projectNameTemplate - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Inline Ant tasks not working - Namespace problem?
I got a ant build.xml invoked properly via maven antrun plugin but when i
define it inline, it doesn't work. Please assist.
I think it has to do with xmlns but not sure where to define it properly.
(To be specific am using a jacoco ant task for code coverage as described
here http://www.eclemma.org/jacoco/trunk/doc/ant.html)
The error that i got is
*[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.6:
run (default) on project xxx.sample.suite: An Ant BuildException has occure
d: The prefix jacoco for element jacoco:report is not bound. - [Help 1]
*
?xml version=1.0 encoding=UTF-8?
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
*xmlns:jacoco=antlib:org.jacoco.ant*
modelVersion4.0.0/modelVersion
groupIdxxx.sample/groupId
artifactIdxxx.sample.suite/artifactId
version1.0.0-SNAPSHOT/version
packagingjar/packaging
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.6/version
executions
execution
phasepackage/phase
configuration
target
taskdef uri=antlib:org.jacoco.ant
resource=org/jacoco/ant/antlib.xml
classpath
path=C:\SOFTWARES\JAVA\Java-external-jars\Jacoco\lib\jacocoant.jar /
/taskdef
echo message=Base dir: ${basedir} /
jacoco:report
executiondata
file file=C:/coverage.exec /
/executiondata
structure name=Example Project
classfiles
fileset
dir=C:\..\bin /
/classfiles
sourcefiles encoding=UTF-8
fileset
dir=C:\..\src /
/sourcefiles
/structure
html destdir=C:/report /
/jacoco:report
/target
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
Thanks,
Hari
Continuous Delivery and Maven
I've been reading about Continuous Delivery http://continuousdelivery.com/ and trying to understand how to best combine Maven and Continuous Delivery. There is a thread in the Continuous Delivery google group where this discussion has started: http://groups.google.com/group/continuousdelivery/browse_thread/thread/c8440681058f2db8 I would be curious as to whether there are other Maven developers following the Maven Users forum that have been looking Continuous Delivery and trying to grapple with the best way to use Maven in this approach. -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3245370.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 3.0 Deployment Problem
Thanks to the reply from Ryan Connolly [which unfortunately isn't reflected here]. Indeed, maven 3.x doesn't support the ssh file transport by default and I needed to add a build extension for the correct wagon artifact extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh/artifactId version1.0-beta-6/version /extension /extensions I had reviewed the maven 3.x compatibility notes at https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html but it didn't register with that our builds would be affected by this change. I am a little uneasy, however, using a 'beta' version of the artifact. Beta-6 seems to be the latest/best available. Is this the case? Thanks for the help. Brad From: Harper, Brad Sent: Friday, October 29, 2010 5:22 PM To: users@maven.apache.org Subject: Maven 3.0 Deployment Problem I just switched [from Maven 2.2.1] to give 3.0 a try and ran into a problem during deployment. The crux of the output seems to be No implementation for org.apache.maven.wagon.Wagon annotated with @Named(value=scp) was bound Nothing obvious jumps out in a web search containing key parts of this text. I'm not explicitly managing or configuring the deploy plugin. Any ideas? Thanks. Brad
Surefire NPE
Greetings,
I've been using Maven and Surefire on a project for about a year now and have
sporadically seen a problem that I've always been able to get around but want
to get to the bottom of. It's a null pointer exception sometimes when I run
mvn and it tries to run all our tests. It happens rarely but four different
people on the project have run into it at one point or another. For some
reason if I bypass the tests and start my Jetty server through maven, I can go
back to run the tests after stopping Jetty and the tests run just fine. This
is typically my workaround.
Here is the output from the command line:
C:\workspaces\tesla\readiness-mobile\tesla-src-mobilemvn
[INFO] Scanning for projects...
[INFO]
[INFO] Building Templated Service Layer Assembler
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 6 resources
Downloading: http://repo1.maven.org/maven2/com/nike/classes/2.2/classes-2.2.pom
[INFO] Unable to find resource 'com.nike:classes:pom:2.2' in repository central
(http://repo1.maven.org/maven2)
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to
C:\workspaces\tesla\readiness-mobile\tesla-src-mobile\target\classes
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 76 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
C:\workspaces\tesla\readiness-mobile\tesla-src-mobile\target\surefire-reports
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at java.util.Properties.setProperty(Properties.java:143)
at
org.apache.maven.surefire.booter.SurefireBooter.setForkProperties(SurefireBooter.java:510)
at
org.apache.maven.surefire.booter.SurefireBooter.forkSuites(SurefireBooter.java:483)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkOnce(SurefireBooter.java:385)
at
org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:246)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:581)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 6 seconds
[INFO] Finished at: Mon Nov 01 08:49:35 PDT 2010
[INFO] Final Memory: 19M/46M
[INFO]
C:\workspaces\tesla\readiness-mobile\tesla-src-mobile
And here is the Surefire
accessing settings.xml when specfiying user.home
I am having trouble accessing the settings.xml when running the following
command on my windows box:
mvn -Duser.home=j:\joe_user compile
where j:\joe_user is a samba mounted drive to my unix box in which the .m2
directory exists. I've run with the -X switch so I can see what's happening:
mvn -Duser.home=j:\joe_user -X compile
[DEBUG] Reading user settings from c:\Documents and
Settings\joe_user\.m2\settings.xml
[DEBUG] Reading global settings from
j:\joe_user\maven\apache-maven-3.0\conf\settings.xml
[DEBUG] Using local repository at j:\joe_user\.m2\repository
I've only included the interesting debug messages and you can see that I am
using version 3.0 as my M2_HOME is set to j:\joe_user\maven\apache-maven-3.0
Things run as expected when I copy the settings.xml file from my unix box onto
my windows box into the appropriate directory OR if i add the -s option:
mvn -Duser.home=j:\joe_user -s j:\joe_user\.m2\settings.xml compile
My question is: based on the maven documentation, it appears that a user's
install is specified at ${user.home}/.m2/settings.xml therefore, should
specifying the user.home via -D option point to the correct location and NOT
the home directory (under windows)?
I apologize if this is answered elsewhere. I did perform several searches
prior to sending this email.
thanks
bill
DEAL OF THE YEAR: 2010 Honda Civic for $1,734.09
SPECIAL REPORT: High ticket items are being auctioned for an incredible 90% off!
http://thirdpartyoffers.netzero.net/TGL3231/4ccebcea695e153f379st04vuc
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Inline Ant tasks not working - Namespace problem?
http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html
You need to define a plugin dependency to jacocoant.jar. If that artifact is
not already in the repo, you need to ad it to your repo manager.
/Anderfs
On Tue, Nov 2, 2010 at 10:59, Hari shankar harsha...@gmail.com wrote:
I got a ant build.xml invoked properly via maven antrun plugin but when i
define it inline, it doesn't work. Please assist.
I think it has to do with xmlns but not sure where to define it properly.
(To be specific am using a jacoco ant task for code coverage as described
here http://www.eclemma.org/jacoco/trunk/doc/ant.html)
The error that i got is
*[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.6:
run (default) on project xxx.sample.suite: An Ant BuildException has occure
d: The prefix jacoco for element jacoco:report is not bound. - [Help
1]
*
?xml version=1.0 encoding=UTF-8?
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
*xmlns:jacoco=antlib:org.jacoco.ant*
modelVersion4.0.0/modelVersion
groupIdxxx.sample/groupId
artifactIdxxx.sample.suite/artifactId
version1.0.0-SNAPSHOT/version
packagingjar/packaging
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.6/version
executions
execution
phasepackage/phase
configuration
target
taskdef uri=antlib:org.jacoco.ant
resource=org/jacoco/ant/antlib.xml
classpath
path=C:\SOFTWARES\JAVA\Java-external-jars\Jacoco\lib\jacocoant.jar /
/taskdef
echo message=Base dir: ${basedir} /
jacoco:report
executiondata
file file=C:/coverage.exec /
/executiondata
structure name=Example Project
classfiles
fileset
dir=C:\..\bin /
/classfiles
sourcefiles encoding=UTF-8
fileset
dir=C:\..\src /
/sourcefiles
/structure
html destdir=C:/report /
/jacoco:report
/target
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
Thanks,
Hari
Re: how can i have two compile phases?
Well, my code generator is attached and it works, the problem is that the code generator itself has to be compiled first. regards Leon On Fri, Oct 29, 2010 at 11:10 PM, Paul Benedict pbened...@apache.org wrote: On Fri, Oct 29, 2010 at 4:03 PM, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hi, I have following requirement. I have a project, in which I have one source folder which contains a code generator (run with apt), another source folder which contains code, which is processed by the generator from folder 1, and a third folder that relies on the code generated by the second folder. Therefor I need two compilation executions after each other, one for the generator and one for the generated code. Is this possible with maven? Yes. Attach your APT generation to generate-sources phase. That will be included in the following compile phase but, I believe, the plugin that generates the sources has to be smart enough to add it to the class path. - 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: how can i have two compile phases?
Sorry, I was not able to answer to this message in the previous three days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com wrote:
You could move the code generator and the generated code out to a separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${cobertura-plugin.version}/version
/dependency
/dependencies
executions
execution
idprocess/id
goals
goalprocess/goal
/goals
phasegenerate-sources/phase
configuration
factoryorg.distributeme.processors.GeneratorProcessorFactory/factory
encodingUTF-8/encoding
verbosetrue/verbose
outputDirectory${project.basedir}/generated/java/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
reporting
/reporting
dependencies
dependency
groupIdnet.anotheria/groupId
artifactIdano-util/artifactId
version1.0.0/version
/dependency
dependency
groupIdnet.anotheria/groupId
artifactIdano-net/artifactId
version1.0.0/version
/dependency
dependency
groupIdnet.anotheria/groupId
artifactIdano-prise/artifactId
version1.0.2/version
/dependency
dependency
groupIdnet.anotheria/groupId
artifactIdconfigureme/artifactId
version1.0.0/version
/dependency
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.5/version
scopeprovided/scope
/dependency
dependency
groupIdjdom/groupId
artifactIdjdom/artifactId
version0.7/version
/dependency
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.6/version
scopeprovided/scope
/dependency
/dependencies
scm
urlsvn:svn://svn.anotheria.net/opensource/distributeme/trunk/url
Dependency problem with jasper
Hi all, I've come accross the following problem recently: when downloading Jasperreports dependencies such as apache commons-xxx libraries with Maven, Jasper site doesn't send a 404 http code but a 202 code with a beautiful redesigned 404 html layered page (similar to this case http://www.mail-archive.com/users@maven.apache.org/msg92732.html). It happens when maven tries to download the maven-metadata file for example, so instead of having the previous content : ?xml version=1.0 encoding=UTF-8? metadata groupIdcommons-digester/groupId artifactIdcommons-digester/artifactId /metadata the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Thanks for your replies.
Re: [ANN] Maven Release Plugin 2.1 Released
+1 on this How could we re-open the issue ? Frédéric On Wed, Oct 20, 2010 at 6:25 PM, Lars Fischer lfisc...@fastmail.fm wrote: [MRELEASE-128] - SCM properties being replaced during release:perform This is still not working for me: http://jira.codehaus.org/browse/MRELEASE-128 Regards, Lars
Re: Dependency problem with jasper
2010/11/2 Clément TRUNG clement.tr...@syntesys.eu: the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Simple, call the Jasper forge administrator and ask him/her to fix it. Other options are: 1. install locally Jasper Reports artifacts and say goodbye to Jasper repositories 2. install a Maven repository manager (e.g. Nexus) that can act as a proxy to Jasper Forge (however I don't know if it will work). Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how can i have two compile phases?
You are fighting the Maven way
Drink the coolaid, split your two phases into two projects and you
will actually end up with a cleaner project in the first place... and
a simpler build process... and it will be doing what you want
Maven is opinionated... you have hit a core opinion, either use
something else or follow the opinion.
I suggest you try following the opinion and see where that takes
you... I believe you'll have a cleaner structure that is _easier for
others to maintain after you have moved on to projects elsewhere_ as
well as easy for you to maintain going forwards
-Stephen
P.S. Maven aims to make building software easier for everyone working
on the project to maintain, not just the person who set up the build
process initially... the easiest tools for setting up a build process
are not necessariliy the best tools for maintaining a build when the
original build engineer moves elsewhere
On 2 November 2010 10:22, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Sorry, I was not able to answer to this message in the previous three days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com wrote:
You could move the code generator and the generated code out to a separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${cobertura-plugin.version}/version
/dependency
/dependencies
executions
execution
idprocess/id
goals
goalprocess/goal
/goals
phasegenerate-sources/phase
configuration
factoryorg.distributeme.processors.GeneratorProcessorFactory/factory
encodingUTF-8/encoding
verbosetrue/verbose
outputDirectory${project.basedir}/generated/java/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
reporting
/reporting
dependencies
dependency
groupIdnet.anotheria/groupId
artifactIdano-util/artifactId
version1.0.0/version
/dependency
dependency
groupIdnet.anotheria/groupId
artifactIdano-net/artifactId
version1.0.0/version
[m3] maven documentation - maven-site-plugin
Hey all, what is happening with the maven-site-plugin in future? Will it be supported for maven 3? I heard from any other plans keyword: idiom: access wiki. Does anybody have some information? Actually my sit generation crashes ;-( Fredy
Re: how can i have two compile phases?
I do something simliar but I use two modules. My very first module builds
various build related tools such as apt plugins. Then subsequent modules
depend on that first module.
On Tue, Nov 2, 2010 at 7:25 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
You are fighting the Maven way
Drink the coolaid, split your two phases into two projects and you
will actually end up with a cleaner project in the first place... and
a simpler build process... and it will be doing what you want
Maven is opinionated... you have hit a core opinion, either use
something else or follow the opinion.
I suggest you try following the opinion and see where that takes
you... I believe you'll have a cleaner structure that is _easier for
others to maintain after you have moved on to projects elsewhere_ as
well as easy for you to maintain going forwards
-Stephen
P.S. Maven aims to make building software easier for everyone working
on the project to maintain, not just the person who set up the build
process initially... the easiest tools for setting up a build process
are not necessariliy the best tools for maintaining a build when the
original build engineer moves elsewhere
On 2 November 2010 10:22, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Sorry, I was not able to answer to this message in the previous three
days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com
wrote:
You could move the code generator and the generated code out to a
separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${cobertura-plugin.version}/version
/dependency
/dependencies
executions
execution
idprocess/id
goals
goalprocess/goal
/goals
phasegenerate-sources/phase
configuration
factoryorg.distributeme.processors.GeneratorProcessorFactory/factory
encodingUTF-8/encoding
verbosetrue/verbose
outputDirectory${project.basedir}/generated/java/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
reporting
Re: how can i have two compile phases?
On 2 November 2010 11:54, Justin Lee evancho...@gmail.com wrote:
I do something simliar but I use two modules. My very first module builds
various build related tools such as apt plugins. Then subsequent modules
depend on that first module.
And that is the Maven way
On Tue, Nov 2, 2010 at 7:25 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
You are fighting the Maven way
Drink the coolaid, split your two phases into two projects and you
will actually end up with a cleaner project in the first place... and
a simpler build process... and it will be doing what you want
Maven is opinionated... you have hit a core opinion, either use
something else or follow the opinion.
I suggest you try following the opinion and see where that takes
you... I believe you'll have a cleaner structure that is _easier for
others to maintain after you have moved on to projects elsewhere_ as
well as easy for you to maintain going forwards
-Stephen
P.S. Maven aims to make building software easier for everyone working
on the project to maintain, not just the person who set up the build
process initially... the easiest tools for setting up a build process
are not necessariliy the best tools for maintaining a build when the
original build engineer moves elsewhere
On 2 November 2010 10:22, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Sorry, I was not able to answer to this message in the previous three
days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com
wrote:
You could move the code generator and the generated code out to a
separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${cobertura-plugin.version}/version
/dependency
/dependencies
executions
execution
idprocess/id
goals
goalprocess/goal
/goals
phasegenerate-sources/phase
configuration
factoryorg.distributeme.processors.GeneratorProcessorFactory/factory
encodingUTF-8/encoding
verbosetrue/verbose
outputDirectory${project.basedir}/generated/java/outputDirectory
/configuration
Re: how can i have two compile phases?
Ok, first of all thank you for your time and let me understand what
the maven way means for me in this case:
I take the project and make 2 out of it, like
xyz-generators module and
xyz-generators-test module, as well as
xyz-runtime module.
Whenever I'm releasing xyz-generators they are actually untested,
because the test project can only test them after the released
happened.
Whenever I'm testing a new generator feature, I have to install
xyz-generators, switch to xyz-generators-test directory, run mvn
compile there - right?
I can not release xyz-generators and xyz-runtime in one package, one
have to maintain both dependencies.
on the plus side I could, at least theoretically, declare
xyz-generators dependency as provided. In the practice probably not.
The pluses aren't really outweigh drawbacks, apparently, in _this_
case, maven makes the life of the developer much harder as it should
be.
Do I miss any pluses ? :-)
regards
Leon
On Tue, Nov 2, 2010 at 12:25 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
You are fighting the Maven way
Drink the coolaid, split your two phases into two projects and you
will actually end up with a cleaner project in the first place... and
a simpler build process... and it will be doing what you want
Maven is opinionated... you have hit a core opinion, either use
something else or follow the opinion.
I suggest you try following the opinion and see where that takes
you... I believe you'll have a cleaner structure that is _easier for
others to maintain after you have moved on to projects elsewhere_ as
well as easy for you to maintain going forwards
-Stephen
P.S. Maven aims to make building software easier for everyone working
on the project to maintain, not just the person who set up the build
process initially... the easiest tools for setting up a build process
are not necessariliy the best tools for maintaining a build when the
original build engineer moves elsewhere
On 2 November 2010 10:22, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Sorry, I was not able to answer to this message in the previous three days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com wrote:
You could move the code generator and the generated code out to a separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
Re: how can i have two compile phases?
I think you are structuring this all upside down
have a root aggregator pom
have child projects
release all as one in one go
On 2 November 2010 13:16, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Ok, first of all thank you for your time and let me understand what
the maven way means for me in this case:
I take the project and make 2 out of it, like
xyz-generators module and
xyz-generators-test module, as well as
xyz-runtime module.
Whenever I'm releasing xyz-generators they are actually untested,
because the test project can only test them after the released
happened.
Whenever I'm testing a new generator feature, I have to install
xyz-generators, switch to xyz-generators-test directory, run mvn
compile there - right?
I can not release xyz-generators and xyz-runtime in one package, one
have to maintain both dependencies.
on the plus side I could, at least theoretically, declare
xyz-generators dependency as provided. In the practice probably not.
The pluses aren't really outweigh drawbacks, apparently, in _this_
case, maven makes the life of the developer much harder as it should
be.
Do I miss any pluses ? :-)
regards
Leon
On Tue, Nov 2, 2010 at 12:25 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
You are fighting the Maven way
Drink the coolaid, split your two phases into two projects and you
will actually end up with a cleaner project in the first place... and
a simpler build process... and it will be doing what you want
Maven is opinionated... you have hit a core opinion, either use
something else or follow the opinion.
I suggest you try following the opinion and see where that takes
you... I believe you'll have a cleaner structure that is _easier for
others to maintain after you have moved on to projects elsewhere_ as
well as easy for you to maintain going forwards
-Stephen
P.S. Maven aims to make building software easier for everyone working
on the project to maintain, not just the person who set up the build
process initially... the easiest tools for setting up a build process
are not necessariliy the best tools for maintaining a build when the
original build engineer moves elsewhere
On 2 November 2010 10:22, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Sorry, I was not able to answer to this message in the previous three
days...
If I understand your replies correctly, I cannot split the compile
phase into two with maven. This sounds pretty ... shitty ;-(
regards
Leon
On Fri, Oct 29, 2010 at 11:07 PM, Manfred Moser manf...@mosabuam.com
wrote:
You could move the code generator and the generated code out to a separate
project. That will save you build time and solve your problem.
manfred
Hi,
I have following requirement. I have a project, in which I have one
source folder which contains a code generator (run with apt), another
source folder
which contains code, which is processed by the generator from folder
1, and a third folder that relies on the code generated by the second
folder.
Therefor I need two compilation executions after each other, one for
the generator and one for the generated code.
Is this possible with maven?
thanx in advance
My pom file sofar:
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;
parent
groupIdnet.anotheria/groupId
artifactIdparent/artifactId
version1.1/version
/parent
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIddistributeme/artifactId
version1.0.0-SNAPSHOT/version
namedistributeme/name
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
source${project.basedir}/src/java/source
source${project.basedir}/src/support/source
source${project.basedir}/test/java/source
/sources
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdapt-maven-plugin/artifactId
version1.0-alpha-3/version
dependencies
dependency
groupIdorg.jfrog.maven.annomojo/groupId
artifactIdmaven-plugin-tools-anno/artifactId
version1.3.1/version
exclusions
exclusion
groupIdcom.sun/groupId
artifactIdtools/artifactId
/exclusion
Re: accessing settings.xml when specfiying user.home
Hello,
when you type mvn -Duser.home=j:\joe_user compile, you provide user.home to
maven. In your case, I think you want to provide this to the jvm that
executes maven, so you should try
set MAVEN_OPTS=-Duser.home=j:\joe_user compile
Cheers,
Vincent
2010/11/1 c...@netzero.net c...@netzero.net
I am having trouble accessing the settings.xml when running the following
command on my windows box:
mvn -Duser.home=j:\joe_user compile
where j:\joe_user is a samba mounted drive to my unix box in which the
.m2 directory exists. I've run with the -X switch so I can see what's
happening:
mvn -Duser.home=j:\joe_user -X compile
[DEBUG] Reading user settings from c:\Documents and
Settings\joe_user\.m2\settings.xml
[DEBUG] Reading global settings from
j:\joe_user\maven\apache-maven-3.0\conf\settings.xml
[DEBUG] Using local repository at j:\joe_user\.m2\repository
I've only included the interesting debug messages and you can see that I am
using version 3.0 as my M2_HOME is set to j:\joe_user\maven\apache-maven-3.0
Things run as expected when I copy the settings.xml file from my unix box
onto my windows box into the appropriate directory OR if i add the -s
option:
mvn -Duser.home=j:\joe_user -s j:\joe_user\.m2\settings.xml compile
My question is: based on the maven documentation, it appears that a user's
install is specified at ${user.home}/.m2/settings.xml therefore, should
specifying the user.home via -D option point to the correct location and NOT
the home directory (under windows)?
I apologize if this is answered elsewhere. I did perform several searches
prior to sending this email.
thanks
bill
DEAL OF THE YEAR: 2010 Honda Civic for $1,734.09
SPECIAL REPORT: High ticket items are being auctioned for an incredible 90%
off!
http://thirdpartyoffers.netzero.net/TGL3231/4ccebcea695e153f379st04vuc
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Vincent
Re: Dependency problem with jasper
On Tue, Nov 2, 2010 at 6:02 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2010/11/2 Clément TRUNG clement.tr...@syntesys.eu: the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Simple, call the Jasper forge administrator and ask him/her to fix it. Other options are: 1. install locally Jasper Reports artifacts and say goodbye to Jasper repositories +1 - Stick the artifacts you need for Jasper in your local repo manager. Working with the Jasper folks is difficult unless you're paying for support. ;) 2. install a Maven repository manager (e.g. Nexus) that can act as a proxy to Jasper Forge (however I don't know if it will work). -- Andrew Close - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Continuous Delivery and Maven
We use maven and continuous integration and it works very very well. SNAPSHOTS are a godsend when it comes to being flexible and delivering something quickly and tested quickly. We commit many times a day and it is unphathomable to create a concrete release for each of those commits. It would waste a lot of time and resources. When working with SNAPSHOTS you don't worry about what released version was that problem found on? You just simply say the error occurs on the trunk and fix it there. The trick here is to have fast feedback. So if you introduce an error today, you should know about that error today or at the latest tomorrow. So you don't have days or weeks go by before you get that feedback. My general advice for devs who get into the rut like the one on the google thread is to switch to concrete releases once you start approaching your release date. So lets say iterations 1 to 10 are on snapshots. Your product owner then feels that you have enough content to ship a release. Create a branch, cut a formal release and have your testing team test that release and iteration 11 with a release. You may have a couple of fixes to do on that branch and you may need to cut a new release to test what you fixed. The idea here though is that 99% of all the feature and bugs were tested and ironed out on SNAPSHOT builds. You just do your last iteration on formal releases. You wait as long as you can before before you move to concrete releases so you don't have to manage multiple branches and tags and all the complication that comes with formal releases. The version numbering would go something like this: 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-SNAPSHOT ... 1.0-01 1.0-02 1.0-03 You release to the field with 1.0-03. -Original Message- From: stug23 [mailto:pat.poden...@gmail.com] Sent: Monday, November 01, 2010 1:14 PM To: users@maven.apache.org Subject: Continuous Delivery and Maven I've been reading about Continuous Delivery http://continuousdelivery.com/ and trying to understand how to best combine Maven and Continuous Delivery. There is a thread in the Continuous Delivery google group where this discussion has started: http://groups.google.com/group/continuousdelivery/browse_thread/thread/c 8440681058f2db8 I would be curious as to whether there are other Maven developers following the Maven Users forum that have been looking Continuous Delivery and trying to grapple with the best way to use Maven in this approach. -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven- tp3245370p3245370.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Surefire NPE
Blind guess: maybe ${resource-bundle-path} is being set to a different value
when the user runs it?
On Mon, Nov 1, 2010 at 11:55 AM, Hinkle, Cameron cameron.hin...@nike.comwrote:
Greetings,
I've been using Maven and Surefire on a project for about a year now and
have sporadically seen a problem that I've always been able to get around
but want to get to the bottom of. It's a null pointer exception sometimes
when I run mvn and it tries to run all our tests. It happens rarely but
four different people on the project have run into it at one point or
another. For some reason if I bypass the tests and start my Jetty server
through maven, I can go back to run the tests after stopping Jetty and the
tests run just fine. This is typically my workaround.
Here is the output from the command line:
C:\workspaces\tesla\readiness-mobile\tesla-src-mobilemvn
[INFO] Scanning for projects...
[INFO]
[INFO] Building Templated Service Layer Assembler
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 6 resources
Downloading:
http://repo1.maven.org/maven2/com/nike/classes/2.2/classes-2.2.pom
[INFO] Unable to find resource 'com.nike:classes:pom:2.2' in repository
central (http://repo1.maven.org/maven2)
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to
C:\workspaces\tesla\readiness-mobile\tesla-src-mobile\target\classes
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 76 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
C:\workspaces\tesla\readiness-mobile\tesla-src-mobile\target\surefire-reports
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at java.util.Properties.setProperty(Properties.java:143)
at
org.apache.maven.surefire.booter.SurefireBooter.setForkProperties(SurefireBooter.java:510)
at
org.apache.maven.surefire.booter.SurefireBooter.forkSuites(SurefireBooter.java:483)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkOnce(SurefireBooter.java:385)
at
org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:246)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:581)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 6 seconds
[INFO] Finished at:
problem with maven-metadata.xml files
hello, the last days I saw following when ever I use a certain pom $ mvn rails3:rake -Dargs=db:setup -f Gemfile.pom Warning: JAVA_HOME environment variable is not set. [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building inflow - rails application 0.0.0 [INFO] Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/gemcutter/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rspec-rails/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/rubyforge/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/hoe/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json_pure/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml Downloading: http://repo1.maven.org/maven2/rubygems/json/maven-metadata.xml after deleting rm ~/.m2/repository/rubygems/hoe/resolver-status.properties rm ~/.m2/repository/rubygems/json/resolver-status.properties rm ~/.m2/repository/rubygems/json_pure/resolver-status.properties rm ~/.m2/repository/rubygems/rubyforge/resolver-status.properties rm ~/.m2/repository/rubygems/gemcutter/resolver-status.properties rm ~/.m2/repository/rubygems/rspec-rails/resolver-status.properties things were back to normal. is there some trick to get back to normal without removing those files manually ? regards, Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency problem with jasper
Thanks for your advise, I temporarily found a solution by modifying the url in the jasperreports pom.xml file in my local repository (repositories/repository tag) but it is obviously a dubious solution and i'll try look at the repository manager option when i have time. Clement, -- I temporarily found a solution by directly modifying jasperreports pom.xml (section 2010/11/2 Andrew Close acl...@gmail.com On Tue, Nov 2, 2010 at 6:02 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2010/11/2 Clément TRUNG clement.tr...@syntesys.eu: the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Simple, call the Jasper forge administrator and ask him/her to fix it. Other options are: 1. install locally Jasper Reports artifacts and say goodbye to Jasper repositories +1 - Stick the artifacts you need for Jasper in your local repo manager. Working with the Jasper folks is difficult unless you're paying for support. ;) 2. install a Maven repository manager (e.g. Nexus) that can act as a proxy to Jasper Forge (however I don't know if it will work). -- Andrew Close - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [m3] maven documentation - maven-site-plugin
It does support Maven 3. But you need to use the 3.0 branch of m-site-p. The latest is 3.0-beta-3 and you find the docs here: http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ It's somewhat hidden/secret as all the documentation is not fully updated. /Anders On Tue, Nov 2, 2010 at 12:33, Hauschel Fred Robert fredrobert.hausc...@cirquent.de wrote: Hey all, what is happening with the maven-site-plugin in future? Will it be supported for maven 3? I heard from any other plans keyword: idiom: access wiki. Does anybody have some information? Actually my sit generation crashes ;-( Fredy
Re: [m3] maven documentation - maven-site-plugin
On 2010-11-02 16:17, Anders Hammar wrote: It does support Maven 3. But you need to use the 3.0 branch of m-site-p. The latest is 3.0-beta-3 and you find the docs here: http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/ It's somewhat hidden/secret as all the documentation is not fully updated. I have added a new entry on the Plugins page for Site Plugin 3.0. It'll show up the next time the site is synced. http://maven.apache.org/plugins/ Hope that makes it easier to find. /Anders On Tue, Nov 2, 2010 at 12:33, Hauschel Fred Robert fredrobert.hausc...@cirquent.de wrote: Hey all, what is happening with the maven-site-plugin in future? Will it be supported for maven 3? I heard from any other plans keyword: idiom: access wiki. Does anybody have some information? Actually my sit generation crashes ;-( Fredy -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using release:branch
On Fri, Oct 29, 2010 at 3:18 PM, Jon Paynter kittl...@gmail.com wrote: Im trying to get the release:branch goal to create a new branch in my scm with a given version number, but it doesnt appear to be working. Ive tried various combinations of parameters from the release:prepare page, but none of them seem to do what I want. Which version of the release plugin are you using? Which SCM provider? so far I have this: mvn release:branch -DbranchName=TestBranch -DreleaseVersion=2.1.1 -DautoVersionSubmodules=true -DupdateWorkingCopyVersions=false -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false I haven't used that particular approach before, but most of what you have should work. However, I don't understand what the point is of a branch with a fixed version on it? Namely, the -DreleaseVersion=2.1.1 -DupdateVersionsToSnapshot=false combination doesn't seem to make sense to me. Does the plugin work as expected with something closer to a default configuration? When everything is done I want the following: - a new branch created named 'test branch' - pom files in the new branch updated to 2.1.1 - do not prompt me for every single new version number - current branch should be left unchanged So far what it seems to do is update my pom files to the new version number, commit that, then change everything back to the starting version number, commit that, make a new branch, and commit that. ending up with a new branch with no visible changes. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release:branch commiting things on tags
Really nobody has encountered the problem ?
Should I fill an issue then ?
Frederic
On Fri, Oct 15, 2010 at 7:08 PM, Frederic Camblor fcamb...@gmail.comwrote:
Hi maven users !
I learned something some days ago, about maven-release-plugin about its
branch goal.
Currently, I execute following command line :
mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.0:branch
-DautoVersionSubmodules=true -DtagBase=tags/ -Dtag=1.0.0
-DupdateBranchVersions=true -DreleaseVersion=2.0.0 -DbranchBase=branches/
-DbranchName=2.0.0
My goal, here, is to create a new branch called 2.0.0 from the 1.0.0 tag.
It works great but I found something crappy : some commit were made on the
1.0.0 tag hierarchy.
That is to say, the plugin is acting this way :
- Checkout tag ${tagBase}${tag} in working directory
- Modify pom to ${releaseVersion}-SNAPSHOT scm
- Commit pom (on tag 1.0.0 !!!)
- If something is going bad during the next two lines, your tag
hierarchy will be altered
- SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
hierarchy
- Re-Modify pom in working directory to ${tag}
- Re-Commit pom on tag 1.0.0
I would think it would act this way :
- SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
hierarchy
- Checkout ${branchBase}${branchName}/ in working directory
- Modify pom to ${releaseVersion}-SNAPSHOT
- Commit pom (on branch !) scm
Would it be some reason why the first strategy is applied ?
Am I badly using release:branch goal ?
Thanks in advance for your precisions.
Frédéric
Re: using release:branch
On Tue, Nov 2, 2010 at 9:44 AM, Zac Thompson zac.thomp...@gmail.com wrote: On Fri, Oct 29, 2010 at 3:18 PM, Jon Paynter kittl...@gmail.com wrote: Im trying to get the release:branch goal to create a new branch in my scm with a given version number, but it doesnt appear to be working. Ive tried various combinations of parameters from the release:prepare page, but none of them seem to do what I want. Which version of the release plugin are you using? Which SCM provider? Thanks for the reply. Our scm here is git so far I have this: mvn release:branch -DbranchName=TestBranch -DreleaseVersion=2.1.1 -DautoVersionSubmodules=true -DupdateWorkingCopyVersions=false -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false I haven't used that particular approach before, but most of what you have should work. However, I don't understand what the point is of a branch with a fixed version on it? Namely, the -DreleaseVersion=2.1.1 -DupdateVersionsToSnapshot=false combination doesn't seem to make sense to me. Does the plugin work as expected with something closer to a default configuration? Mabye I dont understand the purpose of the plugin my goal is to create a new branch from trunk or 'master' in git) with a new version number so development can start work on a new set of changes. So if the current branch is v2.0, i want to create a new branch labeled 2.1 (or 2.1-SNAPSHOT), and hand that to the developers to start work. Meanwhile, the current v 2.0 trunk should remain unchanged since thats the current production version, and I dont want to mess with it. After development on v2.1 is done, it will be merged back into the trunk branch and released to the users. I would much rather issue a single maven command to create the branch rather than having to run several commands in a row: create branch, switch branches, update pom versions, and checkin changes (4 commands vs 1). If the release plugin is not the right tool for this job - what would be?
Re: Dependency problem with jasper
On 02/11/2010 10:40 AM, Andrew Close wrote: On Tue, Nov 2, 2010 at 6:02 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2010/11/2 Clément TRUNGclement.tr...@syntesys.eu: the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Simple, call the Jasper forge administrator and ask him/her to fix it. Other options are: 1. install locally Jasper Reports artifacts and say goodbye to Jasper repositories +1 - Stick the artifacts you need for Jasper in your local repo manager. Working with the Jasper folks is difficult unless you're paying for support. ;) 2. install a Maven repository manager (e.g. Nexus) that can act as a proxy to Jasper Forge (however I don't know if it will work). 2 and then upload the Jasper jars into your Nexus so you don't lose them when you clean out your local Repo or switch computers. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency problem with jasper
Hi again, for those having the same issue, others have already posted at jasperforge : see http://jasperforge.org/plugins/espforum/view.php?group_id=102forumid=103topicid=80434 what is strange is that Mister Teodor Danciu (creator of JasperReports) doesn't remember having external dependencies in jasperforge repo... To be continued... PS: another solution stated in this thread is the use of the mirror/ tag in your settings.xml, which i just tested and worked greatly... -- 2010/11/2 Ron Wheeler rwhee...@artifact-software.com On 02/11/2010 10:40 AM, Andrew Close wrote: On Tue, Nov 2, 2010 at 6:02 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2010/11/2 Clément TRUNGclement.tr...@syntesys.eu: the maven-metadata file contains html code that Maven sure is unable to read. Obviously, I'm not Jasper forge administrator and can't change the way the site works, what are the solutions available to handle this kind of situation ? Simple, call the Jasper forge administrator and ask him/her to fix it. Other options are: 1. install locally Jasper Reports artifacts and say goodbye to Jasper repositories +1 - Stick the artifacts you need for Jasper in your local repo manager. Working with the Jasper folks is difficult unless you're paying for support. ;) 2. install a Maven repository manager (e.g. Nexus) that can act as a proxy to Jasper Forge (however I don't know if it will work). 2 and then upload the Jasper jars into your Nexus so you don't lose them when you clean out your local Repo or switch computers. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Request to re-open MNG-3472
-Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, October 29, 2010 1:14 PM To: users@maven.apache.org Subject: RE: Request to re-open MNG-3472 Hi Brian if diskspace was a concern i would concur but as each repository and their mirrors support terabyte capacity i would hold off on the purge i was bitten by a wizbang version maven plugin that wasnt tested with wizbank injector and failed when the maven-plugin's were injected using incorrect role and roleHint What in the world are you talking about? How can you claim that everyone's has the capability and the money to buy terabytes of disk space, especially for everyone's local repositories? From: brian.lev...@nokia.com To: users@maven.apache.org Date: Fri, 29 Oct 2010 15:28:27 +0200 Subject: RE: Request to re-open MNG-3472 I'm not suggesting that Maven periodically run a task to purge the repo. I'm suggesting that a settable policy be implemented such that a max number of versions of a snapshot artifact be kept in the local repo. When that limit is exceeded, the oldest version is deleted. Yes, it's easy enough to do an rm -rf on your local repo. But that assumes that you understand why you need to do this or have been told by your dev team to do this and that you remember to do it before you realize that a lot of disk space is being used up by something. This is even more of a problem when you have dozens of people performing builds on a variety of shared machines. It seems like many people don't realize that not everyone limits their use of maven to personal PCs with huge disks. When you have several people working on the same system oh, it's just a few GB quickly ends up turning into out of disk space. IMHO, a tool should never have unbounded access to resources such as disk space. Further, I don't think stakeholders (not all of which are developers) should need to understand the inner working of Maven or what they need to do work around a limitation such as this. -brian I definitely agree with this. It's hard enough to get people to clean up the files that the explicitly create. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Hi, As I've written in another reply in this thread, I have set 'project.build.sourceEncoding', but it isn't working! Roland On 02-11-10 18:52, Jörg Hohwiller wrote: Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-resources-plugin file-encoding
any luck replacing CP-1252 encoding with ISO-8859-1 ? Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. From: roland.asm...@adesso.at To: users@maven.apache.org Date: Tue, 2 Nov 2010 19:03:28 +0100 Subject: Re: maven-resources-plugin file-encoding Hi, As I've written in another reply in this thread, I have set 'project.build.sourceEncoding', but it isn't working! Roland On 02-11-10 18:52, Jörg Hohwiller wrote: Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
How do you mean? I have already told our developers to please switch to UTF-8 (as they should've been doing in the first place), but just in case they forget, I want to have Maven complain on their Windows-machines. I don't see how switching to ISO-8859-1 helps in this case? Roland On 02-11-10 19:11, Martin Gainty wrote: any luck replacing CP-1252 encoding with ISO-8859-1 ? Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. From: roland.asm...@adesso.at To: users@maven.apache.org Date: Tue, 2 Nov 2010 19:03:28 +0100 Subject: Re: maven-resources-plugin file-encoding Hi, As I've written in another reply in this thread, I have set 'project.build.sourceEncoding', but it isn't working! Roland On 02-11-10 18:52, Jörg Hohwiller wrote: Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Hi Roland, sorry. My mail client was out of sync. When I wrote the mail, no response to your post was visible to me. In this case it sounds like something very special. You can check... ... if you have any specific profiles in your POM that are OS dependent but I doubt that it is related ... if you have the exact same JVM version on both systems (maybe on linux you even have a different JVM implementation underhood, depending on your distro) ... if there is some effect by the VCS client that you use to checkout the sources on linux or windows. You can probably check with a hex-editor or get both versions on an usb-stick and diff them. Just some toughts but after all I am clue-less. Regards Jörg On 02.11.2010 19:03, Asmann, Roland wrote: Hi, As I've written in another reply in this thread, I have set 'project.build.sourceEncoding', but it isn't working! Roland On 02-11-10 18:52, Jörg Hohwiller wrote: Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Hmmm... Those last two are worth a shot... I'll try that tomorrow when I have access to the build-server again. There's no profiles in this project, so that can't be it. Roland On 02-11-10 19:16, Jörg Hohwiller wrote: Hi Roland, sorry. My mail client was out of sync. When I wrote the mail, no response to your post was visible to me. In this case it sounds like something very special. You can check... ... if you have any specific profiles in your POM that are OS dependent but I doubt that it is related ... if you have the exact same JVM version on both systems (maybe on linux you even have a different JVM implementation underhood, depending on your distro) ... if there is some effect by the VCS client that you use to checkout the sources on linux or windows. You can probably check with a hex-editor or get both versions on an usb-stick and diff them. Just some toughts but after all I am clue-less. Regards Jörg On 02.11.2010 19:03, Asmann, Roland wrote: Hi, As I've written in another reply in this thread, I have set 'project.build.sourceEncoding', but it isn't working! Roland On 02-11-10 18:52, Jörg Hohwiller wrote: Hi Roland, On 01.11.2010 18:03, Asmann, Roland wrote: configure Maven to already fail the build on Windows or have it configured so that it works on Linux? I want the behavior of the two builds to be the same -- as it should be! I suppose the difference comes from the different default encodings of the OS (check your locale settings on Linux, e.g. LC_ALL). However to be OS-independant please use properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Jörg - 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 -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Jörg Hohwiller wrote: Hi Roland, sorry. My mail client was out of sync. When I wrote the mail, no response to your post was visible to me. In this case it sounds like something very special. You can check... ... if you have any specific profiles in your POM that are OS dependent but I doubt that it is related ... if you have the exact same JVM version on both systems (maybe on linux you even have a different JVM implementation underhood, depending on your distro) ... if there is some effect by the VCS client that you use to checkout the sources on linux or windows. You can probably check with a hex-editor or get both versions on an usb-stick and diff them. This would have been my guess also. If you process a Cp1252 encoded file on Windows as UTF-8, this might simply lead to an garbled character. On Linux you have nowaday normally UTF-8 as system encoding and Cp1252 decoded as UTF-8 might result in an invalid UTF-8 character if processed as UTF-8 again. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Ha! Indeed, the output file on Windows contains garbled characters! Great, so I know that the output is sh*t, but how to let Maven cry out so those darn stubborn developers finally get the point? Roland On 02-11-10 19:22, Jörg Schaible wrote: Jörg Hohwiller wrote: Hi Roland, sorry. My mail client was out of sync. When I wrote the mail, no response to your post was visible to me. In this case it sounds like something very special. You can check... ... if you have any specific profiles in your POM that are OS dependent but I doubt that it is related ... if you have the exact same JVM version on both systems (maybe on linux you even have a different JVM implementation underhood, depending on your distro) ... if there is some effect by the VCS client that you use to checkout the sources on linux or windows. You can probably check with a hex-editor or get both versions on an usb-stick and diff them. This would have been my guess also. If you process a Cp1252 encoded file on Windows as UTF-8, this might simply lead to an garbled character. On Linux you have nowaday normally UTF-8 as system encoding and Cp1252 decoded as UTF-8 might result in an invalid UTF-8 character if processed as UTF-8 again. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. -
Re: Request to re-open MNG-3472
On 02/11/2010 1:20 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, October 29, 2010 1:14 PM To: users@maven.apache.org Subject: RE: Request to re-open MNG-3472 Hi Brian if diskspace was a concern i would concur but as each repository and their mirrors support terabyte capacity i would hold off on the purge i was bitten by a wizbang version maven plugin that wasnt tested with wizbank injector and failed when the maven-plugin's were injected using incorrect role and roleHint What in the world are you talking about? How can you claim that everyone's has the capability and the money to buy terabytes of disk space, especially for everyone's local repositories? From: brian.lev...@nokia.com To: users@maven.apache.org Date: Fri, 29 Oct 2010 15:28:27 +0200 Subject: RE: Request to re-open MNG-3472 I'm not suggesting that Maven periodically run a task to purge the repo. I'm suggesting that a settable policy be implemented such that a max number of versions of a snapshot artifact be kept in the local repo. When that limit is exceeded, the oldest version is deleted. Yes, it's easy enough to do an rm -rf on your local repo. But that assumes that you understand why you need to do this or have been told by your dev team to do this and that you remember to do it before you realize that a lot of disk space is being used up by something. This is even more of a problem when you have dozens of people performing builds on a variety of shared machines. It seems like many people don't realize that not everyone limits their use of maven to personal PCs with huge disks. When you have several people working on the same system oh, it's just a few GB quickly ends up turning into out of disk space. The guys with small disk can just delete their entire local repo and let maven rebuild it by itself from your central server which should have lots of space. One or two builds usually gets us back to a fast build from localhost. If your central server is short of space spend $100 and add a terabyte or 2. IMHO, a tool should never have unbounded access to resources such as disk space. Further, I don't think stakeholders (not all of which are developers) should need to understand the inner working of Maven or what they need to do work around a limitation such as this. -brian I definitely agree with this. It's hard enough to get people to clean up the files that the explicitly create. 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: maven-resources-plugin file-encoding
Hi Roland, Asmann, Roland wrote: Ha! Indeed, the output file on Windows contains garbled characters! Great, so I know that the output is sh*t, but how to let Maven cry out so those darn stubborn developers finally get the point? use the verifier plugin to ensure that the generated file actually contain the umlaut (try to use a \u0XXX notation in the contains tag). - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-resources-plugin file-encoding
Hi Jörg, That plugin is tuned for single files, right? That would mean I'd have to have all developers include the plugin with its configuration in their POMs... I'd rather have a solution in a parent-POM (we use a company-wide master)... Also, if there is at least one correct Umlaut in there, it will probably say the file is correct as well, right? So, in all, it's a nice workaround, but still not an actual solution... :-( Roland On 02-11-10 19:53, Jörg Schaible wrote: Hi Roland, Asmann, Roland wrote: Ha! Indeed, the output file on Windows contains garbled characters! Great, so I know that the output is sh*t, but how to let Maven cry out so those darn stubborn developers finally get the point? use the verifier plugin to ensure that the generated file actually contain the umlaut (try to use a \u0XXX notation in the contains tag). - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. -
RE: Request to re-open MNG-3472
-Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] The guys with small disk can just delete their entire local repo and let maven rebuild it by itself from your central server which should have lots of space. One or two builds usually gets us back to a fast build from localhost. To delete the repo of the guy the next desk over I need to wait for him to be in the office, then email or call him, then explain what I want him to delete. And that's all only if I actually notice that that's what's taking up all the space. Even if I'm just cleaning up my own files, why should I have to spend all this time thinking about it and doing things to fix it? For example, I don't have to think about clearing out the cache in my browser, why should maven's cache be any different? If your central server is short of space spend $100 and add a terabyte or 2. Oh, are you going to fund the additional disk space, and the extra backup resources needed, and pay for time it takes to actually update the disk array and provision the space in my company's SAN? If so, great! My point it that using more disk space has more costs than just the price of a drive platter. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Request to re-open MNG-3472
My point it that using more disk space has more costs than just the price of a drive platter. It also has a lot of savings. And besides, you don't need all the frills. What you doing right now sounds very very costly. A simply investment in a bare bones server will save you a lot. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Request to re-open MNG-3472
On 02/11/2010 3:29 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] The guys with small disk can just delete their entire local repo and let maven rebuild it by itself from your central server which should have lots of space. One or two builds usually gets us back to a fast build from localhost. To delete the repo of the guy the next desk over I need to wait for him to be in the office, then email or call him, then explain what I want him to delete. And that's all only if I actually notice that that's what's taking up all the space. Even if I'm just cleaning up my own files, why should I have to spend all this time thinking about it and doing things to fix it? For example, I don't have to think about clearing out the cache in my browser, why should maven's cache be any different? Each of my guys is responsible for his own workstation. They know what maven is doing. Maven would have a hard time knowing what to throw out but I suppose that if it supported a simple rule-set (max space allowed, delete oldest Snapshots if space needed) and the ability to turn automated cleaning on and off it might be useful. If your central server is short of space spend $100 and add a terabyte or 2. Oh, are you going to fund the additional disk space, and the extra backup resources needed, and pay for time it takes to actually update the disk array and provision the space in my company's SAN? If so, great! My point it that using more disk space has more costs than just the price of a drive platter. You are right. I am not sure that a Maven Repo really belongs in a corporate datacentre since it contains nothing that can not be replaced and is mostly stuff that comes from outside sources anyway. You could always move your repo to the cloud and pay a few dollars per month for the storage or just add a local desktop server to the development group. 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
Maven Site Customization
I have tried setting up site.xml in a parent pom project, with the following: ?xml version=1.0 encoding=ISO-8859-1? site project name=iCAMS bannerLeft nameiCAMS/name srcimages/AER_logo_k.jpg/src hrefhttp://aerosource.aero.org/icams/href /bannerLeft bannerRight srchttp://maven.apache.org/images/maven-small.gif/src /bannerRight publishDate position=right/ version position=right/ poweredBy logo name=Aerospace Application Development Department href=https://aerosource.aero.org/add; img=images/AER_logo_k.jpg/ /poweredBy body menu name=iCAMS Project inherit=top item name=Overview href=index.html/ /menu menu ref=reports/ links item name=Aerosource Project href=http://aerosource/icams/ item name=Inside Aerospace href=http://info.aero.org// item name=Aerospace Corporation href=http://www.aero.org// /links /body /site However, when I run mvn site-deploy and access the site, the graphics I mention are not shown. I do see my index.html as the Overview page, but if I navigate to any link in the navigation panel, I can no longer return to Overview (it is not included in the panel). None of my links are included either. This looks like a wonderfully powerful way to document our project (multi-module with a grandparent POM project, a parent POM project (with modules) and modules under that. But, I have yet to make this basic part work. Is there any better documentation of this customization, or working example to follow? Thanks! Ginni -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Site-Customization-tp3247261p3247261.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-resources-plugin file-encoding
Hi Roland, Asmann, Roland wrote: Hi Jörg, That plugin is tuned for single files, right? That would mean I'd have to have all developers include the plugin with its configuration in their POMs... I'd rather have a solution in a parent-POM (we use a company-wide master)... Also, if there is at least one correct Umlaut in there, it will probably say the file is correct as well, right? So, in all, it's a nice workaround, but still not an actual solution... :-( yes, that would have been a single file solution only. However, the real problem is, that some people commit files with wrong encoding. If you tell Maven that the file *is* UTF-8, then you have to ensure, that only files in this encoding can be committed at all e.g. in Subversion using a commit hook. The problem is the *detection*. We normally force ASCII. This is fine for all kind of source code and easy to detect. If some non-ASCII character has to be in the code, you can always encode it with a Unicode notation (e.g. \u). This is true for Java, property files, JavaScript, XML, HTML, ... - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Migration from Ant to Maven2
Hi all,
Currently I am working on migrating my project from Ant to Maven2.
However, I encountered some issues and I am not sure how do I do that in
Maven.
In Ant, subset of source code will be complied sequentially with different
jars. Once done, the compiled classes will be packed in to jar file.
target name=tomcat5.5-valve depends=sources-uptodate
unless=uptodate.sources
javac destdir=${build.classes.dir} srcdir=${src.dir} debug=on
source=1.5
include name=**/Tomcat55LoginValve.java/
classpath refid=**/tomcat55/*.jar/
/javac
/target
target name=tomcat5.0-valve depends=sources-uptodate
unless=uptodate.sources
javac destdir=${build.classes.dir} srcdir=${src.dir} debug=on
source=1.5
include name=**/Tomcat50LoginValve.java/
classpath refid=**/tomcat50/*.jar/
/javac
/target
target name=build-jar depends=tomcat5.5-valve,tomcat5.0-valve
unless=uptodate.sources
!-- pack classes into jar file --
/target
Does anyone know how this can be achieved by Maven?
Or does anyone know any maven-plugin can do this?
Thanks a lot
Tsun
Re: Migration from Ant to Maven2
Maven Yu wrote:
Hi all,
Currently I am working on migrating my project from Ant to Maven2.
However, I encountered some issues and I am not sure how do I do that in
Maven.
In Ant, subset of source code will be complied sequentially with different
jars. Once done, the compiled classes will be packed in to jar file.
target name=tomcat5.5-valve depends=sources-uptodate
unless=uptodate.sources
javac destdir=${build.classes.dir} srcdir=${src.dir}
debug=on
source=1.5
include name=**/Tomcat55LoginValve.java/
classpath refid=**/tomcat55/*.jar/
/javac
/target
target name=tomcat5.0-valve depends=sources-uptodate
unless=uptodate.sources
javac destdir=${build.classes.dir} srcdir=${src.dir}
debug=on
source=1.5
include name=**/Tomcat50LoginValve.java/
classpath refid=**/tomcat50/*.jar/
/javac
/target
target name=build-jar depends=tomcat5.5-valve,tomcat5.0-valve
unless=uptodate.sources
!-- pack classes into jar file --
/target
Does anyone know how this can be achieved by Maven?
Build an own project for each of the variants and use later on another
project with the shade plugin to put all together.
Or does anyone know any maven-plugin can do this?
You cannot have multiple dependency trees in the same lifecycle. This is
nothing a plugin can solve.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Customization
On 2010-11-02 20:08, ginni wrote: I have tried setting up site.xml in a parent pom project, with the following: ?xml version=1.0 encoding=ISO-8859-1? site project name=iCAMS bannerLeft nameiCAMS/name srcimages/AER_logo_k.jpg/src hrefhttp://aerosource.aero.org/icams/href /bannerLeft bannerRight srchttp://maven.apache.org/images/maven-small.gif/src /bannerRight publishDate position=right/ version position=right/ poweredBy logo name=Aerospace Application Development Department href=https://aerosource.aero.org/add; img=images/AER_logo_k.jpg/ /poweredBy body menu name=iCAMS Project inherit=top item name=Overview href=index.html/ /menu menu ref=reports/ links item name=Aerosource Project href=http://aerosource/icams/ item name=Inside Aerospace href=http://info.aero.org// item name=Aerospace Corporation href=http://www.aero.org// /links /body /site However, when I run mvn site-deploy and access the site, the graphics I mention are not shown. Have you included the images in the src/site/resources folder of the project you are building? Note that such resources are not inherited. I do see my index.html as the Overview page, but if I navigate to any link in the navigation panel, I can no longer return to Overview (it is not included in the panel). None of my links are included either. That is to be expected, as the link you have in your site.xml are external links, i.e. full URLs. This looks like a wonderfully powerful way to document our project (multi-module with a grandparent POM project, a parent POM project (with modules) and modules under that. But, I have yet to make this basic part work. Is there any better documentation of this customization, or working example to follow? The Site Plugin has docs at http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html Thanks! Ginni -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] maven deptools plugin 1.1 released
Version 1.1 of maven deptools plugin now supports maven 3 and the maven enforcer plugin maven deptools plugin ...gives build error if maven resolves transient dependencies in such a way that the none-newest version is chosen. This plugin has turned out to be very useful in the company I work for. The plugin can be found here: http://github.com/mbknor/deptools From the README: Maven deptools plugin - Supports Maven 3 * Now also as an enforcer-plugin rule * (See description at the bottom of this README) --- Maven 2 and Maven 3 plugin which gives build error if maven resolves transient dependencies in such a way that the none-newest version is chosen. At work we have all kinds of different dependencies problems related to transient dependencies. Transient dependencies has many downsides, but in my opinion, the alternative is worse. This plugin makes it possible to have the build process fail if not the newest version of a referred dependency is selected by mavens dependency resolving. It is possible to include/exclude which artifacts should be included in the check. This will make it possible for us to check dependency resolving for all inhouse APIs and projects.. The plugin is written in Scala For example-maven-project showing the problem and the pluging, have a look here:http://github.com/mbknor/deptools/tree/master/test/ --- If you find a bug or have a feature request, report them here:http://github.com/mbknor/deptools/issues --- The plugin can be found in this repository: pluginRepositories pluginRepository idmbk_mvn_repo/id namembk_mvn_repo/name urlhttp://github.com/mbknor/mbk_mvn_repo/raw/master//url /pluginRepository /pluginRepositories (PS: the repository does not work from Nexus(http://nexus.sonatype.org/)) --- To run the plugin from the command line: mvn deptools.plugin:maven-deptools-plugin:version-checker To include/exclude dependencies use one/both of these settings: -DexcludePattern=regular expression -DincludePattern=regular expression --- If you want to automatically include the deptools plugin in your build, so it can fail your build if it finds an error, you can do it like this: build plugins plugin groupIddeptools.plugin/groupId artifactIdmaven-deptools-plugin/artifactId !-- Use these optional settings to include and/or include dependencies from the check: configuration includePattern a valid regular expression /includePattern excludePattern a valid regular expression /excludePattern /configuration The pattern is matched against the string groupId:artifactId for all dependencies in the dependency-path. Example: includePatterncom.kjetland:.*/includePattern The pattern above will only fail the build if an error is found on any dependency linked to from a an artifact with groupId equal to 'com.kjetland' -- executions execution phasecompile/phase goals goalversion-checker/goal /goals /execution /executions /plugin /plugins /build pluginRepositories pluginRepository idmbk_mvn_repo/id namembk_mvn_repo/name urlhttp://github.com/mbknor/mbk_mvn_repo/raw/master//url /pluginRepository /pluginRepositories -- The plugin can also be used as a maven-enforcer-plugin rule. For example-maven-projects showing the problem and the plugin as enforcer-rule, have a look here:http://github.com/mbknor/deptools/tree/master/test/enforcer-tests/ This is done like like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId dependencies dependency groupIddeptools.plugin/groupId artifactIdenforcer-rule/artifactId version1.1/version /dependency /dependencies configuration rules requireMavenVersion version2.0.6/version /requireMavenVersion myCustomRule implementation=deptools.plugin.enforcerrule.DeptoolsEnforcerRule includePatterncom.kjetland:.+/includePattern excludePattern.*commons-logging.*/excludePattern
Dependency resolution and version ranges
Hi, How does Maven use version ranges when resolving a specific version of a dependency? I've read this page http://docs.codehaus.org/x/IGU - a design document for Maven 2.0 (I'm using 2.2.1) - but it doesn't quite answer my question (or I don't understand its contents). I have project A and B. A declares a dependency on (say) org.springframework:spring-context with a version range of [2.5,) A also declares B as a dependency. B declares a dependency on org.springframework:spring-context with a version of 3.0.2.RELEASE. When I view the dependency tree of project A, it resolves spring-context to version 2.5.6. If I understand the design document correctly, what I would expect to happen is for project A to resolve spring-context to 3.0.2.RELEASE (the highest soft requirement inside the prescribed range), according to the following statement: Default strategy: Of the overlapping ranges, the highest soft requirement is the version to be used. If there are no soft requirements inside the prescribed ranges, the most recent version is used. If that does not fit the described ranges, then the most recent version number in the prescribed ranges is used. If the ranges exclude all versions, an error occurs. I guess I'm just asking if someone can enlighten me: am I mis-reading the design document? Is it out of date? Most importantly, if someone could tell me why I am seeing the result I'm seeing I would really appreciate it. Many thanks, Elliot -- View this message in context: http://maven.40175.n5.nabble.com/Dependency-resolution-and-version-ranges-tp3247903p3247903.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
