Re: maven-plugin-testing-harness: NoClassDefFoundError: org/apache/maven/execution/MavenExecutionRequest

[org.apache.maven.user]

On 2015-11-13T18:04:01 -0500
Jason van Zyl  wrote:

> You are missing the dependencies which contain the necessary classes. I made 
> a PR for you. The project test now executes. 
> 
> FYI, I use this all the time now for plugin unit and integration testing:
> 
> https://github.com/takari/takari-plugin-testing-project

Thanks for the assistance.

Looks like I'll be switching to Takari today.

M

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

Re: Please reopen MNG-4533 Add an always active profile activator

[Karl Heinz Marbaise]

Hi,

On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:

Hi,

could issue MNG-4533 "Add an always active profile activator" please be
reopened?
https://issues.apache.org/jira/browse/MNG-4533

The issues was automatically closed in 2014.

I find the current workarounds to create an always active profile (check
for non existing property, check for always existing file) quite ugly.



The question is why do you need a profile which is always active ? In 
consequence i would ask why do you need a profile at all in such case? 
If it is always active you don't need a profile



May be you can elaborate more what you like to achieve and what the use 
case is?



Kind regards
Karl Heinz Marbaise

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

Please reopen MNG-4533 Add an always active profile activator

[Arend v. Reinersdorff]

Hi,

could issue MNG-4533 "Add an always active profile activator" please be
reopened?
https://issues.apache.org/jira/browse/MNG-4533

The issues was automatically closed in 2014.

I find the current workarounds to create an always active profile (check
for non existing property, check for always existing file) quite ugly.

Best regards,
Arend

[ANN] JAX-WS Maven Plugin version 2.4 Released

[Hervé BOUTEMY]

Hi,

The Mojo team is pleased to announce the release of the JAX-WS Maven Plugin 
version 2.4. 

This plugin contains Maven adapter for JAX-WS's toolset.
The original code was developed in the Codehaus Mojo project, then as of March 
2007, the project moved to jax-ws-commons with version 1.x in 
org.codehaus.mojo groupId and version 2.x in org.jvnet.jax-ws-commons groupId.
In September 2015, for version 2.4, it went back to MojoHaus (the new home of 
Codehaus Mojo) in org.codehaus.mojo groupId.

http://www.mojohaus.org/jaxws-maven-plugin/

To get this update, simply specify the version in your project's plugin 
configuration: 


org.codehaus.mojo
jaxws-maven-plugin
2.4


Release Notes

http://www.mojohaus.org/jaxws-maven-plugin/release-notes-24.html


Enjoy,

The Mojo team.
 
Hervé

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

Re: Please reopen MNG-4533 Add an always active profile activator

[Karl Heinz Marbaise]

Hi,

On 11/14/15 10:06 PM, Arend v. Reinersdorff wrote:

Hi Karl Heinz,

good point. I'll try to elaborate more:

The idea is to have a profile which is always active, unless explicitly
deactivated. One can nearly achieve this with
true, but not quite because an
activeByDefault profile is deactivated if another profile from the same
pom.xml is activated.

So this is needed when:
- one profile should always be active, but can be turned off explicitly
- another profile can be activated, and activating it should not
deactivate the always active profile


Here's a concrete example. Solution taken from this answer on
Stackoverflow
http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945

- a multi module project
- normally all modules are included in a build
- in some cases certain modules (data-foo and data-bar) should be
excluded from the build (in the Stackoverflow question because the tests
took a long time,



Ok...starting with Maven 3.2.1[1] you can use things like this:


mvn -pl !moduleYouDontLikeToBuild package

So no need for a profile...I'm just quoting the answers which already 
given on SO...


Apart from that if you have tests which run long you should think if 
those tests are really unit- or integration tests...which means 
different life cycle phases etc. and never activate/deactivate modules 
via profiles[2]



[1]: http://maven.apache.org/docs/3.2.1/release-notes.html
[2]: 
http://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/


>
I was researching it to exclude modules from Javadoc

generation) The modules are excluded with "mvn -!Pfull-build"


The above can also be applied to exclude from JavaDoc ...I'm asking 
myself why you like to exclude a module from JavaDoc generation but this 
is a different story




- also, there's another profile to change the target directory.
Activating this should not interfere with module exclusion. "mvn
-PtargetInTemp clean install" should still build all modules.






 common
 foo
 bar



 
 full-build
 

 
 
 pom.xml
 

 
 
 data-foo
 data-bar
 
 

 
 
 targetInTemp
 

${env.TEMP}/${project.groupId}/${project.artifactId}
 



I don't understand why you need such thing (like different directory?) 
and what is the reason for creating this kind of profile ? What is the 
real problem behind this?


Kind regards
Karl Heinz Marbaise




 



Best regards,
Arend


On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise > wrote:

Hi,

On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:

Hi,

could issue MNG-4533 "Add an always active profile activator"
please be
reopened?
https://issues.apache.org/jira/browse/MNG-4533

The issues was automatically closed in 2014.

I find the current workarounds to create an always active
profile (check
for non existing property, check for always existing file) quite
ugly.



The question is why do you need a profile which is always active ?
In consequence i would ask why do you need a profile at all in such
case? If it is always active you don't need a profile


May be you can elaborate more what you like to achieve and what the
use case is?


Kind regards
Karl Heinz Marbaise

-
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

[ANNOUNCEMENT] MojoHaus Properties Maven Plugin Version 1.0.0 Released

[Karl Heinz Marbaise]

The MojoHaus Team is pleased to announce of the
Properties Maven Plugin Version 1.0.0

http://www.mojohaus.org/properties-maven-plugin/

The Properties Maven Plugin is here to make life a little easier when dealing
with properties. It provides goals to read properties from files and URLs and
write properties to files, and also to set system properties.

You should specify the version in your projects dependencies:


  org.codehaus.mojo
  properties-maven-plugin
  1.0.0


Release Notes for the Properties Maven Plugin Version 1.0.0

http://www.mojohaus.org/properties-maven-plugin/github-report.html

We have two contributors for this release.

Reporter:
 * puntogil: Issue #2 properties-maven-plugin does not include the license file.

Reporter and contributor:
 * kreyssel: Issue #15 add m2e lifecycle mapping for 'write-project-properties'

Many thanks for the reporters and contributors.

Enjoy,

- The MojoHaus Team

Kind regards
Karl Heinz Marbaise

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

Re: Offline builds nearly impossible

[Jörg Schaible]

Paul Benedict wrote:

> I think most people, at least once in their life, try to use their local
> repository cache as an offline remote repository. However, the two aren't
> the same in concept though, IIRC, the last time I tried. You still need to
> keep the two separate.
> 
> Now it would be interesting if a tool existed to copy the contents of a
> local repository and scrub its local metadata. That would then give you a
> true "remote offline repo".

That's what Jason proposed. And what I will do. Actually I already have some 
bash scripts that create the metadata of a remote repo. I just do not have 
the clean-up yet. ;-)

Cheers,
Jörg


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

Re: Please reopen MNG-4533 Add an always active profile activator

[Arend v. Reinersdorff]

Hi Karl Heinz,

good point. I'll try to elaborate more:

The idea is to have a profile which is always active, unless explicitly
deactivated. One can nearly achieve this with
true, but not quite because an
activeByDefault profile is deactivated if another profile from the same
pom.xml is activated.

So this is needed when:
- one profile should always be active, but can be turned off explicitly
- another profile can be activated, and activating it should not deactivate
the always active profile


Here's a concrete example. Solution taken from this answer on Stackoverflow
http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945

- a multi module project
- normally all modules are included in a build
- in some cases certain modules (data-foo and data-bar) should be excluded
from the build (in the Stackoverflow question because the tests took a long
time, I was researching it to exclude modules from Javadoc generation) The
modules are excluded with "mvn -!Pfull-build"
- also, there's another profile to change the target directory. Activating
this should not interfere with module exclusion. "mvn -PtargetInTemp clean
install" should still build all modules.



common
foo
bar




full-build




pom.xml




data-foo
data-bar





targetInTemp


${env.TEMP}/${project.groupId}/${project.artifactId}





Best regards,
Arend


On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:
>
>> Hi,
>>
>> could issue MNG-4533 "Add an always active profile activator" please be
>> reopened?
>> https://issues.apache.org/jira/browse/MNG-4533
>>
>> The issues was automatically closed in 2014.
>>
>> I find the current workarounds to create an always active profile (check
>> for non existing property, check for always existing file) quite ugly.
>>
>
>
> The question is why do you need a profile which is always active ? In
> consequence i would ask why do you need a profile at all in such case? If
> it is always active you don't need a profile
>
>
> May be you can elaborate more what you like to achieve and what the use
> case is?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Please reopen MNG-4533 Add an always active profile activator

[Curtis Rueden]

Hi Arend,

> The idea is to have a profile which is always active, unless
> explicitly deactivated.

To achieve that use case, I like to activate based on a property value.
Then you can change the property value from the CLI to deactivate it,
without affecting any other profiles. This is more flexible than using the
-P flag (which I avoid whenever possible).

Regards,
Curtis

On Sat, Nov 14, 2015 at 3:06 PM, Arend v. Reinersdorff 
wrote:

> Hi Karl Heinz,
>
> good point. I'll try to elaborate more:
>
> The idea is to have a profile which is always active, unless explicitly
> deactivated. One can nearly achieve this with
> true, but not quite because an
> activeByDefault profile is deactivated if another profile from the same
> pom.xml is activated.
>
> So this is needed when:
> - one profile should always be active, but can be turned off explicitly
> - another profile can be activated, and activating it should not deactivate
> the always active profile
>
>
> Here's a concrete example. Solution taken from this answer on Stackoverflow
>
> http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945
>
> - a multi module project
> - normally all modules are included in a build
> - in some cases certain modules (data-foo and data-bar) should be excluded
> from the build (in the Stackoverflow question because the tests took a long
> time, I was researching it to exclude modules from Javadoc generation) The
> modules are excluded with "mvn -!Pfull-build"
> - also, there's another profile to change the target directory. Activating
> this should not interfere with module exclusion. "mvn -PtargetInTemp clean
> install" should still build all modules.
>
> 
> 
> common
> foo
> bar
> 
>
> 
> 
> full-build
> 
>
> 
> 
> pom.xml
> 
>
> 
> 
> data-foo
> data-bar
> 
> 
>
> 
> 
> targetInTemp
> 
>
> ${env.TEMP}/${project.groupId}/${project.artifactId}
> 
> 
> 
>
>
> Best regards,
> Arend
>
>
> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:
> >
> >> Hi,
> >>
> >> could issue MNG-4533 "Add an always active profile activator" please be
> >> reopened?
> >> https://issues.apache.org/jira/browse/MNG-4533
> >>
> >> The issues was automatically closed in 2014.
> >>
> >> I find the current workarounds to create an always active profile (check
> >> for non existing property, check for always existing file) quite ugly.
> >>
> >
> >
> > The question is why do you need a profile which is always active ? In
> > consequence i would ask why do you need a profile at all in such case? If
> > it is always active you don't need a profile
> >
> >
> > May be you can elaborate more what you like to achieve and what the use
> > case is?
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>