Re: Maven process stuck on MacOS with Java8
On Thu, Jan 30, 2014 at 12:20 PM, Mark Derricutt m...@talios.com wrote: Can't say I've seen that with any of the 1.8 builds I've been trailing, either the official dev builds or the ones I'm compiling up myself... Have you tried looking at a thread dump and seeing where in Maven it's hanging? I am definitely impatient because looking at that closer, the shell is not stuck but it takes several seconds to give back hand. Sometimes it's ok, sometimes is 5 sec or so. S. Mark On 31 Jan 2014, at 0:13, Stephane Nicoll wrote: Hi, Has anybody else noticed an issue with Java8 running Maven? I am using 1.8.0-ea-b124 and a maven command does not complete properly. It does not matter which plugin or phase is invoked, the process is stuck at the end and I have to ctrl-Z to go back to the shell. Switching back to Java 1.7 fixes the problem for me. Any idea? Thanks, S. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency management across projects
Hi, I was wondering if anyone knows or has experience with a system that would track and consolidate dependencies on a project composed of several sub-projects. Assume a project P with 10 sub-projects (SP1...SP10). Each of those sub-projects are located in its own space and have its own lifecycle (release versioning, etc). But ultimately, the project P needs to be released as a set of coherent *tested* dependencies. For various reasons, some sub-projects have to keep different dependencies of the target for backward compatibility reason. There are two deliverables to this: 1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
local artifact use error
Hi, I use the following command to install a JAR in local repository: mvn install:install-file -Dfile=c:\{module}-{version}.jar -DgroupId=com.sourceforge.code -DartifactId={module} -Dversion={version} -Dpackaging=jar -DgeneratePom=true and its seems to work fine: $ mvn install:install-file -Dfile=C:\\Eclipse\\K2\\W\\covana_old\\lib\\recoder_0.97.jar -DgroupId=com.sourceforge.code -DartifactId=recoder -Dversion=0.97 -Dpackaging=jar -DgeneratePom=true [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building covana 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-install-plugin:2.4:install-file (default-cli) @ covana --- [INFO] Installing C:\Eclipse\K2\W\covana_old\lib\recoder_0.97.jar to d:\Profiles\\.m2\repository\com\sourceforge\code\recoder\0.97\recoder-0.97.jar [INFO] Installing C:\cygwin\tmp\mvninstall4213701695268682729.pom to d:\Profiles\\.m2\repository\com\sourceforge\code\recoder\0.97\recoder-0.97.pom [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.610s [INFO] Finished at: Fri Jan 31 11:45:55 CET 2014 [INFO] Final Memory: 6M/121M [INFO] I add the dependency in my project POM file: dependency groupIdorg.sourceforge.code/groupId artifactIdrecoder/artifactId version0.97/version /dependency But when I launch mvn clean package command it's KO searching central update of my local module... The -offline or -U options doesn't change anything $ mvn clean package [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building covana 1.0-SNAPSHOT [INFO] [WARNING] The POM for org.sourceforge.code:recoder:jar:0.97 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.008s [INFO] Finished at: Fri Jan 31 11:48:50 CET 2014 [INFO] Final Memory: 7M/153M [INFO] [ERROR] Failed to execute goal on project covana: Could not resolve dependencies for project core:covana:jar:1.0-SNAPSHOT: Failure to find org.sourceforge.code:recoder:jar:0.97 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException Can you help me to use local repository and configure it? Regards -- View this message in context: http://maven.40175.n5.nabble.com/local-artifact-use-error-tp5782890.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven process stuck on MacOS with Java8
You're not by any chance using fish as your shell are you? For awhile some strange bug in fish ( at least on my old machine, along with a combination of prompt settings ) would hang on the termination of processes, more often than not maven but also others. Something about it being stuck reading a char from stdin or something - only it wasn't time related, sometimes resizes/splitting the terminal would kick it back into gear. On 31 Jan 2014, at 23:12, Stephane Nicoll wrote: I am definitely impatient because looking at that closer, the shell is not stuck but it takes several seconds to give back hand. Sometimes it's ok, sometimes is 5 sec or so. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: local artifact use error
You've specified the groupId as com.sourceforge.code, not org.sourceforge.code. Change in your pom and it should work. /Anders On Fri, Jan 31, 2014 at 11:54 AM, cyrduf cyr...@free.fr wrote: Hi, I use the following command to install a JAR in local repository: mvn install:install-file -Dfile=c:\{module}-{version}.jar -DgroupId=com.sourceforge.code -DartifactId={module} -Dversion={version} -Dpackaging=jar -DgeneratePom=true and its seems to work fine: $ mvn install:install-file -Dfile=C:\\Eclipse\\K2\\W\\covana_old\\lib\\recoder_0.97.jar -DgroupId=com.sourceforge.code -DartifactId=recoder -Dversion=0.97 -Dpackaging=jar -DgeneratePom=true [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building covana 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-install-plugin:2.4:install-file (default-cli) @ covana --- [INFO] Installing C:\Eclipse\K2\W\covana_old\lib\recoder_0.97.jar to d:\Profiles\\.m2\repository\com\sourceforge\code\recoder\0.97\recoder-0.97.jar [INFO] Installing C:\cygwin\tmp\mvninstall4213701695268682729.pom to d:\Profiles\\.m2\repository\com\sourceforge\code\recoder\0.97\recoder-0.97.pom [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.610s [INFO] Finished at: Fri Jan 31 11:45:55 CET 2014 [INFO] Final Memory: 6M/121M [INFO] I add the dependency in my project POM file: dependency groupIdorg.sourceforge.code/groupId artifactIdrecoder/artifactId version0.97/version /dependency But when I launch mvn clean package command it's KO searching central update of my local module... The -offline or -U options doesn't change anything $ mvn clean package [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building covana 1.0-SNAPSHOT [INFO] [WARNING] The POM for org.sourceforge.code:recoder:jar:0.97 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.008s [INFO] Finished at: Fri Jan 31 11:48:50 CET 2014 [INFO] Final Memory: 7M/153M [INFO] [ERROR] Failed to execute goal on project covana: Could not resolve dependencies for project core:covana:jar:1.0-SNAPSHOT: Failure to find org.sourceforge.code:recoder:jar:0.97 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException Can you help me to use local repository and configure it? Regards -- View this message in context: http://maven.40175.n5.nabble.com/local-artifact-use-error-tp5782890.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven process stuck on MacOS with Java8
Mark, I am using iTerm2 (1.0.0.20130622) S. On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt m...@talios.com wrote: You're not by any chance using fish as your shell are you? For awhile some strange bug in fish ( at least on my old machine, along with a combination of prompt settings ) would hang on the termination of processes, more often than not maven but also others. Something about it being stuck reading a char from stdin or something - only it wasn't time related, sometimes resizes/splitting the terminal would kick it back into gear. On 31 Jan 2014, at 23:12, Stephane Nicoll wrote: I am definitely impatient because looking at that closer, the shell is not stuck but it takes several seconds to give back hand. Sometimes it's ok, sometimes is 5 sec or so. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management across projects
Thanks for the response. On Fri, Jan 31, 2014 at 11:33 AM, Anders Hammar and...@hammar.net wrote: 1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. Yes, but not the versions. The users will have to add the dependency they want to use, yes. The point here is that they don't have to care about the versions (but I do, which is why I need some tooling) In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms BOM is exactly what I want to do, yes. What may not be clear in my original post is that I am looking at this problem as the release manager of P who wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want to have an overview of where the different sub-projects stands with regards to the target for P. Assume that each sub-project has its own release cycle (and is released as a project on its own actually) and at some point those different projects have to be released as a single coherent unit. There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: local artifact use error
Thanks for your help So simple mistake Cyril -- View this message in context: http://maven.40175.n5.nabble.com/local-artifact-use-error-tp5782890p5782896.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: dependency management across projects
Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. Yes, but not the versions. The users will have to add the dependency they want to use, yes. The point here is that they don't have to care about the versions (but I do, which is why I need some tooling) In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms BOM is exactly what I want to do, yes. What may not be clear in my original post is that I am looking at this problem as the release manager of P who wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want to have an overview of where the different sub-projects stands with regards to the target for P. Assume that each sub-project has its own release cycle (and is released as a project on its own actually) and at some point those different projects have to be released as a single coherent unit. The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Creating the BOM would be a manual work I think, as you want to make sure that exactly the correct versions are included (might not be the latest releases). /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
As one of the fans of a non-Maven way to deal with this, I will point you to some documentation on the approach. http://blog.artifact-software.com/tech/?tag=maven This should get you 4 articles that discuss our approach to Maven. http://blog.artifact-software.com/tech/?p=121 Specifically addresses the problem that you are working through. It works well for us. Our big project had over 30 independent modules that depended on more than 70 third party modules - Tomcat, Jetspeed, Apache Commons, Spring, Hibernate, Mysql JSF, CXF, Jasper Reports, etc. We are currently actively developing 2 projects each with about 10 modules (Maven Projects) with the same technology stack (Jackrabbit replacing MySQL and adding Spring-Data) and have continued the same approach. It works well and makes the war files very small and cuts the build time dramatically. It relieves the developer from dealing with versions and dependency configurations. The individual shared libraries have the right versions with the required exclusions already fixed up so inter-library conflicts are resolved. The developer just have to make sure that their code works. If they want to add a third party library that is not included in the corporate utility libraries, this is supposed to be discussed at the project level to see if it should be shared or not. We don't make a big deal about this now that we have a really good core stack settled. At the beginning of each release cycle we review the approved versions and upgrade as appropriate. This lets us review and test dependency changes as a team. We use the STS version of Eclipse so we have full support for Maven and can easily see where dependencies are coming from and where potential dependency conflicts occur between third party software so exclusions can be adjusted. Ron On 31/01/2014 5:33 AM, Anders Hammar wrote: 1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Aw: Re: maven-enforcer-plugin problems with test dependency in multi module project
Without the maven enforce rule “requireReleaseDeps” and without the typetest-jar/type in the pom.xml of the test-child “mvn clean package” failed as predicted. Without the maven enforce rule “requireReleaseDeps” and with the typetest-jar/type “mvn clean package” and “mvn clean compile” succeeded. With the maven enforce rule “requireReleaseDeps” and with the typetest-jar/type in the pom.xml of the test-child “mvn clean package” succeeded but “mvn clean compile” failed because of the missing test:test-parent:jar:tests. But since the scope is set scopetest/scope this shouldn't matter, should it? Best regards Matthias Gesendet: Donnerstag, 30. Januar 2014 um 17:13 Uhr Von: Karl Heinz Marbaise khmarba...@gmx.de An: users@maven.apache.org Betreff: Re: maven-enforcer-plugin problems with test dependency in multi module project Hi, based on the error message you have a dependency on your test-jar project but you defined the dependency a little bit wrong: test:test-child:jar:1.0.0: Failure to find test:test-parent:jar:tests:1.0.0 This shows that you have defined a dependency in the test-parent but like this: dependencies dependency groupIdtest/groupId artifactIdtest-parent/artifactId version1.0-SNAPSHOT/version scopetest/scope /dependency /dependencies BUT you have to give the type in this case like this: dependencies dependency groupIdtest/groupId artifactIdtest-parent/artifactId version1.0-SNAPSHOT/version typetest-jar/type scopetest/scope /dependency /dependencies Best test is to comment out the maven-enforcer-rule and try to build your project just from the parent via mvn clean package I assume in your case without the above fix your project will not build. If it will you need to clean out your local repository first and retry it... Kind regards Karl Heinz Marbaise Hi, I have a multi-module-project with one module that implements classes for testing (test-parent) and another module (test-child) that uses theses classes. There is a dependency in test scope from the test-child to the test-parent. (See article http://stackoverflow.com/questions/1725476/maven-test-dependency-in-multi-module-project and http://maven.apache.org/guides/mini/guide-attached-tests.html[http://maven.apache.org/guides/mini/guide-attached-tests.html]) The pom of the depending test-child contains the following code: dependencies dependency groupIdtest/groupId artifactIdtest-parent/artifactId version1.0-SNAPSHOT/version typetest-jar/type scopetest/scope /dependency /dependencies The test-parent module that contains the derived classes contains the following code: plugins plugin artifactIdmaven-jar-plugin/artifactId version2.2/version executions execution goals goaltest-jar/goal /goals phasetest-compile/phase /execution /executions /plugin /plugins In a parent pom the maven-enforcer-plugin is included and the RequireReleaseDeps rule is added to the list of rules. While running the Maven goal “compile” the project compilation of the test-child fails with the following message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (default) on project test-child: Execution default of goal org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce failed: org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could not resolve dependencies for project test:test-child:jar:1.0.0: Failure to find test:test-parent:jar:tests:1.0.0 It seems that Maven checks the dependencies of type and scope “test” in the compile phase. In the case the test-jar is build in the test-compile and is not present yet. This leads to the error. If I remove the RequireReleaseDeps from the rules it works fine. Here is the simplified config of the maven-enforcer-plugin: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version${maven-enforcer-plugin.version}/version inheritedtrue/inherited executions execution goalsgoalenforce/goal/goals /execution /executions configuration !-- skip/ -- rules requireReleaseDeps onlyWhenReleasefalse/onlyWhenRelease /requireReleaseDeps requireMavenVersion version[3.0.4,]/version /requireMavenVersion /rules fail${maven-enforcer-plugin.fail}/fail /configuration /plugin /plugins /pluginManagement plugins plugin
Re: Maven process stuck on MacOS with Java8
That's the terminal, not the shell ( bash, zsh, fish, csh etc. ). I was also using iTerm when I had my issue, and now I think about it - since the last beta update/release I've not seen the issue again, but I also changed laptops so can't recall if its only on the new install I've not had the issue. I suspect they're not the same issue tho... maybe. On 1 Feb 2014, at 0:05, Stephane Nicoll wrote: Mark, I am using iTerm2 (1.0.0.20130622) S. On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt m...@talios.com wrote: You're not by any chance using fish as your shell are you? For awhile some strange bug in fish ( at least on my old machine, along with a combination of prompt settings ) would hang on the termination of processes, more often than not maven but also others. Something about it being stuck reading a char from stdin or something - only it wasn't time related, sometimes resizes/splitting the terminal would kick it back into gear. On 31 Jan 2014, at 23:12, Stephane Nicoll wrote: I am definitely impatient because looking at that closer, the shell is not stuck but it takes several seconds to give back hand. Sometimes it's ok, sometimes is 5 sec or so. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Work-around to the Maven restriction on AND condition profile activation?
Hi, I’m using Maven 3.1.1 and Java 1.6. From reading over posts online, it seems a profile cannot be activated based on two conditions (i.e. there is no such thing as logical AND in Maven profile activation). So I was wondering if someone knows of a work-around for what I want to do. I want to run a plugin if a flag is given on the command line (“-DdeployWars”) and a file is present in my module, e.g. activation file exists${basedir}/src/main/webapp/WEB-INF/web.xml/exists /file /activation Unfortunately, its not an option to include the AND profile activation extension (https://github.com/johnjcool/and-activation-profile-selector) in our Maven installation, unless there is some way to reference that extension from the Maven project itself. Thanks for your thoughts, - Dave -- View this message in context: http://maven.40175.n5.nabble.com/Work-around-to-the-Maven-restriction-on-AND-condition-profile-activation-tp5782919.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