Re: Code coverage with debug logs: 100% branch coverage not possible?...
My first feeling is that not much time should be spent on that issue,
logging isn't going to take a lot of points of percentage down, having ~95%
would already be great (but maybe you already have).
Anyway, on the other hand, if what you want is to get code coverage, why
not just enable the ALL logging level when recording code coverage and go
ahead?
Then, if the verbosity if an issue, simply plug something like an existing
or custom no-op/Null appender [1]? That might sound the simplest solution,
isn't it?
[1]
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/varia/NullAppender.html
My 2 cents
2014-02-13 7:13 GMT+01:00 Benoît Berthonneau ben...@berthonneau.com:
Ron, Mirko, Kevin,
Thanks for your feedback : you're right with Slf4j implementation.
Unfortunately, it is not. It is a home made logger interface implemented by
Log4j.
Benoît
Le 12 févr. 2014 à 23:25, Ron Wheeler rwhee...@artifact-software.com
a écrit :
Not really a Maven issue but if you do your logging like this:
package com.myco.testapp;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass{
private Logger
_logger=LoggerFactory.getLogger(this.getClass());
logger.debug(“blah {} in the loop that contains {}”, i, max);
}
You can sort out the enabling of logs and destination of your logging by
severity and class(I think by package as well) in the log configuration at
run-time.
Ron
On 12/02/2014 4:20 PM, Mirko Friedenhagen wrote:
Hello Benoit,
Kevin is right, using slf4j[0] one would use sth. like:
logger.debug(“blah {} in the loop that contains {}”, i, max);
No need for iffing :-).
[0] http://www.slf4j.org/manual.html
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Feb 12, 2014 at 10:10 PM, Kevin Krumwiede kjk...@gmail.com
wrote:
It does matter which implementation. The main reason it was
recommended to
check the logging level was because string concatenation can be
expensive,
and you want to avoid doing it for a message that won't be logged.
But if
you're using a logging API like slf4j that uses parameter replacement
tokens in the message string, if the message isn't logged, the
replacement
won't be performed and the call will be cheap.
On Feb 12, 2014 1:57 PM, Benoît Berthonneau ben...@berthonneau.com
wrote:
Hi Paul,
Don't think that I could play with exclusions. Here is an example :
*A Unit Test :*
*The tested class with ALL traces activated:*
*And the same tested class with INFO traces activated:*
-Message d'origine-
De : paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
De
la part de Paul Benedict
Envoyé : mercredi 12 février 2014 21:36
À : Maven Users List
Objet : Re: Code coverage with debug logs: 100% branch coverage not
possible?...
IIRC, there should be an option in Emma/Cobertura that allows you to
exclude coverage on certain classes. So if you can exclude your log4j
classes (you don't really want to test your logging, do you?), then
you
should be able to raise your percentage.
On Wed, Feb 12, 2014 at 2:30 PM, Benoît Berthonneau
ben...@berthonneau.comwrote:
Hi all,
I need your opinion/way to tackle the following problem:
In many projects we use a Logger (doesn't matter which
implementation). It is often recommend to test if the debug level is
activated before logging a debug trace like the following:
if (logger.isDebugEnabled()) {
logger.debug(blah + i + in the loop that contains + max);
}
Now when you run unit tests on this kind of code you need to make a
choice:
run tests with INFO level or run tests with ALL traces activated. I
choose the second option in order to:
* Check that debug traces doesn't throw unwanted exception
(like
NPE)
* Have a better code coverage in term of covered lines
But in term of branches coverage we could never have a 100% :(
To me the only way to cover this is to run the tests suite 2 times:
one with INFO traces configured, and another one with ALL traces
activated.
Did you face this issue and how did you solve it ?
Thanks,
Benoît.
--
Cheers,
Paul
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
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
Re: Code coverage with debug logs: 100% branch coverage not possible?...
because if you enable ALL then the other side of the if will not be
followed... you need to combine runs with ALL and NONE to get both sides of
the logging branches.
Another point that the slf4j is the solution camp misses is sometimes the
log message needs evaluation in order to generate the message. For example
you might want to extract a meaningful string representation out of a
complex data structure... with a @CheckFoNull chain of methods to dance
through. While slf4j and other message formatting saves you a lot of the
cases where an `if (debug) { log }` is needed, it does not and can not
eliminate all cases.
And then there is the final point where you are dealing with a mutable data
structure (this is of more concern with an async logger framework)...
We had a case whereby the logging statements where logging the object in a
state which it could not possibly be in... because the log formatting and
hence toString() evaluation was taking place in a different thread async
(to prevent logging from slowing down the main code path)... so by the time
the log message was being formatted the object state had mutated and from
if (!caller.isAuthenticated()) {
logger.debug(Starting authentication flow for caller {}, caller);
...
}
if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) {
logger.debug(Looking up display name of {} using callerId {}, caller,
caller.getCallerId());
...
caller.setDisplayName(displayName);
logger.debug(Set display name of {} to \{}\ based on caller id
lookup, caller, displayName);
...
}
you would get
DEBUG: Starting authentication flow for caller Caller[id=0x67267,
authenticated=true, callerId=+14325551234, displayName=Jim Smith]
DEBUG: Looking up display name of id=0x67267, authenticated=true,
callerId=+14325551234, displayName=Jim Smith using callerId +14325551234
DEBUG: Set display name of Caller[id=0x67267, authenticated=true,
callerId=+14325551234, displayName=Jim Smith] to Jim Smith based on
caller id lookup
which from the code should never happen... what you expect is something like
DEBUG: Starting authentication flow for caller Caller[id=0x67267,
authenticated=false, callerId=+14325551234, displayName=null]
DEBUG: Looking up display name of Caller[id=0x67267, authenticated=true,
callerId=+14325551234, displayName=null] using callerId +14325551234
DEBUG: Set display name of Caller[id=0x67267, authenticated=true,
callerId=+14325551234, displayName=Jim Smith] to Jim Smith based on
caller id lookup
But because by the time the DEBUG message was formatted we had mutated the
object state already the logging statements were giving the wrong output...
the fix was to change the code to
if (!caller.isAuthenticated()) {
if (logger.isDebug()) logger.debug(Starting authentication flow for
caller {}, caller.toString());
...
}
if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) {
if (logger.isDebug()) logger.debug(Looking up display name of {} using
callerId {}, caller.toString(), caller.getCallerId());
...
caller.setDisplayName(displayName);
if (logger.isDebug()) logger.debug(Set display name of {} to \{}\
based on caller id lookup, caller.toString(), displayName);
...
}
In such cases you actually *have to* wrap the logging statement and force
the .toString() when logging.
What a framework like slf4j and the other message formatting based
frameworks gives you, however, is the default behaviour is lazy toString
and you can add the branches for those cases where you need them.
-Stephen
P.S. this logging example is a rephrase of the actual logging code which
using a home baked framework and I have paraphrased the code somewhat,
since this was actually a state machine... but the same issue can occur in
any multi-threaded code base where you are logging mutable objects and
expecting the log formatter to evaluate the toString()
On 13 February 2014 08:47, Baptiste Mathus m...@batmat.net wrote:
My first feeling is that not much time should be spent on that issue,
logging isn't going to take a lot of points of percentage down, having ~95%
would already be great (but maybe you already have).
Anyway, on the other hand, if what you want is to get code coverage, why
not just enable the ALL logging level when recording code coverage and go
ahead?
Then, if the verbosity if an issue, simply plug something like an existing
or custom no-op/Null appender [1]? That might sound the simplest solution,
isn't it?
[1]
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/varia/NullAppender.html
My 2 cents
2014-02-13 7:13 GMT+01:00 Benoît Berthonneau ben...@berthonneau.com:
Ron, Mirko, Kevin,
Thanks for your feedback : you're right with Slf4j implementation.
Unfortunately, it is not. It is a home made logger interface implemented
by
Log4j.
Benoît
Le 12 févr. 2014 à 23:25, Ron Wheeler rwhee...@artifact-software.com
a écrit :
Not
Re: Code coverage with debug logs: 100% branch coverage not possible?...
On 13 February 2014 09:23, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
because if you enable ALL then the other side of the if will not be
followed... you need to combine runs with ALL and NONE to get both sides of
the logging branches.
Another point that the slf4j is the solution camp misses is sometimes
the log message needs evaluation in order to generate the message. For
example you might want to extract a meaningful string representation out of
a complex data structure... with a @CheckFoNull chain of methods to dance
through. While slf4j and other message formatting saves you a lot of the
cases where an `if (debug) { log }` is needed, it does not and can not
eliminate all cases.
And then there is the final point where you are dealing with a mutable
data structure (this is of more concern with an async logger framework)...
We had a case whereby the logging statements where logging the object in a
state which it could not possibly be in... because the log formatting and
hence toString() evaluation was taking place in a different thread async
(to prevent logging from slowing down the main code path)... so by the time
the log message was being formatted the object state had mutated and from
if (!caller.isAuthenticated()) {
logger.debug(Starting authentication flow for caller {}, caller);
...
}
if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) {
logger.debug(Looking up display name of {} using callerId {}, caller,
caller.getCallerId());
...
caller.setDisplayName(displayName);
logger.debug(Set display name of {} to \{}\ based on caller id
lookup, caller, displayName);
...
}
you would get
DEBUG: Starting authentication flow for caller Caller[id=0x67267,
authenticated=true, callerId=+14325551234, displayName=Jim Smith]
DEBUG: Looking up display name of id=0x67267, authenticated=true, callerId=
+14325551234, displayName=Jim Smith using callerId +14325551234
DEBUG: Set display name of Caller[id=0x67267, authenticated=true, callerId=
+14325551234, displayName=Jim Smith] to Jim Smith based on caller id
lookup
which from the code should never happen... what you expect is something
like
DEBUG: Starting authentication flow for caller Caller[id=0x67267,
authenticated=false, callerId=+14325551234, displayName=null]
DEBUG: Looking up display name of Caller[id=0x67267, authenticated=true,
callerId=+14325551234, displayName=null] using callerId +14325551234
DEBUG: Set display name of Caller[id=0x67267, authenticated=true, callerId=
+14325551234, displayName=Jim Smith] to Jim Smith based on caller id
lookup
But because by the time the DEBUG message was formatted we had mutated the
object state already the logging statements were giving the wrong output...
the fix was to change the code to
if (!caller.isAuthenticated()) {
if (logger.isDebug()) logger.debug(Starting authentication flow for
caller {}, caller.toString());
...
}
if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) {
if (logger.isDebug()) logger.debug(Looking up display name of {} using
callerId {}, caller.toString(), caller.getCallerId());
...
caller.setDisplayName(displayName);
if (logger.isDebug()) logger.debug(Set display name of {} to \{}\
based on caller id lookup, caller.toString(), displayName);
...
}
In such cases you actually *have to* wrap the logging statement and force
the .toString() when logging
Well there are other solutions such as switching to immutable objects...
but if you don't have the ability to make such a change...
What a framework like slf4j and the other message formatting based
frameworks gives you, however, is the default behaviour is lazy toString
and you can add the branches for those cases where you need them.
-Stephen
P.S. this logging example is a rephrase of the actual logging code which
using a home baked framework and I have paraphrased the code somewhat,
since this was actually a state machine... but the same issue can occur in
any multi-threaded code base where you are logging mutable objects and
expecting the log formatter to evaluate the toString()
On 13 February 2014 08:47, Baptiste Mathus m...@batmat.net wrote:
My first feeling is that not much time should be spent on that issue,
logging isn't going to take a lot of points of percentage down, having
~95%
would already be great (but maybe you already have).
Anyway, on the other hand, if what you want is to get code coverage, why
not just enable the ALL logging level when recording code coverage and go
ahead?
Then, if the verbosity if an issue, simply plug something like an existing
or custom no-op/Null appender [1]? That might sound the simplest solution,
isn't it?
[1]
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/varia/NullAppender.html
My 2 cents
2014-02-13 7:13 GMT+01:00 Benoît Berthonneau
An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run: java.lang.NoSuchMethodError
Hi all, I am not sure what this error is about. I thought the jar file might be corrupted which I downloaded again but didnt work. I thought the problem might be with maven compiler but doesn't seem so. I reinstalled the maven in the eclipse but issue remains the same. Below is the whole trace of the issue. Any help will be appreciated. [INFO] Jetty server exiting. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3:11.676s [INFO] Finished at: Thu Feb 13 15:25:10 IST 2014 [INFO] Final Memory: 7M/23M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run (default-cli) on project oslc4j-bugzilla-sample: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run failed: An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run: java.lang.NoSuchMethodError: javax.servlet.ServletContext.getServletRegistration(Ljava/lang/String;)Ljavax/servlet/ServletRegistration; [ERROR] - [ERROR] realm = pluginorg.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/C:/Users/USWU49280/.m2/repository/org/mortbay/jetty/jetty-maven-plugin/8.1.14.v20131031/jetty-maven-plugin-8.1.14.v20131031.jar [ERROR] urls[1] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-util/8.1.14.v20131031/jetty-util-8.1.14.v20131031.jar [ERROR] urls[2] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-webapp/8.1.14.v20131031/jetty-webapp-8.1.14.v20131031.jar [ERROR] urls[3] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-xml/8.1.14.v20131031/jetty-xml-8.1.14.v20131031.jar [ERROR] urls[4] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-servlet/8.1.14.v20131031/jetty-servlet-8.1.14.v20131031.jar [ERROR] urls[5] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-security/8.1.14.v20131031/jetty-security-8.1.14.v20131031.jar [ERROR] urls[6] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/sisu/sisu-inject-bean/2.1.1/sisu-inject-bean-2.1.1.jar [ERROR] urls[7] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/sisu/sisu-guice/2.9.4/sisu-guice-2.9.4-no_aop.jar [ERROR] urls[8] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.6/plexus-utils-2.0.6.jar [ERROR] urls[9] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/aether/aether-util/1.11/aether-util-1.11.jar [ERROR] urls[10] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [ERROR] urls[11] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar [ERROR] urls[12] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar [ERROR] urls[13] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar [ERROR] urls[14] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-tools-api/2.9/maven-plugin-tools-api-2.9.jar [ERROR] urls[15] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar [ERROR] urls[16] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar [ERROR] urls[17] = file:/C:/Users/USWU49280/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[18] = file:/C:/Users/USWU49280/.m2/repository/net/sf/jtidy/jtidy/r938/jtidy-r938.jar [ERROR] urls[19] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-plus/8.1.14.v20131031/jetty-plus-8.1.14.v20131031.jar [ERROR] urls[20] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.jar [ERROR] urls[21] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-jndi/8.1.14.v20131031/jetty-jndi-8.1.14.v20131031.jar [ERROR] urls[22] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-server/8.1.14.v20131031/jetty-server-8.1.14.v20131031.jar [ERROR] urls[23] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/javax.servlet-3.0.0.v201112011016.jar [ERROR] urls[24] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-continuation/8.1.14.v20131031/jetty-continuation-8.1.14.v20131031.jar [ERROR] urls[25] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/orbit/javax.mail.glassfish/1.4.1.v201005082020/javax.mail.glassfish-1.4.1.v201005082020.jar [ERROR]
Fwd: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run: java.lang.NoSuchMethodError
I would turn to the Jetyy people, as it's their plugin. You should also include info on how you're executing the Maven build. (If you're doing this from within Eclipse, you should try from command line as well to verify that it's not Eclipse/m2e being the issue.) /Anders On Thu, Feb 13, 2014 at 11:01 AM, shriharsh l.shriha...@gmail.com wrote: Hi all, I am not sure what this error is about. I thought the jar file might be corrupted which I downloaded again but didnt work. I thought the problem might be with maven compiler but doesn't seem so. I reinstalled the maven in the eclipse but issue remains the same. Below is the whole trace of the issue. Any help will be appreciated. [INFO] Jetty server exiting. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3:11.676s [INFO] Finished at: Thu Feb 13 15:25:10 IST 2014 [INFO] Final Memory: 7M/23M [INFO] [ERROR] Failed to execute goal org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run (default-cli) on project oslc4j-bugzilla-sample: Execution default-cli of goal org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run failed: An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run: java.lang.NoSuchMethodError: javax.servlet.ServletContext.getServletRegistration(Ljava/lang/String;)Ljavax/servlet/ServletRegistration; [ERROR] - [ERROR] realm = pluginorg.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/C:/Users/USWU49280/.m2/repository/org/mortbay/jetty/jetty-maven-plugin/8.1.14.v20131031/jetty-maven-plugin-8.1.14.v20131031.jar [ERROR] urls[1] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-util/8.1.14.v20131031/jetty-util-8.1.14.v20131031.jar [ERROR] urls[2] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-webapp/8.1.14.v20131031/jetty-webapp-8.1.14.v20131031.jar [ERROR] urls[3] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-xml/8.1.14.v20131031/jetty-xml-8.1.14.v20131031.jar [ERROR] urls[4] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-servlet/8.1.14.v20131031/jetty-servlet-8.1.14.v20131031.jar [ERROR] urls[5] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-security/8.1.14.v20131031/jetty-security-8.1.14.v20131031.jar [ERROR] urls[6] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/sisu/sisu-inject-bean/2.1.1/sisu-inject-bean-2.1.1.jar [ERROR] urls[7] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/sisu/sisu-guice/2.9.4/sisu-guice-2.9.4-no_aop.jar [ERROR] urls[8] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.6/plexus-utils-2.0.6.jar [ERROR] urls[9] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/aether/aether-util/1.11/aether-util-1.11.jar [ERROR] urls[10] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [ERROR] urls[11] = file:/C:/Users/USWU49280/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar [ERROR] urls[12] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar [ERROR] urls[13] = file:/C:/Users/USWU49280/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar [ERROR] urls[14] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-tools-api/2.9/maven-plugin-tools-api-2.9.jar [ERROR] urls[15] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar [ERROR] urls[16] = file:/C:/Users/USWU49280/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar [ERROR] urls[17] = file:/C:/Users/USWU49280/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[18] = file:/C:/Users/USWU49280/.m2/repository/net/sf/jtidy/jtidy/r938/jtidy-r938.jar [ERROR] urls[19] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-plus/8.1.14.v20131031/jetty-plus-8.1.14.v20131031.jar [ERROR] urls[20] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.jar [ERROR] urls[21] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-jndi/8.1.14.v20131031/jetty-jndi-8.1.14.v20131031.jar [ERROR] urls[22] = file:/C:/Users/USWU49280/.m2/repository/org/eclipse/jetty/jetty-server/8.1.14.v20131031/jetty-server-8.1.14.v20131031.jar [ERROR] urls[23] =
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
You need to provide more info on what you're doing! Is the deploy:deploy-file bound to the build lifecycle of a project? How? /Anders On Thu, Feb 13, 2014 at 11:06 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote: Hi I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
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
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
executions
execution
idcookbook/id
phasedeploy/phase
goals
goaldeploy-file/goal
/goals
configuration
primaryArtifactfalse/primaryArtifact
repositoryIdartifactory/repositoryId
packagingzip/packaging
url${project.distributionManagement.snapshotRepository.url}/url
generatePomfalse/generatePom
artifactId${project.parent.artifactId}/artifactId
groupId${project.parent.groupId}/groupId
version${project.parent.version}/version
classifierdeploymentfile/classifier
file
${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip
/file
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
/profiles
/project
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar and...@hammar.net wrote:
You need to provide more info on what you're doing! Is the
deploy:deploy-file bound to the build lifecycle of a project? How?
/Anders
On Thu, Feb 13, 2014 at 11:06 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi
I have a question about the expected behaviour of the deploy:deploy-file
goal in the maven deploy plugin 2.8.1 which I am currently using to
deploy
one file.
It surprised me that no matter what I did I kept getting more artifacts
deployed that I asked for and the reason is in the
org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the
attached artifacts are also deployed.
Is this intended behaviour and if so how can I avoid this from happening?
The goal name deploy-file indicates that one artifact (possible incl.
pom/metadata) is to be deployed and not also a throng of other artifacts.
I will be happy to provide a patch where this is aspect is removed.
Thank you in advance
regards
Henrik Skriver Rasmussen
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
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
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
executions
execution
idcookbook/id
phasedeploy/phase
goals
goaldeploy-file/goal
/goals
configuration
primaryArtifactfalse/primaryArtifact
repositoryIdartifactory/repositoryId
packagingzip/packaging
url${project.distributionManagement.snapshotRepository.url}/url
generatePomfalse/generatePom
artifactId${project.parent.artifactId}/artifactId
groupId${project.parent.groupId}/groupId
version${project.parent.version}/version
classifierdeploymentfile/classifier
file
${project.build.directory}/${project.parent.artifactId}-${project.parent.version}-deploymentfile.zip
/file
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
/profiles
/project
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:15 PM, Anders Hammar and...@hammar.net wrote:
You need to provide more info on what you're doing! Is the
deploy:deploy-file bound to the build lifecycle of a project? How?
/Anders
On Thu, Feb 13, 2014 at 11:06 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi
I have a question about the expected
Re: An API incompatibility was encountered while executing org.mortbay.jetty:jetty-maven-plugin:8.1.14.v20131031:run: java.lang.NoSuchMethodError
Thanks for the reply Anders. I would try to get help from Jetty people. -- View this message in context: http://maven.40175.n5.nabble.com/An-API-incompatibility-was-encountered-while-executing-org-mortbay-jetty-jetty-maven-plugin-8-1-14-vr-tp5784451p5784465.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: SCM requires that command line svn be used?
Hi, I am getting the same error. Can you please help me if you have fixed this issue. Do we need to configure anything specifically for https svn URLs? I have given credentials in maven settings and svn configuration in pom files. Any my release plugin is as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.6/version /dependency /dependencies configuration providerImplementations svnjavasvn/svn /providerImplementations tagBasehttps://mydomain.com/svn/New_FW/CI_POC/tags/tagBase mavenExecutorIdforked-path/mavenExecutorId /configuration /plugin PFB the error that I am getting: [INFO] Building Service 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-release-plugin:2.4.2:prepare (default-cli) @ Service --- [INFO] Change the default 'svn' provider implementation to 'javasvn'. [INFO] Verifying that there are no local modifications... [INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag [INFO] SVN status directory: D:\Softwares\jenkins\jobs\Perform_Release\workspace [INFO] [INFO] Reactor Summary: [INFO] [INFO] Service ... FAILURE [14.743s] [INFO] ServiceEJB SKIPPED [INFO] SpringMVC323REST .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 17.859s [INFO] Finished at: Thu Feb 13 10:37:59 IST 2014 [INFO] Final Memory: 9M/55M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications [ERROR] Provider message: [ERROR] SVN status failed. [ERROR] Command output: [ERROR] svn: Authentication required for 'https://mydomain.com:443' [ERROR] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications Provider message: SVN status failed. Command output: svn: Authentication required for 'https://mydomain.com:443' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) -- View this message in context: http://maven.40175.n5.nabble.com/SCM-requires-that-command-line-svn-be-used-tp119251p5784375.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-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter
Good point. After I fixed the spelling, it works fine. Is was a great help to have a second set of eyes to find my stupid mistakes. It would have been nice to have a better error message. [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'com.artifact-software.taw:taw-localized-iumessage-ws:war' o 'com.artifact-software.taw:taw-dataccess-ws:war' A file not found would have been more helpful. I tested to see if the file was not found by adding a deliberate spelling mistake but I drew the wrong conclusion when I got the same error message. Ron On 12/02/2014 6:11 PM, Barrie Treloar wrote: On 13 February 2014 02:24, Ron Wheeler rwhee...@artifact-software.com wrote: I did a debug run and I think that the log shows where the includes get idwebapps/id formats formattar/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet outputDirectory/target/outputDirectory useProjectArtifactfalse/useProjectArtifact unpackfalse/unpack scoperuntime/scope includes includecom.artifact-software.taw:taw-localized-iumessage-ws:war/include includecom.artifact-software.taw:taw-dataccess-ws:war/include /includes /dependencySet /dependencySets [del] [DEBUG] com.artifact_software.taw:taw-localized-uimessage-ws:war:1.0.2 was removed by one or more filters. [DEBUG] com.artifact_software.taw:taw-dataaccess-ws:war:1.0.2 was removed by one or more filters. [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'com.artifact-software.taw:taw-localized-iumessage-ws:war' o 'com.artifact-software.taw:taw-dataccess-ws:war' [del] http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html defines the spec for dependency conflict id and it does not include version. It is either * short form = groupId:artifactId * long form = groupId:artifactId:type:classifier I'm guiding you blind since I've not done this before. The output is telling us that the pattern 'com.artifact-software.taw:taw-localized-iumessage-ws:war' does not match the artifact com.artifact_software.taw:taw-localized-uimessage-ws:war:1.0.2 And there is your problem. You have an _ in your groupid for the artifact, but not your include filter. I've been looking at maven-common-artifact-filters-1.4 PatternIncludesArtifactFilter.matchAgainst(). since I thought that may you needed a trailing : on the long id. But it does the right thing with as much of the pattern you provide - and wildcards the rest. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- 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
Multiple assemblies in a pom
I am trying to create 3 tar files in a single project. I have 3 invocations of the maven-assembly-plugin in the pom. It works but gives the warnings shown below. How likely is it that these dire threats of future problems will come about? What is the Best Practice to fix this? Ron [WARNING] Some problems were encountered while building the effective model for com.artifact_software.taw:taw-webapps-assembler:jar:1.0.2 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-assembly -plugin @ line 77, column 12 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-assembly -plugin @ line 89, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. -- 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
Re: maven-ear-plugin silently overrides libraries
So what's the status on this? Shall I create a ticket? On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler rwhee...@artifact-software.comwrote: Exclusions will not help in this case. Looking through the dependency hierarchy will at least get you to see the problem earlier which I think was the nature of your question. It appears from my brief reading and fun with making servlets run in production that classloaders merge classes by name. Maven does not. I am a bit surprised that groupId does not count. If one uses a lot of third -party libraries, it would seem inevitable that you could need com.artifact-software:utilities:1.0 at the same time as ch.rethab:utilities:1.0 at the same time. The classloader is not going to cause any problem but if Maven throws out one of these as a duplicate, you will be missing classes at run-time. It is difficult to force everyone to create unique artifactIds unless you get rid of the GroupId altogther and make GAV - AV and put the group name into the artifactID. This seems to be a design flaw if it is true. Ron On 07/02/2014 9:43 AM, Reto Hablützel wrote: Sure, but exclusions don't do the trick if you need both of them, do they? I am talking about completely independent libraries that happen to have the same artifactId. Those were actually both libraries of mine and I could obviously fix this issue rather simply, but I was just thinking that it would be helpful to have at least a warning or something from maven - regardless of the IDE. - Reto On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler rwheeler@artifact-software. com mailto:rwhee...@artifact-software.com wrote: If your IDE supports Maven (Eclipse/STS for example), you will see the conflict in the dependency hierarchy view and you can fix it with the right exclusions. It is almost always worth a quick look through the dependency hierarchy view if you use a lot of third party libraries. Not everyone updates their dependencies when they build a shareable library. You can sometimes get some pretty old versions of things dragged in with the latest version of otherwise well-written libraries. Exclusions need to be added to get what you want in your artifacts. Ron On 07/02/2014 9:21 AM, Reto Hablützel wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Multiple assemblies in a pom
You should have multiple execution declarations. Not plugin declarations. /Anders On Thu, Feb 13, 2014 at 1:59 PM, Ron Wheeler rwhee...@artifact-software.com wrote: I am trying to create 3 tar files in a single project. I have 3 invocations of the maven-assembly-plugin in the pom. It works but gives the warnings shown below. How likely is it that these dire threats of future problems will come about? What is the Best Practice to fix this? Ron [WARNING] Some problems were encountered while building the effective model for com.artifact_software.taw:taw-webapps-assembler:jar:1.0.2 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins: maven-assembly -plugin @ line 77, column 12 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins: maven-assembly -plugin @ line 89, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. -- 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
Re: Multiple assemblies in a pom
One quick Google and two reads of the docs - missed the execution id the first time and it worked like a charm! Thanks Ron On 13/02/2014 8:51 AM, Anders Hammar wrote: You should have multiple execution declarations. Not plugin declarations. /Anders On Thu, Feb 13, 2014 at 1:59 PM, Ron Wheeler rwhee...@artifact-software.com wrote: I am trying to create 3 tar files in a single project. I have 3 invocations of the maven-assembly-plugin in the pom. It works but gives the warnings shown below. How likely is it that these dire threats of future problems will come about? What is the Best Practice to fix this? Ron [WARNING] Some problems were encountered while building the effective model for com.artifact_software.taw:taw-webapps-assembler:jar:1.0.2 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins: maven-assembly -plugin @ line 77, column 12 [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins: maven-assembly -plugin @ line 89, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. -- 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 -- 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
Maven Site Plugin and report plugins that need dependencies declared
I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides
Re: Code coverage with debug logs: 100% branch coverage not possible?...
Thanks for all your comments. I will conclude to my first idea: tests
need to be run 2 times (one with traces to OFF or INFO, and the other
one with traces to ALL)
Regards,
Benoît.
Le 13-02-2014 10:25, Stephen Connolly a écrit :
On 13 February 2014 09:23, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
because if you enable ALL then the other side of the if will not be
followed... you need to combine runs with ALL and NONE to get both sides of
the logging branches. Another point that the slf4j is the solution camp
misses is sometimes the log message needs evaluation in order to generate
the message. For example you might want to extract a meaningful string
representation out of a complex data structure... with a @CheckFoNull chain
of methods to dance through. While slf4j and other message formatting saves
you a lot of the cases where an `if (debug) { log }` is needed, it does not
and can not eliminate all cases. And then there is the final point where you
are dealing with a mutable data structure (this is of more concern with an
async logger framework)... We had a case whereby the logging statements
where logging the object in a state which it could not possibly be in...
because the log formatting and hence toString() evaluation was taking place
in a different thread async (to
prevent logging from slowing down the main code path)... so by the time the log
message was being formatted the object state had mutated and from if
(!caller.isAuthenticated()) { logger.debug(Starting authentication flow for
caller {}, caller); ... } if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) { logger.debug(Looking up display
name of {} using callerId {}, caller, caller.getCallerId()); ...
caller.setDisplayName(displayName); logger.debug(Set display name of {} to
{} based on caller id lookup, caller, displayName); ... } you would get
DEBUG: Starting authentication flow for caller Caller[id=0x67267,
authenticated=true, callerId=+14325551234, displayName=Jim Smith] DEBUG:
Looking up display name of id=0x67267, authenticated=true, callerId=
+14325551234, displayName=Jim Smith using callerId +14325551234 DEBUG: Set
display name of Caller[id=0x67267, authenticated=true, callerId= +14325551234,
displayName=Jim Smith] to Jim
Smith based on caller id lookup which from the code should never happen...
what you expect is something like DEBUG: Starting authentication flow for
caller Caller[id=0x67267, authenticated=false, callerId=+14325551234,
displayName=null] DEBUG: Looking up display name of Caller[id=0x67267,
authenticated=true, callerId=+14325551234, displayName=null] using callerId
+14325551234 DEBUG: Set display name of Caller[id=0x67267, authenticated=true,
callerId= +14325551234, displayName=Jim Smith] to Jim Smith based on caller
id lookup But because by the time the DEBUG message was formatted we had
mutated the object state already the logging statements were giving the wrong
output... the fix was to change the code to if (!caller.isAuthenticated()) { if
(logger.isDebug()) logger.debug(Starting authentication flow for caller {},
caller.toString()); ... } if (StringUtils.isEmpty(caller.getDisplayName)
StringUtils.isNotBlank(caller.getCallerId()) { if (logger.isDebug())
logger.debug(Looking up display name of {} using callerId {},
caller.toString(), caller.getCallerId()); ...
caller.setDisplayName(displayName); if (logger.isDebug()) logger.debug(Set
display name of {} to {} based on caller id lookup, caller.toString(),
displayName); ... } In such cases you actually *have to* wrap the logging
statement and force the .toString() when logging
Well there are other solutions such as switching to immutable objects...
but if you don't have the ability to make such a change...
What a framework like slf4j and the other message formatting based frameworks
gives you, however, is the default behaviour is lazy toString and you can add
the branches for those cases where you need them. -Stephen P.S. this logging
example is a rephrase of the actual logging code which using a home baked
framework and I have paraphrased the code somewhat, since this was actually a
state machine... but the same issue can occur in any multi-threaded code base
where you are logging mutable objects and expecting the log formatter to
evaluate the toString() On 13 February 2014 08:47, Baptiste Mathus
m...@batmat.net wrote: My first feeling is that not much time should be
spent on that issue, logging isn't going to take a lot of points of
percentage down, having ~95% would already be great (but maybe you already
have). Anyway, on the other hand, if what you want is to get code coverage,
why not just enable the ALL logging level when recording code coverage and go
ahead? Then, if the
verbosity if an issue, simply plug something like an existing or custom
no-op/Null appender [1]? That might sound the simplest
Strange Array configuration for plugin params
A contributor for MOJO-2006 [1] uses array configuration at http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ( array session) here is the text /** * My List. */ @Parameter private List myList; myList paramvalue1/param paramvalue2/param /myList For details on the mapping of the individual collection elements, see Mapping Listshttp://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Lists . However if you drill down to 'Mapping Lists' it has the usual configuration that we are custom-ed to animals animalcat/animal animaldog/animal animalaardvark/animal /animals is it there by accident? or the plugin api support both format? Thanks [1] https://jira.codehaus.org/browse/MOJO-2006
Re: Maven Site Plugin and report plugins that need dependencies declared
I'll make it short: please don't use reportPlugins in m-site-p configuration see http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configuration_formats use classic configuration and everything will work fine Regards, Hervé Le jeudi 13 février 2014 15:34:03 Alex Potsides a écrit : I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: SCM requires that command line svn be used?
It says authentication required. Did you provide/configure the necessary credentials? Le 13 févr. 2014 12:21, doddalas vijayd1...@gmail.com a écrit : Hi, I am getting the same error. Can you please help me if you have fixed this issue. Do we need to configure anything specifically for https svn URLs? I have given credentials in maven settings and svn configuration in pom files. Any my release plugin is as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.6/version /dependency /dependencies configuration providerImplementations svnjavasvn/svn /providerImplementations tagBase https://mydomain.com/svn/New_FW/CI_POC/tags/tagBase mavenExecutorIdforked-path/mavenExecutorId /configuration /plugin PFB the error that I am getting: [INFO] Building Service 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-release-plugin:2.4.2:prepare (default-cli) @ Service --- [INFO] Change the default 'svn' provider implementation to 'javasvn'. [INFO] Verifying that there are no local modifications... [INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag [INFO] SVN status directory: D:\Softwares\jenkins\jobs\Perform_Release\workspace [INFO] [INFO] Reactor Summary: [INFO] [INFO] Service ... FAILURE [14.743s] [INFO] ServiceEJB SKIPPED [INFO] SpringMVC323REST .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 17.859s [INFO] Finished at: Thu Feb 13 10:37:59 IST 2014 [INFO] Final Memory: 9M/55M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications [ERROR] Provider message: [ERROR] SVN status failed. [ERROR] Command output: [ERROR] svn: Authentication required for 'https://mydomain.com:443' [ERROR] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications Provider message: SVN status failed. Command output: svn: Authentication required for 'https://mydomain.com:443' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) -- View this message in context: http://maven.40175.n5.nabble.com/SCM-requires-that-command-line-svn-be-used-tp119251p5784375.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-ear-plugin silently overrides libraries
That's the way to go. Even more if you're able to attach a test project. One report without report is far less likely to be worked on. Cheers Le 13 févr. 2014 14:06, Reto Hablützel ret...@rethab.ch a écrit : So what's the status on this? Shall I create a ticket? On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler rwhee...@artifact-software.comwrote: Exclusions will not help in this case. Looking through the dependency hierarchy will at least get you to see the problem earlier which I think was the nature of your question. It appears from my brief reading and fun with making servlets run in production that classloaders merge classes by name. Maven does not. I am a bit surprised that groupId does not count. If one uses a lot of third -party libraries, it would seem inevitable that you could need com.artifact-software:utilities:1.0 at the same time as ch.rethab:utilities:1.0 at the same time. The classloader is not going to cause any problem but if Maven throws out one of these as a duplicate, you will be missing classes at run-time. It is difficult to force everyone to create unique artifactIds unless you get rid of the GroupId altogther and make GAV - AV and put the group name into the artifactID. This seems to be a design flaw if it is true. Ron On 07/02/2014 9:43 AM, Reto Hablützel wrote: Sure, but exclusions don't do the trick if you need both of them, do they? I am talking about completely independent libraries that happen to have the same artifactId. Those were actually both libraries of mine and I could obviously fix this issue rather simply, but I was just thinking that it would be helpful to have at least a warning or something from maven - regardless of the IDE. - Reto On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler rwheeler@artifact-software. com mailto:rwhee...@artifact-software.com wrote: If your IDE supports Maven (Eclipse/STS for example), you will see the conflict in the dependency hierarchy view and you can fix it with the right exclusions. It is almost always worth a quick look through the dependency hierarchy view if you use a lot of third party libraries. Not everyone updates their dependencies when they build a shareable library. You can sometimes get some pretty old versions of things dragged in with the latest version of otherwise well-written libraries. Exclusions need to be added to get what you want in your artifacts. Ron On 07/02/2014 9:21 AM, Reto Hablützel wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: maven-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter
On 13 February 2014 23:25, Ron Wheeler rwhee...@artifact-software.com wrote: Good point. After I fixed the spelling, it works fine. Is was a great help to have a second set of eyes to find my stupid mistakes. It would have been nice to have a better error message. [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'com.artifact-software.taw:taw-localized-iumessage-ws:war' o 'com.artifact-software.taw:taw-dataccess-ws:war' A file not found would have been more helpful. I tested to see if the file was not found by adding a deliberate spelling mistake but I drew the wrong conclusion when I got the same error message. You're welcome to make a patch :) I dont think it is working with files at the point it is doing all the checking, especially if the filter has a * in it. I guess you could use http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29 And if they are close include a Did you mean this instead? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Plugin and report plugins that need dependencies declared
Brevity appreciated. You sound like someone who has answered that question before. Thanks, Alex On Thu, Feb 13, 2014 at 5:50 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I'll make it short: please don't use reportPlugins in m-site-p configuration see http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configuration_formats use classic configuration and everything will work fine Regards, Hervé Le jeudi 13 février 2014 15:34:03 Alex Potsides a écrit : I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is dependency:analyze lying to me?
Hi, This may fall into the “How the hell is Maven supposed to know?” category, but one of the dependencies that dependency:analyze lists when I run it on my WAR project is [WARNING] Unused declared dependencies found: … [WARNING] org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile However, when I comment this out of my pom, a few of my JSPs die with the error org.apache.jasper.JasperException: The absolute uri: http://www.springframework.org/security/tags cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116) because the JSP includes this %@ taglib prefix=sec uri=http://www.springframework.org/security/tags% Anyway, not sure if the plugin can be configured to detect these kind of things, but a guy can dream, can’t he?? -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108p5784691.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 is dependency:analyze lying to me?
Especially if you use Spring XML configuration, it's impossible for the Dependency Plugin to figure out you need this-or-that Spring jar. The best you can do, actually, is use the new Spring Java Config so that your configuration is code and thus able to be statically analyzed. On Thu, Feb 13, 2014 at 3:54 PM, laredotornado-3 laredotorn...@gmail.comwrote: Hi, This may fall into the How the hell is Maven supposed to know? category, but one of the dependencies that dependency:analyze lists when I run it on my WAR project is [WARNING] Unused declared dependencies found: ... [WARNING] org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile However, when I comment this out of my pom, a few of my JSPs die with the error org.apache.jasper.JasperException: The absolute uri: http://www.springframework.org/security/tags cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116) because the JSP includes this %@ taglib prefix=sec uri=http://www.springframework.org/security/tags% Anyway, not sure if the plugin can be configured to detect these kind of things, but a guy can dream, can't he?? -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-dependency-analyze-lying-to-me-tp5784108p5784691.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 -- Cheers, Paul
Re: Why is dependency:analyze lying to me?
This may fall into the “How the hell is Maven supposed to know?” category, Yes, it most certainly does. [WARNING] org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile ... Anyway, not sure if the plugin can be configured to detect these kind of things, but a guy can dream, can’t he?? You would need to write code that performs the following tasks: 1. look in jar files related to dependencies 2. find taglib files and other configuration files [each file type needs its own parser] 3. store tag uris that are discovered along with the associated jar 4. check those tag uris vs what is in your code (keep in mind some may be in config files you wrote, so gotta parse those too - more code to write) 5. output the list of jars (dependencies) which are not actually used in code or config This is nontrivial, so no one has done it. I'm sure we'd take a contribution if you did the work. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven parent POM - execute plugin after the submodule execution
Hi Everybody, in my project i have a pom, that contains some childs (submodules). The pom was defined as pom packaging type, and all is working fine. But now i must execute a maven plugin, that should be executed after the submodule build was finished. Is this possible, and when not, how can i realize this? The parent pom is only a aggregator pom. Thank you in Advance! Regards, Denis -- View this message in context: http://maven.40175.n5.nabble.com/Maven-parent-POM-execute-plugin-after-the-submodule-execution-tp5784481.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
How to minimize quantity of profiles in pom.xml file
I have a lot of profiles in my module pom. The difference between them is only target URL. Is there any possibility to make one profile with parameters which will be taken from file or any other solution to make one profile instead of many. -- View this message in context: http://maven.40175.n5.nabble.com/How-to-minimize-quantity-of-profiles-in-pom-xml-file-tp5784478.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: Strange Array configuration for plugin params
ping :-) On Thu, Feb 13, 2014 at 9:46 AM, Dan Tran dant...@gmail.com wrote: A contributor for MOJO-2006 [1] uses array configuration at http://maven.apache.org/guides/plugin/guide-java-plugin-development.html( array session) here is the text /** * My List. */ @Parameter private List myList; myList paramvalue1/param paramvalue2/param /myList For details on the mapping of the individual collection elements, see Mapping Listshttp://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Lists . However if you drill down to 'Mapping Lists' it has the usual configuration that we are custom-ed to animals animalcat/animal animaldog/animal animalaardvark/animal /animals is it there by accident? or the plugin api support both format? Thanks [1] https://jira.codehaus.org/browse/MOJO-2006
Re: Strange Array configuration for plugin params
On 13 Feb 2014, at 17:46, Dan Tran dant...@gmail.com wrote: A contributor for MOJO-2006 [1] uses array configuration at http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ( array session) here is the text /** * My List. */ @Parameter private List myList; myList paramvalue1/param paramvalue2/param /myList For details on the mapping of the individual collection elements, see Mapping Listshttp://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Lists. However if you drill down to 'Mapping Lists' it has the usual configuration that we are custom-ed to animals animalcat/animal animaldog/animal animalaardvark/animal /animals is it there by accident? or the plugin api support both format? Both formats are supported. Thanks [1] https://jira.codehaus.org/browse/MOJO-2006 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: SCM requires that command line svn be used?
Hi, Yes I have provided credentials in Maven settings.xml and also while running the job, as parameters like -Dusername, -Dpassword. Even then I am getting above error. Vijay On Thu, Feb 13, 2014 at 11:45 PM, Baptiste MATHUS-2 [via Maven] ml-node+s40175n578466...@n5.nabble.com wrote: It says authentication required. Did you provide/configure the necessary credentials? Le 13 févr. 2014 12:21, doddalas [hidden email]http://user/SendEmail.jtp?type=nodenode=5784666i=0 a écrit : Hi, I am getting the same error. Can you please help me if you have fixed this issue. Do we need to configure anything specifically for https svn URLs? I have given credentials in maven settings and svn configuration in pom files. Any my release plugin is as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version dependencies dependency groupIdcom.google.code.maven-scm-provider-svnjava/groupId artifactIdmaven-scm-provider-svnjava/artifactId version1.6/version /dependency /dependencies configuration providerImplementations svnjavasvn/svn /providerImplementations tagBase https://mydomain.com/svn/New_FW/CI_POC/tags/tagBase mavenExecutorIdforked-path/mavenExecutorId /configuration /plugin PFB the error that I am getting: [INFO] Building Service 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-release-plugin:2.4.2:prepare (default-cli) @ Service --- [INFO] Change the default 'svn' provider implementation to 'javasvn'. [INFO] Verifying that there are no local modifications... [INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag [INFO] SVN status directory: D:\Softwares\jenkins\jobs\Perform_Release\workspace [INFO] [INFO] Reactor Summary: [INFO] [INFO] Service ... FAILURE [14.743s] [INFO] ServiceEJB SKIPPED [INFO] SpringMVC323REST .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 17.859s [INFO] Finished at: Thu Feb 13 10:37:59 IST 2014 [INFO] Final Memory: 9M/55M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications [ERROR] Provider message: [ERROR] SVN status failed. [ERROR] Command output: [ERROR] svn: Authentication required for 'https://mydomain.com:443' [ERROR] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project Service: Unable to check for local modifications Provider message: SVN status failed. Command output: svn: Authentication required for 'https://mydomain.com:443' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) -- View this message in context: http://maven.40175.n5.nabble.com/SCM-requires-that-command-line-svn-be-used-tp119251p5784375.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5784666i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5784666i=2 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/SCM-requires-that-command-line-svn-be-used-tp119251p5784666.html To unsubscribe from SCM requires that command line svn be used?, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=119251code=dmlqYXlkMTUwOEBnbWFpbC5jb218MTE5MjUxfDE2ODEzNzQzMTQ= .
Re: Maven Site Plugin and report plugins that need dependencies declared
yes :) it has taken a few maven-site-plugin releases to really understand we had make a mistake switching to something that was finally not ready, and document it to have a chance people understand the rationale Regards, Hervé Le jeudi 13 février 2014 21:28:11 Alex Potsides a écrit : Brevity appreciated. You sound like someone who has answered that question before. Thanks, Alex On Thu, Feb 13, 2014 at 5:50 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I'll make it short: please don't use reportPlugins in m-site-p configuration see http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configurati on_formats use classic configuration and everything will work fine Regards, Hervé Le jeudi 13 février 2014 15:34:03 Alex Potsides a écrit : I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides - 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
Re: Maven parent POM - execute plugin after the submodule execution
Just add another submodule. Make it depend on the last submodule (eg you had A, B, C before - make this D, and depend on C, assumes C depends on B which depends on A). Add the plugin to D. Wayne On Thu, Feb 13, 2014 at 7:04 AM, DenisDasKind blto...@abv.bg wrote: Hi Everybody, in my project i have a pom, that contains some childs (submodules). The pom was defined as pom packaging type, and all is working fine. But now i must execute a maven plugin, that should be executed after the submodule build was finished. Is this possible, and when not, how can i realize this? The parent pom is only a aggregator pom. Thank you in Advance! Regards, Denis -- View this message in context: http://maven.40175.n5.nabble.com/Maven-parent-POM-execute-plugin-after-the-submodule-execution-tp5784481.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to minimize quantity of profiles in pom.xml file
I have a lot of profiles in my module pom. The difference between them is only target URL. Is there any possibility to make one profile with parameters which will be taken from file or any other solution to make one profile instead of many. Tell us more about what you are building. Why do you need to vary the target URL as you mention? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-plugin silently overrides libraries
You need to create an account at Codehaus Xircles. Go to http://jira.codehaus.org and there is more info in the top left hand gadget/box. /Anders On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel ret...@rethab.ch wrote: Is JIRA open for public registration / issue creation? I could not find a link to sign up.. Anyways, I attached a sample project. Please follow these steps to recreate the issue (btw. I think the whole naming thing is also a problem if you are referencing two ejbs with the same artifactId and version): Install 'utilities' project in 'collections': collections/utilities mvn install Install 'utilities' project in 'email': email/utilities mvn install Package 'ear' project: ear mvn package Look at contents of ear and notice how only one jar is included: ear unzip -v target/ear-1.0.0.ear Now use the debug flag to see why only one gets included: ear mvn --debug clean package Partial output: [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to [utilities-1.0.0.jar] [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0], as it is already up to date at [utilities-1.0.0.jar] On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus bmat...@batmat.netwrote: That's the way to go. Even more if you're able to attach a test project. One report without report is far less likely to be worked on. Cheers Le 13 févr. 2014 14:06, Reto Hablützel ret...@rethab.ch a écrit : So what's the status on this? Shall I create a ticket? On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler rwhee...@artifact-software.comwrote: Exclusions will not help in this case. Looking through the dependency hierarchy will at least get you to see the problem earlier which I think was the nature of your question. It appears from my brief reading and fun with making servlets run in production that classloaders merge classes by name. Maven does not. I am a bit surprised that groupId does not count. If one uses a lot of third -party libraries, it would seem inevitable that you could need com.artifact-software:utilities:1.0 at the same time as ch.rethab:utilities:1.0 at the same time. The classloader is not going to cause any problem but if Maven throws out one of these as a duplicate, you will be missing classes at run-time. It is difficult to force everyone to create unique artifactIds unless you get rid of the GroupId altogther and make GAV - AV and put the group name into the artifactID. This seems to be a design flaw if it is true. Ron On 07/02/2014 9:43 AM, Reto Hablützel wrote: Sure, but exclusions don't do the trick if you need both of them, do they? I am talking about completely independent libraries that happen to have the same artifactId. Those were actually both libraries of mine and I could obviously fix this issue rather simply, but I was just thinking that it would be helpful to have at least a warning or something from maven - regardless of the IDE. - Reto On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler rwheeler@artifact-software. com mailto:rwhee...@artifact-software.com wrote: If your IDE supports Maven (Eclipse/STS for example), you will see the conflict in the dependency hierarchy view and you can fix it with the right exclusions. It is almost always worth a quick look through the dependency hierarchy view if you use a lot of third party libraries. Not everyone updates their dependencies when they build a shareable library. You can sometimes get some pretty old versions of things dragged in with the latest version of otherwise well-written libraries. Exclusions need to be added to get what you want in your artifacts. Ron On 07/02/2014 9:21 AM, Reto Hablützel wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com
Re: maven-ear-plugin silently overrides libraries
Thank you, Anders. I reported the issue: http://jira.codehaus.org/browse/MEAR-180 - Reto On Fri, Feb 14, 2014 at 7:52 AM, Anders Hammar and...@hammar.net wrote: You need to create an account at Codehaus Xircles. Go to http://jira.codehaus.org and there is more info in the top left hand gadget/box. /Anders On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel ret...@rethab.ch wrote: Is JIRA open for public registration / issue creation? I could not find a link to sign up.. Anyways, I attached a sample project. Please follow these steps to recreate the issue (btw. I think the whole naming thing is also a problem if you are referencing two ejbs with the same artifactId and version): Install 'utilities' project in 'collections': collections/utilities mvn install Install 'utilities' project in 'email': email/utilities mvn install Package 'ear' project: ear mvn package Look at contents of ear and notice how only one jar is included: ear unzip -v target/ear-1.0.0.ear Now use the debug flag to see why only one gets included: ear mvn --debug clean package Partial output: [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to [utilities-1.0.0.jar] [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0], as it is already up to date at [utilities-1.0.0.jar] On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus bmat...@batmat.net wrote: That's the way to go. Even more if you're able to attach a test project. One report without report is far less likely to be worked on. Cheers Le 13 févr. 2014 14:06, Reto Hablützel ret...@rethab.ch a écrit : So what's the status on this? Shall I create a ticket? On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler rwhee...@artifact-software.comwrote: Exclusions will not help in this case. Looking through the dependency hierarchy will at least get you to see the problem earlier which I think was the nature of your question. It appears from my brief reading and fun with making servlets run in production that classloaders merge classes by name. Maven does not. I am a bit surprised that groupId does not count. If one uses a lot of third -party libraries, it would seem inevitable that you could need com.artifact-software:utilities:1.0 at the same time as ch.rethab:utilities:1.0 at the same time. The classloader is not going to cause any problem but if Maven throws out one of these as a duplicate, you will be missing classes at run-time. It is difficult to force everyone to create unique artifactIds unless you get rid of the GroupId altogther and make GAV - AV and put the group name into the artifactID. This seems to be a design flaw if it is true. Ron On 07/02/2014 9:43 AM, Reto Hablützel wrote: Sure, but exclusions don't do the trick if you need both of them, do they? I am talking about completely independent libraries that happen to have the same artifactId. Those were actually both libraries of mine and I could obviously fix this issue rather simply, but I was just thinking that it would be helpful to have at least a warning or something from maven - regardless of the IDE. - Reto On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler rwheeler@artifact-software. com mailto:rwhee...@artifact-software.com wrote: If your IDE supports Maven (Eclipse/STS for example), you will see the conflict in the dependency hierarchy view and you can fix it with the right exclusions. It is almost always worth a quick look through the dependency hierarchy view if you use a lot of third party libraries. Not everyone updates their dependencies when they build a shareable library. You can sometimes get some pretty old versions of things dragged in with the latest version of otherwise well-written libraries. Exclusions need to be added to get what you want in your artifacts. Ron On 07/02/2014 9:21 AM, Reto Hablützel wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or
Re: maven-ear-plugin silently overrides libraries
I confirm that the use case you mention is supposed to work transparently. This most likely looks like a bug. Thanks for reporting this. S. On Fri, Feb 7, 2014 at 3:21 PM, Reto Hablützel ret...@rethab.ch wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto
