Re: [Maven Dependency Plugin] usedDependency vs. ignoredUnusedDeclaredDependencies

[Alexander Kriegisch]

FYI, I have just answered your SO question:
https://stackoverflow.com/a/63894653/1082681

-- 
Alexander Kriegisch
https://scrum-master.de


Shelley Baker schrieb am 14.09.2020 20:54 (GMT +07:00):

> I've also posted this question on Stack Overflow:
> 
> https://stackoverflow.com/questions/63885408/maven-dependency-plugin-useddependency-vs-ignoredunuseddeclareddependencies
> 
> On 2020/09/02 15:09:43, Shelley  wrote: 
>> What is the difference between the maven-dependency-plugin's
>> *ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]?
>> 
>> I have several runtime/test-runtime dependencies that are flagged by the
>> plugin as unused and declared and would like to ignore them. Both of these
>> parameters seem to accomplish this, so I'd like some clarification as to
>> what the difference is between them, and which to use when.
>> 
>> [1]
>> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies
>> [2]
>> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#usedDependencies

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

Re: Why does POM have precedence over -D property expressions?

[Oliver B. Fischer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I had the same question some days back
(https://mail-archives.apache.org/mod_mbox/maven-users/202009.mbox/%3C922b4efc-3296-d35d-0675-d6c0090cc4b1%40swe-blog.net%3E)
and Stuart McCulloch sent me a link to this JIRA issue:
https://issues.apache.org/jira/browse/MNG-4979

So, this seems to be a recurring issue that irritates a lot of people.

Oliver

Am 14.09.20 um 18:11 schrieb Andreas Sewe:
> Hi,
>
> I am currently sprinkling  child elements like the
> following through my (parent) POMs for enforcer:enforce, tidy:check and
> checkstyle:check :
>
>   ${skipChecks}
>
> This allows me to skip all kinds of checks with a simple
> -DskipChecks=true (or even -DskipChecks), just like I am used to for
> tests with -DskipTests.
>
> Unfortunately, I cannot selectively override this, as the following
> doesn't work:
>
>   mvn install -DskipChecks -Denforcer.skip=false
>
> The above command still uses the ${skipChecks} (with
> skipChecks=true).
>
> Further experimentation led me to believe that *any* explicit pom.xml
>  cannot be overridden by a property expression given on
> the command line.
>
> This was very surprising, as I would have expected Maven to follow a
> "command line takes precedence over configuration file" approach like
> other tools -- but apparently it doesn't (at least in Maven 3.3.9 and
> 3.6.3) and thus violates the Principle of Least Astonishment (for one of
> its users anyway).
>
> In particular, Maven's handling of property expressions means that
> having no  element and making the default explicit behave
> differently; a  element like this can never be overridden
> on the command-line:
>
>   false
>
> I wonder why it was designed that way?
>
> Or should this be considered a bug?
>
> Best wishes,
>
> Andreas
>
- -- 
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEU7j685HGR9cAsMGwB88X6wLziPwFAl9fzxAACgkQB88X6wLz
iPzd/w/9FFSjkXtHrspdg9z8sV5tXEEXIGJdw1XRcDL8SDl412GmCIoCN5+HuYSa
MIMyGrmlsMgdeHUkx/0wvUXLBjmV7oEiAIhiLhA4l25F3Qc+y5zoUxZIUjNbZiZu
4oR04RZcrIdBA67sdxkvhQfM8rnv4/P97L70CVZpA8/nFNDjYWrG2troCTLMn6MI
NmjiYMpmG9xHDxy3KkqJqXwfEZDmEqphYV2K4T18EOcw5dP7ZJBK3sHXczK93Wkz
eTrDDgVcBHexSR2aqGX6xlNdtR4UScsCJjsXpnCZq/09qS9pOduBCIPX8Cswsi7B
d1nFKmNR41TpZtQFv8LCrbNkK5FBSupsxrOGgKjGza70y3JPki13I15tKZjnMZFY
CvaSK36VzEQOMVaZL5TB1ybXvF9OWXJgwqGT1dYCoCm3WDFCdGka3igVKKJWEE/P
xriYNkmzhKuKY5mAJa7wpXa1DQLnraFLcIPTEHNKLYocct58yRGtsgCvx7FIXflY
rtfou8+b5Q6FGHJcGpTiL7Zh191nV1gUJJA3ZXJwGzdvs+tvwLYPj34+5LNvwj0z
Ax1MKZLllCfq2wLm8NAnVqHYh55K5YN5O/jG+Fk9Mw87ynj+Tn9qIQ9jQ7nGIVyv
nvF87+KgBTQE5OFSpmLvDJEkN+zPqnp81VDkjNdMUSj16kcgAw8=
=oPqj
-END PGP SIGNATURE-


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

Re: Why does POM have precedence over -D property expressions?

[Tomo Suzuki]

> *any* explicit pom.xml  cannot be overridden by a property
expression given on
> the command line.

I also encountered the problem when my Maven project has multiple main
classes and I wanted to run them by switching "mvn exec:java
-Dexec.mainClass=...' while keeping the default one in pom.xml. I don't
know why Maven is designed in that way.

Good to know the use of properties to control it. Thank you.

-- 
Regards,
Tomo

Re: Why does POM have precedence over -D property expressions?

[Andy Feldman]

I guess you don't even need a custom property since each plugin tends to
have one already. So a simpler property-based approach would just be:


  ${skipChecks}


And maybe you'd also need false in your properties
to provide a default for when skipChecks isn't specified on the command
line. But like I said, I haven't tried this approach so you'd have to
experiment and see if it works for you.


On Mon, Sep 14, 2020 at 10:38 AM Andy Feldman  wrote:

> I agree this behavior is unexpected. But it's different for properties! So
> a workaround here is to have a unique property for each check you want to
> skip, so that you can override the property by command line rather than
> overriding the  configuration directly. Then you can have a single
> way to set all these properties. In my company's parent pom we have a
> profile that can be activated like `mvn install -P quick` to skip tests and
> checks:
>
> 
>   quick
>   
> true
> true
> true
> true
> true
>   
> 
>
> So if I want to still run the enforcer plugin, I can do this: `mvn install
> -P quick -Denforcer.skip=false`.
>
> If you want to keep using a property rather than a profile, I assume you
> could have the specific property for each check reference your main
> property by default, like:
>
> 
>   ${skipChecks}
> 
> [...]
> ${skip.our.enforcer}
>
> But I haven't tested it.
>
>
> On Mon, Sep 14, 2020 at 9:11 AM Andreas Sewe <
> andreas_s...@buildingblobs.com> wrote:
>
>> Hi,
>>
>> I am currently sprinkling  child elements like the
>> following through my (parent) POMs for enforcer:enforce, tidy:check and
>> checkstyle:check :
>>
>>   ${skipChecks}
>>
>> This allows me to skip all kinds of checks with a simple
>> -DskipChecks=true (or even -DskipChecks), just like I am used to for
>> tests with -DskipTests.
>>
>> Unfortunately, I cannot selectively override this, as the following
>> doesn't work:
>>
>>   mvn install -DskipChecks -Denforcer.skip=false
>>
>> The above command still uses the ${skipChecks} (with
>> skipChecks=true).
>>
>> Further experimentation led me to believe that *any* explicit pom.xml
>>  cannot be overridden by a property expression given on
>> the command line.
>>
>> This was very surprising, as I would have expected Maven to follow a
>> "command line takes precedence over configuration file" approach like
>> other tools -- but apparently it doesn't (at least in Maven 3.3.9 and
>> 3.6.3) and thus violates the Principle of Least Astonishment (for one of
>> its users anyway).
>>
>> In particular, Maven's handling of property expressions means that
>> having no  element and making the default explicit behave
>> differently; a  element like this can never be overridden
>> on the command-line:
>>
>>   false
>>
>> I wonder why it was designed that way?
>>
>> Or should this be considered a bug?
>>
>> Best wishes,
>>
>> Andreas
>>
>>

Re: Why does POM have precedence over -D property expressions?

[Andy Feldman]

I agree this behavior is unexpected. But it's different for properties! So
a workaround here is to have a unique property for each check you want to
skip, so that you can override the property by command line rather than
overriding the  configuration directly. Then you can have a single
way to set all these properties. In my company's parent pom we have a
profile that can be activated like `mvn install -P quick` to skip tests and
checks:


  quick
  
true
true
true
true
true
  


So if I want to still run the enforcer plugin, I can do this: `mvn install
-P quick -Denforcer.skip=false`.

If you want to keep using a property rather than a profile, I assume you
could have the specific property for each check reference your main
property by default, like:


  ${skipChecks}

[...]
${skip.our.enforcer}

But I haven't tested it.


On Mon, Sep 14, 2020 at 9:11 AM Andreas Sewe 
wrote:

> Hi,
>
> I am currently sprinkling  child elements like the
> following through my (parent) POMs for enforcer:enforce, tidy:check and
> checkstyle:check :
>
>   ${skipChecks}
>
> This allows me to skip all kinds of checks with a simple
> -DskipChecks=true (or even -DskipChecks), just like I am used to for
> tests with -DskipTests.
>
> Unfortunately, I cannot selectively override this, as the following
> doesn't work:
>
>   mvn install -DskipChecks -Denforcer.skip=false
>
> The above command still uses the ${skipChecks} (with
> skipChecks=true).
>
> Further experimentation led me to believe that *any* explicit pom.xml
>  cannot be overridden by a property expression given on
> the command line.
>
> This was very surprising, as I would have expected Maven to follow a
> "command line takes precedence over configuration file" approach like
> other tools -- but apparently it doesn't (at least in Maven 3.3.9 and
> 3.6.3) and thus violates the Principle of Least Astonishment (for one of
> its users anyway).
>
> In particular, Maven's handling of property expressions means that
> having no  element and making the default explicit behave
> differently; a  element like this can never be overridden
> on the command-line:
>
>   false
>
> I wonder why it was designed that way?
>
> Or should this be considered a bug?
>
> Best wishes,
>
> Andreas
>
>

Why does POM have precedence over -D property expressions?

[Andreas Sewe]

Hi,

I am currently sprinkling  child elements like the
following through my (parent) POMs for enforcer:enforce, tidy:check and
checkstyle:check :

  ${skipChecks}

This allows me to skip all kinds of checks with a simple
-DskipChecks=true (or even -DskipChecks), just like I am used to for
tests with -DskipTests.

Unfortunately, I cannot selectively override this, as the following
doesn't work:

  mvn install -DskipChecks -Denforcer.skip=false

The above command still uses the ${skipChecks} (with
skipChecks=true).

Further experimentation led me to believe that *any* explicit pom.xml
 cannot be overridden by a property expression given on
the command line.

This was very surprising, as I would have expected Maven to follow a
"command line takes precedence over configuration file" approach like
other tools -- but apparently it doesn't (at least in Maven 3.3.9 and
3.6.3) and thus violates the Principle of Least Astonishment (for one of
its users anyway).

In particular, Maven's handling of property expressions means that
having no  element and making the default explicit behave
differently; a  element like this can never be overridden
on the command-line:

  false

I wonder why it was designed that way?

Or should this be considered a bug?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [Maven Dependency Plugin] usedDependency vs. ignoredUnusedDeclaredDependencies

[Shelley Baker]

I've also posted this question on Stack Overflow:

https://stackoverflow.com/questions/63885408/maven-dependency-plugin-useddependency-vs-ignoredunuseddeclareddependencies

On 2020/09/02 15:09:43, Shelley  wrote: 
> What is the difference between the maven-dependency-plugin's
> *ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]?
> 
> I have several runtime/test-runtime dependencies that are flagged by the
> plugin as unused and declared and would like to ignore them. Both of these
> parameters seem to accomplish this, so I'd like some clarification as to
> what the difference is between them, and which to use when.
> 
> [1]
> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies
> [2]
> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#usedDependencies
> 

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

Re: Excluding source files even if they are referenced

[Thomas Broyer]

On Mon, Sep 14, 2020 at 1:41 PM Alex Gerdov 
wrote:

> Hello,
>
> I was wondering - is it possible to instruct the compiler plug-in to
> exclude source files even if they are referenced directly by other source
> files?
>

It depends what you're trying to do.
You can exclude [1] those files, but then because the maven-compiler-plugin
sets the sourcepath to your source roots, the files will be compiled anyway
if they are referenced by others that are being compiled [2].
You could use -implicit:none in compilerArgs to prevent the corresponding
*.class file from being generated though. So compilation will succeed, but
the output will be "incomplete" (but maybe that's what you want after all).

[1]
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#excludes
[2] https://blog.ltgt.net/most-build-tools-misuse-javac/

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 

Excluding source files even if they are referenced

[Alex Gerdov]

Hello,
I was wondering - is it possible to instruct the compiler plug-in to exclude 
source files even if they are referenced directly by other source files?
Thank you.



Alex Gerdov
Research & Development


(t) +972-54-6489120
(e) alex.ger...@unboundtech.com
(w) www.unboundtech.com



[cid:image001_33bc2125-acce-499f-b3e4-d7ff3ead2655.png]
[cid:image002_835de91e-1279-4d5b-8caf-3b333b513648.jpg] 
  
[cid:image003_e0941979-a6a1-4d3c-ad38-16acdd775113.jpg] 

[cid:image004_7cb7b240-000d-45a9-be8b-9afaf7262345.jpg] 




This email message and any attachments thereto are confidential and/or subject 
to privacy laws and/or non-disclosure agreements and are intended only for use 
by the addressee(s) named above. The writer asserts in respect of this message 
and attachments all rights for confidentiality or privacy to the fullest extent 
permitted by law.