On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY <herve.bout...@free.fr> wrote:

Hi Charles,

Thanks for the feedback

Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit :
Hervé,

Great work!
Thank you: it took a lot of time and discussion :)

Some possible additions for the wiki page:

Naming Conventions
consumer pom must continue to be named pom.xml
build pom shall be called build.xml
alternate build inputs could be build.json or build.yaml
ok, makes sense, I reworked it and added to the proposal

Well, I think renaming would cause IDE issues (it's claimed for Ant projects), and this file still represents the Project Object Model, hence pom still makes sense. I expect more issues than benefits, and everywhere is documented: a Maven project requires a pom.xml



EcoSystem Impacts
projects distributing source code through maven central should include the
build pom. This requires updating maven source plugin.
why? do people building with Ant publish their build.xml?

 flattened consumer
pom will impact version resolution;
no, the intent is that it does absolutely not change anything at that level:
that's the whole idea, for compatibility

what was a deep dependency will be
brought to second level how will IDEs be affected?
??

Regards,

Hervé


> On Mar 11, 2018, at 10:03 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>
> Hi,
>
> I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded a
> simplified model for the Consumer POM [2]
> As written in the proposal, this would permit us to create new POM
> versions
> that change everything but not the Consumer POM part without breaking any > compatibility with existing Central repository users: build element is the
> main element that could be changed, adding new build
> features/configuration
> without affecting consumers.
>
> In addition to reviewing choices proposed for majority of POM elements,
> there are 4 elements that require more discussion:
> - contributors
> - mailingLists
> - repositories
> - profiles/activation
>
> Any thoughts?
>
> On the code, IMHO, the only missing part is a test of flatten-maven-plugin
> to check that everything works as expected in any situation.
> And I suppose a discussion on what we do for the xsd
>
> Then we should be able to use this strategy for our own artifacts, before > updating POM model version in any newer Maven version starting with 3.6
> (yay!)
>
> Regards,
>
> Hervé
>
>
> [1]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>
> [2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

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

Reply via email to