Is build number available in ant?
Does anyone know if Continuum passes the build number in to the forked build process, maybe as an environmental?
NPE on date call while executing SCM command
I'm getting the following exception during the build, about two-thirds of the runs. Anyone else seeing this with 1.0.3? 50961296 [SocketListener0-0] INFO org.apache.maven.continuum.Continuum - Enqueuing 'temp' (Build definition id=11). 50961827 [Thread-2] INFO org.apache.maven.continuum.scm.ContinuumScm - Updating project: id: '6', name 'temp'. 50961837 [Thread-2] INFO org.apache.maven.scm.manager.ScmManager - Updating 'D:\BuildMachine\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\6' from 'D:\ivory'. 51013783 [Thread-2] ERROR org.apache.maven.continuum.buildcontroller.BuildController - Error while building project. org.apache.maven.continuum.scm.ContinuumScmException: Error while update sources. at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) at org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command. at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) at org.apache.maven.scm.provider.local.LocalScmProvider.update(LocalScmProvider.java:191) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) ... 5 more Caused by: java.lang.NullPointerException at java.util.Date.getMillisOf(Date.java:938) at java.util.Date.after(Date.java:911) at org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:89) at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) ... 9 more
Execute specific process on maven success and failure.
Does anyone know if there is a way to execute one of two processes dependent on either the success or failure of a maven build. Executng the process needs to be independent of the build lifecycle ie doesn't matter if it fails at clean or test or deploy, just the fact that maven has failed should cause the 'failed' process to execute. The process to execute could either be a shell script, an ant task or an ssh command on a remote machine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven bug?
Hi, I´m trying Maven and followed the simple guide which is included in the book Bettter build with Maven and it is also the 5 minute guide. Everything goes fine, but when I try to package the sample app, or test it, I got this exception: [INFO] Surefire report directory: C:\maven_projekt\application\target\surefire-r eports org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantia te and execute Surefire; nested exception is java.lang.ClassNotFoundException: o rg.apache.maven.surefire.Surefire java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(Isolat edClassLoader.java:103) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:281) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:818) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Sat Mar 03 13:45:37 CET 2007 [INFO] Final Memory: 5M/11M [INFO] Surfire is presented in my local repository, but Maven does not see it? Please help :) -- Pavel Štěpánek [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
On 3/3/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: Howard, can you take a look at it? It demonstrates your use case with a .properties file, and also one with html files for Javadoc that I ran into with an archetype for Shale. FYI: http://jira.codehaus.org/browse/ARCHETYPE-65 Restore the ability to "package" non-Java resources -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the simplest way to populate a remote depot?
Tom Huybrechts wrote: Read That Fine Manual : http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html Thanks, sorry Now if someone could tell me how to get the site generation to work... (see other mail) -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cargo maven 2 plugin : timeout when deploying to JBoss 4x
Hi Guillaume,
On Feb 22, 2007, at 4:29 PM, Guillaume Duchesneau wrote:
Hi,
We are in the process of creating an integration test suite for a J2EE
project using the Cargo Maven 2 plugin with a JBoss 4.0 container.
When
we execute mvn integration-test, the jboss zip is correctly
expanded and
our war is copied at the right place. The problem we have is that our
application takes more than 20 seconds to deploy and Cargo throws an
exception saying that the timeout is exceeded. I do not see any
configuration that can override the timeout for a deployable... is
there
one? Or is there any workaround for that kind of problem?
This would be best posted on the cargo lists...
Yes there are ways to set the timeout. See http://cargo.codehaus.org/
Maven2+Plugin+Reference+Guide
Also, is there a way to tell to the installer (zipUrlInstaller) to
force
a cleanup and a full reinstall (i.e. delete the install dir and
re-expand the zip file)?
No but I don't understand why this would be needed. Could you please
post any further questions on the cargo lists?
Thanks
-Vincent
Here is our plugin config in the pom.xml:
org.codehaus.cargo
cargo-maven2-plugin
false
jboss4x
file:///${jboss.distribution.dir}/JBoss4.0.zip
${installDir}
${log.dir}/cargo.log
${log.dir}/jboss.log
existing
${installDir}/jboss/server/default
start-container
pre-integration-testphase>
start
deploy
org.xyz
my-app
war
http://localhost:8080/index.jsf
stop-container
post-integration-testphase>
stop
Here is the error trace:
[INFO]
--
--
[INFO] Deployable failed to finish deploying within the timeout period
[2]. The Deployable state is thus unknown.
[INFO]
--
--
[INFO] Trace
org.codehaus.cargo.container.ContainerException: Deployable failed to
finish deploying within the timeout period [2]. The Deployable
state
is thus unknown.
at
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch
(Deploye
rWatchdog.java:109)
at
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watchForAva
il
ability(DeployerWatchdog.java:78)
at
org.codehaus.cargo.container.spi.deployer.AbstractLocalDeployer.deploy
(A
bstractLocalDeployer.java:98)
at
org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSi
ng
leDeployable(DeployerDeployMojo.java:75)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOn
Al
lDeployables(AbstractDeployerMojo.java:106)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.execute
(AbstractDeployerM
ojo.java:43)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginMa
nager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Default
LifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif
ec
ycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultL
ifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand
le
Failures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment
s(
DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifec
ycleExecutor.java:140)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
su
Re: What is the simplest way to populate a remote depot?
Read That Fine Manual : http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html On 3/3/07, Christian Goetze <[EMAIL PROTECTED]> wrote: I have some third party jars and want to place them in our common remote repo. I've been placing them there, writing their pom file and doing the sha1sum by hand. Is there some kind of deploy target for this which would make it easier? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is the simplest way to populate a remote depot?
I have some third party jars and want to place them in our common remote repo. I've been placing them there, writing their pom file and doing the sha1sum by hand. Is there some kind of deploy target for this which would make it easier? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
On 3/3/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: I think a good way to demonstrate the problem would be to patch the quickstart archetype to include both a package.html file (which should live in src/main/java so it doesn't get included in the jar) and src/main/resources/App.properties which should get packaged with the Java source and included in the jar. That immediately raised the problem of needing package.html to land in the package structure, but overview.html to stay at the top, directly in src/main/java. I took the quickstart archetype to the Maven sandbox and added the files mentioned above: http://svn.apache.org/repos/asf/maven/sandbox/trunk/archetype/maven-archetype-quickstart/ Howard, can you take a look at it? It demonstrates your use case with a .properties file, and also one with html files for Javadoc that I ran into with an archetype for Shale. There is already an issue open that talks about package.html (which mysteriously just does not get included in the archetype jar). http://jira.codehaus.org/browse/ARCHETYPE-62 And at this point, we should adjourn to the dev list to talk about how to fix this. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 settings.xml
On 3/1/07, sarancse <[EMAIL PROTECTED]> wrote: Hi I am looking for a sample settings.xml file. Could anyone upload it to me? It will be very useful for Maven2 beginners. Hi, I also find uneasy to configure the settings.xml file. I have worked a little on a GUI to configure Maven2. I would be happy that you try the alpha-version and give me feedback. http://code.google.com/p/m2settings/ -- Régis http://regis.decamps.info/
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
On 3 Mar 07, at 10:29 AM 3 Mar 07, Wendy Smoak wrote: On 3/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Before reading that what did you think something like: 1.0 meant? I'm actually interested in what general user opinion is here. I suppose I've never reconciled how I thought it ought to work, with the actual behavior of "nearest" in the directed graph It's not a graph unfortunately which is a fundamental mistake in the current artifact mechanism. It needs to changed to have the graph be a first class citizens. No reliable transformation can occur without a graph. (which I like) coupled with the unpredictable things that would happen with dependencyManagement + transitivity. (Fixed in 2.0.5?) MNG-1577 is not fixed. For 2.0.6. But how does this change things? If I declare a dependency on 1.0 and something two levels out declares [2.0], what do I get in my webapp? Try it but according to what's documented it would cause a problem. Because the only version that could be used is [2.0], if many dependencies used hard versions then you are fundamentally screwed. This is why the soft versions are the default and it wiggles around. Does [...] syntax allow transitive dependencies to override my choices? If everyone switches to [...] then are we back where we started with "nearest" ? Well, anything down stream that uses hard versions will require everything else to include that hard version in the range or it will fail according to the rules. The actual calculations to find suitable ranges requires a graph, walking down branches and sometimes back tracking and throwing results away. I've been looking at how Gentoo/RPM/OSGi calculate ranges and we need something similar. We need to seriously rethink what we have for artifact resolution. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
Howard Lewis Ship wrote: [...] Hey thanks! appears to work with -DpackageName=x.y.z to place the various Java places in the right place under src/main/java. But I can't find the equivalent for a resource file. Hmm. How about just adding those to ? Manos On 3/3/07, Manos Batsis <[EMAIL PROTECTED]> wrote: Howard Lewis Ship wrote: > I'm trying to create a archetype where some of my Java source files > have related resources. Thus, if I have a Java source as > src/main/java/pages/Start.java, I would like to have a companion > src/main/resources/pages/Start.properties. > > In the generated application, these would both be qualified with the > package name, ex: src/main/java/org/example/myapp/pages/Start.java and > src/main/resources/org/example/myapp/pages/Start.properties. > > The .java file is no problem, but I haven't found how to do the > related resource. Err, i cant really answer your question but can you please tip me on how to do this for the java files at least? I asked the question some time ago [1], maybe my terminology probably stopped people from passing an answer. I was thinking to go the antrun route and work something out there, in any case if a solution is available it would be of great help. [1] http://www.nabble.com/Arbitary-directory-package-names-with-archetype:create--t3285139s177.html Many thanks in advance, Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
On 3/2/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: As a under , it isn't put in the proper directory (the package name interpolation does not occur). As a under , it doesn't seem to do anything at all. Ideas? This (package name interpolation) used to work if you specified your resources in the section. But last time I tried it, I got an error from a element that was not in src/main/java. There seems to be no way to get non-Java resources into a package structure now. I think a good way to demonstrate the problem would be to patch the quickstart archetype to include both a package.html file (which should live in src/main/java so it doesn't get included in the jar) and src/main/resources/App.properties which should get packaged with the Java source and included in the jar. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
I actually thought that 1.0 meant that I was getting 1.0 of the artifact but if something else needed a newer version then I would get that. The problem with nearness is that you have to understand every dependency tree for every dependency you use. It could be as in our case that 7 layers deep into the tree far far from our code there is an issue that is causing this downgrading. The issue we have is that we are using Jasper Reports as well as an open source persistence frameworks and somewhere down in the guts of those dependencies they are walking on each other. The fix is for me to go into all those projects and figure out what is going on and fix them in my pom.xml. This is "ok" however I don't see the problem until run time when I access those frameworks and they die. We ran for several days until someone actually produced a chart and the system died. I actually think that frameworks should not be using the [ notation cause that is what is causing the null pointer when we include Jasper and there is no way to override it without mucking in their pom. I guess bottom line is we need a best practices document for frameworks developers like apache commons and users like me so that there is a predictable system in place with no mystery as to what we are getting. Scott On Mar 3, 2007, at 8:29 AM, Wendy Smoak wrote: On 3/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Before reading that what did you think something like: 1.0 meant? I'm actually interested in what general user opinion is here. I suppose I've never reconciled how I thought it ought to work, with the actual behavior of "nearest" in the directed graph (which I like) coupled with the unpredictable things that would happen with dependencyManagement + transitivity. (Fixed in 2.0.5?) But how does this change things? If I declare a dependency on 1.0 and something two levels out declares [2.0], what do I get in my webapp? Does [...] syntax allow transitive dependencies to override my choices? If everyone switches to [...] then are we back where we started with "nearest" ? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
tapestry-simple .classpath .project src/main/webapp/WEB-INF/web.xml src/main/webapp/WEB-INF/Start.html src/main/resources/log4j.properties src/test/java/PLACEHOLDER src/test/resources/PLACEHOLDER src/main/java/pages/Start.java src/main/java/services/AppModule.java appears to work with -DpackageName=x.y.z to place the various Java places in the right place under src/main/java. But I can't find the equivalent for a resource file. On 3/3/07, Manos Batsis <[EMAIL PROTECTED]> wrote: Howard Lewis Ship wrote: > I'm trying to create a archetype where some of my Java source files > have related resources. Thus, if I have a Java source as > src/main/java/pages/Start.java, I would like to have a companion > src/main/resources/pages/Start.properties. > > In the generated application, these would both be qualified with the > package name, ex: src/main/java/org/example/myapp/pages/Start.java and > src/main/resources/org/example/myapp/pages/Start.properties. > > The .java file is no problem, but I haven't found how to do the > related resource. Err, i cant really answer your question but can you please tip me on how to do this for the java files at least? I asked the question some time ago [1], maybe my terminology probably stopped people from passing an answer. I was thinking to go the antrun route and work something out there, in any case if a solution is available it would be of great help. [1] http://www.nabble.com/Arbitary-directory-package-names-with-archetype:create--t3285139s177.html Many thanks in advance, Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
On 3/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Before reading that what did you think something like: 1.0 meant? I'm actually interested in what general user opinion is here. I suppose I've never reconciled how I thought it ought to work, with the actual behavior of "nearest" in the directed graph (which I like) coupled with the unpredictable things that would happen with dependencyManagement + transitivity. (Fixed in 2.0.5?) But how does this change things? If I declare a dependency on 1.0 and something two levels out declares [2.0], what do I get in my webapp? Does [...] syntax allow transitive dependencies to override my choices? If everyone switches to [...] then are we back where we started with "nearest" ? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Ah now I get it I need to include [ ] around my dependencies. I will try that and see if it makes a difference. I thought that as a general rule that versions numbers were fairly well defined. If a project decides not to play by the generally accepted standards then it seems that would be the exception not the rule. I would assume that downgrading from 3.2 to 2.1 would not be an expected outcome. I do see that many of the apache projects use the 2nd position as a compatible version and only use 2 rather than 3 numbers. I would assume that most projects follow the rule that changes in the 2 or 3 position represent changes that are upwardly compatible for example 1.6.2 can be use in place of 1.6.1 and 1.7 can be used in place of 1.6. However even if projects are not following the standard I would expect the system to be more stable if you replace 2.1 with 3.2 and deal with those issues rather than replacing 3.2 with 2.1 and knowing it will break. Maybe a simple report we can run on the system that would indicate any downgrades that are being done by Maven with a red star so that we are aware the change is taking place and can resolve them manually. I personally would expect the system to always upgrade my dependencies and never downgrade them. Upgrading will seldom yield an issue and if it can be identified and dealt with then that is even better. Downgrading will always yield an issue and mean that you will always have issues that you must deal with. Why won't a simple version match work when resolving dependencies. 1.6 replaces 1.7 , 3.2 replaces 2.1 and then warn the user via a report or message that they need to check the dependencies and allow them to override the change. SInce most of the time we cannot control the nearness without putting all the dependencies in our local project it seems to be we are back to the Maven 1 approach of including all dependencies including transitive ones in our project otherwise we run the risk of introducing runtime errors. Any way that is my 2 cents. I still think you guys built an awesome system and I just need to work out the quirks with very large and complex projects. As I learn more about what the system does I can make changes to adapt. It is important to get the information out so that people realize what can happen and what to look for. We can develop reports to help people find and address situations like I have encountered. Thanks for the help and I will test the change to hard dependencies on Monday and see what that yields us. At least i can fix the issue in one location rather than having to include a bunch of bogus dependencies in all of our projects. Thanks again for the information and suggestions. Scott Ryan On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote: On 1 Mar 07, at 10:11 PM 1 Mar 07, Scott Ryan wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a "nearness" process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons- Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the "nearness" process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? It is impossible for us to know what the most current compatible version is. A lot of groups are careless with API changes and for a first take we decided that you know what you need to use so any specification closest to your project wins. Almost no work has been done on the artifa
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Yes I have over a hundred hard versions listed in my parent pom and it is ignoring them all during resolution except for internally refereced dependencies which is kind of what I expected. The one thing it does guarantee is that if all my users just put in the groupId and artifactId without the version then it gets the version from the parent. That allows me to control the versions we use internally of all the open source software we use. It seems to have no effect on the dependency resolution of artifacts that are brought in as a result of other dependencies. I do not use any of the ( or [ just the hard version number. Scott On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote: On 1 Mar 07, at 11:57 PM 1 Mar 07, Scott Ryan wrote: Yes I did make entries in my master parent for all the versions of software that we use but it is ignoring that as well. You have hard versions and it's ignoring them? Jason. Scott On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote: Have you tried using node in your parent pom to "lock down" the versions you will accept ie: net.sf.saxon saxon [8.7] Of course, this requires that you list all your dependencies (even the transitive ones) in this node and update versions etc here, but at least it centralizes things a bit... Wayne On 3/1/07, Scott Ryan <[EMAIL PROTECTED]> wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a "nearness" process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons-Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the "nearness" process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Am I missing something or doing something wrong that is causing this behavior? Thanks for all the support and a great open source offering. I hope you can educate me so I can deal with this issue and teach others. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Problems with Maven example
Hi, I´m trying Maven and followed the simple guide which is included in the book Bettter build with Maven and also in the 5 minute guide. Everything goes fine (donwloading, compiling), but when I try to package the sample app (mvn package), or test it, I always get this exception: [INFO] Surefire report directory: C:\maven_projekt\application\target\surefire-r eports org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantia te and execute Surefire; nested exception is java.lang.ClassNotFoundException: o rg.apache.maven.surefire.Surefire java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(Isolat edClassLoader.java:103) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:281) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:818) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Sat Mar 03 13:45:37 CET 2007 [INFO] Final Memory: 5M/11M [INFO] Surfire is presented in my local repository, but Maven does not see it? Please help :) -- Pavel Štěpánek [EMAIL PROTECTED]
Re: EAR plugin: dependent libraries location
Ron Piterman wrote: I have an EAR project, which includes an EJB project as module, say Foo. Foo is dependant on Bar, and bar is included in the EAR, but not in the root directory of the EAR instead in the /lib directory. This results in a class-not-found exception when deploying in jboss. Check out the md4j-quickstarter poms [1]. Library jars go yo ear/APP-INF/lib and are visible from both the war and ejb module; the purpose was to reuse libraries. The root project contains ear, ejb and web modules. In their POMs you can see how dependencies are used along with the ear, war and ejb plugins to do this. [1] http://md4j.cvs.sourceforge.net/md4j/md4j-quickstarter-mvn/ hth, Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype: create resources as companions to java source files
Howard Lewis Ship wrote: I'm trying to create a archetype where some of my Java source files have related resources. Thus, if I have a Java source as src/main/java/pages/Start.java, I would like to have a companion src/main/resources/pages/Start.properties. In the generated application, these would both be qualified with the package name, ex: src/main/java/org/example/myapp/pages/Start.java and src/main/resources/org/example/myapp/pages/Start.properties. The .java file is no problem, but I haven't found how to do the related resource. Err, i cant really answer your question but can you please tip me on how to do this for the java files at least? I asked the question some time ago [1], maybe my terminology probably stopped people from passing an answer. I was thinking to go the antrun route and work something out there, in any case if a solution is available it would be of great help. [1] http://www.nabble.com/Arbitary-directory-package-names-with-archetype:create--t3285139s177.html Many thanks in advance, Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EAR plugin: dependent libraries location
On 3/2/07, Ron Piterman <[EMAIL PROTECTED]> wrote: Hi all, I have an EAR project, which includes an EJB project as module, say Foo. Foo is dependant on Bar, and bar is included in the EAR, but not in the root directory of the EAR instead in the /lib directory. It does not matter where it's located except if you're using JavaEE5. If it's a standard library, it should be defined in the manifest of your ejb-jar and it will be located in the root directory unless you overwrite the defaults. Do you have defined the defaultJarBundleDir parameter? This results in a class-not-found exception when deploying in jboss. Did I forget anything or do I really have to specify any dependency in the EAR explicitly to deploy to the EAR/lib ? It's an EAR thing. Just make sure that Bar is defined somewhere. HTH, Stéphane Cheers, Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly plugin: is it capable of working out for itself what artifacts it must include?
Hi all, More questions about the assembly plugin. According to the docs at http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html, it is implied that the assembly plugin is capable of working out for itself what the artifact is produced by a module. All you need to do this tell the assembly plugin the name of the module, like this: org.test:child1 The behaviour we are seeing however is that the assembly plugin cannot find the artifact, claiming the artifact does not exist. This would imply that the assembly plugin is not capable of working out for itself what artifact you are talking about, contrary to the documentation. In our case, the artifact when built has a classifier (eg macosx-ppc). Does the assembly plugin support the inclusion of modules containing artifacts with classifiers? [INFO] [assembly:directory-inline] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Included module: alchemy:alchemy-cdo:jar:4.0.6-SNAPSHOT does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Included module: alchemy:alchemy-cdo:jar:4.0.6-SNAPSHOT does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Username and password for deploy plugin
I think that you might be talking about what was reported in http://jira.codehaus.org/browse/MNG-553 . This issue was reported a long time ago and doesn't seem to be getting much attention anymore... Maybe a few more votes for it? On 3/3/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 2/28/07, Paul Gier <[EMAIL PROTECTED]> wrote: > Is there a way to supply a username and password for a remote repository > on the command line instead of in the settings.xml? It would be helpful > if the deploy plugin could prompt the user as needed for this > information. The password could be hidden from view this way, and > developers would not have to worry about configuring settings.xml. > > Specifically, I would like to have this feature for the wagon-webdav > plugin, but I think it could apply to all the deploy related plugins. No idea if it takes userid/password on the command line, but there is some work in the gpg plugin to prompt for a passphrase (and mask it). Perhaps that could be borrowed. (wagon-webdav isn't a plugin, is it? I only know it as an artifact that needs to be configured as a build extension or otherwise added to Maven since it doesn't support dav by default.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly plugin: does package phase have to be run before or during assembly:directory?
Hi all, I just need to clarify the behaviour of the assembly plugin. For some reason assembly:directory triggers the package phase whether you wanted it to or not (a good reason you might not want to run the package phase, is that the package phase has already been run). I see that assembly:directory-inline does not trigger the package phase - but - when you run it, it complains that the package phase needs to be run (the package phase in this case has already been run). So the question is: - Does the assembly plugin need to run the package phase before every single invocation? The error message below suggests this is true. In our case the package phase takes 10 minutes, meaning that there is little or no chance we are ever going to get the assembly plugin config working in any cost effective time frame. - Is there a way to run the assembly plugin _without_ triggering a package phase every time? [INFO] [assembly:directory-inline] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Included module: alchemy:alchemy-cdo:jar:4.0.6-SNAPSHOT does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Included module: alchemy:alchemy-cdo:jar:4.0.6-SNAPSHOT does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
