Re: Why does Maven fail to compile my project occasionally?
My code is correct because I could successfully build the whole project in Eclipse again and again. This is 100% true. Within Eclipse you can manually add libraries. Actually, if you create your first JUnit test, Eclipse will ask if the JUnit4 library should be added. If you do so, it's added as an Eclipse library, but your Maven build won't have junit as a dependency, resulting in uncompilable tests. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\src\main\java\com\centerm\system\devicecenter\network\AgentIdResourceMapIpHandle.java:[36,24] Can't find the symbol Symbol: Variable TYPE_AGENT_ID Location: Class com.xxx.system.common.ResourceTypeDef [ERROR] \Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\src\main\java\com\centerm\system\devicecenter\network\AgentUuidResourceMapIpHandle.java:[38,24] Can't find the symbol Symbol: Variable TYPE_AGENT_UUID Location: Class com.xxx.system.common.ResourceTypeDef [ERROR] \Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\src\main\java\com\centerm\system\devicecenter\network\AgentIdAgentUpdateMapIpHandle.java:[32,24] Can't find the symbol Symbol: Variable TYPE_COMPUTER_ID_FOR_UPDATE Location: Class com.xxx.system.common.ResourceTypeDef [INFO] 3 errors [INFO] - Did you open this file? AgentIdResourceMapIpHandle.java:[36,24] refers to line 36, column 24. Just open that file with notepad (copy/paste the fully qualified path to ensure you're picking up the correct file, not some copy) Where is that symbol/Class coming from? It seems to be on the classpath of your Eclipse, but it is not a dependency for Maven. Robert Op Fri, 14 Feb 2014 16:36:32 +0100 schreef LevskiWeng levskiw...@gmail.com: After changing the compiler to javac, and add verbose parameters as the following: the problem remains the same, but the console output reveals the compile procedure in details, could you help me to find what is missing? Thanks. BEGIN ... [DEBUG] Command line options: [DEBUG] -d C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\target\classes -classpath C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\target\classes;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\com\centerm\system\network\1.1.0\network-1.1.0.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\apache\ws\commons\schema\XmlSchema\1.4.5\XmlSchema-1.4.5.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-all\1.2.6\xfire-all-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-aegis\1.2.6\xfire-aegis-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\net\java\dev\stax-utils\stax-utils\20040917\stax-utils-20040917.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-ws-security\1.2.6\xfire-ws-security-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\jmock\jmock\1.0.1\jmock-1.0.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xfire\opensaml\1.0.1\opensaml-1.0.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\bouncycastle\bcprov-jdk15\133\bcprov-jdk15-133.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xml-security\xmlsec\1.3.0\xmlsec-1.3.0.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\wss4j\wss4j\1.5.1\wss4j-1.5.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\commons-discovery\commons-discovery\0.2\commons-discovery-0.2.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-core\1.2.6\xfire-core-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\javax\activation\activation\1.1\activation-1.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\javax\mail\mail\1.4\mail-1.4.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\wsdl4j\wsdl4j\1.6.1\wsdl4j-1.6.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\woodstox\wstx-asl\3.2.0\wstx-asl-3.2.0.jar;C:\Program Files
Re: Possible build collision between CI snapshot build and Release build
Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan
Re: Possible build collision between CI snapshot build and Release build
On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/
Re: Possible build collision between CI snapshot build and Release build
On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.com wrote: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Perhaps write a custom enforcer rule (enabled by a profile on CI) that fails the build when the project artifact version is not a snapshot? http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Cheers, Stuart
Re: Possible build collision between CI snapshot build and Release build
Or filter commits where the log message starts with m-r-p's prefix On Saturday, 15 February 2014, Stuart McCulloch mccu...@gmail.com wrote: On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.comjavascript:; wrote: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.netjavascript:; wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Perhaps write a custom enforcer rule (enabled by a profile on CI) that fails the build when the project artifact version is not a snapshot? http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com javascript:; a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Cheers, Stuart -- Sent from my phone
Re: Possible build collision between CI snapshot build and Release build
Hi, Isn't it the other way around? There's only a critical situation: when the maven-release-plugin has committed the non-SNAPSHOT poms or when it is busy tagging. In such cases the CI can be triggered by SCM changes, but it shouldn't continue since there's a final version. I think most CI's have a solution for that. If you want to do it with an enforcer rule, it's not there yet. This requiresSnapshot rule should be active by default, while the m-release-p should disable this rule. Robert Op Sat, 15 Feb 2014 17:52:14 +0100 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Or filter commits where the log message starts with m-r-p's prefix On Saturday, 15 February 2014, Stuart McCulloch mccu...@gmail.com wrote: On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.comjavascript:; wrote: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.netjavascript:; wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Perhaps write a custom enforcer rule (enabled by a profile on CI) that fails the build when the project artifact version is not a snapshot? http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com javascript:; a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible build collision between CI snapshot build and Release build
Thank you all, enforcer rule is the way to go. I will put it at my company top level pom and disable this rule at release time. -Dan On Sat, Feb 15, 2014 at 8:52 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Or filter commits where the log message starts with m-r-p's prefix On Saturday, 15 February 2014, Stuart McCulloch mccu...@gmail.com wrote: On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.com javascript:; wrote: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net javascript:; wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Perhaps write a custom enforcer rule (enabled by a profile on CI) that fails the build when the project artifact version is not a snapshot? http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.comjavascript:; a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Cheers, Stuart -- Sent from my phone
Re: Why does Maven fail to compile my project occasionally?
On Saturday, 15 February 2014, LevskiWeng levskiw...@gmail.com wrote: Parsing POMs Downloaded artifact http://192.168.4.172:8081/nexus/content/groups/public/com/xxx/system/systempom/1.0.0-SNAPSHOT/maven-metadata.xml Downloaded artifact http://192.168.4.172:8081/nexus/content/groups/public/com/xxx/pom/1.0.0-SNAPSHOT/maven-metadata.xml Modules changed, recalculating dependency graph [managerpom] $ C:\Program Files\Java\jdk1.6.0_35/bin/java -Xms256m -Xmx1024m -cp C:\Program Files (x86)\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven31-agent-1.4.jar;C:\Program Files\apache-maven-3.1.1\boot\plexus-classworlds-2.5.1.jar;C:\Program Files\apache-maven-3.1.1/conf/logging jenkins.maven3.agent.Maven31Main C:\Program Files\apache-maven-3.1.1 C:\Windows\Temp\jetty-0.0.0.0-80-jenkins.war--any-\webapp\WEB-INF\lib\remoting-2.33.jar C:\Program Files (x86)\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven31-interceptor-1.4.jar C:\Program Files (x86)\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven3-interceptor-commons-1.4.jar 52434 ===[JENKINS REMOTING CAPACITY]===channel started http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html Using the evil one makes Maven behave in ways that it doesn't intend to... Please try with a FreeStyle job using a Maven Build step to see if it is the evil job type causing issues for you log4j:WARN No appenders could be found for logger (org.apache.commons.beanutils.converters.BooleanConverter). log4j:WARN Please initialize the log4j system properly. Executing Maven: -B -f C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\common\managerpom\pom.xml -Dmaven.repo.local=C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository clean install -Dmaven.test.skip=true --update-snapshots --batch-mode --fail-fast --debug -Dmaven.compiler.forceJavacCompilerUse=true -Dmaven.compiler.verbose=true Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 23:22:22+0800) Maven home: C:\Program Files\apache-maven-3.1.1 Java version: 1.6.0_35, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_35\jre Default locale: zh_CN, platform encoding: GBK OS name: windows 7, version: 6.1, arch: amd64, family: windows [INFO] Error stacktraces are turned on. [DEBUG] Reading global settings from C:\Program Files\apache-maven-3.1.1\conf\settings.xml [DEBUG] Reading user settings from C:\.m2\settings.xml Ron Wheeler wrote Where is the compiler version and options line? Ron -- View this message in context: http://maven.40175.n5.nabble.com/Why-does-Maven-fail-to-compile-my-project-occasionally-tp5784849p5784947.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone
Re: Possible build collision between CI snapshot build and Release build
hmm, time for me to upgrade my hudson/jenkins :-) -D On Sat, Feb 15, 2014 at 10:46 AM, Robert Scholte rfscho...@apache.orgwrote: Hi, Isn't it the other way around? There's only a critical situation: when the maven-release-plugin has committed the non-SNAPSHOT poms or when it is busy tagging. In such cases the CI can be triggered by SCM changes, but it shouldn't continue since there's a final version. I think most CI's have a solution for that. If you want to do it with an enforcer rule, it's not there yet. This requiresSnapshot rule should be active by default, while the m-release-p should disable this rule. Robert Op Sat, 15 Feb 2014 17:52:14 +0100 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Or filter commits where the log message starts with m-r-p's prefix On Saturday, 15 February 2014, Stuart McCulloch mccu...@gmail.com wrote: On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.com javascript:; wrote: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net javascript:; wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Perhaps write a custom enforcer rule (enabled by a profile on CI) that fails the build when the project artifact version is not a snapshot? http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.comjavascript:; a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible build collision between CI snapshot build and Release build
OK, so this has to be CVCS (svn and so on) specific? I didn't check if the release-plugin commits + push each time. If this is so, it should be fixed so that this cannot happen. I would say that though this is a valid technical concern, it's very unlikely to happen in real life. Let's take an example with a well known CI server, and specifically with svn: * You start a release. At the end of the release:prepare, the release-plugin commits the poms just before copying the path to the tags directory, then reverting the poms to the next snapshot development version. * Unfortunately, the CI kicks in just there, just after that commit, and before the trunk comes back to snapshot. * In Jenkins (and Hudson), there's a default delay of some seconds, historically to support VCS like CVS that wouldn't commit files in an atomic manner * So, Jenkins is gonna wait those seconds before actually starting the build. Then it asks the VCS once more if a new change occurred. So, the probability to encounter this issue is even lower... So, all in all, if that's the issue you're talking about. Not sure it's worth to worry a lot :-). Btw, if you use a repo manager with a staging area, then at worse you're gonna create a staging repo from the CI build in addition to your release build. So, in the end you won't be able to push many releases under the same names and your release should still be able to proceed. HTH 2014-02-15 16:51 GMT+01:00 Thomas Broyer t.bro...@gmail.com: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
RE: Reload MavenProject MavenSession and BuildPluginManager
I tried the following but the project version didn't work
Artifact artifact = project.getArtifact();
try {
artifactResolver.resolve(artifact,
remoteArtifactRepositories, localRepository);
System.out.println(project = + project.getVersion());
System.out.println(artifact = + artifact.getVersion());
} catch (ArtifactResolutionException ex) {
getLog().error(null, ex);
} catch (ArtifactNotFoundException ex) {
getLog().error(null, ex);
}
--
View this message in context:
http://maven.40175.n5.nabble.com/Reload-MavenProject-MavenSession-and-BuildPluginManager-tp5783698p5785012.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Why does Maven fail to compile my project occasionally?
To: users@maven.apache.org Subject: Re: Why does Maven fail to compile my project occasionally? Date: Sat, 15 Feb 2014 11:45:57 +0100 From: rfscho...@apache.org My code is correct because I could successfully build the whole project in Eclipse again and again. This is 100% true. Within Eclipse you can manually add libraries. Actually, if you create your first JUnit test, Eclipse will ask if the JUnit4 library should be added. If you do so, it's added as an Eclipse library, but your Maven build won't have junit as a dependency, resulting in uncompilable tests. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\src\main\java\com\centerm\system\devicecenter\network\AgentIdResourceMapIpHandle.java:[36,24] Can't find the symbol Symbol: Variable TYPE_AGENT_ID Location: Class com.xxx.system.common.ResourceTypeDef [ERROR] \Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\src\main\java\com\centerm\system\devicecenter\network\AgentUuidResourceMapIpHandle.java:[38,24] Can't find the symbol Symbol: Variable TYPE_AGENT_UUID Location: Class com.xxx.system.common.ResourceTypeDef MGLevski MGwhere is the source for this web-server? MGMartin- Did you open this file? AgentIdResourceMapIpHandle.java:[36,24] refers to line 36, column 24. Just open that file with notepad (copy/paste the fully qualified path to ensure you're picking up the correct file, not some copy) Where is that symbol/Class coming from? It seems to be on the classpath of your Eclipse, but it is not a dependency for Maven. Robert Op Fri, 14 Feb 2014 16:36:32 +0100 schreef LevskiWeng levskiw...@gmail.com: After changing the compiler to javac, and add verbose parameters as the following: the problem remains the same, but the console output reveals the compile procedure in details, could you help me to find what is missing? Thanks. BEGIN ... [DEBUG] Command line options: [DEBUG] -d C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\target\classes -classpath C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\src\com.xxx.system\com.xxx.system.devicecenter\target\classes;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\com\centerm\system\network\1.1.0\network-1.1.0.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\apache\ws\commons\schema\XmlSchema\1.4.5\XmlSchema-1.4.5.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-all\1.2.6\xfire-all-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-aegis\1.2.6\xfire-aegis-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\net\java\dev\stax-utils\stax-utils\20040917\stax-utils-20040917.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-ws-security\1.2.6\xfire-ws-security-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\jmock\jmock\1.0.1\jmock-1.0.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xfire\opensaml\1.0.1\opensaml-1.0.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\bouncycastle\bcprov-jdk15\133\bcprov-jdk15-133.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\xml-security\xmlsec\1.3.0\xmlsec-1.3.0.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\wss4j\wss4j\1.5.1\wss4j-1.5.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\commons-discovery\commons-discovery\0.2\commons-discovery-0.2.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\xfire\xfire-core\1.2.6\xfire-core-1.2.6.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\javax\activation\activation\1.1\activation-1.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\javax\mail\mail\1.4\mail-1.4.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\wsdl4j\wsdl4j\1.6.1\wsdl4j-1.6.1.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\org\codehaus\woodstox\wstx-asl\3.2.0\wstx-asl-3.2.0.jar;C:\Program Files (x86)\Jenkins\jobs\CDMS-web-server\workspace\.repository\commons-httpclient\commons-httpclient\3.0\commons-httpclient-3.0.jar;C:\Program Files
Re: Possible build collision between CI snapshot build and Release build
Baptiste, you are totally correct. For my case, I use one staging repo per project ( long story), so there is a very small window of collision. Thank you for this very good advice. -Dan On Sat, Feb 15, 2014 at 1:07 PM, Baptiste Mathus bmat...@batmat.net wrote: OK, so this has to be CVCS (svn and so on) specific? I didn't check if the release-plugin commits + push each time. If this is so, it should be fixed so that this cannot happen. I would say that though this is a valid technical concern, it's very unlikely to happen in real life. Let's take an example with a well known CI server, and specifically with svn: * You start a release. At the end of the release:prepare, the release-plugin commits the poms just before copying the path to the tags directory, then reverting the poms to the next snapshot development version. * Unfortunately, the CI kicks in just there, just after that commit, and before the trunk comes back to snapshot. * In Jenkins (and Hudson), there's a default delay of some seconds, historically to support VCS like CVS that wouldn't commit files in an atomic manner * So, Jenkins is gonna wait those seconds before actually starting the build. Then it asks the VCS once more if a new change occurred. So, the probability to encounter this issue is even lower... So, all in all, if that's the issue you're talking about. Not sure it's worth to worry a lot :-). Btw, if you use a repo manager with a staging area, then at worse you're gonna create a staging repo from the CI build in addition to your release build. So, in the end you won't be able to push many releases under the same names and your release should still be able to proceed. HTH 2014-02-15 16:51 GMT+01:00 Thomas Broyer t.bro...@gmail.com: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? I currently have to keep remind my self to turn off CI snapshot build while release is in progress, and too many to remember. Advice is greatly appreciated -Dan -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Thanks for the advice on how to restructure.
Could you have a look at the deploy-plugin project and the file
org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in
version 2.8.1 ? I would really like to understand the following:
1) What controls which artifacts are attached the model for the given
project?
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
3) Is it really the intended behaviour of the deploy:file goal to also
deploy the attached artifacts? To me that is a very non-intuitive
behaviour.
I Basically have a working setup which deploys the zip file I generate to
repo with the name I have specified. But the only thing that bothers me is
that for some unclear reason the same zip is deployed again with the name
of the project in the same deploy:file goal. To me - that is a bug.
Should I open an issue instead somewhere and provide the patch which fixes
this??
I already mailed the email listed in the top of the java file in question
but he does not reply.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote:
You should really restart with the module 2 pom.
Your multi-module structure is good. You have a separate projekt/module
which creates your distro. What you should do is to create the distro
(zip or whatever) to be created as part of the normal build and then
deployed as the project's artifact it is.
This is done in many projects and you could for example have a look at the
Maven core project where we create a zip and a tar file.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;hb=HEAD
So in the end, you will not use deploy:deploy-file. Also, your pom will be
very small with pretty much only the m-assembly-p being bound to the build
lifecycle.
/Anders
On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi Anders
I have a multi-module project with this structure:
A (root and parent pom project)
- module 1 - builds a jar as artifact
- module 2 - uses module 1 jar artifact in assembly tries to deploy the
assembled zip file to artifactory.
This is the module 2 pom file with inserted to replace project
specific names.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupId/groupId
artifactId/artifactId
version1.1-SNAPSHOT/version
/parent
artifactIdscripts/artifactId
packagingpom/packaging
namescripts/name
description/description
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
main.basedir${project.parent.basedir}/main.basedir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.5.1/version
configuration
skiptrue/skip
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.4/version
configuration
skiptrue/skip
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.8.1/version
configuration
skiptrue/skip
/configuration
/plugin
/plugins
/build
profiles
profile
iddeployprofile/id
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
version1.2.1/version
executions
execution
idCopy into target folder and copy service jar into files/default
/id
phasepackage/phase
goals
goalexec/goal
/goals
configuration
executable${project.basedir}/build_cookbook.sh/executable
arguments
argument${project.parent.artifactId}/argument
argument${project.parent.version}/argument
/arguments
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.4/version
executions
execution
iddeployprofile/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
finalName${project.parent.artifactId}-${project.parent.version}
/finalName
outputDirectory${project.build.directory}//outputDirectory
filteringtrue/filtering
descriptors
descriptorassembly/dist.xml/descriptor
/descriptors
/configuration
