Re: Treat maven warnings as errors

[Gordon Cody]

Hello Yaron

You may find this an impossible task to accomplish. The standard maven
plugins generally do a good job with their messages but some 3rd-party jars
and plugins log WARNING messages, a few even log ERROR messages when the
developer really should have used INFO or possibly logged nothing at all.

Mostly these messages would show up in the logs when you run your
junit/surefire tests but some can come even when you build with
skipTests=true.
How far you get will depend on your projects dependencies and the set of
plugins you use in your builds.

I wish you luck.

Just my personal opinion, Gordon

On Mon, Mar 6, 2017 at 8:25 PM, Daniel Schulz 
wrote:

> Hi,
>
> Might this help you?
>
> https://maven.apache.org/plugins/maven-dependency-
> plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
>
> http://stackoverflow.com/questions/9192613/how-do-i-
> get-a-java-maven-build-to-fail-for-compiler-warnings
>
> Kind regards, Daniel.
>
>
> > On 06.03.2017, at 15:58, Yaron Golan  wrote:
> >
> > Anyone?
> >
> > "No" is an answer as well, you know ... :)
> >
> >
> > -Original Message-
> > From: Yaron Golan [mailto:ygo...@interwise.com]
> > Sent: Wednesday, March 01, 2017 12:05 PM
> > To: users@maven.apache.org
> > Subject: Treat maven warnings as errors
> >
> > Hi,
> > Is there a way to treat the maven warnings as errors?
> >
> >
> >
> > -
> > 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
>
>


-- 
Best Regards, Gord Cody

Senior Release Manager  Zafin Inc.
179 Colonnade Road-Suite 100, Ottawa ON, Canada
Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1 613-601-2734
Web: http://zafin.com  Email: gordon.c...@zafin.com

Re: Treat maven warnings as errors

[Daniel Schulz]

Hi,

Might this help you?

https://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html

http://stackoverflow.com/questions/9192613/how-do-i-get-a-java-maven-build-to-fail-for-compiler-warnings

Kind regards, Daniel.


> On 06.03.2017, at 15:58, Yaron Golan  wrote:
> 
> Anyone?
> 
> "No" is an answer as well, you know ... :)
> 
> 
> -Original Message-
> From: Yaron Golan [mailto:ygo...@interwise.com] 
> Sent: Wednesday, March 01, 2017 12:05 PM
> To: users@maven.apache.org
> Subject: Treat maven warnings as errors
> 
> Hi,
> Is there a way to treat the maven warnings as errors?
> 
> 
> 
> -
> 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: Formerly Aether, now Maven Artifact Resolver--documentation?

[Laird Nelson]

On Mon, Mar 6, 2017 at 2:20 PM Laird Nelson  wrote:

> The Javadocs for it say, among other things:
>
> "To acquire a complete repository system, clients need to add an artifact
> descriptor reader, a version resolver, a version range resolver and
> optionally some repository connector and transporter factories to access
> remote repositories."
>

I also notice that the ArtifactDescriptorReader interface is effectively
deprecated
:
"This type is provisional and can be changed, moved or removed without
prior notice."  So that makes me wonder if perhaps I should not be using
the DefaultServiceLocator that says that its usage is required
?
If indeed I shouldn't use this class either, then is there an example
somewhere of how to manually assemble a RepositorySystem out of existing
spare parts?

Best,
Laird

Re: Formerly Aether, now Maven Artifact Resolver--documentation?

[Christian Schulte]

Am 03/07/17 um 00:06 schrieb Laird Nelson:
> Ah!  After some more bashing around in Github and Maven central searching,
> I found this:
> https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java
> 
> This looks like the replacement for this:
> https://maven.apache.org/ref/3.3.9/maven-aether-provider/apidocs/org/apache/maven/repository/internal/MavenRepositorySystemUtils.html
> 
> ...which suggests to me that maven-resolver-provider is the replacement for
> maven-aether-provider going forward.  If so, I see that the only release of
> this is 3.5.0-alpha-1 (
> http://search.maven.org/#artifactdetails%7Corg.apache.maven%7Cmaven-resolver-provider%7C3.5.0-alpha-1%7Cjar
> ).
> 
> Am I on the right track with all this? Should I follow the general spirit
> of this (
> https://github.com/eclipse/aether-demo/tree/master/aether-demo-snippets/src/main/java/org/eclipse/aether/examples),
> but squinting and making these replacements along the way?

You are correct. maven-aether-provider has been renamed to
maven-resolver-provider. No changes in package names or class names. It
should be possible to just exchange the artifacts.

Regards,
-- 
Christian


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

Re: Formerly Aether, now Maven Artifact Resolver--documentation?

[Laird Nelson]

Ah!  After some more bashing around in Github and Maven central searching,
I found this:
https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java

This looks like the replacement for this:
https://maven.apache.org/ref/3.3.9/maven-aether-provider/apidocs/org/apache/maven/repository/internal/MavenRepositorySystemUtils.html

...which suggests to me that maven-resolver-provider is the replacement for
maven-aether-provider going forward.  If so, I see that the only release of
this is 3.5.0-alpha-1 (
http://search.maven.org/#artifactdetails%7Corg.apache.maven%7Cmaven-resolver-provider%7C3.5.0-alpha-1%7Cjar
).

Am I on the right track with all this? Should I follow the general spirit
of this (
https://github.com/eclipse/aether-demo/tree/master/aether-demo-snippets/src/main/java/org/eclipse/aether/examples),
but squinting and making these replacements along the way?

Thanks,
Laird

On Mon, Mar 6, 2017 at 2:31 PM Laird Nelson  wrote:

> On Mon, Mar 6, 2017 at 2:20 PM Laird Nelson  wrote:
>
> The Javadocs for it say, among other things:
>
> "To acquire a complete repository system, clients need to add an artifact
> descriptor reader, a version resolver, a version range resolver and
> optionally some repository connector and transporter factories to access
> remote repositories."
>
>
> I also notice that the ArtifactDescriptorReader interface is effectively
> deprecated
> :
> "This type is provisional and can be changed, moved or removed without
> prior notice."  So that makes me wonder if perhaps I should not be using
> the DefaultServiceLocator that says that its usage is required
> ?
> If indeed I shouldn't use this class either, then is there an example
> somewhere of how to manually assemble a RepositorySystem out of existing
> spare parts?
>
> Best,
> Laird
>

Formerly Aether, now Maven Artifact Resolver--documentation?

[Laird Nelson]

Hello; I'd like to use the Maven Artifact Resolver project (
https://maven.apache.org/resolver/), which, as I understand it, is where
the original Maven dependency resolution code finally ended up after a long
detour through two different companies' attempts to break it off as the
Aether project (Sonatype Aether, Eclipse Aether).

I get the general idea: if I am using it outside of Maven (which I am),
then I should be using the API project (
https://maven.apache.org/resolver/maven-resolver-api/), and hopefully via
some dependency injection system backing it with an implementation.  And
presumably I'd be nuts not to back it with the impl project (
https://maven.apache.org/resolver/maven-resolver-impl/index.html).

The impl project provides a what-looks-like-it-would-be-handy assembler and
service locator of sorts:
https://maven.apache.org/resolver/maven-resolver-impl/apidocs/org/eclipse/aether/impl/DefaultServiceLocator.html.
I suppose I'd like to start by using that.

The Javadocs for it say, among other things:

"To acquire a complete repository system, clients need to add an artifact
descriptor reader, a version resolver, a version range resolver and
optionally some repository connector and transporter factories to access
remote repositories."

Let's say I wanted to make this behave exactly like Maven (i.e. I'd like to
read and work with the local Maven repository cache, etc.), but ultimately
I'm using it to resolve group/artifact/version/packaging/classifier
specifications from something like a command line application.  What
implementations drawn from what Maven-authored projects would I use here?
Do the other submodules listed here (
https://maven.apache.org/resolver/index.html) contain the implementations
described by the Javadocs I cited?  Is there anything missing?  I see
several (presumably) transporter factories in there—would I pick one, or
add all of them?

I have seen this Github repository (https://github.com/eclipse/aether-demo/)
but of course it is for
Aether-as-maintained-by-Eclipse-which-has-now-become-Maven-Artifact-Resolver,
and the Maven-related classes it references are not written to work with
the Maven Artifact Resolver project so I'm not sure how valid the approach
shown here is anymore.

Thanks,
Best,
Laird

[ANN] Mock Repository Manager 1.0.1 Released

[Robert Scholte]

Hi,

The Mojo team is pleased to announce the release of the Mock Repository  
Manager version 1.0.1.


The Mock Repository Manager suite of projects are used to provide mock or  
lightweight Maven Repository Managers for use during integration testing  
of Maven plugins.


http://www.mojohaus.org/mrm/index.html

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



org.codehaus.mojo
mrm-maven-plugin
1.0.1


Release Notes

https://github.com/mojohaus/mrm/milestone/3?closed=1

Enjoy,

The Mojo team.

Robert Scholte

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

[ANN] Exec Maven Plugin 1.6.0 Released

[Robert Scholte]

Hi,

The Mojo team is pleased to announce the release of the Exec Maven Plugin  
version 1.6.0.


The plugin provides 2 goals to help execute system and Java programs.

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

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



org.codehaus.mojo
exec-maven-plugin
1.6.0


Release Notes

https://github.com/mojohaus/exec-maven-plugin/milestone/3?closed=1

Enjoy,

The Mojo team.

Robert Scholte

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

Re: Treat maven warnings as errors

[Robert Scholte]

https://issues.apache.org/jira/browse/MNG-6065 is what you are looking for.
So the answer is: no, not yet.

Robert

On Mon, 06 Mar 2017 15:57:32 +0100, Yaron Golan   
wrote:



Anyone?

"No" is an answer as well, you know ... :)


-Original Message-
From: Yaron Golan [mailto:ygo...@interwise.com]
Sent: Wednesday, March 01, 2017 12:05 PM
To: users@maven.apache.org
Subject: Treat maven warnings as errors

Hi,
Is there a way to treat the maven warnings as errors?



-
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: Enforcer requirePropertyDiverges not propagated to descendants?

[org . apache . maven . user]

On 2017-03-06T10:58:30 -0600
Curtis Rueden  wrote:

> Hi,
> 
> For what it's worth, I agree that the requirePropertyDiverges rule is
> difficult to use (and maybe buggy?). After playing with it some months ago,
> I concluded that it was not going to work for me. That's why I ended up
> writing my own rule.
> 
> If you want to ensure that the description is set in each child POM, maybe
> the scijava-maven-plugin's requireElements rule _can_ help you here? Or do
> you, again, only want to set the description in some intermediate POM layer?

https://github.com/io7m/primogenitor/commit/021b5a9a6577c02346d85242b77db31f88f8e25c

:D

"A better fix would be to use scijava's requireElements rule and just
assume that anyone capable of creating new elements would be capable of
making them different from the ancestor."

M


pgpyTk0gy5JRU.pgp
Description: OpenPGP digital signature

Re: Enforcer requirePropertyDiverges not propagated to descendants?

[Curtis Rueden]

Hi,

For what it's worth, I agree that the requirePropertyDiverges rule is
difficult to use (and maybe buggy?). After playing with it some months ago,
I concluded that it was not going to work for me. That's why I ended up
writing my own rule.

If you want to ensure that the description is set in each child POM, maybe
the scijava-maven-plugin's requireElements rule _can_ help you here? Or do
you, again, only want to set the description in some intermediate POM layer?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Sun, Mar 5, 2017 at 3:31 AM,  wrote:

> Hello.
>
> On 2017-03-05T01:18:34 +0100
> Hervé BOUTEMY  wrote:
>
> > first, you'll have to talk about rules, not only the plugin: there are
> many
> > rules, some implemented by the plugin and some implemented by MojoHaus
> extra-
> > enforcer-rules
>
> Right, yes. It's the requirePropertyDiverges rule in the
> extra-enforcer-rules package in this case.
>
> >
> > then: MojoHaus requirePropertyDiverges [1] requires that the property
> value is
> > different, not that it is not empty
> >
> > IIUC what you're trying to do, you'll need both Maven requireProperty
> [2] and
> > MojoHaus requirePropertyDiverge [1]
>
> That seems wrong, somehow, and it doesn't match the behaviour that I
> posted. If I don't define a property, then the property (if any) will
> be inherited from an ancestor project, yes? The problem I'm having is
> that the requirePropertyDiverges rule seems to stop working after one
> level of inheritance. See these three example cases:
>
> 0. Project A defines a property P. Project B inherits from
>A and doesn't redefine or declare P. The requirePropertyDiverges rule
>correctly rejects this case and the build fails.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-0
>
>^^ Building this project should fail, and it does.
>
> 1. Project A defines a property P. Project B inherits from A and
>redefines P with a different value. The requirePropertyDiverges rule
>correctly accepts this case and the build succeeds.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-1
>
>^^ Building this project should succeed, and it does.
>
> 2. Project A defines a property P. Project B inherits from A and
>redefines P with a different value. Project C inherits from B
>and doesn't redefine or declare P. This case *should* fail,
>because in C, P is inherited from B and therefore has not diverged.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-2
>
>^^ Building this project should fail, but it doesn't.
>
> M
>

RE: Treat maven warnings as errors

[Yaron Golan]

Anyone?

"No" is an answer as well, you know ... :)


-Original Message-
From: Yaron Golan [mailto:ygo...@interwise.com] 
Sent: Wednesday, March 01, 2017 12:05 PM
To: users@maven.apache.org
Subject: Treat maven warnings as errors

Hi,
Is there a way to treat the maven warnings as errors?



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

Re: vcmcvsssh.jar

[Martin Gainty]

a bit suprised when i meet "planned obsoloence"


i commented out the code  and all is well


Martin
__




From: Benson Margulies 
Sent: Monday, March 6, 2017 12:00 AM
To: Maven Users List
Subject: Re: vcmcvsssh.jar

On Sun, Mar 5, 2017 at 1:35 PM, Martin Gainty  wrote:
> can you suggest a developer list that is responsible for maintaining eclipse 
> 2.0?

You are joking, right? Maintain? It's ancient and obsolete. It might
be archived somewhere.

>
>
> vielen danke her eckenfels
>
> Martin
> __
>
>
>
> 
> From: Bernd Eckenfels 
> Sent: Sunday, March 5, 2017 3:24 PM
> To: users@maven.apache.org; Maven Users List
> Subject: Re: vcmcvsssh.jar
>
> Hello,
> I guess you better ask the Eclipse Team project. I would suspect you find the 
> libraries only in the historic Eclipse 2.0 archives.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Sun, Mar 5, 2017 at 7:45 PM +0100, "Martin Gainty"  
> wrote:
>
>
>
>
>
>
>
>
>
>
> anyone know where i can acquire org.eclipse.vcm library?
>
> the eclipse vcm library is supposed to be available in vcmcvsssh.jar which i 
> cannot locate
>
>
> Thanks!
>
> Martin
> __
>
>
>
>
>
>
>

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