Archetype Catalog Question

[KevinO]

Quick question:

What is the difference between a 'local' catalog and an 'internal' catalog?

Thanks,

Kevin

Query on increasing virtual memory for java heap size issue

[Saisowjanya N]

Dear All
I am facing java heap space issue.I want increase the heap size using vm 
arguments through maven.

When searched in internet I found a solution that says to define 
${maven.projectBasedir}/.mvn/extensions.xml in our project

Could you please help on how to define the file 
${maven.projectBasedir}/.mvn/extensions.xml in our project 



Thanks and Regards,
N.Sai Sowjanya 
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Skip deploy of test-jars?

[Robert Scholte]

of the 2 option 1 is the cleanest: at least you don't make don't go  
outside of you project like you do with option 2. But it comes with too  
much overhead.


I would go for option 3: write a Maven plugin:
use MavenSession.getProjects() to find the specific instance(s) from which  
you want to copy the sources.

AFAIK there's no such plugin available yet.

thanks,
Robert

On Tue, 30 Jan 2018 09:12:01 +0100, Christofer Dutz  
 wrote:


Regarding the number of kittens being hurt in both ways ... which one  
would you guys see the one with more happy kittens?


1) Use the test-jar and unpack it
2) Copy classes from a location outside the module (but relative to the  
current module)


Chris



Am 29.01.18, 22:41 schrieb "Christofer Dutz"  
:


Hi Robert,
   Well in that case I would copy resources from one module to another  
using relative paths which point outside the module itself.
That doesn't sound ideal either. At least I always try to avoid  
accessing things this way cause I have burnt myself too often when doing  
it.
   With the "test-jar unpacking" one module only consumes maven  
artifacts another project created.

   Chris
   Am 29.01.18, 18:47 schrieb "Robert Scholte" :
   This makes me wonder: is the pack/unpack already hackish?
Wouldn't it be nicer to simply copy the content from  
target/classes +

target/test-classes?
With a Maven plugin is it quite simple to access this as part of  
the

reactor.
   thanks,
Robert
   On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz
 wrote:
   > Hi all,
>
> in the Apache Edgent (incubating) project we are producing  
java 8 and
> java 7 compatible jars by using the retrolambda-maven-plugin.  
The Java 7
> versions are just a convenience byproduct for us. In order to  
do this,
> we create the jar as well as the test-jars for each module and  
hava
> separate java 7 modules where no code is compiled, but instead  
in the
> compile phase we unpack the jar and in the compile-test phase  
we unpack

> the test-jar of the matching Java 8 module. After unpacking the
> retrolambda plugin is executed and it generates the Java 7  
versions.
> From then on the converted class files are used to run the  
tests and

> create the java 7 jars.
>
> A little inconvenience of this approach is, that all test-jars  
are also
> published to nexus. We do need them to be installed in the  
local repo,
> but there is generally no point in deploying them to  
Maven-Central.
> While I have no big deals with this, some in the project would  
like to

> remove those test-jars from deployment.
>
> Is there any way to do this by usual configuration? Right now  
we are
> thinking of using the Nexus REST interface to programmatically  
strip
> them form the staging repo prior to closing it, but this all  
feels like

> a huge hack.
>
> Do you have any advice how to do this or some good reasons not  
to do it?

>
> Chris
   -
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


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Exec Maven Plugin

[Sandra Parsick]

Hi,

I'd recommend you to use the fronend-maven-plugin [1] for your use case.
This plugin installs and configures npm for you, so your build is
regardless of external tools.


Best regards,

Sandra

[1]https://github.com/eirslett/frontend-maven-plugin




Am 29.01.2018 um 22:02 schrieb yossi balan:
> Hi
> 
> I tried to use the plugin and run npm install from java application
> 
> 
> org.codehaus.mojo
> exec-maven-plugin
> 1.6.0
> 
> 
> 
> npm install (initialize)
> 
> exec
> 
> initialize
> 
> npm
> ${project.basedir}/../
> 
> install
> 
> 
> 
> 
> 
> 
> when I run mvn build I got error
> 
> [INFO] --- exec-maven-plugin:1.6.0:exec (npm install mynpm) @ srv ---
> 10:37:31 PM  npm ERR! ...'
> 
> npm ERR! A complete log of this run can be found in:
> npm ERR!
>  
> /home/vcap/app/META-INF/cache/8.9.1/.npm/_logs/2018-01-29T20_37_30_159Z-debug.log
> [ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1
> (Exit value: 1)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:804)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:751)
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:313)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 
> I tried also to ladd .npmrc but it look like it didn't consider this file
> Could you please advise me ?
> 



signature.asc
Description: OpenPGP digital signature

RE: Exec Maven Plugin

[Yaron Golan]

From a first glance, It doesn't look like a maven nor the plugin issue.
Please try to :
1. Run the NPM command from command line
2. Run a script (sh/batch) instead the NPM command.
In the script, you can set your proxy, NPM proxy, NPM registry and etc.


Yaron Golan
CI/CD, ALM Team 
AT Network Applications Development · SD  
Tel Aviv | Tampa | Atlanta | New Jersey |Chicago
···
Office: +972 (3) 976 5938
Mobile: +972 (54) 248 4460
e-mail:  yaron.go...@att.com



Hi

I tried to use the plugin and run npm install from java application


org.codehaus.mojo
exec-maven-plugin
1.6.0

  
npm install (initialize)  exec  
initialize  npm 
${project.basedir}/../

install






when I run mvn build I got error

[INFO] --- exec-maven-plugin:1.6.0:exec (npm install mynpm) @ srv ---
10:37:31 PM  npm ERR! ...'

npm ERR! A complete log of this run can be found in:
npm ERR!
 
/home/vcap/app/META-INF/cache/8.9.1/.npm/_logs/2018-01-29T20_37_30_159Z-debug.log
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit 
value: 1) at
org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:313)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

I tried also to ladd .npmrc but it look like it didn't consider this file Could 
you please advise me ?

jacoco-maven-plugin site generation question

[David Hoffer]

I am using jacoco-maven-plugin v0.8.0 to generate test code coverage
reports (and checks) to the build. This is working fine for normal dev
builds, e.g. mvn clean install.

However we also need to include these reports in the Maven site that is
generated and published that part is not working.

The build is a multi-module build and I see you have a link to some ways of
creating an aggregated report, https://github.com/jacoco/
jacoco/wiki/MavenMultiModule, however I am not to the part yet. Right now
I'm just trying to get it to publish the individual reports in the site
build.

The problem is that the site build is including JaCoCo but its labeled
as JaCoCo
Aggregate on each of the modules (and parent) and each of these point to
'target/site/jacoco-aggregate/index.html' however that folder does not
exist. The actual generated report is at target/site/jacoco-ut/index.html.

How can I configure JaCoCo so that it reports the correct name and location
for each report? I have tried various configuration options in the
reporting section but to no avail. It seems hard coded to use
ReportAggregateMojo when it should use ReportMojo (and optionally
ReportITMojo) and I need to provide the outputDirectory when used
indirectly via the site plugin. I will include my config below.

build...


org.jacoco
jacoco-maven-plugin



jacoco-pre-unit-test

prepare-agent




${project.build.directory}/coverage-reports/jacoco-ut.exec

surefireArgLine





jacoco-post-unit-test
test

report





${project.build.directory}/coverage-reports/jacoco-ut.exec


${project.reporting.outputDirectory}/jacoco-ut





jacoco-check
test

check



${project.build.directory}/coverage-reports/jacoco-ut.exec
true



BUNDLE



INSTRUCTION

COVEREDRATIO

${jacoco.percentage.instruction}



BRANCH

COVEREDRATIO

${jacoco.percentage.branch}










jacoco-pre-integration-test
pre-integration-test

prepare-agent



${jacoco.it.execution.data.file}

failsafeArgLine




jacoco-post-integration-test
post-integration-test

report




${jacoco.ut.execution.data.file}


${project.reporting.outputDirectory}/jacoco-it







org.apache.maven.plugins
maven-surefire-plugin
2.15


${surefireArgLine}

${skip.unit.tests}


**/IT*.java





org.apache.maven.plugins
maven-failsafe-plugin
2.15



integration-tests

integration-test
verify



${failsafeArgLine}

${skip.integration.tests}






org.apache.maven.plugins
maven-site-plugin
3.7



reporting...


org.jacoco
jacoco-maven-plugin
0.8.0



Note I'm not running IT tests yet. But ideally when we do I'd like to be
able to publish both sets of reports in the site.


My command line to generate the site is mvn clean package site

-Dave

Re: Skip deploy of test-jars?

[Christofer Dutz]

Regarding the number of kittens being hurt in both ways ... which one would you 
guys see the one with more happy kittens?

1) Use the test-jar and unpack it
2) Copy classes from a location outside the module (but relative to the current 
module)

Chris



Am 29.01.18, 22:41 schrieb "Christofer Dutz" :

Hi Robert,

Well in that case I would copy resources from one module to another using 
relative paths which point outside the module itself. 
That doesn't sound ideal either. At least I always try to avoid accessing 
things this way cause I have burnt myself too often when doing it.

With the "test-jar unpacking" one module only consumes maven artifacts 
another project created.

Chris 



Am 29.01.18, 18:47 schrieb "Robert Scholte" :

This makes me wonder: is the pack/unpack already hackish?
Wouldn't it be nicer to simply copy the content from target/classes +  
target/test-classes?
With a Maven plugin is it quite simple to access this as part of the  
reactor.

thanks,
Robert

On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz  
 wrote:

> Hi all,
>
> in the Apache Edgent (incubating) project we are producing java 8 and 
 
> java 7 compatible jars by using the retrolambda-maven-plugin. The 
Java 7  
> versions are just a convenience byproduct for us. In order to do 
this,  
> we create the jar as well as the test-jars for each module and hava  
> separate java 7 modules where no code is compiled, but instead in the 
 
> compile phase we unpack the jar and in the compile-test phase we 
unpack  
> the test-jar of the matching Java 8 module. After unpacking the  
> retrolambda plugin is executed and it generates the Java 7 versions.  
> From then on the converted class files are used to run the tests and  
> create the java 7 jars.
>
> A little inconvenience of this approach is, that all test-jars are 
also  
> published to nexus. We do need them to be installed in the local 
repo,  
> but there is generally no point in deploying them to Maven-Central.  
> While I have no big deals with this, some in the project would like 
to  
> remove those test-jars from deployment.
>
> Is there any way to do this by usual configuration? Right now we are  
> thinking of using the Nexus REST interface to programmatically strip  
> them form the staging repo prior to closing it, but this all feels 
like  
> a huge hack.
>
> Do you have any advice how to do this or some good reasons not to do 
it?
>
> Chris

-
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