Re: Backwards incompatibility with 2.0.8?
Hi I'm in this situation as well, only with maven-2.0.7. Reading http://jira.codehaus.org/browse/SUREFIRE-61 I haven't understood if they are taking into account both ordering options (main vs test first)... cheers Francesco Ronn.Chinowutthichai wrote: I've worked out what happened. Surefire 2.3.1 is not in the central repository yet but apparantly it has been tagged (http://jira.codehaus.org/browse/MNG-3118). Last Friday, I've downloaded maven source and build it on my local machine (and added apache snapshot into Artifactory). As a result, surefire 2.3.1-SNAPSHOT got into our Artifactory. This is what I've found. Maven 2.0.6 + surefire 2.3 works. Maven 2.0.6 + surefire 2.3.1-SNAPSHOT doesn't work. Maven 2.0.8 + surefire 2.3 doesn't work Maven 2.0.8 + surefire 2.3.1-SNAPSHOT works. I'm not sure what differences there are in surefire 2.3.1-SNAPSHOT and 2.3.1. I can't find surefire 2.3.1 anywhere so I'll wait and see. Thanks for your help. Cheers, rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 11:24 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? Your act of upgrading certainly can't have broken his environment :) There are two possibilities: a) something changed in a surefire snapshot. This is possible as its under active development, though I'm not sure if new snapshots are being deployed regularly. b) a test was added to your environment that relied on the classpath ordering. b) still sounds like the most likely based on your original message - note that 2.0.6 always had main-first ordering, while 2.0.8 has test-first ordering. If you have a sample case where 2.0.6 + surefire 2.3 succeeds and 2.0.6 + 2.3.1 fails, please file it in the surefire JIRA. Otherwise, I would look at the test cases as above. Note you can also use the enforcer to force a Maven version to require people to upgrade to 2.0.8 - consistency is likely to give you less headaches, though I can understand that this is not something you would want to jump to quite so soon perhaps given it is a recent release. I'm still using 2.0.7 myself :) Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you
Re: Backwards incompatibility with 2.0.8?
its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backwards incompatibility with 2.0.8?
No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backwards incompatibility with 2.0.8?
Right, thanks for the explanation. Explicitly specifying the plugin version would help in this particular case but would we then need explictly declare every single plugin in the project to guard against future problem? i.e., clean, compiler, deployer, install, jar, war etc... would you then recommending this as the best practice? Surely this will lead to a very large pom.xml. I supposed, the release plugin can do this work, but does it currently do this ? rOnn c. Michael McCallum [EMAIL PROTECTED] 12/10/2007 10:41 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Backwards incompatibility with 2.0.8?
It is a best practice - in a shared parent POM so that you don't need to do it frequently. The release plugin doesn't do it, but the enforcer plugin can be used to ensure that you have. Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Right, thanks for the explanation. Explicitly specifying the plugin version would help in this particular case but would we then need explictly declare every single plugin in the project to guard against future problem? i.e., clean, compiler, deployer, install, jar, war etc... would you then recommending this as the best practice? Surely this will lead to a very large pom.xml. I supposed, the release plugin can do this work, but does it currently do this ? rOnn c. Michael McCallum [EMAIL PROTECTED] 12/10/2007 10:41 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backwards incompatibility with 2.0.8?
Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Backwards incompatibility with 2.0.8?
Your act of upgrading certainly can't have broken his environment :) There are two possibilities: a) something changed in a surefire snapshot. This is possible as its under active development, though I'm not sure if new snapshots are being deployed regularly. b) a test was added to your environment that relied on the classpath ordering. b) still sounds like the most likely based on your original message - note that 2.0.6 always had main-first ordering, while 2.0.8 has test-first ordering. If you have a sample case where 2.0.6 + surefire 2.3 succeeds and 2.0.6 + 2.3.1 fails, please file it in the surefire JIRA. Otherwise, I would look at the test cases as above. Note you can also use the enforcer to force a Maven version to require people to upgrade to 2.0.8 - consistency is likely to give you less headaches, though I can understand that this is not something you would want to jump to quite so soon perhaps given it is a recent release. I'm still using 2.0.7 myself :) Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed
Re: Backwards incompatibility with 2.0.8?
I've worked out what happened. Surefire 2.3.1 is not in the central repository yet but apparantly it has been tagged (http://jira.codehaus.org/browse/MNG-3118). Last Friday, I've downloaded maven source and build it on my local machine (and added apache snapshot into Artifactory). As a result, surefire 2.3.1-SNAPSHOT got into our Artifactory. This is what I've found. Maven 2.0.6 + surefire 2.3 works. Maven 2.0.6 + surefire 2.3.1-SNAPSHOT doesn't work. Maven 2.0.8 + surefire 2.3 doesn't work Maven 2.0.8 + surefire 2.3.1-SNAPSHOT works. I'm not sure what differences there are in surefire 2.3.1-SNAPSHOT and 2.3.1. I can't find surefire 2.3.1 anywhere so I'll wait and see. Thanks for your help. Cheers, rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 11:24 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? Your act of upgrading certainly can't have broken his environment :) There are two possibilities: a) something changed in a surefire snapshot. This is possible as its under active development, though I'm not sure if new snapshots are being deployed regularly. b) a test was added to your environment that relied on the classpath ordering. b) still sounds like the most likely based on your original message - note that 2.0.6 always had main-first ordering, while 2.0.8 has test-first ordering. If you have a sample case where 2.0.6 + surefire 2.3 succeeds and 2.0.6 + 2.3.1 fails, please file it in the surefire JIRA. Otherwise, I would look at the test cases as above. Note you can also use the enforcer to force a Maven version to require people to upgrade to 2.0.8 - consistency is likely to give you less headaches, though I can understand that this is not something you would want to jump to quite so soon perhaps given it is a recent release. I'm still using 2.0.7 myself :) Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility
Re: Backwards incompatibility with 2.0.8?
Is there a philosophical reason why release plugin shouldn't do that on behalf of the users? Maven makes alot of things simpler and pleasant for you (i.e., transitive dependencies, lifecycles management etc..) and then there are occasional things like this that makes you wonder why would I have to care? Most of the time users don't really care if he/she run sure fire 2.3, complier plugin 2.0.2, jar plugin 2.1 and countless other plugins that are magically invoked to make the build works. Explicitly specifying all the plugins (let alone its version) is definitely not a fun thing to do. The trouble with shared parent pom is that, there will be one per logical set of deliverable projects. So in our environment, there is one poping up all the time. Even if we can create our own super pom and store it some where in SVN, maven won't know how to tag the custom super pom that is outside it's project. Personally, I think release plugin should have some of the enforcer features built in. If enforcer is the way to go, then I think there needs to be a big disclaimer in the release plugin or Maven FAQ saying that you must use enforcer to ensure repeatable build across releases. Cheers, rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 11:13 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? It is a best practice - in a shared parent POM so that you don't need to do it frequently. The release plugin doesn't do it, but the enforcer plugin can be used to ensure that you have. Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Right, thanks for the explanation. Explicitly specifying the plugin version would help in this particular case but would we then need explictly declare every single plugin in the project to guard against future problem? i.e., clean, compiler, deployer, install, jar, war etc... would you then recommending this as the best practice? Surely this will lead to a very large pom.xml. I supposed, the release plugin can do this work, but does it currently do this ? rOnn c. Michael McCallum [EMAIL PROTECTED] 12/10/2007 10:41 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain
