Hi Robert, thanks for your feedback and input.
I am fairly with you that FlattenMode.minimum is kind of confusing and
tending to incompatibilities.
We should probably deprecated or remove it...
At least I will now mark it as deprecated in the code and log a
deprecation warning if it is still used.
Further I will revert the impact that is caused when this mode is
actually used to keep compatibility and keep the IT of that mode as it
was before. I guess we can both agree on this step...
Via pomElements and listing everything you can still reach the same goal
as with minimum mode but in a stable way and this is an exotic case.
I am also thinking about your suggestion to depend logic on the
packaging and type of POM.
However I do not want to invent artificial intelligence to distinguish a
parent POM from a BOM as both have the same packaging. To get out of
that I invented to "bom" mode but in case of a BOM you might in the one
case keep dependencyManagement as is and in an other case resolve it
effectively.
Best regards
Jörg
Am 14.02.2015 um 14:27 schrieb Robert Scholte:
>
> /** For projects that want to keep all {@link FlattenDescriptor
> optional POM elements}. */
> FlattenMode.minimum
>
> now I suddenly understand one of the messages from a user. This is
> indeed not what I would have expected when using minimum. I guess the
> result would look like the release-pom.xml.
> My definition of minimum was: only those elements required to be able
> to use this file as a dependency. And this is the absolute minimum,
> without these elements your build will probably break.
>
> It is worth breaking backwards compatibility? I think just changing
> the definition will cause a lot of issues.
> Instead I'd prefer to rename it to 'minimized' and break the build if
> someone still uses minimum, add an explanation.
>
> It looks more and more to me that flatten floats between consumer-pom
> and effective-pom. The first one is the minimized, possibly with extra
> elements if the repository manager used for distribution has extra rules.
> Then we have we effective-pom, which is an xml merge of all the
> parents, no more logic at all. However, this could contain too much
> elements.
>
> So we might need to rethink this a bit: users must choose between
> consumer-pom + some additional elements OR effective-pom minus some
> elements. Both must at least contain the minimized elements. For the
> first one I'd prefer to have control over the elements to choose, the
> latter can be free and for that reason should be made extendable.
>
> Since consumer-pom is still reserved for Apache Maven, we might want
> to call it dependable-pom.
>
> WDYT?
>
> Robert
>
> Op Sat, 14 Feb 2015 12:17:45 +0100 schreef Robert Scholte
> <codeh...@sourcegrounds.com>:
>
>> Hi Jörg,
>>
>> I think your adjustment of rev. 20330 to the
>> optional-elements-modeMinimum/verify.groovy is incorrect.
>> This project results in a jar so there's no reason to keep
>> dependencyManagement here: all dependencies should be resolved.
>>
>> What I'm missing is a project *using* this bom. I seem to be missing
>> some parts of the pattern, because to me it still would look like
>> this change is not required: a jar having a bom as dependency with
>> 'import' scope should still have the same result.
>>
>> thanks,
>> Robert
>>
>> Op Sat, 14 Feb 2015 11:24:46 +0100 schreef Jörg Hohwiller
>> <jo...@j-hohwiller.de>:
>>
>>> Hi Robert,
>>>
>>>> you can't use attributes unless you do the parsing yourself. I'd still
>>>> love to see ITs showing the usage, it is still not there.
>>> Did you have a look at my BOM IT? Probably you missed it...
>>> https://svn.codehaus.org/mojo/trunk/mojo/flatten-maven-plugin/src/it/projects/bom
>>>
>>>
>>> For attributes I wanted first to discuss and then add ITs and
>>> implement.
>>>
>>> Regards
>>> Jörg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
smime.p7s
Description: S/MIME Cryptographic Signature
