[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359265#comment-359265
]
Herve Boutemy edited comment on MPIR-263 at 12/17/14 8:53 PM:
--------------------------------------------------------------
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- {{maven.compiler.source}} and {{maven.compiler.target}} conventions were
created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the different algorithms.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switched to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback to support every classical ways of configuring
the plugin.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
A few days ago, I started the discussion with "I'm not convinced" since I
really didn't have any strong opinion at that time: now, after working on this
and having rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 generic
API to share configuration between plugins is the graal, perhaps in the future
if the need is found for more than compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
and avoid the regression that would be the actual fix
was (Author: hboutemy):
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- {{maven.compiler.source}} and {{maven.compiler.target}} conventions were
created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the algorithm.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switch to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
a few days ago, I started the discussion with "I'm not convinced" but I didn't
have strong opinion at that time: now, after working on this and having
rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 geenric
API is the graal, perhaps in the future if the need is found for more than
compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
> Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
> ---------------------------------------------------------------------
>
> Key: MPIR-263
> URL: https://jira.codehaus.org/browse/MPIR-263
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
> Components: summary
> Affects Versions: 2.6
> Environment: Maven 2.2.1 and 3.0.3
> Reporter: Michael Osipov
> Assignee: Michael Osipov
> Fix For: 2.8
>
>
> If you define {{maven.compiler.target}} in the {{<properties>}} section or
> per command line, that value is not taken into account in report generation.
> The source and target version are retrieved from the static model.
> If someone could use an interpolated model that would solve the issue. At
> least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
