Re: surefire plugin output changes
3.0.3 defaulted to surefire 2.7.2 if you did not specify a version
3.0.4 and 3.0.5 default to surefire 2.10
3.1.1 defaults surefire to 2.12.4
HTH
On 28 January 2014 00:52, John Dix wrote:
> I should point out that I have run 3.0.3 against the build in question and
> I still received the same non-verbose output they are complaining about. At
> a loss at what to tell them other than a shoulder shrug and "idunno" I
> thought I would ask here to see if there was a change somewhere that could
> account for this.
>
> -Original Message-
> From: John Dix
> Sent: Monday, January 27, 2014 4:35 PM
> To: Maven Users List
> Subject: surefire plugin output changes
>
> Hello all,
>
> We have migrated our maven from version 3.0.3 to 3.0.5 and our developers
> are claiming now that they're not seeing the verbosity in the test outputs
> like they did before.
>
> The only see a synopsis and summary of the number of tests run, failed,
> and which ones failed. Servers are run in a CentOS 5.3 linux environment
> within Jenkins.
>
> I am being told that before this upgrade they had an extremely chatty
> output like below. What they haven't been able to confirm for me is whether
> this change happened after we moved from 2.1.0 to 3.0.3 or not as that was
> before my time.
>
> Can anyone please confirm if this output was/is handled by surefire and
> maybe a commandline switch in maven got lost, or from somewhere else? The
> output as from an old archived log the developer gave me.
>
>
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Connected to Mission Control Server on :: myWar from getWarUrl =
> mobilePaymentsApp-amp_i-SNAPSHOT.war
> objname = ampait/
> ampait-control-1.opsdevna3.amdocsdc.net/5666/com.qpass:Type=Environment
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployAppWartoSelectedsEnv Result={0}:
> {=Successfull Deployment of WAR file: app} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployAppWar: Time Spent 2 min 24 secs 324 ms myWar from
> getWarUrl = mobilePaymentExtractsApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployExtractsWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of WAR
> file: extractsApp} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployExtractsWar: Time Spent 1 min 23 secs 14 ms myWar from
> getWarUrl = nxtcomSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployNxtSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of WAR
> file: nxtcomServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployNxtSampleWar: Time Spent 47 secs 410 ms myWar from
> getWarUrl = zmobileSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployZmobileSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of WAR
> file: zmobileServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployZmobileSampleWar: Time Spent 31 secs 400 ms myWar from
> getWarUrl = mobilePaymentsWebServiceApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployWebServiceApp Result={0}:
> {ampait-front-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of WAR
> file: ROOT} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployBackWarToSelectedEnv: Time Spent 1 min 33 secs 791 ms
> myWar from getWarUrl = paymentsReportingUiApplication-amp_i-SNAPSHOT.war
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may review at
> http://www.amdocs.com/email_disclaimer.asp
>
> -
> 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
>
>
Maven 3.1.1. and Windows 8
Hello, I am trying to execute Maven on Windows 8.1 Pro. When I try to run it, I got a Windows message notifying that I cannot run the application on my PC. I tried a couple of versions, including the latest stable. Is there anyone encountering the same issue? Thanks, Manuel
Re: Maven 3.1.1. and Windows 8
> I am trying to execute Maven on Windows 8.1 Pro. When I try to run it, I > got a Windows message notifying that I cannot run the application on my PC. Are you an "experienced" Maven user who is moving to Win 8.1 Pro, or a new user of Win 8.1 Pro who is also new to Maven? This answer may help us zero-in on the problem a little bit. I've never used Win 8.1 Pro so I have no idea what might be wrong. Can you grab a screenshot of the error message and post it online somewhere? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1.1. and Windows 8
I'm not that "experienced" with Maven, but I just tried to run the .bat file (both via console and via double-click) and it didn't work. I have just moved to Win 8.1 and I have already configured the environment variables correctly (I guess). The error I get is something like this http://i.stack.imgur.com/q4LZ9.png Thanks, Manuel *Manuel Mastrofini* *Sistemi e Processi, Direttore di Divisione* www.infoone.it *Sede operativa*: Via Vicinale dei Colli 22, 00040 Rocca di Papa (RM) *Contatto diretto: +39 328 88 95 334* On Tue, Jan 28, 2014 at 3:19 PM, Wayne Fay wrote: > > I am trying to execute Maven on Windows 8.1 Pro. When I try to run it, I > > got a Windows message notifying that I cannot run the application on my > PC. > > Are you an "experienced" Maven user who is moving to Win 8.1 Pro, or a > new user of Win 8.1 Pro who is also new to Maven? This answer may help > us zero-in on the problem a little bit. > > I've never used Win 8.1 Pro so I have no idea what might be wrong. Can > you grab a screenshot of the error message and post it online > somewhere? > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
RE: surefire plugin output changes
Do you know which version Maven 2.1.0 had?
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Tuesday, January 28, 2014 12:56 AM
To: Maven Users List
Subject: Re: surefire plugin output changes
3.0.3 defaulted to surefire 2.7.2 if you did not specify a version
3.0.4 and 3.0.5 default to surefire 2.10
3.1.1 defaults surefire to 2.12.4
HTH
On 28 January 2014 00:52, John Dix wrote:
> I should point out that I have run 3.0.3 against the build in question
> and I still received the same non-verbose output they are complaining
> about. At a loss at what to tell them other than a shoulder shrug and
> "idunno" I thought I would ask here to see if there was a change
> somewhere that could account for this.
>
> -Original Message-
> From: John Dix
> Sent: Monday, January 27, 2014 4:35 PM
> To: Maven Users List
> Subject: surefire plugin output changes
>
> Hello all,
>
> We have migrated our maven from version 3.0.3 to 3.0.5 and our
> developers are claiming now that they're not seeing the verbosity in
> the test outputs like they did before.
>
> The only see a synopsis and summary of the number of tests run,
> failed, and which ones failed. Servers are run in a CentOS 5.3 linux
> environment within Jenkins.
>
> I am being told that before this upgrade they had an extremely chatty
> output like below. What they haven't been able to confirm for me is
> whether this change happened after we moved from 2.1.0 to 3.0.3 or not
> as that was before my time.
>
> Can anyone please confirm if this output was/is handled by surefire
> and maybe a commandline switch in maven got lost, or from somewhere
> else? The output as from an old archived log the developer gave me.
>
>
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Connected to Mission Control Server on :: myWar from
> getWarUrl = mobilePaymentsApp-amp_i-SNAPSHOT.war
> objname = ampait/
> ampait-control-1.opsdevna3.amdocsdc.net/5666/com.qpass:Type=Environmen
> t [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployAppWartoSelectedsEnv Result={0}:
> {=Successfull Deployment of WAR file: app} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployAppWar: Time Spent 2 min 24 secs 324 ms myWar from
> getWarUrl = mobilePaymentExtractsApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployExtractsWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: extractsApp} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployExtractsWar: Time Spent 1 min 23 secs 14 ms myWar
> from getWarUrl = nxtcomSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployNxtSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: nxtcomServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployNxtSampleWar: Time Spent 47 secs 410 ms myWar from
> getWarUrl = zmobileSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployZmobileSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: zmobileServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployZmobileSampleWar: Time Spent 31 secs 400 ms myWar
> from getWarUrl = mobilePaymentsWebServiceApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployWebServiceApp Result={0}:
> {ampait-front-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: ROOT} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployBackWarToSelectedEnv: Time Spent 1 min 33 secs 791
> ms myWar from getWarUrl =
> paymentsReportingUiApplication-amp_i-SNAPSHOT.war
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may
> review at http://www.amdocs.com/email_disclaimer.asp
>
> -
> 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
>
>
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency
I want to use Cobertura for code coverage, but its dependencies are interfering with my XML parsing and Jetty serving. I'm able to resolve most of these by using 's, but Maven is somehow *still* putting one dependency in particular, jetty servlet-api, on the CLASSPATH. pom.xml: ... net.sourceforge.cobertura cobertura 2.0.3 org.mortbay.jetty servlet-api ... As confirmed by `mvn dependency:tree`, cobertura is still bringing jetty's servlet-api onto the CLASSPATH. Am I doing something wrong? -- Cheers, Andrew Pennebaker apenneba...@42six.com
RE: surefire plugin output changes
I got it... 2.16
-Original Message-
From: John Dix
Sent: Tuesday, January 28, 2014 9:45 AM
To: Maven Users List
Subject: RE: surefire plugin output changes
Do you know which version Maven 2.1.0 had?
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Tuesday, January 28, 2014 12:56 AM
To: Maven Users List
Subject: Re: surefire plugin output changes
3.0.3 defaulted to surefire 2.7.2 if you did not specify a version
3.0.4 and 3.0.5 default to surefire 2.10
3.1.1 defaults surefire to 2.12.4
HTH
On 28 January 2014 00:52, John Dix wrote:
> I should point out that I have run 3.0.3 against the build in question
> and I still received the same non-verbose output they are complaining
> about. At a loss at what to tell them other than a shoulder shrug and
> "idunno" I thought I would ask here to see if there was a change
> somewhere that could account for this.
>
> -Original Message-
> From: John Dix
> Sent: Monday, January 27, 2014 4:35 PM
> To: Maven Users List
> Subject: surefire plugin output changes
>
> Hello all,
>
> We have migrated our maven from version 3.0.3 to 3.0.5 and our
> developers are claiming now that they're not seeing the verbosity in
> the test outputs like they did before.
>
> The only see a synopsis and summary of the number of tests run,
> failed, and which ones failed. Servers are run in a CentOS 5.3 linux
> environment within Jenkins.
>
> I am being told that before this upgrade they had an extremely chatty
> output like below. What they haven't been able to confirm for me is
> whether this change happened after we moved from 2.1.0 to 3.0.3 or not
> as that was before my time.
>
> Can anyone please confirm if this output was/is handled by surefire
> and maybe a commandline switch in maven got lost, or from somewhere
> else? The output as from an old archived log the developer gave me.
>
>
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Connected to Mission Control Server on :: myWar from
> getWarUrl = mobilePaymentsApp-amp_i-SNAPSHOT.war
> objname = ampait/
> ampait-control-1.opsdevna3.amdocsdc.net/5666/com.qpass:Type=Environmen
> t [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployAppWartoSelectedsEnv Result={0}:
> {=Successfull Deployment of WAR file: app} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployAppWar: Time Spent 2 min 24 secs 324 ms myWar from
> getWarUrl = mobilePaymentExtractsApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployExtractsWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: extractsApp} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployExtractsWar: Time Spent 1 min 23 secs 14 ms myWar
> from getWarUrl = nxtcomSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployNxtSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: nxtcomServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployNxtSampleWar: Time Spent 47 secs 410 ms myWar from
> getWarUrl = zmobileSampleApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployZmobileSampleWar Result={0}:
> {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: zmobileServices} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployZmobileSampleWar: Time Spent 31 secs 400 ms myWar
> from getWarUrl = mobilePaymentsWebServiceApp-amp_i-SNAPSHOT.war
> [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test: deployWebServiceApp Result={0}:
> {ampait-front-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> WAR
> file: ROOT} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> Test:deployBackWarToSelectedEnv: Time Spent 1 min 33 secs 791
> ms myWar from getWarUrl =
> paymentsReportingUiApplication-amp_i-SNAPSHOT.war
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may
> review at http://www.amdocs.com/email_disclaimer.asp
>
> -
> 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
>
>
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may review at
http://www.amdocs.com/email_disclaimer.asp
-
To unsubscribe, e-mail: u
Re: surefire plugin output changes
No, that's the latest version of maven-surefire-plugin.
Run mvn help:effective-pom from a pom.xml in your project and look for the
stanza that concerns the maven-surefire-plugin and that will tell you for
sure.
Best,
Laird
On Tue, Jan 28, 2014 at 10:06 AM, John Dix wrote:
> I got it... 2.16
>
> -Original Message-
> From: John Dix
> Sent: Tuesday, January 28, 2014 9:45 AM
> To: Maven Users List
> Subject: RE: surefire plugin output changes
>
> Do you know which version Maven 2.1.0 had?
>
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Tuesday, January 28, 2014 12:56 AM
> To: Maven Users List
> Subject: Re: surefire plugin output changes
>
> 3.0.3 defaulted to surefire 2.7.2 if you did not specify a version
>
> 3.0.4 and 3.0.5 default to surefire 2.10
>
> 3.1.1 defaults surefire to 2.12.4
>
> HTH
>
>
> On 28 January 2014 00:52, John Dix wrote:
>
> > I should point out that I have run 3.0.3 against the build in question
> > and I still received the same non-verbose output they are complaining
> > about. At a loss at what to tell them other than a shoulder shrug and
> > "idunno" I thought I would ask here to see if there was a change
> > somewhere that could account for this.
> >
> > -Original Message-
> > From: John Dix
> > Sent: Monday, January 27, 2014 4:35 PM
> > To: Maven Users List
> > Subject: surefire plugin output changes
> >
> > Hello all,
> >
> > We have migrated our maven from version 3.0.3 to 3.0.5 and our
> > developers are claiming now that they're not seeing the verbosity in
> > the test outputs like they did before.
> >
> > The only see a synopsis and summary of the number of tests run,
> > failed, and which ones failed. Servers are run in a CentOS 5.3 linux
> > environment within Jenkins.
> >
> > I am being told that before this upgrade they had an extremely chatty
> > output like below. What they haven't been able to confirm for me is
> > whether this change happened after we moved from 2.1.0 to 3.0.3 or not
> > as that was before my time.
> >
> > Can anyone please confirm if this output was/is handled by surefire
> > and maybe a commandline switch in maven got lost, or from somewhere
> > else? The output as from an old archived log the developer gave me.
> >
> >
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Connected to Mission Control Server on :: myWar from
> > getWarUrl = mobilePaymentsApp-amp_i-SNAPSHOT.war
> > objname = ampait/
> > ampait-control-1.opsdevna3.amdocsdc.net/5666/com.qpass:Type=Environmen
> > t [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployAppWartoSelectedsEnv Result={0}:
> > {=Successfull Deployment of WAR file: app} [INFO ]:
> > com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployAppWar: Time Spent 2 min 24 secs 324 ms myWar from
> > getWarUrl = mobilePaymentExtractsApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployExtractsWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: extractsApp} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployExtractsWar: Time Spent 1 min 23 secs 14 ms myWar
> > from getWarUrl = nxtcomSampleApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployNxtSampleWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: nxtcomServices} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployNxtSampleWar: Time Spent 47 secs 410 ms myWar from
> > getWarUrl = zmobileSampleApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployZmobileSampleWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: zmobileServices} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployZmobileSampleWar: Time Spent 31 secs 400 ms myWar
> > from getWarUrl = mobilePaymentsWebServiceApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployWebServiceApp Result={0}:
> > {ampait-front-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: ROOT} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployBackWarToSelectedEnv: Time Spent 1 min 33 secs 791
> > ms myWar from getWarUrl =
> > paymentsReportingUiApplication-amp_i-SNAPSHOT.war
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement, you may
> > review at http://www.amdocs.com/email_disclaimer.asp
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> > -
RE: surefire plugin output changes
Thanks laird... I got 2.4.3. Do you know where I can find the release notes for
the various versions to see the list of changes made between then and now?
-Original Message-
From: Laird Nelson [mailto:ljnel...@gmail.com]
Sent: Tuesday, January 28, 2014 10:27 AM
To: Maven Users List
Subject: Re: surefire plugin output changes
No, that's the latest version of maven-surefire-plugin.
Run mvn help:effective-pom from a pom.xml in your project and look for the
stanza that concerns the maven-surefire-plugin and that will tell you for sure.
Best,
Laird
On Tue, Jan 28, 2014 at 10:06 AM, John Dix wrote:
> I got it... 2.16
>
> -Original Message-
> From: John Dix
> Sent: Tuesday, January 28, 2014 9:45 AM
> To: Maven Users List
> Subject: RE: surefire plugin output changes
>
> Do you know which version Maven 2.1.0 had?
>
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Tuesday, January 28, 2014 12:56 AM
> To: Maven Users List
> Subject: Re: surefire plugin output changes
>
> 3.0.3 defaulted to surefire 2.7.2 if you did not specify a version
>
> 3.0.4 and 3.0.5 default to surefire 2.10
>
> 3.1.1 defaults surefire to 2.12.4
>
> HTH
>
>
> On 28 January 2014 00:52, John Dix wrote:
>
> > I should point out that I have run 3.0.3 against the build in
> > question and I still received the same non-verbose output they are
> > complaining about. At a loss at what to tell them other than a
> > shoulder shrug and "idunno" I thought I would ask here to see if
> > there was a change somewhere that could account for this.
> >
> > -Original Message-
> > From: John Dix
> > Sent: Monday, January 27, 2014 4:35 PM
> > To: Maven Users List
> > Subject: surefire plugin output changes
> >
> > Hello all,
> >
> > We have migrated our maven from version 3.0.3 to 3.0.5 and our
> > developers are claiming now that they're not seeing the verbosity in
> > the test outputs like they did before.
> >
> > The only see a synopsis and summary of the number of tests run,
> > failed, and which ones failed. Servers are run in a CentOS 5.3 linux
> > environment within Jenkins.
> >
> > I am being told that before this upgrade they had an extremely
> > chatty output like below. What they haven't been able to confirm for
> > me is whether this change happened after we moved from 2.1.0 to
> > 3.0.3 or not as that was before my time.
> >
> > Can anyone please confirm if this output was/is handled by surefire
> > and maybe a commandline switch in maven got lost, or from somewhere
> > else? The output as from an old archived log the developer gave me.
> >
> >
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Connected to Mission Control Server on :: myWar from
> > getWarUrl = mobilePaymentsApp-amp_i-SNAPSHOT.war
> > objname = ampait/
> > ampait-control-1.opsdevna3.amdocsdc.net/5666/com.qpass:Type=Environm
> > en t [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployAppWartoSelectedsEnv Result={0}:
> > {=Successfull Deployment of WAR file: app} [INFO ]:
> > com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployAppWar: Time Spent 2 min 24 secs 324 ms myWar
> > from getWarUrl = mobilePaymentExtractsApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployExtractsWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: extractsApp} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployExtractsWar: Time Spent 1 min 23 secs 14 ms
> > myWar from getWarUrl = nxtcomSampleApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployNxtSampleWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: nxtcomServices} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployNxtSampleWar: Time Spent 47 secs 410 ms myWar
> > from getWarUrl = zmobileSampleApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployZmobileSampleWar Result={0}:
> > {ampait-back-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment of
> > WAR
> > file: zmobileServices} [INFO ]:
> com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployZmobileSampleWar: Time Spent 31 secs 400 ms
> > myWar from getWarUrl =
> > mobilePaymentsWebServiceApp-amp_i-SNAPSHOT.war
> > [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test: deployWebServiceApp Result={0}:
> > {ampait-front-1.opsdevna3.amdocsdc.net:8999=Successfull Deployment
> > of WAR
> > file: ROOT} [INFO ]: com.qpass.payment.multinodeCloud.DeployTest:
> > Test:deployBackWarToSelectedEnv: Time Spent 1 min 33 secs
> > 791 ms myWar from getWarUrl =
> > paymentsReportingUiApplication-amp_i-SNAPSHOT.war
> >
> > This message and the information contained herein is proprie
Re: surefire plugin output changes
On Tue, Jan 28, 2014 at 11:12 AM, John Dix wrote: > Thanks laird... I got 2.4.3. Do you know where I can find the release > notes for the various versions to see the list of changes made between then > and now? > This is the closest thing I found: http://jira.codehaus.org/browse/SUREFIRE#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel Have fun digging manually. Best, Laird -- http://about.me/lairdnelson
Deployment to Tomcat (provided jars)
I was hoping that someone could either show me best practice or just comment on
the correctness of my approach.
We have multiple projects which run on our app server (tomcat). Therefore, we
want our projects to share as much as possible when it comes to provided
artifacts in order to reduce our war file size - so everyone relies on the same
version of guava for example, which is defined in the dependency management
section of our common-parent pom.
We have configured our app servers to include a 2nd lib folder (call it
"common-lib") - this is where we want to put all of our projects provided
artifacts (after wiping the files in the folder out - hence the separate
"common-lib" folder). Tomcat is setup to include this in its classpath.
For example, our nightly build trigger would rm -f all jar files in the
common-lib folder, then Project1 would build and push all of its provided jars
up to common-lib, followed by Project2, and on, and on. At the end of the build
you have a completely refreshed "common-lib" folder with all of the provided
jars for each project. (Obviously, if this were the "live" common-lib this
might be an issue so we have a "staging" area we actually deploy to - then in
our tomcat startup script we replace the "live" common-lib files with those
from the "staging" area)
Obviously, if we do not keep a tight rein on dependency versions in project
poms this could turn into a nightmare -- but let's assume we can do that.
So here is the approach I am taking:
1. I use the maven-dependency-plugin to copy provided jars into
"${project.build.directory}\provided" - I have tied this to
package
2. I use the maven-antrun-plugin to scp all files in the
"${project.build.directory}\provided" folder up to our "common-lib" folder on
our app server - I have tied this to deploy
I am afraid that maybe our horrible past practices have blinded me from seeing
the Maven best practice, so I am looking for a reality check. To me, this seems
like something that people would need to do all the time - but I can't seem to
find anything that specifically relates to this approach.
Side Note: As I was writing this I kept thinking "why not just deploy our wars
with everything that they need, that would be much cleaner and more
reproducible. We shouldn't care about artifact (war) file size if this happens
in the middle of the night". Here is what I came up with -- we have one jar
file that we build which has all of our hibernate code in it, it also generates
all of our shared connections for all of our contexts (these are shared session
factories). This single artifact *must* be shared - we simply cannot allow each
war file to include its own copy - due to singleton style bootstrap of
connections.
Is it best practice for a war to deploy with all of its dependencies?
Thanks, in advance
scott
__ Information from ESET NOD32 Antivirus, version of virus signature
database 9348 (20140128) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1.1. and Windows 8
> I'm not that "experienced" with Maven, but I just tried to run the .bat > file (both via console and via double-click) and it didn't work. > I have just moved to Win 8.1 and I have already configured the environment > variables correctly (I guess). What does "I guess" mean? Go to a new command line window and type "set" - you should see the variables listed there. (It must be new - once you set variables, already-opened windows do not get the variables, only new windows.) > The error I get is something like this http://i.stack.imgur.com/q4LZ9.png Is your error message "exactly like" this one or just "something like" this one? I would expect it to run with no issues from command line (not just double-clicking the .bat file). What happens from command line when you type "java -version"? What happens when you type "mvn.bat"? I have zero experience with Win 8.1 Pro. Most likely you need to find local IT resources to help resolve your issues, but we'll try to support you here as well. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment to Tomcat (provided jars)
On 1/28/2014 11:34 AM, Scott Klein wrote:
I was hoping that someone could either show me best practice or just
comment on the correctness of my approach.
We have multiple projects which run on our app server (tomcat).
Therefore, we want our projects to share as much as possible when it
comes to provided artifacts in order to reduce our war file size - so
everyone relies on the same version of guava for example, which is
defined in the dependency management section of our common-parent
pom.
We have configured our app servers to include a 2nd lib folder (call
it "common-lib") - this is where we want to put all of our projects
provided artifacts (after wiping the files in the folder out - hence
the separate "common-lib" folder). Tomcat is setup to include this in
its classpath.
For example, our nightly build trigger would rm -f all jar files in
the common-lib folder, then Project1 would build and push all of its
provided jars up to common-lib, followed by Project2, and on, and on.
At the end of the build you have a completely refreshed "common-lib"
folder with all of the provided jars for each project. (Obviously, if
this were the "live" common-lib this might be an issue so we have a
"staging" area we actually deploy to - then in our tomcat startup
script we replace the "live" common-lib files with those from the
"staging" area)
Obviously, if we do not keep a tight rein on dependency versions in
project poms this could turn into a nightmare -- but let's assume we
can do that.
So here is the approach I am taking: 1. I use the
maven-dependency-plugin to copy provided jars into
"${project.build.directory}\provided" - I have tied this to
package
2. I use the maven-antrun-plugin to scp all files in the
"${project.build.directory}\provided" folder up to our "common-lib"
folder on our app server - I have tied this to deploy
I am afraid that maybe our horrible past practices have blinded me
from seeing the Maven best practice, so I am looking for a reality
check. To me, this seems like something that people would need to do
all the time - but I can't seem to find anything that specifically
relates to this approach.
Side Note: As I was writing this I kept thinking "why not just deploy
our wars with everything that they need, that would be much cleaner
and more reproducible. We shouldn't care about artifact (war) file
size if this happens in the middle of the night".
Yes, this is the way to go for a variety of reasons (most of which are
better discussed on the Tomcat mailing list). Run Tomcat 7 (currently
7.0.50), use parallel deployment, the Tomcat Maven plugin, and
deployments should be seamless.
Here is what I came
up with -- we have one jar file that we build which has all of our
hibernate code in it, it also generates all of our shared connections
for all of our contexts (these are shared session factories).
I (think I) know how Hibernate works . . . So you have one JAR that
contains the information for all of your connections? Each context then
gets all of the connections?
I'm not sure I would agree with that practice. So your hibernate.cfg.xml
has configurations for all of your connections? What happens if a
particular web application doesn't need one or more of the connections?
This single artifact *must* be shared - we simply cannot allow each war
file to include its own copy - due to singleton style bootstrap of
connections.
Singletons are isolated per web application. Again, this is more of a
Tomcat question than a Maven one.
Is it best practice for a war to deploy with all of its
dependencies?
Thanks, in advance scott
I'm new to Maven, so take the following with a grain (or two) of salt.
I'm working on creating a rational build environment by doing the following:
1. Examine applications
2. Break up applications into reusable components (WAR, JAR, etc.)
a. components should be as independent as possible
b. reference coupled components as a POM dependency
c. application-specific components belong solely in that application
3. If many projects have the same structure, make an archetype
4. Manage plugins in a parent POM
This all gets shunted off to an internal Nexus for artifact management,
and an internal Jenkins for continuous build, test, and deployment.
I'm not there yet, but we've already seen gains in reproducible builds,
ease of creating new projects, and earlier detection of issues.
. . . just my two cents.
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1.1. and Windows 8
I guest means that my os is in a different language, but most likely the error is the same. Java command works, mvn triggers the Windows error, also via console. It looks to me like a compatibility issue. Il 28/gen/2014 21:13 "Wayne Fay" ha scritto: > > I'm not that "experienced" with Maven, but I just tried to run the .bat > > file (both via console and via double-click) and it didn't work. > > I have just moved to Win 8.1 and I have already configured the > environment > > variables correctly (I guess). > > What does "I guess" mean? Go to a new command line window and type > "set" - you should see the variables listed there. (It must be new - > once you set variables, already-opened windows do not get the > variables, only new windows.) > > > The error I get is something like this > http://i.stack.imgur.com/q4LZ9.png > > Is your error message "exactly like" this one or just "something like" > this one? I would expect it to run with no issues from command line > (not just double-clicking the .bat file). > > What happens from command line when you type "java -version"? > What happens when you type "mvn.bat"? > > I have zero experience with Win 8.1 Pro. Most likely you need to find > local IT resources to help resolve your issues, but we'll try to > support you here as well. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven 3.1.1. and Windows 8
> Java command works, mvn triggers the Windows error, also via console. It > looks to me like a compatibility issue. The batch file is just a shell script that automatically runs a series of commands. Open the mvn.bat file in Notepad. Copy and paste the contents one line at a time into the command line. It will break on a specific line. Tell us which line breaks. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1.1. and Windows 8
Or type the following: set MAVEN_BATCH_ECHO=on mvn -v Now you'll see every executed line. It would be nice if you could return the failing line(s). One possibility is that Windows 8 is not recognized. Robert Op Tue, 28 Jan 2014 21:52:36 +0100 schreef Wayne Fay : Java command works, mvn triggers the Windows error, also via console. It looks to me like a compatibility issue. The batch file is just a shell script that automatically runs a series of commands. Open the mvn.bat file in Notepad. Copy and paste the contents one line at a time into the command line. It will break on a specific line. Tell us which line breaks. Wayne - 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 3.1.1. and Windows 8
Thanks Robert! Learn something new every day... I agree it is fairly likely that we simply do not "expect" Win8 thus some additional configuration or modification is necessary to permit Maven to run. Wayne On Tue, Jan 28, 2014 at 3:02 PM, Robert Scholte wrote: > Or type the following: > > set MAVEN_BATCH_ECHO=on > mvn -v > > Now you'll see every executed line. It would be nice if you could return the > failing line(s). > One possibility is that Windows 8 is not recognized. > > Robert > > Op Tue, 28 Jan 2014 21:52:36 +0100 schreef Wayne Fay : > >>> Java command works, mvn triggers the Windows error, also via console. It >>> looks to me like a compatibility issue. >> >> >> The batch file is just a shell script that automatically runs a series >> of commands. >> >> Open the mvn.bat file in Notepad. >> Copy and paste the contents one line at a time into the command line. >> It will break on a specific line. >> Tell us which line breaks. >> >> Wayne >> >> - >> 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 > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
cobertura & maven
Hi, I search how to solve all the ERROR and WARNING of may maven execution (see attached file toto.txt and extract of POM) => I launch "mvn clean site" I don’t find any topic with solution on forums. It's cobertura and com.sun.tools uses problems. Thanks for your help. Regards pom.xml Description: XML document [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building subproject0 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ subproject0 --- [INFO] Deleting C:\Eclipse\K2\W\subproject0\target [INFO] [INFO] --- maven-site-plugin:3.3:site (default-site) @ subproject0 --- [INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.7 [INFO] configuring report plugin org.codehaus.mojo:cobertura-maven-plugin:2.6 [INFO] [INFO] >>> cobertura-maven-plugin:2.6:cobertura (report:cobertura) @ subproject0 >>> [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ subproject0 --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory C:\Eclipse\K2\W\subproject0\src\main\resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ subproject0 --- [INFO] Compiling 1 source file to C:\Eclipse\K2\W\subproject0\target\classes [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument (report:cobertura) @ subproject0 --- [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] janv. 28, 2014 12:14:27 PM net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler saveCoverageData Infos: Cobertura: Saved information on 1 classes. [INFO] Instrumentation was successful. [INFO] NOT adding cobertura ser file to attached artifacts list. [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ subproject0 --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory C:\Eclipse\K2\W\subproject0\src\test\resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ subproject0 --- [INFO] Compiling 4 source files to C:\Eclipse\K2\W\subproject0\target\test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ subproject0 --- [INFO] Surefire report directory: C:\Eclipse\K2\W\subproject0\target\surefire-reports --- T E S T S --- Running project.AppAUTOTest Hello World! Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec Running project.AppTest Hello World! Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running project.AppUTest Hello World! Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Results : Tests run: 19, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] <<< cobertura-maven-plugin:2.6:cobertura (report:cobertura) @ subproject0 <<< [INFO] Relativizing decoration links with respect to project URL: http://maven.apache.org [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 skin. [INFO] Generating "Dependencies" report--- maven-project-info-reports-plugin:2.7 [WARNING] Unable to process class com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer File d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 60 at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146) at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67) at org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222) at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136) at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92) at org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1454) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:536) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:263) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186) at org.apache.maven.reporting.AbstractMavenReport.generate(A
Re: Maven 3.1.1. and Windows 8
Thank you for your contribution. The failing line is: .shared.domain."C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe" -classpath "D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar" "-Dclassworlds.conf=D:\apache-maven-3.1.1\bin\..\bin\m2.conf" "-Dmaven.home=D:\apache-maven-3.1.1\bin\.." org.codehaus.plexus.classworlds.launcher.Launcher -v It is immediately after .shared.domain.set CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher Manuel *Manuel Mastrofini* *Sistemi e Processi, Direttore di Divisione* www.infoone.it *Sede operativa*: Via Vicinale dei Colli 22, 00040 Rocca di Papa (RM) *Contatto diretto: +39 328 88 95 334* On Tue, Jan 28, 2014 at 10:19 PM, Wayne Fay wrote: > Thanks Robert! Learn something new every day... > > I agree it is fairly likely that we simply do not "expect" Win8 thus > some additional configuration or modification is necessary to permit > Maven to run. > > Wayne > > On Tue, Jan 28, 2014 at 3:02 PM, Robert Scholte > wrote: > > Or type the following: > > > > set MAVEN_BATCH_ECHO=on > > mvn -v > > > > Now you'll see every executed line. It would be nice if you could return > the > > failing line(s). > > One possibility is that Windows 8 is not recognized. > > > > Robert > > > > Op Tue, 28 Jan 2014 21:52:36 +0100 schreef Wayne Fay >: > > > >>> Java command works, mvn triggers the Windows error, also via console. > It > >>> looks to me like a compatibility issue. > >> > >> > >> The batch file is just a shell script that automatically runs a series > >> of commands. > >> > >> Open the mvn.bat file in Notepad. > >> Copy and paste the contents one line at a time into the command line. > >> It will break on a specific line. > >> Tell us which line breaks. > >> > >> Wayne > >> > >> - > >> 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 > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: cobertura & maven
> I search how to solve all the ERROR and WARNING of may maven execution (see > attached file toto.txt and extract of POM) ... > It's cobertura and com.sun.tools uses problems. [WARNING] Unable to process class com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer File d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 60 at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146) at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67) at org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222) at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136) at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92) at org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255) Looks like there is a problem with a class file in the icu4j-2.6.1.jar file. Is there a newer version (2.6.2) available? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: cobertura & maven
Search engines are your friend: http://jira.codehaus.org/browse/MPIR-142 -- Alexander Kriegisch Am 28.01.2014 um 22:59 schrieb Wayne Fay : >> I search how to solve all the ERROR and WARNING of may maven execution (see >> attached file toto.txt and extract of POM) > ... >> It's cobertura and com.sun.tools uses problems. > > [WARNING] Unable to process class > com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer > File > d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar > org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in > constant pool: 60 > at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146) > at org.apache.bcel.classfile.ConstantPool.(ConstantPool.java:67) > at > org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222) > at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136) > at > org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92) > at > org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255) > > Looks like there is a problem with a class file in the icu4j-2.6.1.jar > file. Is there a newer version (2.6.2) available? > > Wayne > > - > 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 3.1.1. and Windows 8
On 29 January 2014 08:26, Manuel Mastrofini wrote: > Thank you for your contribution. > > The failing line is: > > .shared.domain."C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe" > -classpath > "D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar" > "-Dclassworlds.conf=D:\apache-maven-3.1.1\bin\..\bin\m2.conf" > "-Dmaven.home=D:\apache-maven-3.1.1\bin\.." > org.codehaus.plexus.classworlds.launcher.Launcher -v > > It is immediately after .shared.domain.set > CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher > > Manuel Manuel, it is very difficult to help you trouble shoot because you are not providing enough information. Wayne has tried to coax this information out of you but you have not answered all his questions, and when you do you will need to paste in the results from the computer rather than paraphrasing as we need the actual error messages/debug information to learn more. Have a look at http://www.catb.org/~esr/faqs/smart-questions.html in general, and specifically the "Be precise and informative about your problem" section. Go through the emails again and make sure you have answered Wayne's questions and provided enough details in the answers and we will probably have more luck in helping you out. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1.1. and Windows 8
I believe I answered all relevant questions. I'm going through all of them
again to make a synthesis of my answers. Furthermore, I'm going to report
the entire output of mvn -v.
> Are you an "experienced" Maven user who is moving to Win 8.1 Pro, or a
new user of Win 8.1 Pro who is also new to Maven?
Semi-experienced in both: I understand what I do.
> Can you grab a screenshot of the error message and post it online
somewhere?
http://i.stack.imgur.com/q4LZ9.png
> java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)
> What happens when you type "mvn.bat"?
Windows error as above
After mvn -n and setting the environment variable, this is the output
("Access denied" is the error).
if "" == "" (set "HOME=" )
if not "" == "" goto skipRcPre
if exist "\mavenrc_pre.bat" call
"\mavenrc_pre.bat"
set ERROR_CODE=0
if "Windows_NT" == "Windows_NT"
if "Windows_NT" == "WINNT"
if not "C:\Program Files (x86)\Java\jdk1.7.0_45" == "" goto OkJHome
if exist "C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe"
goto chkMHome
if not "" == "" goto valMHome
if "Windows_NT" == "Windows_NT" SET "M2_HOME=D:\apache-maven-3.1.1\bin\.."
if "Windows_NT" == "WINNT" SET "M2_HOME=D:\apache-maven-3.1.1\bin\.."
if not "D:\apache-maven-3.1.1\bin\.." == "" goto valMHome
if not "_." == "_\" goto checkMBat
if exist "D:\apache-maven-3.1.1\bin\..\bin\mvn.bat" goto init
if "Windows_NT" == "WINNT" goto WinNTNovell
if NOT "Windows_NT" == "Windows_NT" goto Win9xArg
if "@eval[2+2]" == "4" goto 4NTArgs
set MAVEN_CMD_LINE_ARGS=-v
goto endInit
SET MAVEN_JAVA_EXE="C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe"
if "@eval[2+2]" == "4" goto 4NTCWJars
for %i in ("D:\apache-maven-3.1.1\bin\.."\boot\plexus-classworlds-*) do set
CLASSWORLDS_JAR="%i"
set
CLASSWORLDS_JAR="D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar"
goto runm2
set CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher
"C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe" -classpath
"D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar"
"-Dclassworlds.conf=D:\apache-maven-3.1.1\bin\..\bin\m2.conf"
"-Dmaven.home=D:\apache-maven-3.1.1\bin\.."
org.codehaus.plexus.classworlds.launcher.Launcher -v
Access denied.
if ERRORLEVEL 1 goto error
if "Windows_NT" == "Windows_NT"
if "Windows_NT" == "WINNT"
set ERROR_CODE=1
if "Windows_NT" == "Windows_NT" goto endNT
if not "" == "" goto skipRcPost
if exist "\mavenrc_post.bat" call
"\mavenrc_post.bat"
if "" == "on" pause
if "" == "on" exit 1
cmd /C exit /B 1
*Manuel Mastrofini*
*Sistemi e Processi, Direttore di Divisione*
www.infoone.it
*Sede operativa*: Via Vicinale dei Colli 22, 00040 Rocca di Papa (RM)
*Contatto diretto: +39 328 88 95 334 <%2B39%20328%2088%2095%20334>*
On Tue, Jan 28, 2014 at 11:17 PM, Barrie Treloar wrote:
> On 29 January 2014 08:26, Manuel Mastrofini
> wrote:
> > Thank you for your contribution.
> >
> > The failing line is:
> >
> > .shared.domain."C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe"
> > -classpath
> > "D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar"
> > "-Dclassworlds.conf=D:\apache-maven-3.1.1\bin\..\bin\m2.conf"
> > "-Dmaven.home=D:\apache-maven-3.1.1\bin\.."
> > org.codehaus.plexus.classworlds.launcher.Launcher -v
> >
> > It is immediately after .shared.domain.set
> > CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher
> >
> > Manuel
>
> Manuel, it is very difficult to help you trouble shoot because you are
> not providing enough information.
> Wayne has tried to coax this information out of you but you have not
> answered all his questions, and when you do you will need to paste in
> the results from the computer rather than paraphrasing as we need the
> actual error messages/debug information to learn more.
>
> Have a look at http://www.catb.org/~esr/faqs/smart-questions.html in
> general, and specifically the "Be precise and informative about your
> problem" section.
>
> Go through the emails again and make sure you have answered Wayne's
> questions and provided enough details in the answers and we will
> probably have more luck in helping you out.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
dependency plugin strangeness
So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said "Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop" (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deployment to Tomcat (provided jars)
http://blog.artifact-software.com/tech/?tag=maven
This will get you to a series of articles on how we addressed some of
the issues that you are raising.
Tomcat 7 has made some changes to make this easier but I have not tried
to document how we are using this yet.
Ron
On 28/01/2014 2:34 PM, Scott Klein wrote:
I was hoping that someone could either show me best practice or just comment on
the correctness of my approach.
We have multiple projects which run on our app server (tomcat). Therefore, we
want our projects to share as much as possible when it comes to provided
artifacts in order to reduce our war file size - so everyone relies on the same
version of guava for example, which is defined in the dependency management
section of our common-parent pom.
We have configured our app servers to include a 2nd lib folder (call it "common-lib") -
this is where we want to put all of our projects provided artifacts (after wiping the files in the
folder out - hence the separate "common-lib" folder). Tomcat is setup to include this in
its classpath.
For example, our nightly build trigger would rm -f all jar files in the common-lib folder, then Project1 would build and push all
of its provided jars up to common-lib, followed by Project2, and on, and on. At the end of the build you have a completely
refreshed "common-lib" folder with all of the provided jars for each project. (Obviously, if this were the
"live" common-lib this might be an issue so we have a "staging" area we actually deploy to - then in our
tomcat startup script we replace the "live" common-lib files with those from the "staging" area)
Obviously, if we do not keep a tight rein on dependency versions in project
poms this could turn into a nightmare -- but let's assume we can do that.
So here is the approach I am taking:
1. I use the maven-dependency-plugin to copy provided jars into
"${project.build.directory}\provided" - I have tied this to
package
2. I use the maven-antrun-plugin to scp all files in the "${project.build.directory}\provided" folder
up to our "common-lib" folder on our app server - I have tied this to deploy
I am afraid that maybe our horrible past practices have blinded me from seeing
the Maven best practice, so I am looking for a reality check. To me, this seems
like something that people would need to do all the time - but I can't seem to
find anything that specifically relates to this approach.
Side Note: As I was writing this I kept thinking "why not just deploy our wars with
everything that they need, that would be much cleaner and more reproducible. We shouldn't
care about artifact (war) file size if this happens in the middle of the night".
Here is what I came up with -- we have one jar file that we build which has all of our
hibernate code in it, it also generates all of our shared connections for all of our
contexts (these are shared session factories). This single artifact *must* be shared - we
simply cannot allow each war file to include its own copy - due to singleton style
bootstrap of connections.
Is it best practice for a war to deploy with all of its dependencies?
Thanks, in advance
scott
__ Information from ESET NOD32 Antivirus, version of virus signature
database 9348 (20140128) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
-
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: Renaming site.xml or using different top-level site.xml for site plugin
ok defining profiles to have 2 site runs without same reporting plugins is ok: the 2 site runs share the same site.xml what would be an issue would be to require 2 different site.xml files. But from your description, you don't need such thing, no? Regards, Hervé Le lundi 27 janvier 2014 20:35:00 Benjamin Damm a écrit : > Thanks to you and Mr. Boutemy for your replies. Let me explain a little > more about what I want to do. > > We have perhaps two dozen maven modules that together provide a collection > of core services. Together these modules are an SDK of sorts for clients. > I'm trying to create a structure for generated documentation; however > JavaDoc alone is not enough since we have other artifacts that make up our > SDK. Protobuf definitions, WSDL files, REST services, etc. So, if an > effort to create reliable documentation is going to produce good results, > we need a mechanism that can be shared across all these modules and a model > for how to aggregate the resulting documentation back into one SDK. > > The maven site plugin seems like the perfect structure to base this effort. > We can take advantage of the maven build cycle and the parent pom > structure, we can use skins to create a consistent look and feel, and we > can use existing and new plugins (e.g. JavaDoc and others) to produce > "site" artifacts from source. Controlling the inherited site definition > gives us a relatively easy way to cross-link module output. > > However, the "site" defaults and related plugins also are useful, so I want > to retain the ability to generate classic "site" output (e.g. test reports, > code coverage, javadoc, findbugs). This output is not appropriate for > distribution, but it's very useful for us internally. Hence, my > investigation of using profiles. I started by redefining the site plugin's > configuration in the parent pom within two profiles, so that all the > sub-modules got access to those profiles without defining them > individually. > > If this is a maven anti-pattern, then I certainly hear that and respect > that. I wonder what other options are available? Any ideas? > > Thanks, > -Ben > > -- > Benjamin Damm > Silver Spring Networks > +1-650-839-4201 > > From: Stephen Connolly [stephen.alan.conno...@gmail.com] > Sent: Sunday, January 26, 2014 11:37 AM > To: Maven Users List > Subject: Re: Renaming site.xml or using different top-level site.xml for > site plugin > > In a multimodule project you need to attach the site descriptor of parent > poms to the reactor. > > Thus the site descriptor you attach will depend on your profile... > > Thus you are in a maven anti-pattern (ie artifacts attached to the reactor > should not depend on the profiles active at the time) > > You will likely have to find a different way, as I believe the rest if the > maven developers will agree with me that this is a bad plan, and hence > there will not be support for trying to solve your actual problem with the > technique that us giving you thus problem > > HTH > > Stephen > > On Friday, 24 January 2014, Benjamin Damm wrote: > > Hello Mavens, > > > > Is there a way to rename site.xml to something else? I want to use the > > site framework to produce two "trees" of sites, each quite distinct from > > each other because they are based on two different profiles, and I was > > hoping, two different site.xml from the superpom at the top. > > > > In other words, I'm trying to achieve two trees of sites, each with a > > different site.xml at the top, but otherwise retaining the same structure > > (in terms of modules). I also plan to use profiles to use different > > site.xml files at the module level; that part works fine already because I > > can repoint the entire site document structure by using siteDirectory. > > > > It's the site.xml at the very top that's giving me trouble. No matter > > what I seem to do, I can only have one site.xml at the top of the module > > hierarchy. Does anyone know if there's a way around this limitation? > > > > Scouring the source code of the site plugin has so far not revealed > > > > anything. > > > > Thank you, > > -Ben > > > > -- > > Benjamin Damm > > Silver Spring Networks > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > -- > Sent from my phone > - > 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: dependency plugin strangeness
Hi Roy, Can you use a bisect-style debugging approach? Remove half of the modules from the build and run dependency:tree again. If it works, add half back in again; if not, remove half of what remains. Etc. Then at least you might isolate the problem a bit more. It also might make it easier to create a minimal test case for bug reporting purposes. Regards, Curtis On Jan 28, 2014 4:56 PM, "Lyons, Roy" wrote: > So, I tried my google-fu first - and in general my google-fu is very very > strong... > > I've been fighting with this multi-module plan for some time now with the > developer who is reporting the issue to me. The issue manifested itself as > part of a Sonar failure... the funny thing is, that the failure was on a > dependenct tree resolution that Sonar was doing - so I had him try the > dependency plugin and perform a dependency:tree > > dependency tree failed us... well, it probably isn't dependency plugin's > fault but I am at a loss as to what it is really dying on or why. > > I would absolutely love it if someone saw this and said "Oh yeah, I know > that issue. Its a real pain. They have XXX defined incorrectly in their > multimodule build so the dependency plugin is in a circular dependency > loop" (or something like that). I have no idea if its a dependency loop, > was just an example. > > I can't share the poms because its all proprietary closed source stuff > (and I have to be careful about what is shared). If this means that I dont > have enough info to help, I can live with that - and will continue to plow > forwards... I just wanted to see if theres someone on the list who knows > exactly what I should be looking for to help shorten my investigation time. > > Here's an example of what dependency:tree is complaining about. > > > mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X > > urls[38] = > file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar > Number of foreign imports: 1 > import: Entry[import from realm ClassRealm[maven.api, parent: null]] > - > > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.PluginContainerException: An API > incompatibility was encountered while executing > org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: > java.lang.AbstractMethodError: > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
