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
