Re: What to do with maven-continuum-plugin ?
Actually, this plugin is very basic. With it you can add projects (maven1/Maven2/ant/shell) and you can ping the continuum server to see if it is up. In future, we'll can add more goals to build projects... It's very easy to add more goals with the xmlrpc client. Emmanuel Damien Lecan a écrit : Hello, I have seen a plugin called maven-continuum-plugin in Continuum distribution. What to do with this plugin ? Declaring new projects (use plugin once) ? Trigger something in Continuum itself at the end of a build ? Update projects information ? Anything else ? Thanks Damien Lecan
Re: When builds are done in multi-module projects ?
Continuum look at scm changes, if it contains some sources updates, it build the project. Then, it looks at dependencies list, if a dependency (that is a continuum project too) is updated (new build result in success), continuum build the project With no SCM changes and no dependencies, if the build definition is marked as always build and the build isn't forced, continuum won't build the project. Emmanuel Damien Lecan a écrit : Hum, I'm working with Continuum 1.1-beta-3 Damien 2007/9/24, Damien Lecan [EMAIL PROTECTED]: Hello, I would like to understand how Continuum knows which sub-projects of a multi-module project have to be built. All sub-projects are in eparate projects under a main project group. it seems that build of a project is done when : - sources are updated - dependency projects have been updated (= built or sources updated ?) - ... I would like to know all the rules in order to understand why some projects are built whereas I can read for theses projects : SCM Changes : No SCM changes Dependencies Changes : No dependencies changes Thanks Damien Lecan
Re: Control the build sequency
No, it isn't possible to chain some build definitions. Isn't it possible to run mvn clean install site dashboard-report:dashboard site:deploy in one command? Emmanuel Doucet Arnaud a écrit : Hi, I'm using dashboard plugin which requires to split site generation in 3 steps in a certain order : * 1 : mvn clean install site (scheduled at 02:05). * 2 : mvn dashboard-report:dashboard (scheduled at 02:45). * 3 : mvn site :deploy (scheduled at 02:55). The problem is that Continuum may have to insert the execution of a build between the first and the last build above. For example an hourly 'mvn clean deploy' which normally should be executed at 02:00 may have been reported to 02:30. In such a case, the build 'mvn site:deploy' will fail. Is there a way to chain some build definitions and make sure that there will be no other build execution inside this chain. Thanks. Arnaud Doucet
Re: When builds are done in multi-module projects ?
Weird. Can you verify in your build definition if Build Fresh/Always Build are really false. Maybe we don't print the right value. What is the status of the build result? and the previous? I'll look at the code. Emmanuel Damien Lecan a écrit : 2007/9/24, Emmanuel Venisse [EMAIL PROTECTED]: Continuum look at scm changes, if it contains some sources updates, it build the project. Then, it looks at dependencies list, if a dependency (that is a continuum project too) is updated (new build result in success), continuum build the project With no SCM changes and no dependencies, if the build definition is marked as always build and the build isn't forced, continuum won't build the project. For theses projects, always build is set to false :( Copy/paste for project build summary : SCM Changes : No SCM changes Dependencies Changes : No dependencies changes Build Definition Used POM filename : pom.xml Goals : clean deploy Arguments : --batch-mode --non-recursive Build Fresh : false Always Build : false Is it default ? : true Schedule : Midi And this project was built this noon ! Damien
Re: Error running Continuum - address already in use ????
the port was probably used by an other application and wasn't released properly. Try to reboot your machine. If you start on Continuum, I think it would be better to use Continuum 1.1. We'll release 1.1-beta-3 this week. Emmanuel Raffaele a écrit : Hi all, I have the following stack trace running Continuum: jvm 1| [INFO] Deploying application 'continuum'. jvm 1| [INFO] Adding HTTP listener on *:8080 jvm 1| 15:27:06.754 WARN!! Failed to start: [EMAIL PROTECTED]:8080 jvm 1| Error while deploying application 'continuum-plexus-application-1.0.3 .jar'. jvm 1| org.codehaus.plexus.application.ApplicationServerException: Could not deploy the JAR jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:216) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:136) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:116) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer$2.on JarDiscovered(DefaultApplicationServer.java:117) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scanDirectory(DefaultSupervisor.java:89) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scan(DefaultSupervisor.java:68) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer.star t(DefaultApplicationServer.java:146) jvm 1| at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartP hase.execute(StartPhase.java:16) jvm 1| at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start( AbstractLifecycleHandler.java:101) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.startComponentLifecycle(AbstractComponentManager.java:105) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.createComponentInstance(AbstractComponentManager.java:95) jvm 1| at org.codehaus.plexus.component.manager.ClassicSingletonCompone ntManager.getComponent(ClassicSingletonComponentManager.java:92) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlex usContainer.java:331) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.start(P lexusApplicationHost.java:109) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.main(Pl exusApplicationHost.java:236) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.jav a:315) jvm 1| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) jvm 1| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.j ava:430) jvm 1| at org.codehaus.classworlds.Launcher.main(Launcher.java:375) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimple App.java:136) jvm 1| at java.lang.Thread.run(Thread.java:619) jvm 1| Caused by: org.codehaus.plexus.service.jetty.ServletContainerExceptio n: Error while starting listener on address: 'null', port: 8080. jvm 1| at org.codehaus.plexus.service.jetty.JettyServletContainer.addLi stener(JettyServletContainer.java:161) jvm 1| at org.codehaus.plexus.service.jetty.JettyPlexusService.afterApp licationStart(JettyPlexusService.java:191) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployApplicationDirectory(DefaultApplicationDeployer.java:385) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:212) jvm 1| ... 28 more jvm 1| Caused by: java.net.BindException: Address already in use: JVM_Bind I have already tried to change the port number in applciation.xml inside continuum installation dir\apps\continuum\conf. I'm sure to have the 8080 port free. Any hint? Thansk in advance, best regards. Raffaele
Re: When builds are done in multi-module projects ?
Weird. Can you verify in your build definition if Build Fresh/Always Build are really false. Maybe we don't print the right value. Do you mean to verify by editing each Build Definitions of each project and by checking if always build/build fresh check boxes are checked ? If yes, both are not checked. If you mean to verify by looking at the content of the database, please tell which table/field I have to check. What is the status of the build result? and the previous? success/success Additionnal information : this project have been upgraded from old 1.1-beta-2 database schema. Damien
Re: Error running Continuum - address already in use ????
Thanks Emmanuel by the way I have the same error also with continuum 1.1 alpha 2 I tried also to restart my pc, and I trid also to change the port as already explained in my previous post. Now I remember that I had these same errores with another Apache product, that is ActiveMQand also in the forum of ActiveMQ many people had this problem, that is address already in use. What could I try? Thanks. Raffaele Emmanuel Venisse wrote: the port was probably used by an other application and wasn't released properly. Try to reboot your machine. If you start on Continuum, I think it would be better to use Continuum 1.1. We'll release 1.1-beta-3 this week. Emmanuel Raffaele a écrit : Hi all, I have the following stack trace running Continuum: jvm 1| [INFO] Deploying application 'continuum'. jvm 1| [INFO] Adding HTTP listener on *:8080 jvm 1| 15:27:06.754 WARN!! Failed to start: [EMAIL PROTECTED]:8080 jvm 1| Error while deploying application 'continuum-plexus-application-1.0.3 .jar'. jvm 1| org.codehaus.plexus.application.ApplicationServerException: Could not deploy the JAR jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:216) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:136) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:116) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer$2.on JarDiscovered(DefaultApplicationServer.java:117) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scanDirectory(DefaultSupervisor.java:89) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scan(DefaultSupervisor.java:68) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer.star t(DefaultApplicationServer.java:146) jvm 1| at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartP hase.execute(StartPhase.java:16) jvm 1| at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start( AbstractLifecycleHandler.java:101) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.startComponentLifecycle(AbstractComponentManager.java:105) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.createComponentInstance(AbstractComponentManager.java:95) jvm 1| at org.codehaus.plexus.component.manager.ClassicSingletonCompone ntManager.getComponent(ClassicSingletonComponentManager.java:92) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlex usContainer.java:331) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.start(P lexusApplicationHost.java:109) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.main(Pl exusApplicationHost.java:236) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.jav a:315) jvm 1| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) jvm 1| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.j ava:430) jvm 1| at org.codehaus.classworlds.Launcher.main(Launcher.java:375) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimple App.java:136) jvm 1| at java.lang.Thread.run(Thread.java:619) jvm 1| Caused by: org.codehaus.plexus.service.jetty.ServletContainerExceptio n: Error while starting listener on address: 'null', port: 8080. jvm 1| at org.codehaus.plexus.service.jetty.JettyServletContainer.addLi stener(JettyServletContainer.java:161) jvm 1| at org.codehaus.plexus.service.jetty.JettyPlexusService.afterApp licationStart(JettyPlexusService.java:191) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployApplicationDirectory(DefaultApplicationDeployer.java:385) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:212) jvm 1| ... 28 more jvm 1
Re: Error running Continuum - address already in use ????
Hi, In order to test if the port is already use just try : telnet localhost 8080 -- Olivier 2007/9/24, Raffaele [EMAIL PROTECTED]: Thanks Emmanuel by the way I have the same error also with continuum 1.1 alpha 2 I tried also to restart my pc, and I trid also to change the port as already explained in my previous post. Now I remember that I had these same errores with another Apache product, that is ActiveMQand also in the forum of ActiveMQ many people had this problem, that is address already in use. What could I try? Thanks. Raffaele Emmanuel Venisse wrote: the port was probably used by an other application and wasn't released properly. Try to reboot your machine. If you start on Continuum, I think it would be better to use Continuum 1.1. We'll release 1.1-beta-3 this week. Emmanuel Raffaele a écrit : Hi all, I have the following stack trace running Continuum: jvm 1| [INFO] Deploying application 'continuum'. jvm 1| [INFO] Adding HTTP listener on *:8080 jvm 1| 15:27:06.754 WARN!! Failed to start: [EMAIL PROTECTED]:8080 jvm 1| Error while deploying application 'continuum-plexus-application-1.0.3 .jar'. jvm 1| org.codehaus.plexus.application.ApplicationServerException: Could not deploy the JAR jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:216) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:136) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:116) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer$2.on JarDiscovered(DefaultApplicationServer.java:117) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scanDirectory(DefaultSupervisor.java:89) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scan(DefaultSupervisor.java:68) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer.star t(DefaultApplicationServer.java:146) jvm 1| at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartP hase.execute(StartPhase.java:16) jvm 1| at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start( AbstractLifecycleHandler.java:101) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.startComponentLifecycle(AbstractComponentManager.java:105) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.createComponentInstance(AbstractComponentManager.java:95) jvm 1| at org.codehaus.plexus.component.manager.ClassicSingletonCompone ntManager.getComponent(ClassicSingletonComponentManager.java:92) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlex usContainer.java:331) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.start(P lexusApplicationHost.java:109) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.main(Pl exusApplicationHost.java:236) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.jav a:315) jvm 1| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) jvm 1| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.j ava:430) jvm 1| at org.codehaus.classworlds.Launcher.main(Launcher.java:375) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimple App.java:136) jvm 1| at java.lang.Thread.run(Thread.java:619) jvm 1| Caused by: org.codehaus.plexus.service.jetty.ServletContainerExceptio n: Error while starting listener on address: 'null', port: 8080. jvm 1| at org.codehaus.plexus.service.jetty.JettyServletContainer.addLi stener(JettyServletContainer.java:161) jvm 1| at org.codehaus.plexus.service.jetty.JettyPlexusService.afterApp licationStart(JettyPlexusService.java:191) jvm 1| at
Maven JavaScript Plugin 1.2 released
Hey all, We have released version 1.2 of the maven-js-plugin. All release notes and such can be found at http://ossi.mobilvox.com/maven-js-plugin or http://sf.net/projects/maven-js-plugin. Thanks, -- Adam Altemus http://www.mobilvox.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What to do with maven-continuum-plugin ?
Hello, I have seen a plugin called maven-continuum-plugin in Continuum distribution. What to do with this plugin ? Declaring new projects (use plugin once) ? Trigger something in Continuum itself at the end of a build ? Update projects information ? Anything else ? Thanks Damien Lecan
MAVEN BUG: typeejb-client/type problem
It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies All is ok, but when I use typeejb-client/type for first dependency, it tells me Missing: -- 1) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=co .mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.mhf:mhfApplication:ear:1.0 2) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 -- 1 required artifact is missing. for artifact: com.mhf:mhfApplication:ear:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) But when I don't have typeejb-client/type, all is ok and this jars just copies to lib dir in my EAR. But I need to have the link to this jar in generated application.xml, and I don't have it. Where is the dog? - 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] - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN BUG: typeejb-client/type problem
You did not answer the question of Tim why your artifactId for the ejb client is different from the artifactId of the ejb itself. As long as you do not answer, we assume the bug is between screen and keyboard ... ;-) Denis Bessmertniy wrote on Monday, September 24, 2007 8:57 AM: It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies All is ok, but when I use typeejb-client/type for first dependency, it tells me Missing: -- 1) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=co .mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.mhf:mhfApplication:ear:1.0 2) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 -- 1 required artifact is missing. for artifact: com.mhf:mhfApplication:ear:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) But when I don't have typeejb-client/type, all is ok and this jars just copies to lib dir in my EAR. But I need to have the link to this jar in generated application.xml, and I don't have it. Where is the dog? - 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] - 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] - 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: MAVEN BUG: typeejb-client/type problem
The first, I haven't received the letter form Tim about artifactId. The second, I cannot understand what do you mean here. May you resend me the letter from Tim? Thank you - Denis -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:29 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem You did not answer the question of Tim why your artifactId for the ejb client is different from the artifactId of the ejb itself. As long as you do not answer, we assume the bug is between screen and keyboard ... ;-) Denis Bessmertniy wrote on Monday, September 24, 2007 8:57 AM: It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies All is ok, but when I use typeejb-client/type for first dependency, it tells me Missing: -- 1) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=co .mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.mhf:mhfApplication:ear:1.0 2) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 -- 1 required artifact is missing. for artifact: com.mhf:mhfApplication:ear:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) But when I don't have typeejb-client/type, all is ok and this jars just copies to lib dir in my EAR. But I need to have the link to this jar in generated application.xml, and I don't have it. Where is the dog? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
[m2] In which order are called plugins of a same phase?
Hi, I've got a simple question: In which order are called plugins of a same phase? - in the pom's order? - what about parent plugins? - can we be sure it will always be in that order? Regards, Gerald Reinhart
RE: [ANN] Maven Clover 2 Plugin 3.0-beta-4 Released
Pity this took so long, we have now moved to cobertura. Andy Aspell-Clark Software Engineer *: + 44 (0)1633 637649 *: [EMAIL PROTECTED] WebSite - www.eadsdsuk.com For and on behalf of EADS Defence and Security Systems Limited Registered Office: Meadows Road , Queensway Meadows, Newport , NP19 4SS , UK . -Original Message- From: Tom Davies [mailto:[EMAIL PROTECTED] Sent: 24 September 2007 06:01 To: Maven Users List Subject: [ANN] Maven Clover 2 Plugin 3.0-beta-4 Released Atlassian has released a new version of the maven-clover-plugin for use with Clover 2.0b2. The plugin remains open source under the Apache license. The plugin facilitates the creation of test coverage reports for projects built with Maven 2. There is an overview of the new features of Clover 2 at http:// www.atlassian.com/software/clover/whats-new.jsp Note that this version does not include an evaluation license -- you will need to download one from http://www.atlassian.com/software/ clover/GenerateCloverEvaluationLicense!default.jspa The groupId has changed, and at present the plugin is only available from Atlassian's repository. Please see http://confluence.atlassian.com/x/K4CDBQ for information on usage, bug reporting and source code location. Thanks, Tom Davies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. EADS Defence and Security Systems Limited Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.eadsdsuk.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN BUG: typeejb-client/type problem
Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 9:43 AM: The first, I haven't received the letter form Tim about artifactId. The second, I cannot understand what do you mean here. May you resend me the letter from Tim? It's still included in this mail ... simply do not stop reading after the first sentence. - Jörg Thank you - Denis -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:29 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem You did not answer the question of Tim why your artifactId for the ejb client is different from the artifactId of the ejb itself. As long as you do not answer, we assume the bug is between screen and keyboard ... ;-) Denis Bessmertniy wrote on Monday, September 24, 2007 8:57 AM: It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies All is ok, but when I use typeejb-client/type for first dependency, it tells me Missing: -- 1) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=co .mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.mhf:mhfApplication:ear:1.0 2) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 -- 1 required artifact is missing. for artifact: com.mhf:mhfApplication:ear:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) But when I don't have typeejb-client/type, all is ok and this jars just copies to lib dir in my EAR. But I need to have the link to this jar in generated application.xml, and I don't have it. Where is the dog? [snip footers] - 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 : MAVEN BUG: typeejb-client/type problem
Hello, I think you do not generate the ejb-client from your project : groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version Look at this page : http://maven.apache.org/maven-1.x/plugins/ejb/properties.html. You will find how to ask Maven EJB Plugin to generate your client. Do not forget to use the property maven.ejb.client.excludes to exclude classes which are not client specific. Yan Langlois. - Message d'origine De : Denis Bessmertniy [EMAIL PROTECTED] À : Maven Users List users@maven.apache.org Envoyé le : Lundi, 24 Septembre 2007, 9h43mn 08s Objet : RE: MAVEN BUG: typeejb-client/type problem The first, I haven't received the letter form Tim about artifactId. The second, I cannot understand what do you mean here. May you resend me the letter from Tim? Thank you - Denis -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:29 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem You did not answer the question of Tim why your artifactId for the ejb client is different from the artifactId of the ejb itself. As long as you do not answer, we assume the bug is between screen and keyboard ... ;-) Denis Bessmertniy wrote on Monday, September 24, 2007 8:57 AM: It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies All is ok, but when I use typeejb-client/type for first dependency, it tells me Missing: -- 1) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=co .mhf -DartifactId=mhfEJBModuleClient \ -Dversion=1.0 -Dclassifier=client -Dpackaging=ejb-client -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.mhf:mhfApplication:ear:1.0 2) com.mhf:mhfEJBModuleClient:ejb-client:client:1.0 -- 1 required artifact is missing. for artifact: com.mhf:mhfApplication:ear:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) But when I don't have typeejb-client/type, all is ok and this jars just copies to lib dir in my EAR. But I need to have the link to this jar in generated application.xml, and I don't have it. Where is the dog?
RE: MAVEN BUG: typeejb-client/type problem
If you mean this Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim I have read this. Ok, I will try to describe my situation more concrete. In my main project I have 4 subprojects modulemhfEJBModuleClient/module- here I have interfaces for EJB impl classes and additional classes modulemhfEJBModule/module- here I have EJB implementation classes modulemhfWebModule/module - here is my web-app modulemhfApplication/module - here I store only pom.xml, because after mvn install here I will have ear file So and here what I have in pom.xml which in mhfApplication project dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies So, what is wrong here, because maven in anger with typeejb-client/type? When I replace it, no problem, but then I don't have mhfEJBModuleClient.jar link in application.xml and mhfEJBModuleClient.jar stores not in main dir of ear file, but in lib dir. Thank you for answers) -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:53 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 9:43 AM: The first, I haven't received the letter form Tim about artifactId. The second, I cannot understand what do you mean here. May you resend me the letter from Tim? It's still included in this mail ... simply do not stop reading after the first sentence. - Jörg Thank you - Denis -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:29 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem You did not answer the question of Tim why your artifactId for the ejb client is different from the artifactId of the ejb itself. As long as you do not answer, we assume the bug is between screen and keyboard ... ;-) Denis Bessmertniy wrote on Monday, September 24, 2007 8:57 AM: It sound like a bug in maven, because nobody knows where is the dog. I still have this problem and I have read a lot of manuals and also Better Build with maven book in order to find the answer, but nothing. -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:36 PM To: 'Maven Users List' Subject: RE: typeejb-client/type problem No, I still have this problem, that is why I'm asking to help me. Please, -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 6:33 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: That is good, but maybe somebody will help me, because I don't have my client jar in application.xml. I don't understand what you mean. What has this to do with your original question? Is the problem with the resolution of the ejb-client dependency fixed now? -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 5:50 PM To: Maven Users List Subject: Re: typeejb-client/type problem Denis Bessmertniy schrieb: Sorry, my last letter was with wrong topic name This wouldn't have happened if you would just create new threads for your questions instead of hijacking existing threads. Now there are messages which are irrelevant to the original question - which has yet to be answered. Hi folks, I building J2EE application with maven and now I encounter with problem: Here is the dependency part of my pom from project where I consturct EAR file dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency
Why Maven is Hard?
It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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: Maven with Websphere
Hi, you may have a look at peter pilgrim's weblog: http://www.jroller.com/peter_pilgrim/ and the entries related to maven2 and websphere. http://www.jroller.com/peter_pilgrim/entry/battling_with_maven_2_integrating Wish you get some answers. Christian-Luc Hemant Ved wrote: Hi all Can anybody explain me the steps to deploy ejb using maven with Websphere 6?Has anybody tried using Maven and RAD combination? Can maven follow the directory structure of RAD? Thanks and regards Hemant Ved -- View this message in context: http://www.nabble.com/Maven-with-Websphere-tf4480338s177.html#a12855708 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I haven't read (1), but I definitely recommend (2). Very good indeed. Yours, Rodrigo On 9/24/07, Nick Stolwijk [EMAIL PROTECTED] wrote: What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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: Why Maven is Hard?
That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN BUG: typeejb-client/type problem
Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 10:04 AM: If you mean this Exaclty. :) Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim I have read this. Ok, I will try to describe my situation more concrete. In my main project I have 4 subprojects modulemhfEJBModuleClient/module- here I have interfaces for EJB impl classes and additional classes modulemhfEJBModule/module- here I have EJB implementation classes modulemhfWebModule/module - here is my web-app modulemhfApplication/module - here I store only pom.xml, because after mvn install here I will have ear file And that is what confused anybody here. It is as Yan explained, normally you use the EJB module to generate your client also. In your case you have a totally different artifact for the client. So and here what I have in pom.xml which in mhfApplication project dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies So, what is wrong here, because maven in anger with typeejb-client/type? When I replace it, no problem, but then I don't have mhfEJBModuleClient.jar link in application.xml and mhfEJBModuleClient.jar stores not in main dir of ear file, but in lib dir. Your client is as far as Maven concerns a simple jar artifact. It simply does not know that it contains your ejb client code. Therefore it complains that it cannot find the artifact of type ejb-client and all the special handling for ejb-clients do not apply (i.e. making an entry in application.xml). [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any advantage of utisng plexus-compiler-eclipse ?
Just curious, Is there anybody that use an alternative compiler for maven-compiler-plugin ? Does the eclipse compiler support any must-have feature ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 10:07 AM: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. Regading the EJBs there are quite a lot examples available. See, the strength of Maven is that it *enforces* some kind of project layout and best practices. When you start to do things in other ways, it will not help you (although you *can* do differently if you really really want). With Ant every project establishes its own layout and best practices and new team members will always have to take a very close look. And this is different with Maven, it works always the same way over the complete lifecycle (well, most of the time). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN BUG: typeejb-client/type problem
Ok, but what I may to do to have what I want? -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:31 AM To: Maven Users List Subject: RE: MAVEN BUG: typeejb-client/type problem Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 10:04 AM: If you mean this Exaclty. :) Shouldn't this be: dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb-client/type /dependency Or isn't your ejb-client artifact autogenerated by the ejb-plugin? -Tim I have read this. Ok, I will try to describe my situation more concrete. In my main project I have 4 subprojects modulemhfEJBModuleClient/module- here I have interfaces for EJB impl classes and additional classes modulemhfEJBModule/module- here I have EJB implementation classes modulemhfWebModule/module - here is my web-app modulemhfApplication/module - here I store only pom.xml, because after mvn install here I will have ear file And that is what confused anybody here. It is as Yan explained, normally you use the EJB module to generate your client also. In your case you have a totally different artifact for the client. So and here what I have in pom.xml which in mhfApplication project dependencies dependency groupIdcom.mhf/groupId artifactIdmhfEJBModuleClient/artifactId version1.0/version typeejb-client/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfEJBModule/artifactId version1.0/version typeejb/type /dependency dependency groupIdcom.mhf/groupId artifactIdmhfWebModule/artifactId version1.0/version typewar/type /dependency /dependencies So, what is wrong here, because maven in anger with typeejb-client/type? When I replace it, no problem, but then I don't have mhfEJBModuleClient.jar link in application.xml and mhfEJBModuleClient.jar stores not in main dir of ear file, but in lib dir. Your client is as far as Maven concerns a simple jar artifact. It simply does not know that it contains your ejb client code. Therefore it complains that it cannot find the artifact of type ejb-client and all the special handling for ejb-clients do not apply (i.e. making an entry in application.xml). [snip] - Jörg - 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: Why Maven is Hard?
Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN BUG: typeejb-client/type problem
Denis Bessmertniy wrote on Monday, September 24, 2007 10:44 AM: Ok, but what I may to do to have what I want? The client is normally generated building the EJB itself, sou you should be able to moive your classes over to your ejb module, drop your client module at all and configure the ejb module accordingly. Look at the examples here: http://maven.apache.org/plugins/maven-ejb-plugin/ and let us know which part of the configuration is not understandable by you or makes you problems. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - 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: attached tests dependency error
Hi,
I will try my best to explain how I understand the underlying concepts
but as I'm not a maven developer and the code and design documentation
is rather sparse there might be some misconceptions on my side.
What I'm a little bit confused about is the distinction between type and
packaging. The termes are used somewhat interchangable in the pom and
documentation: You give a 'packaging' for the artifact you build but
declare the 'type' of dependencies. In the below text I will use them as
if they would mean the same.
For example when you build a j2ee app you would have a war project with
the packaging set to 'war'. In the ear project you then declare the
dependency to the war project with a type of 'war'.
Perhaps someone with more insight than me can explain why this
distinction between packaging and type is made.
A maven artifact is identified by the coordinates
groupId:artifactid:classifier:version:packaging (where a default
packaging of kind 'jar' is assumed if no packaging is explicitly given).
What is going on behind the scences is this:
For each artifact-(type/packaging) there is an associated
ArtifactHandler [1] either explicitly declared or implicitly created
on the fly. An ArtifactHandler provides the file extension and default
classifier for an artifact-type. The ArtifactHandler for a dependency is
looked up in the ArtifactHandlerManager [2].
The ArtifactHandlers for the standard artifact-types are declared in
this components.xml file [3].
When you declare this dependency:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetests/type
/dependency
Maven looks up the ArtifactHandler for artifacts of type 'tests' in its
ArtifactHandlerManager, since there is no such handler explicitly
declared in [3] the DefaultArtifactHandlerManager [4] creates one on the
fly based on the given type. This on-the-fly handler returns the value
of the type for the extension and packaging ('tests' in this case). So
the dependency given above resolves to this path in the repository:
com/myco/app/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.tests
wich obviously doesn't exist. However, this dependency declaration
should work:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetest-jar/type
/dependency
As there is a artifact handler defined for the type 'test-jar' that maps
to a standard classifier of 'tests' and an extension of 'jar'. This
should result in a repository path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
Similar for this declaration:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
classifiertests/classifier
/dependency
Here a default type of 'jar' is assumed which maps to an extension of
'jar' via the associated artifact handler. Together with the explicitly
declared classifier one should end up with a path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
PERIOD.
Sorry for this lengthy explanation, I hope it is somewhat understandable.
-Tim
[1]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java
[2]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/ArtifactHandlerManager.java
[3]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/resources/META-INF/plexus/components.xml
[4]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/DefaultArtifactHandlerManager.java
zalym schrieb:
Hi Tim,
totally out of scope, but i am curious. what is this type identifier for in
dependency? and why is it resolved as period in the artifact?
Saleem
Tim Kettler wrote:
zalym schrieb:
I followed the attached tests guide to create a dependency to my core
tests.
The first part of the tutorial worked, and I could install a version of
the
test jar in the local repository as models-3.0-tests.jar. When I tried
to
add this as a dependency in another project, it came up with a dependency
missing error and when I noticed this in the message:
models-3.0.tests
What could be wrong? Why would the dependency be resolbed with a period
and
not a hyphen.
This is most probably a bug in the documentation. Looking at the mojo's
source code [1] shows that the artifact is created with a type of
'test-jar' and the classifier 'tests'.
You should try to use 'test-jar' as the type in your dependency
declaration or respectivly skip the type declaration and use a
classifiertests/classifier element in the declaration.
Please report this as a bug in jira [2] and provide the correct
dependency declaration to use.
Appreciate your help.
-Tim
[1]
how to specify the name of assembled distribution file
Hi, i want to specify the name of one of three triggered assembly descriptors. I have three different assemblies to build and the name of one should be templates.zip instead of test-0.8.7-SNAPSHOT-templates.zip If i declare the name with the finalName i define the element of all assemblies. Is there a way to declare the finalName in the assembly-descriptor? I dont want to use an extra profile. assembly-plugin in my pom ... plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc\main\assembly\a.xml/descriptor descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /plugin ... __ regards Martin Ritz
Re: Why Maven is Hard?
Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. I am in the process of doing a handover of a fully mavenised build (all the way through to using the release plugin for releases) to someone who has only ever used ant before, and this process has highlighted that maven IS hard for a beginner to understand. Maven's first problem is that it is not described anywhere neatly in one single paragraph. To a maven beginner, project comprehension tool is entirely meaningless: Why do I need a tool to help me comprehend my project? It makes no sense to a beginner. I have tried to explain maven by calling it an extensible Swiss Army Knife: Rather than telling ant how to do every step of your build, maven already knows how to do every step of your build. You just add the missing bits of information like your project name and version number, and maven does the rest automatically. Another thing a beginner gets confused about is the bewildering volume of plugins. To cut through this confusion I grouped plugins into the basic core group of plugins, and all the other plugins after people ran with the idea and went bananas. Getting across to the user that they don't have to learn to use every plugin, but only the ones they need, is very reassuring for a new user. Something else new users get worried about is what happens if maven cannot do what I want maven to do, and here pointing out if all else fails strategies like using the antrun plugin to get ant to do stuff for you is very reassuring to the new user. The new user doesn't need to know how the antrun plugin works, they only need to know that it is there. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to specify the name of assembled distribution file
Hi, split the plugin configuration in distinct executions: plugin artifactIdmaven-assembly-plugin/artifactId executions execution idexecution-one/id goals goalattached/goal /goals configuration finalNamecustomName/finalName appendAssemblyIdfalse/appendAssemblyId descriptorsrc\main\assembly\a.xml/descriptor /configuration /execution execution idexecution-two/id goals goalattached/goal /goals configuration descriptors descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /execution /executions /plugin -Tim Ritz, Martin schrieb: Hi, i want to specify the name of one of three triggered assembly descriptors. I have three different assemblies to build and the name of one should be templates.zip instead of test-0.8.7-SNAPSHOT-templates.zip If i declare the name with the finalName i define the element of all assemblies. Is there a way to declare the finalName in the assembly-descriptor? I dont want to use an extra profile. assembly-plugin in my pom ... plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc\main\assembly\a.xml/descriptor descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /plugin ... __ regards Martin Ritz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I think one of Ant's main strengths was not that it was a great build tool (that XML format was quite painful to use when I'm honest about it) but the documentation was brilliant that it was thus very easy to get things working. The maven documentation is not really complete on the website and there a tonne of undocumented features and odd behaviours. I would agree the documetation needs some work and in my opinion three things need attention: 1) A general reorganisation for the reference docs so that they are as accessible as the basic tutorials and get that access from the maven front page so its one click away just like Ant's was. 2) The reference material needs more detail. Specific things like what all the options for a value do. 3) More advanced tutorials for complex project structures, probably in the reference documents. For example a lot more detail on multimodule projects would be nice, things like how to have a dependency on a multi-module project and pulling in all the code. How to publish a multi-module project to a repository etc. Its not just multimodule, its also how to build anything other than a library. I'll think about it a bit more and propose a structure and tutorials that I think we need to write. Paul Keeble - Original Message From: Denis Bessmertniy [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Monday, 24 September, 2007 9:56:01 AM Subject: RE: Why Maven is Hard? I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - 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] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: how to specify the name of assembled distribution file
thx for the quick response but i get an error if i split like you told me. Error: the system couln't find the assembly descriptor file... But i have declared the right path and filename and the files are existing. Any hint what i'am doing wrong? Martin Hi, split the plugin configuration in distinct executions: plugin artifactIdmaven-assembly-plugin/artifactId executions execution idexecution-one/id goals goalattached/goal /goals configuration finalNamecustomName/finalName appendAssemblyIdfalse/appendAssemblyId descriptorsrc\main\assembly\a.xml/descriptor /configuration /execution execution idexecution-two/id goals goalattached/goal /goals configuration descriptors descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /execution /executions /plugin -Tim Ritz, Martin schrieb: Hi, i want to specify the name of one of three triggered assembly descriptors. I have three different assemblies to build and the name of one should be templates.zip instead of test-0.8.7-SNAPSHOT-templates.zip If i declare the name with the finalName i define the element of all assemblies. Is there a way to declare the finalName in the assembly-descriptor? I dont want to use an extra profile. assembly-plugin in my pom ... plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc\main\assembly\a.xml/descriptor descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /plugin ... __ regards Martin Ritz - 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: Why Maven is Hard?
Yes, Maven is hard. I should agree, there is why: New and buggy: Maven is hard, because it is new and like all new stuffs, it's buggy. Working around those little bugs or waiting for one good soul to provide a patch is a pain... Expertise on Maven is also harder to find. Black Box: Maven is hard, because for most people , it is a black box. Like with all black boxes, it's wonderful when it does what you want, and it is the worst nightmare when it doesn't. Ant scripts are indeed much more easy to accommodate. The true question is: why is Maven not doing what I want ? And the true answer to this is: Because what I want to do is probably not correct... -Toni Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-Maven-is-Hard--tf4507688s177.html#a12856941 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - 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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
When builds are done in multi-module projects ?
Hello, I would like to understand how Continuum knows which sub-projects of a multi-module project have to be built. All sub-projects are in eparate projects under a main project group. it seems that build of a project is done when : - sources are updated - dependency projects have been updated (= built or sources updated ?) - ... I would like to know all the rules in order to understand why some projects are built whereas I can read for theses projects : SCM Changes : No SCM changes Dependencies Changes : No dependencies changes Thanks Damien Lecan
Re: When builds are done in multi-module projects ?
Hum, I'm working with Continuum 1.1-beta-3 Damien 2007/9/24, Damien Lecan [EMAIL PROTECTED]: Hello, I would like to understand how Continuum knows which sub-projects of a multi-module project have to be built. All sub-projects are in eparate projects under a main project group. it seems that build of a project is done when : - sources are updated - dependency projects have been updated (= built or sources updated ?) - ... I would like to know all the rules in order to understand why some projects are built whereas I can read for theses projects : SCM Changes : No SCM changes Dependencies Changes : No dependencies changes Thanks Damien Lecan
RE: Why Maven is Hard?
Easy to you but not for clietns. Client is always right ;-) -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 1:04 PM To: Maven Users List Subject: Re: Why Maven is Hard? with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modul es modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. -- -- - 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] - 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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - 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: Why Maven is Hard?
Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That depends just how much of maven you are using. You might choose to use maven to build you a jar. Or you might have many jars, and arrange tham as dependencies of one another. Then you might go one step further and create many jars released at once in a multi-module configuration. Then you might choose to start using the maven release process to handle releases, and you might choose to run your own maven repository infrastructure. I can tell you from experience that getting the above working took a significant amount of time and effort, and in some cases, it involved stepping through maven modules in a debugger to figure out what the modules were doing. Many things about maven can be found in the documentation in 5 minutes, but to say that every question can be answered by the maven docs in under 5 minutes does both maven and maven users a disservice. Maven is an extremely valuable tool, but it is by no means trivial. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: AW: how to specify the name of assembled distribution file
It's working for me with this testproject: . |-- pom.xml `-- src `-- main |-- assembly | |-- A.xml | |-- B.xml | `-- C.xml `-- java `-- TestClass.java pom.xml: project modelVersion4.0.0/modelVersion groupIdmy-test-group/groupId artifactIdmy-test-artifact/artifactId version1.0-SNAPSHOT/version build plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version executions execution idexecution-one/id phasepackage/phase goals goalsingle/goal /goals configuration finalNameCUSTOM/finalName appendAssemblyIdfalse/appendAssemblyId descriptors descriptorsrc/main/assembly/A.xml/descriptor /descriptors /configuration /execution execution idexecution-two/id phasepackage/phase goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/B.xml/descriptor descriptorsrc/main/assembly/C.xml/descriptor /descriptors /configuration /execution /executions /plugin /plugins /build /project The only difference is that I used the 'single' goal instead of the 'attached' one and I changed the lone descriptor/ tag to be in a descriptors/ list as well (I just noticed that the lone descriptor tag will be depricated). If you can't get it working just post the relevant ouptut of 'mvn -X ...' and hopefully we can figure it out together. -Tim Ritz, Martin schrieb: thx for the quick response but i get an error if i split like you told me. Error: the system couln't find the assembly descriptor file... But i have declared the right path and filename and the files are existing. Any hint what i'am doing wrong? Martin Hi, split the plugin configuration in distinct executions: plugin artifactIdmaven-assembly-plugin/artifactId executions execution idexecution-one/id goals goalattached/goal /goals configuration finalNamecustomName/finalName appendAssemblyIdfalse/appendAssemblyId descriptorsrc\main\assembly\a.xml/descriptor /configuration /execution execution idexecution-two/id goals goalattached/goal /goals configuration descriptors descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /execution /executions /plugin -Tim Ritz, Martin schrieb: Hi, i want to specify the name of one of three triggered assembly descriptors. I have three different assemblies to build and the name of one should be templates.zip instead of test-0.8.7-SNAPSHOT-templates.zip If i declare the name with the finalName i define the element of all assemblies. Is there a way to declare the finalName in the assembly-descriptor? I dont want to use an extra profile. assembly-plugin in my pom ... plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc\main\assembly\a.xml/descriptor descriptorsrc\main\assembly\b.xml/descriptor descriptorsrc\main\assembly\c.xml/descriptor /descriptors /configuration /plugin ... __ regards Martin Ritz - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
There are questions that I have that I simply can't find answers for at all! Not only are the details not in the documentation but they aren't even blogged about. Just compare the level of documentation in Ant verses Maven and its a night and day difference. Don't get me wrong there is a lot of documentation for Maven I just don't think its as accessible or as detailed. If you have 5 options for a parameter then the details of what each does is essential and that is just missing (for instance what does a dependency being of type pom mean?! I had to write an example app to see what it meant). Ant has no such corner cases, it documents every single value and parameter. Maven still has better documentation than many other open source projects but its not a 5 minute lookup, its several hours of searching and prototyping on google. I'd never consider looking for ant documentation anywhere except their site, for maven I prefer to look else where as the site is not detailed enough. Paul K - Original Message From: Michael McCallum [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Monday, 24 September, 2007 11:04:10 AM Subject: Re: Why Maven is Hard? with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - 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] - 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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: Why Maven is Hard?
Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Clover 2 Plugin 3.0-beta-4 Released
Hi Tom, Congrats for this first release under the Atlassian umbrella! Where can we see what's different from the last version of the Clover plugin located at Apache? I tried checking http://developer.atlassian.com/jira/browse/CLMVN? report=com.atlassian.jira.plugin.system.project:changelog-panel but there's only a 3.0 beta 1 version listed and it has no issues in it. I think this information might be useful for users interested in switching for the current version to this new version. Thanks -Vincent On Sep 24, 2007, at 7:00 AM, Tom Davies wrote: Atlassian has released a new version of the maven-clover-plugin for use with Clover 2.0b2. The plugin remains open source under the Apache license. The plugin facilitates the creation of test coverage reports for projects built with Maven 2. There is an overview of the new features of Clover 2 at http:// www.atlassian.com/software/clover/whats-new.jsp Note that this version does not include an evaluation license -- you will need to download one from http://www.atlassian.com/ software/clover/GenerateCloverEvaluationLicense!default.jspa The groupId has changed, and at present the plugin is only available from Atlassian's repository. Please see http://confluence.atlassian.com/x/K4CDBQ for information on usage, bug reporting and source code location. Thanks, Tom Davies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: how to specify the name of assembled distribution file
my pom is: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version executions execution idassemblyone/id phasepackage/phase goals goalsingle/goal /goals configuration finalNametemplates/finalName appendAssemblyIdfalse/appendAssemblyId descriptors descriptorsrc/main/assembly/assembly_descriptor_templates.xml/descriptor /descriptors /configuration /execution execution idassemblytwo/id phasepackage/phase goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/assembly_descriptor_srcs.xml/descriptor descriptorsrc/main/assembly/assembly_descriptor_deploy.xml/descriptor /descriptors /configuration /execution /executions /plugin and I use the same structure (like your post) if I bind the plugin to the package phase everything works fine - the assemblies are built in the right way. I don't want to bind - i want to execute the plugin by the 'assembly:single' command. If I use this command i get the error below: [INFO] Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml D:\*\assembly_descriptor.xml (The System couldn't find the file) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:257) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.getAssemblyFromDescriptorFile(DefaultAssemblyReader.java:174) at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:75) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:253) ... 18 more Caused by: java.io.FileNotFoundException: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml (Das System kann die angegebene Datei nicht finden = System could not find file) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileReader.init(FileReader.java:55)
Re: Why Maven is Hard?
just to repeat i have been able to answer every question I have been asked thats not to say every question but to say every question that in my experience new users have asked... often they proceeded to go and do something else anyway but thats beside the point... modules are way overused IMO and do cause lots of problems usually because people confuse parent poms and modules projects when really they are not the same thing... On Monday 24 September 2007 22:32, Graham Leggett wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That depends just how much of maven you are using. You might choose to use maven to build you a jar. Or you might have many jars, and arrange tham as dependencies of one another. Then you might go one step further and create many jars released at once in a multi-module configuration. Then you might choose to start using the maven release process to handle releases, and you might choose to run your own maven repository infrastructure. I can tell you from experience that getting the above working took a significant amount of time and effort, and in some cases, it involved stepping through maven modules in a debugger to figure out what the modules were doing. Many things about maven can be found in the documentation in 5 minutes, but to say that every question can be answered by the maven docs in under 5 minutes does both maven and maven users a disservice. Maven is an extremely valuable tool, but it is by no means trivial. Regards, Graham -- -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I should also add that that does not include supporting 3rd party plugins... and often getting the source for them can be useful... i have my own versions of mojo hibernate, xslt among a few others while waiting for bug fixes... thats like saying that micrsoft is responsible for the documentation of the drivers for my one-touch maxtor usb drive... just because i can't get the one touch button going on the maxtor does not make windows hard... On Monday 24 September 2007 23:23, Rodrigo Madera wrote: Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Clover 2 Plugin 3.0-beta-4 Released
On 24/09/2007, at 9:47 PM, Vincent Massol wrote: Hi Tom, Congrats for this first release under the Atlassian umbrella! Where can we see what's different from the last version of the Clover plugin located at Apache? I tried checking http://developer.atlassian.com/jira/browse/CLMVN? report=com.atlassian.jira.plugin.system.project:changelog-panel but there's only a 3.0 beta 1 version listed and it has no issues in it. I think this information might be useful for users interested in switching for the current version to this new version. Hi Vincent, We haven't migrated the outstanding issues from the codehaus JIRA instance yet. Features of beta 4: - uses Clover 2 instead of Clover 1 - fixes MCLOVER-71, MCLOVER-79, MCLOVER-80, MCLOVER-82 I've added a 3.0-beta-4 version to http://developer.atlassian.com/ jira/browse/CLMVN There's a fisheye instance here: http://svn.atlassian.com/fisheye/ browse/public/contrib/clover/maven-clover-plugin Regards, Tom
Re: AW: AW: how to specify the name of assembled distribution file
Sorry, I missed that you don't want to attach the assembly generation to the lifecycle. The proposed solution with the separate executions will not work in this scenario as maven only reads the plugin level configuration (plugin/configuration/) when a goal is invoked directly from the command line. The only option I see is to use profiles then. What I don't understand is the error message you get. I get a simple: [INFO] Error reading assemblies: No assembly descriptors found. And that's expected, as there in no one defined in the plugin level configuration. The assembly descriptor it's searching isn't even declared in the pom you posted. Is it defined in some parent pom? -Tim Ritz, Martin schrieb: my pom is: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version executions execution idassemblyone/id phasepackage/phase goals goalsingle/goal /goals configuration finalNametemplates/finalName appendAssemblyIdfalse/appendAssemblyId descriptors descriptorsrc/main/assembly/assembly_descriptor_templates.xml/descriptor /descriptors /configuration /execution execution idassemblytwo/id phasepackage/phase goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/assembly_descriptor_srcs.xml/descriptor descriptorsrc/main/assembly/assembly_descriptor_deploy.xml/descriptor /descriptors /configuration /execution /executions /plugin and I use the same structure (like your post) if I bind the plugin to the package phase everything works fine - the assemblies are built in the right way. I don't want to bind - i want to execute the plugin by the 'assembly:single' command. If I use this command i get the error below: [INFO] Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml D:\*\assembly_descriptor.xml (The System couldn't find the file) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading assemblies: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:257) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Error locating assembly descriptor file: D:\MRRITZ\workspace\xi\editools\trunk_m2\analyser\assembly_descriptor.xml at
Re: When builds are done in multi-module projects ?
2007/9/24, Emmanuel Venisse [EMAIL PROTECTED]: Continuum look at scm changes, if it contains some sources updates, it build the project. Then, it looks at dependencies list, if a dependency (that is a continuum project too) is updated (new build result in success), continuum build the project With no SCM changes and no dependencies, if the build definition is marked as always build and the build isn't forced, continuum won't build the project. For theses projects, always build is set to false :( Copy/paste for project build summary : SCM Changes : No SCM changes Dependencies Changes : No dependencies changes Build Definition Used POM filename : pom.xml Goals : clean deploy Arguments : --batch-mode --non-recursive Build Fresh : false Always Build : false Is it default ? : true Schedule : Midi And this project was built this noon ! Damien
Re: Why Maven is Hard?
So you are saying that Maven IS hard because someone doesn't understand a huge project that they've never used before? You are saying that if it was done in ant it would be easier to understand? I find that extremely hard to believe. I've read plenty of articles written that I thought explained nicely what Maven 2 is. If there is no good paragraph on the Maven website about what it is, then why would someone have started using it if they didn't know? If people are going nuts installing every plugin on the planet and then wondering why they can't understand Maven, then I have no pity for them. You don't start off programming by trying to do something complicated. Anyone that does that is asking for trouble, and can't blame that on the tool. Tools are tools, they can be misused and abused. With anything, someone has to have realistic expectations and expect to learn rather than just be productive instantly. I got started with Maven by simply building a jar, then a webapp (all documented on their site) and then added stuff to it as I needed. I've never had a problem and never felt lost to the point of frustration. On 9/24/07, Graham Leggett [EMAIL PROTECTED] wrote: Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. I am in the process of doing a handover of a fully mavenised build (all the way through to using the release plugin for releases) to someone who has only ever used ant before, and this process has highlighted that maven IS hard for a beginner to understand. Maven's first problem is that it is not described anywhere neatly in one single paragraph. To a maven beginner, project comprehension tool is entirely meaningless: Why do I need a tool to help me comprehend my project? It makes no sense to a beginner. I have tried to explain maven by calling it an extensible Swiss Army Knife: Rather than telling ant how to do every step of your build, maven already knows how to do every step of your build. You just add the missing bits of information like your project name and version number, and maven does the rest automatically. Another thing a beginner gets confused about is the bewildering volume of plugins. To cut through this confusion I grouped plugins into the basic core group of plugins, and all the other plugins after people ran with the idea and went bananas. Getting across to the user that they don't have to learn to use every plugin, but only the ones they need, is very reassuring for a new user. Something else new users get worried about is what happens if maven cannot do what I want maven to do, and here pointing out if all else fails strategies like using the antrun plugin to get ant to do stuff for you is very reassuring to the new user. The new user doesn't need to know how the antrun plugin works, they only need to know that it is there. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I'm really floored that this discussion is even happening. Here is why: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? If you are that upset about it, then you obviously like it. Therefore, give back to the community and do something productive with your time rather than complaining. Complaining won't give the project contributors more time in their day to write documentation, it will just simply make them feel unappreciated. I was always told that you can't complain about something unless you have a better idea. If you think there should be better documentation, help them out rather than hassle them. I'm managing a full enterprise application with Maven 2, with MANY subprojects (right about 20 or so), all of them have dependencies on each other. I'm also managing our repository, handling releases and deployments from Maven 2. I have portlet maven 2 projects in my build, core libraries (DAO), third party integration libraries, servicemix services and external web applications (that get loaded externally into the portlet because they can't be portlets themselves. And with all that I have to say that I have not had one time where Maven 2 hasn't provided me a way to get done what I needed to in a complicated build system and quickly. If you like ant, then the antrun plugin is your best friend. Just tell it when to run and then that's it. If I had to do all this in ant, it would have taken me way longer to create and manage. Even with managing all of this by myself, I find PLENTY of time to code and make improvements to the software. I think ant builds are way over complicated. I've seen ant builds that are just a complete mess because there is no structure to it. Every Maven project that I've come across (open source projects I've downloaded) have been very easy for me to get up and running with. The ant based ones I downloaded make me cringe and I don't even want to touch them. They are very hard to follow and I can't stand build.xml files that import other build.xml files. Yes some of the documentation is lacking, but you have to realize this is a really good project for free and I rarely have ever come across any problems with due to bugs. I can stand up a new project in our build in a couple minutes and instantly have a new component and ready to go. I think it takes more planning to how you are going to organize your code and projects so that dependencies are correct than they are that Maven 2 is just too difficult. I think maybe people could be feeling lost due to not being sure of the best practices, but no one is able to do everything perfectly the first time. I've never had problems finding information on what I've needed in places other than the Maven 2 site, and there is no shame in people having to look elsewhere. I'd rather a stable product with less documentation than an unstable product with documentation (why do I want to learn how to use something that doesn't work?). I've found plugins that I thought were hard to use, so I just use the ant version of them which is cake to plugin. I applaud the Maven team and am thankful for the time they've put into a product that has saved me so much time. Also, Maven is way easier to follow with a good tool. Just like code that you are trying to understand is very hard to follow without a tool. The Maven 2 netbeans plugin makes this all so easy to use. On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: I should also add that that does not include supporting 3rd party plugins... and often getting the source for them can be useful... i have my own versions of mojo hibernate, xslt among a few others while waiting for bug fixes... thats like saying that micrsoft is responsible for the documentation of the drivers for my one-touch maxtor usb drive... just because i can't get the one touch button going on the maxtor does not make windows hard... On Monday 24 September 2007 23:23, Rodrigo Madera wrote: Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum
How to pass options to the release plugin's 'goals' option?
Hi all, I'm using the release plugin as [1] but, when the plugin calls tomcat:redeploy [2], it ignores the -Dmaven.tomcat.url option. How can I pass a -Dsomething to the goals called by release plugin from -Dgoals option? Is that clear? [1] mvn -e release:perform -P homologacao -Dgoals=tomcat:redeploy -Dtag=seaup-2_0_22 -Dusername=alegomes -Dmaven.tomcat.url=http://192.168.1.68:8080/manager [2] [INFO] Executing goals 'tomcat:redeploy'... [INFO] Executing: mvn tomcat:redeploy --no-plugin-updates -P homologacao -DperformRelease=true [3] [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'tomcat'. [INFO] [INFO] Building SEAUP [INFO]task-segment: [tomcat:redeploy] [INFO] [INFO] [tomcat:redeploy] [INFO] Redeploying application at http://localhost:8080/seaup [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot invoke Tomcat manager thanks Alexandre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any advantage of utisng plexus-compiler-eclipse ?
osgi package imports/exports for instance. AFAIK is the only one that supports it On 9/24/07, nicolas de loof [EMAIL PROTECTED] wrote: Just curious, Is there anybody that use an alternative compiler for maven-compiler-plugin ? Does the eclipse compiler support any must-have feature ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make a Codehaus plugin works on a local configuration
Hi, I have exactly the same error on the same plugin, we are using artifactory locally and when the plugin is installed as a snapshot it frequently fails to download and fails the build. Running maven with a -U seems to fix the problem temporally. Did you ever find a solution to this? Did using artifactory help? Thanks James RomainTaz wrote: - Sorry, my previous mail was not properly sent. Here is a clen version - Hi all, I need to use a plugin available from Codehaus sandbox (this plugin is dashboard-maven-plugin). As explained in the plugin page, I need to add the following lines in my settings.xml file: pluginRepositories pluginRepository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories With this information, the plugin works correctly. In my company, we use a global repository, which is currently a shared directory on a network drive. Thus, all users have the following settings.xml file: settings !-- Path to local repository. The default location is ~/.m2/repository -- localRepositoryC:\m2\repository\/localRepository !-- Definition of mirror of Central Repository -- mirrors mirror idglobal-repository/id nameGlobal repo/name urlfile://F:\...\repository/url mirrorOfcentral/mirrorOf /mirror /mirrors profiles profile activation activeByDefaulttrue/activeByDefault /activation repositories repository idglobal-repository/id releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots urlfile://F:\...\repository/url /repository /repositories /profile /profiles !-- Definition of Plugins groups created by our team. -- pluginGroups pluginGroupmy.company.plugins/pluginGroup /pluginGroups /settings This repository is the mirror of the Global repository, and the users has no access to external repositories (Maven is not configured to access Internet on their computers). So, I added the plugin Dashboard-Report in our global repository. Now, in local configuration (i.e. with a settings.xml without external access), Maven is not able to retrieve this plugin. It throws the following error when I try to use it: The plugin 'org.apache.maven.plugins:maven-dashboard-report-plugin' does not exist or no valid version could be found I think that somewhere, in a XML metadata file, something is wrong, because Maven did not understand that the plugin is not a org.apache.maven.plugins (the prefix of this plugin is dashboard-report). What do I need to change in the settings.xml to make this plugin works in a local configuration? Or is there a good way to install this plugin in my global repository in order to work fine with local configuration? Note that we will move to Artifactory asap, but for the moment, I need a solution to make this plugin works with a repository based on a shared drive... Thanks for your help. ps: If you have any link, any information that clearly explains what Maven do with all metadata-*.xml, do not hesitate to share them :o) -- View this message in context: http://www.nabble.com/Make-a-Codehaus-plugin-works-on-a-local-configuration-tf4297606s177.html#a12860071 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make a Codehaus plugin works on a local configuration
Hi James, Sorry, but I didn't find any solution to solve this problem :( Thus, this plugin has been disabled on my configuration. Note that we still do not use Artifactory. So I can't tell you if this tool can solve this problem... If you have any idea... Regards. Romain Jimbog wrote: Hi, I have exactly the same error on the same plugin, we are using artifactory locally and when the plugin is installed as a snapshot it frequently fails to download and fails the build. Running maven with a -U seems to fix the problem temporally. Did you ever find a solution to this? Did using artifactory help? Thanks James -- View this message in context: http://www.nabble.com/Make-a-Codehaus-plugin-works-on-a-local-configuration-tf4297606s177.html#a12860139 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pass options to the release plugin's 'goals' option?
Problem solved with -Darguments=-Dmaven.tomcat.url=http://.. option. http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#arguments thanks On 9/24/07, Alexandre Gomes [EMAIL PROTECTED] wrote: Hi all, I'm using the release plugin as [1] but, when the plugin calls tomcat:redeploy [2], it ignores the -Dmaven.tomcat.url option. How can I pass a -Dsomething to the goals called by release plugin from -Dgoals option? Is that clear? [1] mvn -e release:perform -P homologacao -Dgoals=tomcat:redeploy -Dtag=seaup-2_0_22 -Dusername=alegomes -Dmaven.tomcat.url=http://192.168.1.68:8080/manager [2] [INFO] Executing goals 'tomcat:redeploy'... [INFO] Executing: mvn tomcat:redeploy --no-plugin-updates -P homologacao -DperformRelease=true [3] [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'tomcat'. [INFO] [INFO] Building SEAUP [INFO]task-segment: [tomcat:redeploy] [INFO] [INFO] [tomcat:redeploy] [INFO] Redeploying application at http://localhost:8080/seaup [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot invoke Tomcat manager thanks Alexandre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Way to distribute zip and sources
Hi, what is the easiest way to share artifacts like Zips, and SourceArchives with maven 2? Are there some plugins to handle and provide nightlybuilds on a central place? --- regards Martin Ritz
Re: Way to distribute zip and sources
Provide more details about your use case and perhaps someone can help. Wayne On 9/24/07, Ritz, Martin [EMAIL PROTECTED] wrote: Hi, what is the easiest way to share artifacts like Zips, and SourceArchives with maven 2? Are there some plugins to handle and provide nightlybuilds on a central place? --- regards Martin Ritz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Way to distribute zip and sources
I have setted up my maven infrastructure with nightlybuilds via Continuum Server. Now I want to provide the artifacts built by continuum (e.g. zips, sources, other archives, .exe, ...) in an flat hierarchy where my team members could easily find and download the artifacts. It should looks like for example http://people.apache.org/builds/james/nightly/ . Im on search for an maven plugin or an continuum extension which could handle the distribution of such directorys. So in this directories only the specific artifacts should be available and not the temporary build files or so on. Some hints/ recommendations would be very helpfull for me. Thx Martin -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. September 2007 16:09 An: Maven Users List Betreff: Re: Way to distribute zip and sources Provide more details about your use case and perhaps someone can help. Wayne On 9/24/07, Ritz, Martin [EMAIL PROTECTED] wrote: Hi, what is the easiest way to share artifacts like Zips, and SourceArchives with maven 2? Are there some plugins to handle and provide nightlybuilds on a central place? --- regards Martin Ritz - 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: attached tests dependency error
It was almost perfect, Tim. Then you screwed up the last example. ;-)
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
classifiertests/classifier
/dependency
This corresponds to the file:
com/myco/app/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT-tests.jar
The default naming convention is:
groupId/artifactId-version-classifier.packaging
Wayne
On 9/24/07, Tim Kettler [EMAIL PROTECTED] wrote:
Hi,
I will try my best to explain how I understand the underlying concepts
but as I'm not a maven developer and the code and design documentation
is rather sparse there might be some misconceptions on my side.
What I'm a little bit confused about is the distinction between type and
packaging. The termes are used somewhat interchangable in the pom and
documentation: You give a 'packaging' for the artifact you build but
declare the 'type' of dependencies. In the below text I will use them as
if they would mean the same.
For example when you build a j2ee app you would have a war project with
the packaging set to 'war'. In the ear project you then declare the
dependency to the war project with a type of 'war'.
Perhaps someone with more insight than me can explain why this
distinction between packaging and type is made.
A maven artifact is identified by the coordinates
groupId:artifactid:classifier:version:packaging (where a default
packaging of kind 'jar' is assumed if no packaging is explicitly given).
What is going on behind the scences is this:
For each artifact-(type/packaging) there is an associated
ArtifactHandler [1] either explicitly declared or implicitly created
on the fly. An ArtifactHandler provides the file extension and default
classifier for an artifact-type. The ArtifactHandler for a dependency is
looked up in the ArtifactHandlerManager [2].
The ArtifactHandlers for the standard artifact-types are declared in
this components.xml file [3].
When you declare this dependency:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetests/type
/dependency
Maven looks up the ArtifactHandler for artifacts of type 'tests' in its
ArtifactHandlerManager, since there is no such handler explicitly
declared in [3] the DefaultArtifactHandlerManager [4] creates one on the
fly based on the given type. This on-the-fly handler returns the value
of the type for the extension and packaging ('tests' in this case). So
the dependency given above resolves to this path in the repository:
com/myco/app/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.tests
wich obviously doesn't exist. However, this dependency declaration
should work:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetest-jar/type
/dependency
As there is a artifact handler defined for the type 'test-jar' that maps
to a standard classifier of 'tests' and an extension of 'jar'. This
should result in a repository path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
Similar for this declaration:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
classifiertests/classifier
/dependency
Here a default type of 'jar' is assumed which maps to an extension of
'jar' via the associated artifact handler. Together with the explicitly
declared classifier one should end up with a path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
PERIOD.
Sorry for this lengthy explanation, I hope it is somewhat understandable.
-Tim
[1]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java
[2]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/ArtifactHandlerManager.java
[3]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/resources/META-INF/plexus/components.xml
[4]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/DefaultArtifactHandlerManager.java
zalym schrieb:
Hi Tim,
totally out of scope, but i am curious. what is this type identifier for in
dependency? and why is it resolved as period in the artifact?
Saleem
Tim Kettler wrote:
zalym schrieb:
I followed the attached tests guide to create a dependency to my core
tests.
The first part of the tutorial worked, and I could install a version of
the
test jar in the local repository as models-3.0-tests.jar. When I tried
to
add this as a dependency in another project, it came up with a dependency
missing error and when I noticed this in the message:
models-3.0.tests
What could be wrong? Why would the
Re: Error running Continuum - address already in use ????
Now, incredibly it works but I did nothing of helpful, I didn't close Skype, I did'nt restart my pc A H Y E A H my friends! olivier lamy wrote: Hi, In order to test if the port is already use just try : telnet localhost 8080 -- Olivier 2007/9/24, Raffaele [EMAIL PROTECTED]: Thanks Emmanuel by the way I have the same error also with continuum 1.1 alpha 2 I tried also to restart my pc, and I trid also to change the port as already explained in my previous post. Now I remember that I had these same errores with another Apache product, that is ActiveMQand also in the forum of ActiveMQ many people had this problem, that is address already in use. What could I try? Thanks. Raffaele Emmanuel Venisse wrote: the port was probably used by an other application and wasn't released properly. Try to reboot your machine. If you start on Continuum, I think it would be better to use Continuum 1.1. We'll release 1.1-beta-3 this week. Emmanuel Raffaele a écrit : Hi all, I have the following stack trace running Continuum: jvm 1| [INFO] Deploying application 'continuum'. jvm 1| [INFO] Adding HTTP listener on *:8080 jvm 1| 15:27:06.754 WARN!! Failed to start: [EMAIL PROTECTED]:8080 jvm 1| Error while deploying application 'continuum-plexus-application-1.0.3 .jar'. jvm 1| org.codehaus.plexus.application.ApplicationServerException: Could not deploy the JAR jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deployJar(DefaultApplicationDeployer.java:216) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:136) jvm 1| at org.codehaus.plexus.application.deploy.DefaultApplicationDepl oyer.deploy(DefaultApplicationDeployer.java:116) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer$2.on JarDiscovered(DefaultApplicationServer.java:117) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scanDirectory(DefaultSupervisor.java:89) jvm 1| at org.codehaus.plexus.application.supervisor.DefaultSupervisor. scan(DefaultSupervisor.java:68) jvm 1| at org.codehaus.plexus.application.DefaultApplicationServer.star t(DefaultApplicationServer.java:146) jvm 1| at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartP hase.execute(StartPhase.java:16) jvm 1| at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start( AbstractLifecycleHandler.java:101) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.startComponentLifecycle(AbstractComponentManager.java:105) jvm 1| at org.codehaus.plexus.component.manager.AbstractComponentManage r.createComponentInstance(AbstractComponentManager.java:95) jvm 1| at org.codehaus.plexus.component.manager.ClassicSingletonCompone ntManager.getComponent(ClassicSingletonComponentManager.java:92) jvm 1| at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlex usContainer.java:331) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.start(P lexusApplicationHost.java:109) jvm 1| at org.codehaus.plexus.application.PlexusApplicationHost.main(Pl exusApplicationHost.java:236) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.jav a:315) jvm 1| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) jvm 1| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.j ava:430) jvm 1| at org.codehaus.classworlds.Launcher.main(Launcher.java:375) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jvm 1| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) jvm 1| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) jvm 1| at java.lang.reflect.Method.invoke(Method.java:597) jvm 1| at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimple App.java:136) jvm 1| at java.lang.Thread.run(Thread.java:619) jvm 1| Caused by: org.codehaus.plexus.service.jetty.ServletContainerExceptio n: Error while starting listener on address: 'null', port: 8080. jvm 1| at org.codehaus.plexus.service.jetty.JettyServletContainer.addLi stener(JettyServletContainer.java:161) jvm 1| at
Re: Control the build sequency
No, it seems not to be possible (extract from http://mojo.codehaus.org/dashboard-maven-plugin/continuum.html) : the dashboard report plugin must be running in 2 passes. To work fine with *Continuum*, you must configure the goals as : 1. *first goal* : mvn clean install site 1. compile and test all sources. 2. generate the site. 3. let each report plugin generate its xml file. 2. *second goal* : mvn dashboard-report:dashboard 1. aggregate all results of each report. 2. re-generate the dashboard HTML file. 3. *third goal* : mvn site:deploy Perhaps I would have to use a script shell... Arnaud Emmanuel Venisse a écrit : No, it isn't possible to chain some build definitions. Isn't it possible to run mvn clean install site dashboard-report:dashboard site:deploy in one command? Emmanuel Doucet Arnaud a écrit : Hi, I'm using dashboard plugin which requires to split site generation in 3 steps in a certain order : * 1 : mvn clean install site (scheduled at 02:05). * 2 : mvn dashboard-report:dashboard (scheduled at 02:45). * 3 : mvn site :deploy (scheduled at 02:55). The problem is that Continuum may have to insert the execution of a build between the first and the last build above. For example an hourly 'mvn clean deploy' which normally should be executed at 02:00 may have been reported to 02:30. In such a case, the build 'mvn site:deploy' will fail. Is there a way to chain some build definitions and make sure that there will be no other build execution inside this chain. Thanks. Arnaud Doucet
Re: Why Maven is Hard?
On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Control the build sequency
Doucet Arnaud a écrit : No, it seems not to be possible (extract from http://mojo.codehaus.org/dashboard-maven-plugin/continuum.html) : the dashboard report plugin must be running in 2 passes. To work fine with *Continuum*, you must configure the goals as : 1. *first goal* : mvn clean install site 1. compile and test all sources. 2. generate the site. 3. let each report plugin generate its xml file. 2. *second goal* : mvn dashboard-report:dashboard 1. aggregate all results of each report. 2. re-generate the dashboard HTML file. 3. *third goal* : mvn site:deploy Perhaps I would have to use a script shell... Yes, I don't see an other solution for this case. Emmanuel Arnaud Emmanuel Venisse a écrit : No, it isn't possible to chain some build definitions. Isn't it possible to run mvn clean install site dashboard-report:dashboard site:deploy in one command? Emmanuel Doucet Arnaud a écrit : Hi, I'm using dashboard plugin which requires to split site generation in 3 steps in a certain order : * 1 : mvn clean install site (scheduled at 02:05). * 2 : mvn dashboard-report:dashboard (scheduled at 02:45). * 3 : mvn site :deploy (scheduled at 02:55). The problem is that Continuum may have to insert the execution of a build between the first and the last build above. For example an hourly 'mvn clean deploy' which normally should be executed at 02:00 may have been reported to 02:30. In such a case, the build 'mvn site:deploy' will fail. Is there a way to chain some build definitions and make sure that there will be no other build execution inside this chain. Thanks. Arnaud Doucet
Re: Why Maven is Hard?
And having read the rest of your statement I do exactly the same with with 90+ artifacts culminating in 9 different aggregations == war, ear, compound jar On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: I'm managing a full enterprise application with Maven 2, with MANY subprojects (right about 20 or so), all of them have dependencies on each other. I'm also managing our repository, handling releases and deployments from Maven 2. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Duplicate class problem
Hello, I have a small and interesting problem I would like to solve. I have 2 projects A and B. - A contains a jjtree source file that is used to generate AST nodes and a parser - B uses A *but* also rewrites some of the AST nodes thus providing its own classes. When I package everything, here is what happens: - A compiles OK but then B's compilation fails becasue the compiler uses classes from A instead of their rewritten form - if I exclude offending classes in A, of courses it does not compile. I could use maven-jar to exclude specific classes from packaging but exclusion does not work according to recent posts. Help appreciated, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Isn't this sort of a catch-22? People are saying I don't get maven, it's too complex. Now it's time for them to give something back and document it? How do you propose they do that? Start at the source and pore through it to explain it? Saying that is sort of a cop-out, IMO. I think that the problem is that we have maven in 5 minutes and then the rest of the docs assume that people are experts with it - the 2 books mentioned earlier are useful, but I think people want something more approachable and contextual. One other thing is the navigation - I find it very difficult to get around the maven site in any meaningful way. There are many inter-dependent concepts and components, and each area's documentation assumes that the reader understands the other areas. For a beginner, that is rarely if ever the case. I'm not trying to add the rants, just provide some constructive criticism. Larry On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - 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: Why Maven is Hard?
The Maven User wiki is a great place for users to begin contributing in a meaningful way: http://docs.codehaus.org/display/MAVENUSER/Home Also, the wiki is a great place to look for help, documentation, examples etc. If you're having trouble with finding things on the Maven site, check out the Wiki. Wayne On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - 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: Any advantage of utisng plexus-compiler-eclipse ?
Is there any compiler to target 1.3 with source 1.5 ? There is no limitation for that in the class file format. 2007/9/24, Carlos Sanchez [EMAIL PROTECTED]: osgi package imports/exports for instance. AFAIK is the only one that supports it On 9/24/07, nicolas de loof [EMAIL PROTECTED] wrote: Just curious, Is there anybody that use an alternative compiler for maven-compiler-plugin ? Does the eclipse compiler support any must-have feature ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: Why Maven is Hard?
One of Maven's values is that it does the heavy lifting for you. (as it's literature describes.) But that is also exactly the problem - because it is sometimes hard to tell what is going on. You need to keep the Maven cycle in mind at all times - and that does add another level of indirection. As a build engineer I am often getting complicated Maven poms from developers and then I gotta decipher what is happening. With Ant - it's a lot more transparent. I am not criticizing maven (then we'd be talking about the painful bugs), but I do think that it is fair to say that it is harder to understand what is happening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Junit4 and oneTimeSetUp
I'm trying to run JUnit4 tests in one of the modules of a project that uses 3.8.1 I have added the 4.4 version as dependency and configured the maven-surefire-plugin to 2.3 When I run the test it seems that is not running JUnit4 tests, instead is using the 3.8.1. I have added the method oneTimeSetUp with the @BeforeClass annotation, and is not being called. Is Maven overriding the old version of JUnit that it's specified in the parent project? -- View this message in context: http://www.nabble.com/Junit4-and-oneTimeSetUp-tf4509797s177.html#a12861920 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Way to distribute zip and sources
If you're using maven2 take a look at the assmebly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#src). Basically it can create a zip file of your source and upload it to your repo. -Christopher -Original Message- From: Ritz, Martin [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 10:23 AM To: Maven Users List Subject: AW: Way to distribute zip and sources I have setted up my maven infrastructure with nightlybuilds via Continuum Server. Now I want to provide the artifacts built by continuum (e.g. zips, sources, other archives, .exe, ...) in an flat hierarchy where my team members could easily find and download the artifacts. It should looks like for example http://people.apache.org/builds/james/nightly/ . Im on search for an maven plugin or an continuum extension which could handle the distribution of such directorys. So in this directories only the specific artifacts should be available and not the temporary build files or so on. Some hints/ recommendations would be very helpfull for me. Thx Martin -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. September 2007 16:09 An: Maven Users List Betreff: Re: Way to distribute zip and sources Provide more details about your use case and perhaps someone can help. Wayne On 9/24/07, Ritz, Martin [EMAIL PROTECTED] wrote: Hi, what is the easiest way to share artifacts like Zips, and SourceArchives with maven 2? Are there some plugins to handle and provide nightlybuilds on a central place? --- regards Martin Ritz - 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] ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Junit4 and oneTimeSetUp
mateamargo wrote: I'm trying to run JUnit4 tests in one of the modules of a project that uses 3.8.1 I have added the 4.4 version as dependency and configured the maven-surefire-plugin to 2.3 When I run the test it seems that is not running JUnit4 tests, instead is using the 3.8.1. I have added the method oneTimeSetUp with the @BeforeClass annotation, and is not being called. Is Maven overriding the old version of JUnit that it's specified in the parent project? Nevermind, I found the solution. The test class shouldn't extend the TestCase class. -- View this message in context: http://www.nabble.com/Junit4-and-oneTimeSetUp-tf4509797s177.html#a12861925 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there anybody caring for bugs in the Maven 2.x Help Plugin?
Is there anybody caring for bugs in the Maven 2.x Help Plugin? Especially http://jira.codehaus.org/browse/MPH-16 (inherited profiles are not shown when calling help:active-profiles) has been opened since June 2006 and is still unassigned. -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repos Managers : Archiva, artifactory, proximity, file://
Hi I have to install some maven repositories for our internal artifacts. I have already try 3 types of repo : file://, archiva and artifactory I also have heard about proximity, but the live demo is down since .. pfui... 2 months... not sure I want to use that.. Archiva : pro store artifact on file cons : SLOW, very slow unstable, or I dont know how to use it... I have installed the last version (apache-archiva-1.0-beta-2-bin.tar.gz) and the upgrade from 1.0 beta1 was hard : various bug, I have lost artifacts... (how do you do to restart a fresh install of archiva? clear archiva/database? Artifactory : cons: slow too, ajax web interface is not very fast. use an internal db to store artifacts... pro : may be quicker than archiva file// (I mean deploy to file:// urls) pro: easy! store artifacts on hdd cons : no web interface to show depenencies, license, various infos... So here is my question : what do you use? any of those 4 repos manager, another? Here is my needs : use it as a maven repository deploy artifacts (file or dav...) : snapshots and releases clean olds snapshots Thx! -- Julien Graglia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repos Managers : Archiva, artifactory, proximity, file://
Hi I have to install some maven repositories for our internal artifacts. I have already try 3 types of repo : file://, archiva and artifactory I also have heard about proximity, but the live demo is down since .. pfui... 2 months... not sure I want to use that.. Archiva : pro store artifact on file cons : SLOW, very slow unstable, or I dont know how to use it... I have installed the last version (apache-archiva-1.0-beta-2-bin.tar.gz) and the upgrade from 1.0 beta1 was hard : various bug, I have lost artifacts... (how do you do to restart a fresh install of archiva? clear archiva/database? Artifactory : cons: slow too, ajax web interface is not very fast. use an internal db to store artifacts... pro : may be quicker than archiva file// (I mean deploy to file:// urls) pro: easy! store artifacts on hdd cons : no web interface to show depenencies, license, various infos... So here is my question : what do you use? any of those 4 repos manager, another? Here is my needs : use it as a maven repository deploy artifacts (file or dav...) : snapshots and releases clean olds snapshots Thx! -- Julien Graglia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Way to distribute zip and sources
Did you ask the Apache James people how they set this up? They may have some advice for you. Or perhaps you can browse their source code and look at the pom.xml etc files to figure it out. It looks like a plain-jane filesystem which is front-ended by a web server. Take a look at mvn deploy and point it at a simple filesystem path, then put a webserver on top, and you're done. Wayne On 9/24/07, Ritz, Martin [EMAIL PROTECTED] wrote: I have setted up my maven infrastructure with nightlybuilds via Continuum Server. Now I want to provide the artifacts built by continuum (e.g. zips, sources, other archives, .exe, ...) in an flat hierarchy where my team members could easily find and download the artifacts. It should looks like for example http://people.apache.org/builds/james/nightly/ . Im on search for an maven plugin or an continuum extension which could handle the distribution of such directorys. So in this directories only the specific artifacts should be available and not the temporary build files or so on. Some hints/ recommendations would be very helpfull for me. Thx Martin -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. September 2007 16:09 An: Maven Users List Betreff: Re: Way to distribute zip and sources Provide more details about your use case and perhaps someone can help. Wayne On 9/24/07, Ritz, Martin [EMAIL PROTECTED] wrote: Hi, what is the easiest way to share artifacts like Zips, and SourceArchives with maven 2? Are there some plugins to handle and provide nightlybuilds on a central place? --- regards Martin Ritz - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Ryan Moquin wrote: So you are saying that Maven IS hard because someone doesn't understand a huge project that they've never used before? Yes. You are saying that if it was done in ant it would be easier to understand? Absolutely not. What on earth gave you that idea? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Eclipse complaining about filter tokens in orion-application.xml file
If you read all of my posts to this list (doubtful), then you'll know
that I'm working with Eclipse lately (under the guise of SAP NWDS).
Things are generally OK except that Eclipse is complaining about my
orion-application.xml file. I am using filtering to insert values
during the build, but Eclipse doesn't know that so it complains, and
I'm not sure what the best approach is to get around this annoyance.
Here's the file and it works great in Maven:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE orion-application PUBLIC -//ORACLE//DTD OC4J Application
runtime 9.04//EN
http://xmlns.oracle.com/ias/dtds/orion-application-9_04.dtd;
orion-application
jazn ${jazn.config} /
/orion-application
And my corresponding profiles.xml:
prod,qe = jazn.configprovider=LDAP/jazn.config
local = jazn.configprovider=XML location=jazn-data.xml
persistence=VM_EXIT/jazn.config
(Basically its a hassle to set up the LDAP option, so we just use the
XML option locally, but then on the prod and qe environment we like to
use LDAP.)
I've tried the following:
orion-application
jazn provider=${jazn.config} /
/orion-application
Plus changed profiles.xml:
prod,qe = jazn.configLDAP/jazn.config
local = jazn.configXML location=jazn-data.xml
persistence=VM_EXIT/jazn.config
That should work, but Eclipse looks at the DTD and says options for
provider are XML and LDAP and breaks.
Similar stuff happens when I tried:
orion-application
${jazn.config}
/orion-application
and other things similar. The DTD says the file is bad so Eclipse complains.
My next thought is to simply replace the filtered file with a full
(proper) XML file for each environment and then tell Maven to copy one
or the other using profiles. But I'm not certain if this is the best
approach, nor am I sure how the main/src/resources folder should look
to make this work best. Another option is to write a little plugin
that I can add some configuration options to etc and allow it to
generate the file for me during the build.
Anyone run into this (or something similar) and have some
advice/options for the best way forward? I'd be OK with a simple way
to tell Eclipse shut up, this file is fine but can't find that
option... ;-)
Wayne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I agree with previous observations that some of the plugins have very poor documentation regarding their parameters. Regarding complex projects, any POM that is non-trivial should be well commented to describe the operations that are novel. Every effort should be made to keep builds plain and simple. In Ant, of course, you can just read the script as it describes the procedure down to the last detail. But in Mavens nippy declarative language, heavy commenting is essential because of the black-box effect. Novel plugins should be well documented and can make use of the info log to tell the builder what is happening. Regards, John -Original Message- From: Bob Aiello [mailto:[EMAIL PROTECTED] Sent: 24 September 2007 16:24 To: Maven Users List Subject: RE: Why Maven is Hard? One of Maven's values is that it does the heavy lifting for you. (as it's literature describes.) But that is also exactly the problem - because it is sometimes hard to tell what is going on. You need to keep the Maven cycle in mind at all times - and that does add another level of indirection. As a build engineer I am often getting complicated Maven poms from developers and then I gotta decipher what is happening. With Ant - it's a lot more transparent. I am not criticizing maven (then we'd be talking about the painful bugs), but I do think that it is fair to say that it is harder to understand what is happening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: attached tests dependency error
Thanks Tim. Enlightening.
-- Saleem
Tim Kettler wrote:
Hi,
I will try my best to explain how I understand the underlying concepts
but as I'm not a maven developer and the code and design documentation
is rather sparse there might be some misconceptions on my side.
What I'm a little bit confused about is the distinction between type and
packaging. The termes are used somewhat interchangable in the pom and
documentation: You give a 'packaging' for the artifact you build but
declare the 'type' of dependencies. In the below text I will use them as
if they would mean the same.
For example when you build a j2ee app you would have a war project with
the packaging set to 'war'. In the ear project you then declare the
dependency to the war project with a type of 'war'.
Perhaps someone with more insight than me can explain why this
distinction between packaging and type is made.
A maven artifact is identified by the coordinates
groupId:artifactid:classifier:version:packaging (where a default
packaging of kind 'jar' is assumed if no packaging is explicitly given).
What is going on behind the scences is this:
For each artifact-(type/packaging) there is an associated
ArtifactHandler [1] either explicitly declared or implicitly created
on the fly. An ArtifactHandler provides the file extension and default
classifier for an artifact-type. The ArtifactHandler for a dependency is
looked up in the ArtifactHandlerManager [2].
The ArtifactHandlers for the standard artifact-types are declared in
this components.xml file [3].
When you declare this dependency:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetests/type
/dependency
Maven looks up the ArtifactHandler for artifacts of type 'tests' in its
ArtifactHandlerManager, since there is no such handler explicitly
declared in [3] the DefaultArtifactHandlerManager [4] creates one on the
fly based on the given type. This on-the-fly handler returns the value
of the type for the extension and packaging ('tests' in this case). So
the dependency given above resolves to this path in the repository:
com/myco/app/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.tests
wich obviously doesn't exist. However, this dependency declaration
should work:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
typetest-jar/type
/dependency
As there is a artifact handler defined for the type 'test-jar' that maps
to a standard classifier of 'tests' and an extension of 'jar'. This
should result in a repository path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
Similar for this declaration:
dependency
groupIdcom.myco.app/groupId
artifactIdfoo/artifactId
version1.0-SNAPSHOT/version
classifiertests/classifier
/dependency
Here a default type of 'jar' is assumed which maps to an extension of
'jar' via the associated artifact handler. Together with the explicitly
declared classifier one should end up with a path of:
com/myco/app/foo/1.0-SNAPSHOT/foo-tests-1.0-SNAPSHOT.jar
PERIOD.
Sorry for this lengthy explanation, I hope it is somewhat understandable.
-Tim
[1]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java
[2]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/ArtifactHandlerManager.java
[3]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/resources/META-INF/plexus/components.xml
[4]
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/manager/DefaultArtifactHandlerManager.java
zalym schrieb:
Hi Tim,
totally out of scope, but i am curious. what is this type identifier for
in
dependency? and why is it resolved as period in the artifact?
Saleem
Tim Kettler wrote:
zalym schrieb:
I followed the attached tests guide to create a dependency to my core
tests.
The first part of the tutorial worked, and I could install a version of
the
test jar in the local repository as models-3.0-tests.jar. When I tried
to
add this as a dependency in another project, it came up with a
dependency
missing error and when I noticed this in the message:
models-3.0.tests
What could be wrong? Why would the dependency be resolbed with a
period
and
not a hyphen.
This is most probably a bug in the documentation. Looking at the mojo's
source code [1] shows that the artifact is created with a type of
'test-jar' and the classifier 'tests'.
You should try to use 'test-jar' as the type in your dependency
declaration or respectivly skip the type declaration and use a
Some questions about site generation
Hi, So I've gotten pretty far with Maven (to the point where I'm liking it more and more). It's a slow slog, wading through articles and documentation, but I'm starting to like it. I've got a few questions on site generation 1. How do I specify the location of my license file for site generation. I assume this is just a tag in my POM like most of the other site related bits. 2. Can I supply HTML formatted text for my description text in my POM that is used to form the about section of the website? It seems like I can only use unformatted text. Maybe there's an alternate tag to an external HTML snippet? 3. To include clover code coverage reports in my site generation, I always need to run clover:instrument goal first. (I've already got plugin artifactIdmaven-clover-plugin/artifactId /plugin in my pom to include the report). Is there a way I can specify this as an added task (still using ant terminology) for site generation so I don't need to include the instrument goal whenever I want to create my site? Any help is appreciated. Thanks, Bryant
Re: Some questions about site generation
Bryant Harris [EMAIL PROTECTED] writes: Hi, So I've gotten pretty far with Maven (to the point where I'm liking it more and more). It's a slow slog, wading through articles and documentation, but I'm starting to like it. I've got a few questions on site generation 1. How do I specify the location of my license file for site generation. I assume this is just a tag in my POM like most of the other site related bits. There is a tag licences in the POM http://maven.apache.org/ref/current/maven-model/maven.html#class_license 2. Can I supply HTML formatted text for my description text in my POM that is used to form the about section of the website? It seems like I can only use unformatted text. Maybe there's an alternate tag to an external HTML snippet? Did you try using ![CDATA[ ... ]] section ? 3. To include clover code coverage reports in my site generation, I always need to run clover:instrument goal first. (I've already got plugin artifactIdmaven-clover-plugin/artifactId /plugin in my pom to include the report). Is there a way I can specify this as an added task (still using ant terminology) for site generation so I don't need to include the instrument goal whenever I want to create my site? Not sure of this issue but instrumentation and report generation are two different things: - when you run mvn site, it does compile,test or does anything that pertains to the normal (ie. default lifecycle). AFAIK, clover's reporting scheme follows standard convention and the usual thing it does is just read generated data from previous test runs and generate the report - if you still want your plugin to run as part of a site build, you could use the following syntax: build plugins plugin artifactIdmaven-clover-plugin/artifactId executions execution phasesite/phase goals goalinstrument/goal/goals configuration HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running hibernate3 plugin with jpaconfiguration
It works in AppFuse - maybe it'd help to look at our configuration.
Archetype creation commands @
http://appfuse.org/display/APF/AppFuse+QuickStart
Change from Hibernate to JPA:
http://appfuse.org/display/APF/Using+JPA#UsingJPA-setup
HTH,
Matt
thebugslayer wrote:
Hi,
Can someone please help me see why I do not see my database table
created after I ran $ mvn hibernate3:hbm2ddl? I don't have any errors,
just database wasn't updated.
This is my partial pom.xml
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdhibernate3-maven-plugin/artifactId
version2.0-alpha-2/version
configuration
components
component
namehbm2ddl/name
/component
/components
componentProperties
implementationjpaconfiguration/implementation
droptrue/drop
createtrue/create
exporttrue/export
jdk5true/jdk5
persistenceunitdefault/persistenceunit
/componentProperties
/configuration
dependencies
dependency
groupIdmysql/groupId
artifactIdmysql-connector-java/artifactId
version5.0.5/version
/dependency
/dependencies
/plugin
Here is my persistence.xml
?xml version=1.0 encoding=UTF-8?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd;
version=1.0
persistence-unit name=default
providerorg.hibernate.ejb.HibernatePersistence/provider
properties
!-- Auto detect annotation model classes --
property name=hibernate.archive.autodetection
value=class/
!-- Datasource --
property name=hibernate.dialect
value=org.hibernate.dialect.MySQLDialect/
property name=hibernate.connection.driver_class
value=com.mysql.jdbc.Driver/
property name=hibernate.connection.username value=root/
property name=hibernate.connection.password value=/
property name=hibernate.connection.url
value=jdbc:mysql://localhost/auction_dev/
/properties
/persistence-unit
/persistence
Here is my mvn output:
[INFO] [hibernate3:hbm2ddl]
04:40:52,707 INFO org.hibernate.ejb.Version - Hibernate EntityManager
3.2.0.GA
04:40:52,723 INFO org.hibernate.cfg.annotations.Version - Hibernate
Annotations 3.2.0.GA
04:40:52,730 INFO org.hibernate.cfg.Environment - Hibernate 3.2.0.cr5
04:40:52,734 INFO org.hibernate.cfg.Environment -
hibernate.properties not found
04:40:52,735 INFO org.hibernate.cfg.Environment - Bytecode provider
name : cglib
04:40:52,740 INFO org.hibernate.cfg.Environment - using JDK 1.4
java.sql.Timestamp handling
[DEBUG] basedir: /Users/zemian/Desktop/projects/auction
[INFO] src/main/resources/hibernate.cfg.xml not found within the
project. Trying absolute path.
[INFO] No hibernate configuration file loaded.
[INFO] src/main/resources/database.properties not found within the
project. Trying absolute path.
[INFO] No hibernate properties file loaded.
04:40:53,067 INFO org.hibernate.dialect.Dialect - Using dialect:
org.hibernate.dialect.MySQLDialect
04:40:53,108 INFO org.hibernate.tool.hbm2ddl.SchemaExport - Running
hbm2ddl schema export
04:40:53,109 INFO org.hibernate.tool.hbm2ddl.SchemaExport - exporting
generated schema to database
04:40:53,112 INFO
org.hibernate.connection.DriverManagerConnectionProvider - Using
Hibernate built-in connection pool (not for production use!)
04:40:53,112 INFO
org.hibernate.connection.DriverManagerConnectionProvider - Hibernate
connection pool size: 20
04:40:53,112 INFO
org.hibernate.connection.DriverManagerConnectionProvider - autocommit
mode: true
04:40:53,116 INFO
org.hibernate.connection.DriverManagerConnectionProvider - using
driver: com.mysql.jdbc.Driver at URL:
jdbc:mysql://localhost/auction_dev
04:40:53,116 INFO
org.hibernate.connection.DriverManagerConnectionProvider - connection
properties: {user=root, password=, autocommit=true,
release_mode=auto}
04:40:53,329 INFO org.hibernate.tool.hbm2ddl.SchemaExport - schema
export complete
04:40:53,330 INFO
org.hibernate.connection.DriverManagerConnectionProvider - cleaning up
connection pool: jdbc:mysql://localhost/auction_dev
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
Re: Why Maven is Hard?
I too find the official Maven docs to be insufficient to many tasks. On the other hand, while I have rewritten some of those docs and submitted them back, I can't really figure out a good way to reorganize them so as to provide me with what I need. Someone will think of that someday and we will all go, Why didn't I think of that? and the problem will be solved. I suspect that the first Ant version had docs that were harder to use than the current Ant does. When I started with Ant it was 2001 and I found it hard to understand. Then came an ah-ah moment and I knew Ant's system well enough to start finding my answers. I think the basic docs for Ant are still a bit lacking. (That's as opposed to the task docs.) Once you know enough that you can find a 'task' name and look it up, though, that part of Ant's doc works pretty well. Compare that to Maven. Maven has a bigger basic part than Ant. That means it's going to take longer to get to the ah-ha where you start knowing how to look things up. If you don't know whether you need info on a plugin or in the basic Maven features, it's really hard to know where to look in the online docs. Second, I also remember maintaining giant, complicated Ant scripts to build the complete EAR for a whole application. The first time I did that, all on my own, without stealing the ANT code from other folks, it was a mess. I spent weeks getting things to build right and nobody else could touch the Ant build file without messing it up somehow. Similarly, coming into a big project with existing Ant scripts, I never figured out how it worked. I only learned how to make changes to the small parts I worked with. (Maven is much easier to use in this situation.) That confusion with a new build system is exactly what happened with my first set of POMs for building a complete application. Every feature that wasn't a standard part of a Maven build was a mess. But, the messes were independent of each other because of the way Maven works. So I didn't have to get everything working before anything worked. (That's the way that first Ant script worked.) Then I added a couple dozen lines to the parent POM and ended up with lots of interesting reports. I added a few more lines of xml and got the build totally repeatable with documented jar versions and maven versions set. I was able to clean up the funky parts without breaking everything else. That was a wonderful thing Maven did for me. The main tricky part (and this was early last year) was the bugs in the various plugins and mismatch issues with other development tools. Oops, sorry, you can't have it build all the javadoc for all the jars together until the next version. And you have to organize your project this way to make it work with Eclipse 3.2 but then the release plugin doesn't quite work. And you can't get MyEclipse to deploy your application because it has different conventions than Maven. The bug situation is so much better now but I'm sure it still frustrates new users. My conclusions: 1) Maven is better than Ant and I have the same learning curve I did when I learned Ant. I'm just older and more set in my ways now. 2) Maven and other development tools don't quite work together smoothly. I hope that gets fixed. I see progress. 3) Any bug in Maven or a plugin drives me nuts because it's hard to work around it. Adding Ant tasks to the Maven build as a work-around is not always straightforward and always requires more knowledge of the internal way Maven works than I want to learn. Thanks. -- Lee On 9/24/07, Bob Aiello [EMAIL PROTECTED] wrote: One of Maven's values is that it does the heavy lifting for you. (as it's literature describes.) But that is also exactly the problem - because it is sometimes hard to tell what is going on. You need to keep the Maven cycle in mind at all times - and that does add another level of indirection. As a build engineer I am often getting complicated Maven poms from developers and then I gotta decipher what is happening. With Ant - it's a lot more transparent. I am not criticizing maven (then we'd be talking about the painful bugs), but I do think that it is fair to say that it is harder to understand what is happening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Code Coverage Plugins with Maven 2
AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Could not find parent's pom.xml when running site
Hello, It seems to me that maven (or site plug-in) could not find the parent's pom.xml when I run mvn site in the module. I have this parent defined: parent groupIdmycompany/groupId artifactIdmyparent/artifactId version$myversion/version relativePath../../../relativePath /parent When I run mvn site, I got this warning message: [WARNING] Unable to load parent project from repository: Could not find the model file 'C:\myfolder1\myfolder2\myfolder3\myfolder4\myfolder5\myfolder6\..\..\..'. for project unknown and also it seems to me that the $version is not resolved when running under site. On the contrast, when I run mvn install', maven is able to find the parent's pom.xml and resolve the variable $version which is defined in parent. Any ideas? Thanks Yan
Re: Code Coverage Plugins with Maven 2
We use cobertura with Maven no problems. When I set it up it was just a matter of picking the previous version of the plugin, one minor number down. - Original message - From: mraible [EMAIL PROTECTED] To: users@maven.apache.org Date: Mon, 24 Sep 2007 09:56:48 -0700 (PDT) Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: Code Coverage Plugins with Maven 2
Matt, Cobertura 2.0 works ok for me... My pom.xml has: build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin That sets the cobertura version to 2.0 as the latest did not seem to work... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin Regards, Iker -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 9:57 AM To: users@maven.apache.org Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html# a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: Code Coverage Plugins with Maven 2
the problem i have is:
i have a struts2 hibernate 3 and spring 2 env. setup with appfuse 2.0m5
when i run cobertura plugin 2.1 i get a coverage of 100%
when i run vobertura plugin 2.0 i get the following error:
[INFO] [hibernate3:hbm2ddl {execution: default}]
[INFO] Configuration XML file loaded:
/home/tibi/eclipseworkspace/incipio-match/src/main/resources/hibernate.cfg.xml
[INFO] Configuration XML file loaded:
/home/tibi/eclipseworkspace/incipio-match/src/main/resources/hibernate.cfg.xml
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unable to load class declared as mapping
class=nl.incipio.match.model.Candidate/ in the configuration:
[INFO]
[INFO] Trace
org.hibernate.MappingException: Unable to load class declared as mapping
class=nl.incipio.match.model.Candidate/ in the configuration:
at
org.hibernate.cfg.AnnotationConfiguration.parseMappingElement(AnnotationConfiguration.java:545)
at
org.hibernate.cfg.Configuration.parseSessionFactory(Configuration.java:1479)
when i remove the mappings from the hibernate files cobertura will run but
my test will not.
--
View this message in context:
http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12864156
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Coverage Plugins with Maven 2
This is what I'm using. However, it reports 0% coverage. Maybe this is caused by another plugin? Matt Iker Almandoz wrote: Matt, Cobertura 2.0 works ok for me... My pom.xml has: build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin That sets the cobertura version to 2.0 as the latest did not seem to work... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin Regards, Iker -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 9:57 AM To: users@maven.apache.org Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html# a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12864295 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Coverage Plugins with Maven 2
Hmmm, it looks like the aspectj-maven-plugin is causing the problem. If I remove the following from my pom.xml, everything works fine: plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.0-beta-2/version configuration source1.5/source verbosetrue/verbose complianceLevel1.5/complianceLevel showWeaveInfotrue/showWeaveInfo aspectLibraries aspectLibrary groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId /aspectLibrary /aspectLibraries /configuration executions execution goals goalcompile/goal /goals /execution /executions /plugin Any ideas how to make the two play nicely together? Matt mraible wrote: This is what I'm using. However, it reports 0% coverage. Maybe this is caused by another plugin? Matt Iker Almandoz wrote: Matt, Cobertura 2.0 works ok for me... My pom.xml has: build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin That sets the cobertura version to 2.0 as the latest did not seem to work... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin Regards, Iker -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 9:57 AM To: users@maven.apache.org Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html# a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12864355 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Coverage Plugins with Maven 2
It looks like this is a known issue in the aspectj-maven-plugin. http://jira.codehaus.org/browse/MOJO-456 Looks like we're using the latest version, so I guess I need to add a new execution with a configuration to do weaveMainSourceFolder=false. Matt mraible wrote: Hmmm, it looks like the aspectj-maven-plugin is causing the problem. If I remove the following from my pom.xml, everything works fine: plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.0-beta-2/version configuration source1.5/source verbosetrue/verbose complianceLevel1.5/complianceLevel showWeaveInfotrue/showWeaveInfo aspectLibraries aspectLibrary groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId /aspectLibrary /aspectLibraries /configuration executions execution goals goalcompile/goal /goals /execution /executions /plugin Any ideas how to make the two play nicely together? Matt mraible wrote: This is what I'm using. However, it reports 0% coverage. Maybe this is caused by another plugin? Matt Iker Almandoz wrote: Matt, Cobertura 2.0 works ok for me... My pom.xml has: build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin That sets the cobertura version to 2.0 as the latest did not seem to work... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin Regards, Iker -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 9:57 AM To: users@maven.apache.org Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html# a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12864482 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Coverage Plugins with Maven 2
This didn't work. AFAICT, the Cobertura and AspectJ plugin can't be activated at the same time if you want Cobertura reports to work. Matt mraible wrote: It looks like this is a known issue in the aspectj-maven-plugin. http://jira.codehaus.org/browse/MOJO-456 Looks like we're using the latest version, so I guess I need to add a new execution with a configuration to do weaveMainSourceFolder=false. Matt mraible wrote: Hmmm, it looks like the aspectj-maven-plugin is causing the problem. If I remove the following from my pom.xml, everything works fine: plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.0-beta-2/version configuration source1.5/source verbosetrue/verbose complianceLevel1.5/complianceLevel showWeaveInfotrue/showWeaveInfo aspectLibraries aspectLibrary groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId /aspectLibrary /aspectLibraries /configuration executions execution goals goalcompile/goal /goals /execution /executions /plugin Any ideas how to make the two play nicely together? Matt mraible wrote: This is what I'm using. However, it reports 0% coverage. Maybe this is caused by another plugin? Matt Iker Almandoz wrote: Matt, Cobertura 2.0 works ok for me... My pom.xml has: build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin That sets the cobertura version to 2.0 as the latest did not seem to work... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin Regards, Iker -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 9:57 AM To: users@maven.apache.org Subject: Code Coverage Plugins with Maven 2 AFAICT, the cobertura-maven-plugin (versions 2.0 and 2.1) doesn't work and neither does the emma-maven-plugin in Mojo's sandbox. Has anyone had any luck with either of these plugins? Is there an open source code-coverage plugin that works with Maven 2? I know about Clover, but that's not open source. Using Emma and Cobertura with Ant seem to work great. Thanks, Matt -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html# a12863761 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Code-Coverage-Plugins-with-Maven-2-tf4510331s177.html#a12864765 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Coverage Plugins with Maven 2
Hello Tibi Hmmm that sounds like a bug i saw some time ago, can you try this fix found here and let me know if it works? http://jira.codehaus.org/browse/MCOBERTURA-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101458 Regards Johann Reyes
selective modules build
Hi, I want to run a selective modules when I am building, my pom hierarchy is like * Super- parent * Parent1 * Ch1 * Ch2 * Parent 2 * Ch1 * Ch2 * Parent 3 * Ch1 * Ch2 * Ch3 I am running pom for super-parent as these are necessary tasks and want to custom run modules like parent 1 only, parent 1@ only, parent 3 only, in super-parent.pom I defined profiles as profile id1/id modules moduleparent1/module /profile profile id12/id modules moduleparent1/module moduleparent2/module /profile profile id3/id modules moduleparent3/module /profile profile idall/id modules moduleparent1/module moduleparent2/module moduleparent3/module /profile My intension is to control this selective module build from command line specifying which modules to build, is it possible? Regards, Nishant Sonar
