You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2016/10/15 13:20:40 UTC
Some thoughts on Maven 5
So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order:
* scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions declare scopes to resolve, we no longer need a compiler:testCompile goal as you can just have a second default execution of compiler:compile with different required scopes and different default configuration... bonus win, I can now add many different layers of test-compilation for integration tests, etc... each pulling in different scopes... ditto for surefire/failsafe... yeah integration tests
* we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)
* mixins can be properly considered... they only affect build time anyway
* Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)
* does Maven 5 build Maven 2/3 projects?
Sent from my iPhone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
If you look at my suggested sample POM, you are able to define additions to
the lifecycle for a specific project or for a mix-in *from the POM*... user
is free to shoot their own foot off if they want to
On 20 October 2016 at 17:24, Andreas Sewe <
sewe@st.informatik.tu-darmstadt.de> wrote:
> Stephen Connolly wrote:
> > * we should let the user define lifecycles directly in the Pom (ok,
> maybe we don't *encourage it*)
>
> More packaging-related phases in the default lifecycle.
>
> I very much like the idea of a standard lifecycle, as it often forces
> you to rethink your project's structure. (me: "Why can't I have two
> compile phases in the same build, on compiling the code generator and
> one compiling the generated code?" Maven: "Because this is not Ant and
> you really have two different projects." me: "Of course; makes much more
> sense!").
>
> Alas, the current default lifecycle doesn't cope well with builds that
> need to selectively (profiles) sign and pack200 their artifacts. See [1]
> for an example where the exact declaration order in the POM matters
> (which it really shouldn't), just because there are no suitable phases
> after "package".
>
> Best wishes,
>
> Andreas
>
> [1] <http://www.codetrails.com/blog/sign-your-eclipse-project>
>
>
>
Re: Some thoughts on Maven 5
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
Stephen Connolly wrote:
> * we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)
More packaging-related phases in the default lifecycle.
I very much like the idea of a standard lifecycle, as it often forces
you to rethink your project's structure. (me: "Why can't I have two
compile phases in the same build, on compiling the code generator and
one compiling the generated code?" Maven: "Because this is not Ant and
you really have two different projects." me: "Of course; makes much more
sense!").
Alas, the current default lifecycle doesn't cope well with builds that
need to selectively (profiles) sign and pack200 their artifacts. See [1]
for an example where the exact declaration order in the POM matters
(which it really shouldn't), just because there are no suitable phases
after "package".
Best wishes,
Andreas
[1] <http://www.codetrails.com/blog/sign-your-eclipse-project>
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Yep. I'll probably take a stab at that while I try and turn this into an
RFC / specification. Is there anything specific you think we could be
adding?
("an" because RFC is pronounced Or Eff See, which starts with a vowel)
On Saturday 15 October 2016, Robert Scholte <rf...@apache.org> wrote:
> We should have a look at the MNG jira issues for those marked for Maven 4
> too
>
> On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> So now that I have a spec for the PDTs drafted, I have been thinking of
>> how that could influence Maven 5. Some things that came to mind, in no
>> particular order:
>>
>> * scope becomes a build time only concern. Thus we can let users define
>> custom scopes in their pom. If we let plugin executions declare scopes to
>> resolve, we no longer need a compiler:testCompile goal as you can just have
>> a second default execution of compiler:compile with different required
>> scopes and different default configuration... bonus win, I can now add many
>> different layers of test-compilation for integration tests, etc... each
>> pulling in different scopes... ditto for surefire/failsafe... yeah
>> integration tests
>>
>> * we should let the user define lifecycles directly in the Pom (ok, maybe
>> we don't *encourage it*)
>>
>> * mixins can be properly considered... they only affect build time anyway
>>
>> * Pom doesn't need to be XML any more... (maybe we want to keep XML
>> though... just a less verbose form)
>>
>> * does Maven 5 build Maven 2/3 projects?
>>
>> Sent from my iPhone
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Ahh *version* ok... (glad I asked)
On Saturday 15 October 2016, Robert Scholte <rf...@apache.org> wrote:
> Those are the component: "Features dependent on POM Format Changes"
> Also have a look at version: "Issues to be reviewed for 4.x"
>
>
> On Sat, 15 Oct 2016 23:13:19 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> I assume that is any issues in the FDPFC component... or is there
>> additional issues I need to scan?
>>
>> On 15 October 2016 at 19:37, Robert Scholte <rf...@apache.org> wrote:
>>
>> We should have a look at the MNG jira issues for those marked for Maven 4
>>> too
>>>
>>>
>>> On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> So now that I have a spec for the PDTs drafted, I have been thinking of
>>>
>>>> how that could influence Maven 5. Some things that came to mind, in no
>>>> particular order:
>>>>
>>>> * scope becomes a build time only concern. Thus we can let users define
>>>> custom scopes in their pom. If we let plugin executions declare scopes
>>>> to
>>>> resolve, we no longer need a compiler:testCompile goal as you can just
>>>> have
>>>> a second default execution of compiler:compile with different required
>>>> scopes and different default configuration... bonus win, I can now add
>>>> many
>>>> different layers of test-compilation for integration tests, etc... each
>>>> pulling in different scopes... ditto for surefire/failsafe... yeah
>>>> integration tests
>>>>
>>>> * we should let the user define lifecycles directly in the Pom (ok,
>>>> maybe
>>>> we don't *encourage it*)
>>>>
>>>> * mixins can be properly considered... they only affect build time
>>>> anyway
>>>>
>>>> * Pom doesn't need to be XML any more... (maybe we want to keep XML
>>>> though... just a less verbose form)
>>>>
>>>> * does Maven 5 build Maven 2/3 projects?
>>>>
>>>> Sent from my iPhone
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Robert Scholte <rf...@apache.org>.
Those are the component: "Features dependent on POM Format Changes"
Also have a look at version: "Issues to be reviewed for 4.x"
On Sat, 15 Oct 2016 23:13:19 +0200, Stephen Connolly
<st...@gmail.com> wrote:
> I assume that is any issues in the FDPFC component... or is there
> additional issues I need to scan?
>
> On 15 October 2016 at 19:37, Robert Scholte <rf...@apache.org> wrote:
>
>> We should have a look at the MNG jira issues for those marked for Maven
>> 4
>> too
>>
>>
>> On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> So now that I have a spec for the PDTs drafted, I have been thinking of
>>> how that could influence Maven 5. Some things that came to mind, in no
>>> particular order:
>>>
>>> * scope becomes a build time only concern. Thus we can let users define
>>> custom scopes in their pom. If we let plugin executions declare scopes
>>> to
>>> resolve, we no longer need a compiler:testCompile goal as you can just
>>> have
>>> a second default execution of compiler:compile with different required
>>> scopes and different default configuration... bonus win, I can now add
>>> many
>>> different layers of test-compilation for integration tests, etc... each
>>> pulling in different scopes... ditto for surefire/failsafe... yeah
>>> integration tests
>>>
>>> * we should let the user define lifecycles directly in the Pom (ok,
>>> maybe
>>> we don't *encourage it*)
>>>
>>> * mixins can be properly considered... they only affect build time
>>> anyway
>>>
>>> * Pom doesn't need to be XML any more... (maybe we want to keep XML
>>> though... just a less verbose form)
>>>
>>> * does Maven 5 build Maven 2/3 projects?
>>>
>>> Sent from my iPhone
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
I assume that is any issues in the FDPFC component... or is there
additional issues I need to scan?
On 15 October 2016 at 19:37, Robert Scholte <rf...@apache.org> wrote:
> We should have a look at the MNG jira issues for those marked for Maven 4
> too
>
>
> On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> So now that I have a spec for the PDTs drafted, I have been thinking of
>> how that could influence Maven 5. Some things that came to mind, in no
>> particular order:
>>
>> * scope becomes a build time only concern. Thus we can let users define
>> custom scopes in their pom. If we let plugin executions declare scopes to
>> resolve, we no longer need a compiler:testCompile goal as you can just have
>> a second default execution of compiler:compile with different required
>> scopes and different default configuration... bonus win, I can now add many
>> different layers of test-compilation for integration tests, etc... each
>> pulling in different scopes... ditto for surefire/failsafe... yeah
>> integration tests
>>
>> * we should let the user define lifecycles directly in the Pom (ok, maybe
>> we don't *encourage it*)
>>
>> * mixins can be properly considered... they only affect build time anyway
>>
>> * Pom doesn't need to be XML any more... (maybe we want to keep XML
>> though... just a less verbose form)
>>
>> * does Maven 5 build Maven 2/3 projects?
>>
>> Sent from my iPhone
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Some thoughts on Maven 5
Posted by Robert Scholte <rf...@apache.org>.
We should have a look at the MNG jira issues for those marked for Maven 4
too
On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly
<st...@gmail.com> wrote:
> So now that I have a spec for the PDTs drafted, I have been thinking of
> how that could influence Maven 5. Some things that came to mind, in no
> particular order:
>
> * scope becomes a build time only concern. Thus we can let users define
> custom scopes in their pom. If we let plugin executions declare scopes
> to resolve, we no longer need a compiler:testCompile goal as you can
> just have a second default execution of compiler:compile with different
> required scopes and different default configuration... bonus win, I can
> now add many different layers of test-compilation for integration tests,
> etc... each pulling in different scopes... ditto for
> surefire/failsafe... yeah integration tests
>
> * we should let the user define lifecycles directly in the Pom (ok,
> maybe we don't *encourage it*)
>
> * mixins can be properly considered... they only affect build time anyway
>
> * Pom doesn't need to be XML any more... (maybe we want to keep XML
> though... just a less verbose form)
>
> * does Maven 5 build Maven 2/3 projects?
>
> Sent from my iPhone
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
On 17 October 2016 at 01:25, Christian Schulte <cs...@schulte.it> wrote:
> Am 10/15/16 um 15:20 schrieb Stephen Connolly:
> > * Pom doesn't need to be XML any more... (maybe we want to keep XML
> though... just a less verbose form)
>
> Maybe XML really isn't the way to go. Whenever I look at an XML file, it
> appears to be a mixture of meta-data, data and behaviour/logic. Last
> being evil most of the time. Does not necessarily need to be contained
> in one single file. Almost never do I see people making use of the X in
> XML.
>
> Btw: You can execute "sh" and get a shell prompt, it would be cool if
> you could execute "mvn" and get a build prompt. Maven uses classloaders
> heavily. Almost no hotspot compiler optimization can be performed by the
> VM due to throwing away classloaders after plugin executions immediately.
>
> sh>ls
> src
> pom.xml
>
> sh>mvn
> Project: Some info from the pom.xml.
> Ready.
> mvn>
>
> If not in a project directory, error message "No project directory.".
>
> mvn> compile
> mvn> clean
> mvn> which compile
> Lifecycle:
> ...other bindings....
> org.apache.maven.plugins:maven-compiler-plugin:x.y.z:compile
> ...other bindings....
> mvn> which testCompile
> Goal:
> org.apache.maven.plugins:maven-compiler-plugin:x.y.z:testCompile
>
>
> What is the PATH environment variable for the shell is a list of plugin
> group ids for the build shell. Maven 5.0 really should work like this.
> Maybe an additional lauchner script is needed "mvnsh" so that the "mvn"
> becomes the batch launcher and "mvnsh" becomes what developers will be
> using most of the time.
>
you mean something like: https://github.com/jdillon/mvnsh ;-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/15/16 um 15:20 schrieb Stephen Connolly:
> * Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)
Maybe XML really isn't the way to go. Whenever I look at an XML file, it
appears to be a mixture of meta-data, data and behaviour/logic. Last
being evil most of the time. Does not necessarily need to be contained
in one single file. Almost never do I see people making use of the X in XML.
Btw: You can execute "sh" and get a shell prompt, it would be cool if
you could execute "mvn" and get a build prompt. Maven uses classloaders
heavily. Almost no hotspot compiler optimization can be performed by the
VM due to throwing away classloaders after plugin executions immediately.
sh>ls
src
pom.xml
sh>mvn
Project: Some info from the pom.xml.
Ready.
mvn>
If not in a project directory, error message "No project directory.".
mvn> compile
mvn> clean
mvn> which compile
Lifecycle:
...other bindings....
org.apache.maven.plugins:maven-compiler-plugin:x.y.z:compile
...other bindings....
mvn> which testCompile
Goal:
org.apache.maven.plugins:maven-compiler-plugin:x.y.z:testCompile
What is the PATH environment variable for the shell is a list of plugin
group ids for the build shell. Maven 5.0 really should work like this.
Maybe an additional lauchner script is needed "mvnsh" so that the "mvn"
becomes the batch launcher and "mvnsh" becomes what developers will be
using most of the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/15/16 um 16:26 schrieb Stephen Connolly:
> Thinking out loud... perhaps something like
>
> <project modelVersion="5.0.0" [groupId="..."] artifactId="..."
> [version="..."] packaging="...">
> [<parent groupId="..." artifactId="..." [version="..."]
> [relativePath="...']/>
>
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> ...
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
Looking at this from a syntax point of view only, we will run into those
"XML element declaration order has an implicit meaning" issues again.
Q: How are conflicts resolved?
A: There is no conflict resolution during building the effective model
(in general - not only for mixins). Mixin elements are just substituted
with what they reference in place - before inheritance processing. After
all mixins have been substituted, the effective model is validated. So
that it's perfectly valid to write redundant mixins like
<mixin groupId="G" artifactId="A" version="V"/>
<mixin groupId="G" artifactId="A" version="V"/>
leading to an invalid effective model that will not pass further
validation. Every identifiable complex content element should support
mixins. Maybe we name that element 'include' following XML schema. Maybe
allow selection of the node(s) to include based on XPapth.
<mixin groupId="G"
artifactId="A"
version="V"
[ xpath="project/lifecycle[id='whatever']" ]/>
Q: How to handle properties? What if someone writes:
<mixing groupId="${something.groupId}"
artifactId="${something.artifactId}"
version="${something.version}"/>
?
A: Current master dependency management import scope uses the effective
properties after inheritance processing. If mixins can bring in
properties, this is no longer possible because there is no way to build
the effective properties without substituting the properties of the
mixins. Current dependency management import does not have this issue
because it cannot import properties. So if properties can be brought in
via mixins, we cannot allow properties in mixins anymore. That's pretty
much the experience I gained by working on the import scope.
>
> [<lifecycle id="..." mode="override|inherit">
Maybe mode="override|append-parent|prepend-parent" or
mode="override|append|prepend" with "append" and "prepend" referencing
the element of the attribute. So that "prepend" equals "append-parent"
and "append" equals "prepend-parent". "prepend-parent"/"append" being
the default. More verbose: inheritance-mode. Also need "final" and
"override" boolean attributes working like the java keyword/annotation.
<lifecycle id="..."
[ mode="override|append|prepend" ] defaults to "append"
[ final="true" ] defaults to false
[ override="true" ] defaults to false>
> <phase id="..." [after="..." | before="..."]/>
> <phase id="..." [after="..." | before="..."]/>
> ...
> <phase id="..." [after="..." | before="..."]/>
"after" or "before" need to be mandatory to avoid order of XML element
declaration issues, if I got the intention of those attributes
correctly. As a general rule of thumb we should validate the model as
strictly as possible in the first release. It's easier to relax a
constraint in a next release then to enforce a new one. That's mainly
where all those warnings in Maven 3 come from. Cannot enforce a new
constraint, so print a warning. Let's try to do it the other way around
this time. Be as strict as possible. If something isn't quite clear,
just add a constraint disallowing the specific usage which can be
relaxed later.
That's mainly what came to mind when reading this the first time.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/15/16 um 19:32 schrieb Stephen Connolly:
> I'm thinking that we still want a dependency management section
I think dependency management is a must have. That's a build tool
feature to allow overriding dependency details from the consumed PDT.
What is different here is that instead of having one global dependency
management, you would need different management possibilities by tree.
So that it becomes possible to manage all trees independently of each other.
Hmm. Sounds like someone just needs to declare the dependency in
question directly in the build pom to make that the dependency to use
for the consumed trees, no? Seems like a build pom dependency already is
the requested management facility. Will be transitive automatically.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
I'm thinking that we still want a dependency management section, so I'd probably just have that as a dependency tag at the top level or aggregate them in a dependencies tag at the top level... mostly that section though becomes about specifying versions... and really it's only useful from the parent pom... and I wonder if the supports concept in the PDT will remove the need...
Needs thinking either way
Sent from my iPhone
> On 15 Oct 2016, at 15:26, Stephen Connolly <st...@gmail.com> wrote:
>
> Thinking out loud... perhaps something like
>
> <project modelVersion="5.0.0" [groupId="..."] artifactId="..." [version="..."] packaging="...">
> [<parent groupId="..." artifactId="..." [version="..."] [relativePath="...']/>
>
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> ...
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
>
> [<lifecycle id="..." mode="override|inherit">
> <phase id="..." [after="..." | before="..."]/>
> <phase id="..." [after="..." | before="..."]/>
> ...
> <phase id="..." [after="..." | before="..."]/>
> </lifecycle>]
> [<lifecycle id="...">
> ...
> </lifecycle>]
> ...
> [<lifecycle id="...">
> ...
> </lifecycle>]
>
> [<scope id="compile" [mode="override|inherit"]>
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> <!-- type is mandatory-->
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
> ...
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
> </scope>]
> [<scope id="...">
> ...
> </scope>]
> ...
> [<scope id="...">
> ...
> </scope>]
>
> [<plugins [mode="override|inherit"]>
> <!-- this is what pluginManagement was -->
> </plugins>]
>
> [<bindings [mode="override|inherit"]>
> <!-- this is what plugins was, we make explicit here that this is the binding of executions into the lifecycles -->
> </bindings>]
>
> [<platform id="..." [mode="override|inherit"]>
> <activation>
> <!-- define how we determine that this platform can be built in the current environment -->
> </activation>
> <!-- allow platform specific mixins -->
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from the root only -->
> [<bindings>
> ...
> </bindings>]
>
> <!-- allow most of the other root tags except platform and packaging and deployment config -->
> </platform>]
> [<platform id="...">
> ...
> </platform>]
> ...
> [<platform id="...">
> ...
> </platform>]
>
> <!-- packaging is only allowed in poms with an id of "parent" or "mixin". It allows a parent/mixin to be used by different packaging ids and define specialized defaults -->
> [<packaging id="...">
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from the root only -->
> [<bindings>
> ...
> </bindings>]
> <!-- allow most of the other root tags except platform and packaging and deployment config -->
> </packaging>]
> [<packaging id="...">
> ...
> </packaging>]
> ...
> [<packaging id="...">
> ...
> </packaging>]
>
> <!-- unsure if we still need profiles -->
> <!-- perhaps we still need properties -->
> <!-- TBD deployment config, repositories, etc -->
>
> </project>
>
>
> Most of the above is just a note for myself based on thoughts I had while going for a walk... but it may inspire others to think about this topic too
>
> -Stephen
>
>
>> On 15 October 2016 at 14:34, Stephen Connolly <st...@gmail.com> wrote:
>>
>>
>> Sent from my iPhone
>>
>> > On 15 Oct 2016, at 14:20, Stephen Connolly <st...@gmail.com> wrote:
>> >
>> > So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order:
>> >
>> > * scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions declare scopes to resolve, we no longer need a compiler:testCompile goal as you can just have a second default execution of compiler:compile with different required scopes and different default configuration... bonus win, I can now add many different layers of test-compilation for integration tests, etc... each pulling in different scopes... ditto for surefire/failsafe... yeah integration tests
>> >
>> > * we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)
>> >
>> > * mixins can be properly considered... they only affect build time anyway
>>
>> Mixins should get their own packaging type
>>
>> >
>> > * Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)
>> >
>> > * does Maven 5 build Maven 2/3 projects?
>>
>> We may want to keep XML but move to attributes... in which case it would be super awesome if Maven 3.4.x didn't see project/modelVersion then it should check for same as attribute and then say: you need a newer Maven to build/inherit this
>>
>> >
>> > Sent from my iPhone
>
Re: Some thoughts on Maven 5
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
Stephen Connolly wrote:
> https://hjson.org/ was what I had in mind... but it would be awesome if for
> dependencies we didn't have to quote, e.g.
>
> scopes {
> compile: [
> org.slf4j:slf4j-api::1.8.0::jar
> ]
> test: [
> junit:junit::4.12::jar
> ]
> }
>
> which is not valid hjson as in hjson you would have to write
>
> scopes {
> compile: [
> "org.slf4j:slf4j-api::1.8.0::jar"
> ]
> test: [
> "junit:junit::4.12::jar"
> ]
> }
Personally, I still like XML better (Schema-based editing support out of
the box :-), although the current POM 4.0.0 format with its almost
exclusive use of elements over attributes consumes too much vertical space.
Best wishes,
Andreas
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
https://hjson.org/ was what I had in mind... but it would be awesome if for
dependencies we didn't have to quote, e.g.
scopes {
compile: [
org.slf4j:slf4j-api::1.8.0::jar
]
test: [
junit:junit::4.12::jar
]
}
which is not valid hjson as in hjson you would have to write
scopes {
compile: [
"org.slf4j:slf4j-api::1.8.0::jar"
]
test: [
"junit:junit::4.12::jar"
]
}
On 20 October 2016 at 08:46, Andreas Sewe <
sewe@st.informatik.tu-darmstadt.de> wrote:
> Stephen Connolly wrote:
> > Hmmm shower thinking now has me pondering if a custom DSL might be
> > better... something close to human friendly JSON with exceptions for
> > dependency declaration so that they are always specified as g:a:p:v:c:t
> > with the optional p and c being empty, e.g. g:a::v::t
>
> For me, human-friendly would mean "allows comments", which is something
> that plain JSON doesn't have but XML has (and which I use a lot in my
> POMs).
>
> Just something to think about.
>
> Best wishes,
>
> Andreas
>
>
>
Re: Some thoughts on Maven 5
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
Stephen Connolly wrote:
> Hmmm shower thinking now has me pondering if a custom DSL might be
> better... something close to human friendly JSON with exceptions for
> dependency declaration so that they are always specified as g:a:p:v:c:t
> with the optional p and c being empty, e.g. g:a::v::t
For me, human-friendly would mean "allows comments", which is something
that plain JSON doesn't have but XML has (and which I use a lot in my POMs).
Just something to think about.
Best wishes,
Andreas
Re: Some thoughts on Maven 5
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Sat, Oct 15, 2016 at 4:41 PM, Stephen Connolly
<st...@gmail.com> wrote:
> Hmmm shower thinking now has me pondering if a custom DSL might be
> better... something close to human friendly JSON with exceptions for
> dependency declaration so that they are always specified as g:a:p:v:c:t
> with the optional p and c being empty, e.g. g:a::v::t
Please, keep in mind that this would most likely change *all* build
tools, which are dealing with the POM contents right now, including
such trivial things like auto completion in M2E while editing the POM.
IMO, this would be a major hazzle to all users, and we should avoid
that. There isn't so much to gain from changing the well understood
XML format of the POM.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Hmmm shower thinking now has me pondering if a custom DSL might be
better... something close to human friendly JSON with exceptions for
dependency declaration so that they are always specified as g:a:p:v:c:t
with the optional p and c being empty, e.g. g:a::v::t
On 15 October 2016 at 15:26, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Thinking out loud... perhaps something like
>
> <project modelVersion="5.0.0" [groupId="..."] artifactId="..."
> [version="..."] packaging="...">
> [<parent groupId="..." artifactId="..." [version="..."]
> [relativePath="...']/>
>
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> ...
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
>
> [<lifecycle id="..." mode="override|inherit">
> <phase id="..." [after="..." | before="..."]/>
> <phase id="..." [after="..." | before="..."]/>
> ...
> <phase id="..." [after="..." | before="..."]/>
> </lifecycle>]
> [<lifecycle id="...">
> ...
> </lifecycle>]
> ...
> [<lifecycle id="...">
> ...
> </lifecycle>]
>
> [<scope id="compile" [mode="override|inherit"]>
> <dependency groupId="..." artifactId="..." [platformId="..."]
> version="..." [classifier="..."] type="..."/> <!-- type is mandatory-->
> <dependency groupId="..." artifactId="..." [platformId="..."]
> version="..." [classifier="..."] type="..."/>
> ...
> <dependency groupId="..." artifactId="..." [platformId="..."]
> version="..." [classifier="..."] type="..."/>
> </scope>]
> [<scope id="...">
> ...
> </scope>]
> ...
> [<scope id="...">
> ...
> </scope>]
>
> [<plugins [mode="override|inherit"]>
> <!-- this is what pluginManagement was -->
> </plugins>]
>
> [<bindings [mode="override|inherit"]>
> <!-- this is what plugins was, we make explicit here that this is the
> binding of executions into the lifecycles -->
> </bindings>]
>
> [<platform id="..." [mode="override|inherit"]>
> <activation>
> <!-- define how we determine that this platform can be built in the
> current environment -->
> </activation>
> <!-- allow platform specific mixins -->
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from
> the root only -->
> [<bindings>
> ...
> </bindings>]
>
> <!-- allow most of the other root tags except platform and packaging
> and deployment config -->
> </platform>]
> [<platform id="...">
> ...
> </platform>]
> ...
> [<platform id="...">
> ...
> </platform>]
>
> <!-- packaging is only allowed in poms with an id of "parent" or
> "mixin". It allows a parent/mixin to be used by different packaging ids and
> define specialized defaults -->
> [<packaging id="...">
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from
> the root only -->
> [<bindings>
> ...
> </bindings>]
> <!-- allow most of the other root tags except platform and packaging
> and deployment config -->
> </packaging>]
> [<packaging id="...">
> ...
> </packaging>]
> ...
> [<packaging id="...">
> ...
> </packaging>]
>
> <!-- unsure if we still need profiles -->
> <!-- perhaps we still need properties -->
> <!-- TBD deployment config, repositories, etc -->
>
> </project>
>
>
> Most of the above is just a note for myself based on thoughts I had while
> going for a walk... but it may inspire others to think about this topic too
>
> -Stephen
>
>
> On 15 October 2016 at 14:34, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> > On 15 Oct 2016, at 14:20, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>> >
>> > So now that I have a spec for the PDTs drafted, I have been thinking of
>> how that could influence Maven 5. Some things that came to mind, in no
>> particular order:
>> >
>> > * scope becomes a build time only concern. Thus we can let users define
>> custom scopes in their pom. If we let plugin executions declare scopes to
>> resolve, we no longer need a compiler:testCompile goal as you can just have
>> a second default execution of compiler:compile with different required
>> scopes and different default configuration... bonus win, I can now add many
>> different layers of test-compilation for integration tests, etc... each
>> pulling in different scopes... ditto for surefire/failsafe... yeah
>> integration tests
>> >
>> > * we should let the user define lifecycles directly in the Pom (ok,
>> maybe we don't *encourage it*)
>> >
>> > * mixins can be properly considered... they only affect build time
>> anyway
>>
>> Mixins should get their own packaging type
>>
>> >
>> > * Pom doesn't need to be XML any more... (maybe we want to keep XML
>> though... just a less verbose form)
>> >
>> > * does Maven 5 build Maven 2/3 projects?
>>
>> We may want to keep XML but move to attributes... in which case it would
>> be super awesome if Maven 3.4.x didn't see project/modelVersion then it
>> should check for same as attribute and then say: you need a newer Maven to
>> build/inherit this
>>
>> >
>> > Sent from my iPhone
>>
>
>
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
So building the effective build time model would be:
Start with parent, add in matching packaging from parent, in Pom order, add each mix-in (including matching packaging from mix-in before processing subsequent mix-ins), finally apply local pom.
To compute effective lifecycle and build plan, allow platform activation to be considered... each platform is like a mini-sub project that can "run in parallel" (yes I need to doc this better...)
Sent from my iPhone
> On 15 Oct 2016, at 15:26, Stephen Connolly <st...@gmail.com> wrote:
>
> Thinking out loud... perhaps something like
>
> <project modelVersion="5.0.0" [groupId="..."] artifactId="..." [version="..."] packaging="...">
> [<parent groupId="..." artifactId="..." [version="..."] [relativePath="...']/>
>
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> ...
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
>
> [<lifecycle id="..." mode="override|inherit">
> <phase id="..." [after="..." | before="..."]/>
> <phase id="..." [after="..." | before="..."]/>
> ...
> <phase id="..." [after="..." | before="..."]/>
> </lifecycle>]
> [<lifecycle id="...">
> ...
> </lifecycle>]
> ...
> [<lifecycle id="...">
> ...
> </lifecycle>]
>
> [<scope id="compile" [mode="override|inherit"]>
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> <!-- type is mandatory-->
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
> ...
> <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
> </scope>]
> [<scope id="...">
> ...
> </scope>]
> ...
> [<scope id="...">
> ...
> </scope>]
>
> [<plugins [mode="override|inherit"]>
> <!-- this is what pluginManagement was -->
> </plugins>]
>
> [<bindings [mode="override|inherit"]>
> <!-- this is what plugins was, we make explicit here that this is the binding of executions into the lifecycles -->
> </bindings>]
>
> [<platform id="..." [mode="override|inherit"]>
> <activation>
> <!-- define how we determine that this platform can be built in the current environment -->
> </activation>
> <!-- allow platform specific mixins -->
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from the root only -->
> [<bindings>
> ...
> </bindings>]
>
> <!-- allow most of the other root tags except platform and packaging and deployment config -->
> </platform>]
> [<platform id="...">
> ...
> </platform>]
> ...
> [<platform id="...">
> ...
> </platform>]
>
> <!-- packaging is only allowed in poms with an id of "parent" or "mixin". It allows a parent/mixin to be used by different packaging ids and define specialized defaults -->
> [<packaging id="...">
> [<mixin groupId="..." artifactId="..." [version="..."]/>]
> <!-- allow platform specific lifecycles -->
> [<lifecycle id="...">
> ...
> </lifecycle>]
> <!-- allow platform specific dependencies -->
> [<scope>
> ...
> </scope>]
> <!-- allow platform specific bindings... but plugin management is from the root only -->
> [<bindings>
> ...
> </bindings>]
> <!-- allow most of the other root tags except platform and packaging and deployment config -->
> </packaging>]
> [<packaging id="...">
> ...
> </packaging>]
> ...
> [<packaging id="...">
> ...
> </packaging>]
>
> <!-- unsure if we still need profiles -->
> <!-- perhaps we still need properties -->
> <!-- TBD deployment config, repositories, etc -->
>
> </project>
>
>
> Most of the above is just a note for myself based on thoughts I had while going for a walk... but it may inspire others to think about this topic too
>
> -Stephen
>
>
>> On 15 October 2016 at 14:34, Stephen Connolly <st...@gmail.com> wrote:
>>
>>
>> Sent from my iPhone
>>
>> > On 15 Oct 2016, at 14:20, Stephen Connolly <st...@gmail.com> wrote:
>> >
>> > So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order:
>> >
>> > * scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions declare scopes to resolve, we no longer need a compiler:testCompile goal as you can just have a second default execution of compiler:compile with different required scopes and different default configuration... bonus win, I can now add many different layers of test-compilation for integration tests, etc... each pulling in different scopes... ditto for surefire/failsafe... yeah integration tests
>> >
>> > * we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)
>> >
>> > * mixins can be properly considered... they only affect build time anyway
>>
>> Mixins should get their own packaging type
>>
>> >
>> > * Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)
>> >
>> > * does Maven 5 build Maven 2/3 projects?
>>
>> We may want to keep XML but move to attributes... in which case it would be super awesome if Maven 3.4.x didn't see project/modelVersion then it should check for same as attribute and then say: you need a newer Maven to build/inherit this
>>
>> >
>> > Sent from my iPhone
>
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Thinking out loud... perhaps something like
<project modelVersion="5.0.0" [groupId="..."] artifactId="..."
[version="..."] packaging="...">
[<parent groupId="..." artifactId="..." [version="..."]
[relativePath="...']/>
[<mixin groupId="..." artifactId="..." [version="..."]/>]
[<mixin groupId="..." artifactId="..." [version="..."]/>]
...
[<mixin groupId="..." artifactId="..." [version="..."]/>]
[<lifecycle id="..." mode="override|inherit">
<phase id="..." [after="..." | before="..."]/>
<phase id="..." [after="..." | before="..."]/>
...
<phase id="..." [after="..." | before="..."]/>
</lifecycle>]
[<lifecycle id="...">
...
</lifecycle>]
...
[<lifecycle id="...">
...
</lifecycle>]
[<scope id="compile" [mode="override|inherit"]>
<dependency groupId="..." artifactId="..." [platformId="..."]
version="..." [classifier="..."] type="..."/> <!-- type is mandatory-->
<dependency groupId="..." artifactId="..." [platformId="..."]
version="..." [classifier="..."] type="..."/>
...
<dependency groupId="..." artifactId="..." [platformId="..."]
version="..." [classifier="..."] type="..."/>
</scope>]
[<scope id="...">
...
</scope>]
...
[<scope id="...">
...
</scope>]
[<plugins [mode="override|inherit"]>
<!-- this is what pluginManagement was -->
</plugins>]
[<bindings [mode="override|inherit"]>
<!-- this is what plugins was, we make explicit here that this is the
binding of executions into the lifecycles -->
</bindings>]
[<platform id="..." [mode="override|inherit"]>
<activation>
<!-- define how we determine that this platform can be built in the
current environment -->
</activation>
<!-- allow platform specific mixins -->
[<mixin groupId="..." artifactId="..." [version="..."]/>]
<!-- allow platform specific lifecycles -->
[<lifecycle id="...">
...
</lifecycle>]
<!-- allow platform specific dependencies -->
[<scope>
...
</scope>]
<!-- allow platform specific bindings... but plugin management is from
the root only -->
[<bindings>
...
</bindings>]
<!-- allow most of the other root tags except platform and packaging
and deployment config -->
</platform>]
[<platform id="...">
...
</platform>]
...
[<platform id="...">
...
</platform>]
<!-- packaging is only allowed in poms with an id of "parent" or "mixin".
It allows a parent/mixin to be used by different packaging ids and define
specialized defaults -->
[<packaging id="...">
[<mixin groupId="..." artifactId="..." [version="..."]/>]
<!-- allow platform specific lifecycles -->
[<lifecycle id="...">
...
</lifecycle>]
<!-- allow platform specific dependencies -->
[<scope>
...
</scope>]
<!-- allow platform specific bindings... but plugin management is from
the root only -->
[<bindings>
...
</bindings>]
<!-- allow most of the other root tags except platform and packaging
and deployment config -->
</packaging>]
[<packaging id="...">
...
</packaging>]
...
[<packaging id="...">
...
</packaging>]
<!-- unsure if we still need profiles -->
<!-- perhaps we still need properties -->
<!-- TBD deployment config, repositories, etc -->
</project>
Most of the above is just a note for myself based on thoughts I had while
going for a walk... but it may inspire others to think about this topic too
-Stephen
On 15 October 2016 at 14:34, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
>
> Sent from my iPhone
>
> > On 15 Oct 2016, at 14:20, Stephen Connolly <stephen.alan.connolly@gmail.
> com> wrote:
> >
> > So now that I have a spec for the PDTs drafted, I have been thinking of
> how that could influence Maven 5. Some things that came to mind, in no
> particular order:
> >
> > * scope becomes a build time only concern. Thus we can let users define
> custom scopes in their pom. If we let plugin executions declare scopes to
> resolve, we no longer need a compiler:testCompile goal as you can just have
> a second default execution of compiler:compile with different required
> scopes and different default configuration... bonus win, I can now add many
> different layers of test-compilation for integration tests, etc... each
> pulling in different scopes... ditto for surefire/failsafe... yeah
> integration tests
> >
> > * we should let the user define lifecycles directly in the Pom (ok,
> maybe we don't *encourage it*)
> >
> > * mixins can be properly considered... they only affect build time anyway
>
> Mixins should get their own packaging type
>
> >
> > * Pom doesn't need to be XML any more... (maybe we want to keep XML
> though... just a less verbose form)
> >
> > * does Maven 5 build Maven 2/3 projects?
>
> We may want to keep XML but move to attributes... in which case it would
> be super awesome if Maven 3.4.x didn't see project/modelVersion then it
> should check for same as attribute and then say: you need a newer Maven to
> build/inherit this
>
> >
> > Sent from my iPhone
>
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my iPhone
> On 15 Oct 2016, at 14:20, Stephen Connolly <st...@gmail.com> wrote:
>
> So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order:
>
> * scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions declare scopes to resolve, we no longer need a compiler:testCompile goal as you can just have a second default execution of compiler:compile with different required scopes and different default configuration... bonus win, I can now add many different layers of test-compilation for integration tests, etc... each pulling in different scopes... ditto for surefire/failsafe... yeah integration tests
>
> * we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)
>
> * mixins can be properly considered... they only affect build time anyway
Mixins should get their own packaging type
>
> * Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)
>
> * does Maven 5 build Maven 2/3 projects?
We may want to keep XML but move to attributes... in which case it would be super awesome if Maven 3.4.x didn't see project/modelVersion then it should check for same as attribute and then say: you need a newer Maven to build/inherit this
>
> Sent from my iPhone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
On Sunday 16 October 2016, Christian Schulte <cs...@schulte.it> wrote:
> Am 10/16/16 um 00:57 schrieb Stephen Connolly:
> > We only have to generate a "consumer pom" in modelVersion 4.0.0... and
> that
> > need only be best effort, and will be generated off the PDT ... the new
> Pom
> > schema is what drives generating the PDT
>
> If a scope is used not known to POM 4.0.0, just discard it during
> generating POM 4.0.0. Things like that. Someone wanting to support
> building with Maven < 5 as well can provide a 4.0.0 POM manually besides
> the new build pom. Any thoughts about how to name that new build pom?
> maven.xml? So someone can have pom.xml besides maven.xml and can build
> with Maven < 5 and >= 5. For remote deployment Maven >= 5 should be
> used. We cannot stop someone from deploying with Maven < 5 and then one
> more time again with Maven >= 5. Maybe repository managers need to be
> aware of that somehow. Disallow deployments with Maven < 5 or disallow
> deployments with Maven >= 5 if already deployed with Maven < 5. Or just
> name the new file 'pom.xml' again to avoid that situation right from the
> start. Maven < 5 just cannot parse it and fails. Best we can do, I think.
You are over-thinking
My question was: should Maven 5.0.0 be able to build a Maven 2.0-3.x pom?
We have to be able to parse them anyway - for the case that dependencies do
not have a PDT...
Its debatable whether we should allow them as parents...
We probably will want to allow using [2.0,5.0) plugins with [5.0,) projects
(as otherwise "I can't use maven 5 because my favourite plugin doesn't work
with it)
If we have all those constraints... is it that much extra work to be able
to build them too? (Or maybe we just pull down a compat layer that uses
embedder to build those older ones)
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Karl/John can you give permissions to edit (or at least comment) to
Christofer
Also perhaps we should add all the PMC as owners of the space
On Sunday 16 October 2016, Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi Stephen,
>
>
> My Username is "cdutz".
>
>
> Chris
>
> ________________________________
> Von: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> Gesendet: Sonntag, 16. Oktober 2016 13:49:39
> An: Maven Developers List
> Betreff: Re: Some thoughts on Maven 5
>
> Let us know your cwiki username and we can grant permission to edit
>
> On Sunday 16 October 2016, Christofer Dutz <christofer.dutz@c-ware.de
> <javascript:;>>
> wrote:
>
> > Hi guys,
> >
> >
> > I just wanted to add one thing to the list:
> >
> > https://issues.apache.org/jira/browse/MNG-6107
> >
> > But I can't edit or comment on the page:
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/POM+
> Model+Version+5.0.0
> >
> >
> > Chris
> >
> > ________________________________
> > Von: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>
> <javascript:;>>
> > Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> > An: Maven Developers List
> > Betreff: Re: Some thoughts on Maven 5
> >
> > Adding a section to the wiki to help track this
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/POM+
> Model+Version+5.0.0
> >
> > On 16 October 2016 at 04:12, Christian Schulte <cs@schulte.it
> <javascript:;>
> > <javascript:;>> wrote:
> >
> > > Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> > > >> On 16 Oct 2016, at 00:07, Christian Schulte <cs@schulte.it
> <javascript:;>
> > <javascript:;>> wrote:
> > > >> Any thoughts about how to name that new build pom?
> > > >
> > > > project.mvn or pom.mvn
> > > >
> > > > But only if we move to a non-xml DSL
> > > >
> > > > If we are still XML then I say stick with pom.xml and sniff the
> > > modelVersion
> > >
> > > +1
> > >
> > > Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> > > be cool. It's not a must have in my opinion. If this would degrade the
> > > possibilities of Maven 5+, I'd say it's worth giving up on it.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;> <javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > <javascript:;>
> > >
> > >
> >
>
>
> --
> Sent from my phone
>
--
Sent from my phone
AW: Some thoughts on Maven 5
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Stephen,
My Username is "cdutz".
Chris
________________________________
Von: Stephen Connolly <st...@gmail.com>
Gesendet: Sonntag, 16. Oktober 2016 13:49:39
An: Maven Developers List
Betreff: Re: Some thoughts on Maven 5
Let us know your cwiki username and we can grant permission to edit
On Sunday 16 October 2016, Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi guys,
>
>
> I just wanted to add one thing to the list:
>
> https://issues.apache.org/jira/browse/MNG-6107
>
> But I can't edit or comment on the page:
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
>
> Chris
>
> ________________________________
> Von: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven Developers List
> Betreff: Re: Some thoughts on Maven 5
>
> Adding a section to the wiki to help track this
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
> On 16 October 2016 at 04:12, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
>
> > Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> > >> On 16 Oct 2016, at 00:07, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
> > >> Any thoughts about how to name that new build pom?
> > >
> > > project.mvn or pom.mvn
> > >
> > > But only if we move to a non-xml DSL
> > >
> > > If we are still XML then I say stick with pom.xml and sniff the
> > modelVersion
> >
> > +1
> >
> > Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> > be cool. It's not a must have in my opinion. If this would degrade the
> > possibilities of Maven 5+, I'd say it's worth giving up on it.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Let us know your cwiki username and we can grant permission to edit
On Sunday 16 October 2016, Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi guys,
>
>
> I just wanted to add one thing to the list:
>
> https://issues.apache.org/jira/browse/MNG-6107
>
> But I can't edit or comment on the page:
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
>
> Chris
>
> ________________________________
> Von: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven Developers List
> Betreff: Re: Some thoughts on Maven 5
>
> Adding a section to the wiki to help track this
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
> On 16 October 2016 at 04:12, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
>
> > Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> > >> On 16 Oct 2016, at 00:07, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
> > >> Any thoughts about how to name that new build pom?
> > >
> > > project.mvn or pom.mvn
> > >
> > > But only if we move to a non-xml DSL
> > >
> > > If we are still XML then I say stick with pom.xml and sniff the
> > modelVersion
> >
> > +1
> >
> > Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> > be cool. It's not a must have in my opinion. If this would degrade the
> > possibilities of Maven 5+, I'd say it's worth giving up on it.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
I'm kind of against includes and import... I favour mix-ins as the solution
to that set of problems...
Additionally I see all the "hacks" people have evolved as been
significantly less relevant with PDTs including both ranges and hints as
well as the provides and supports declarations... but yes we need to
address what we see as the "resolution" of these issues is in the 5.0.0+
world
On Sunday 16 October 2016, Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi guys,
>
>
> I just wanted to add one thing to the list:
>
> https://issues.apache.org/jira/browse/MNG-6107
>
> But I can't edit or comment on the page:
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
>
> Chris
>
> ________________________________
> Von: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven Developers List
> Betreff: Re: Some thoughts on Maven 5
>
> Adding a section to the wiki to help track this
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
> On 16 October 2016 at 04:12, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
>
> > Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> > >> On 16 Oct 2016, at 00:07, Christian Schulte <cs@schulte.it
> <javascript:;>> wrote:
> > >> Any thoughts about how to name that new build pom?
> > >
> > > project.mvn or pom.mvn
> > >
> > > But only if we move to a non-xml DSL
> > >
> > > If we are still XML then I say stick with pom.xml and sniff the
> > modelVersion
> >
> > +1
> >
> > Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> > be cool. It's not a must have in my opinion. If this would degrade the
> > possibilities of Maven 5+, I'd say it's worth giving up on it.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>
--
Sent from my phone
AW: Some thoughts on Maven 5
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi guys,
I just wanted to add one thing to the list:
https://issues.apache.org/jira/browse/MNG-6107
But I can't edit or comment on the page:
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
Chris
________________________________
Von: Stephen Connolly <st...@gmail.com>
Gesendet: Sonntag, 16. Oktober 2016 13:33:29
An: Maven Developers List
Betreff: Re: Some thoughts on Maven 5
Adding a section to the wiki to help track this
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
On 16 October 2016 at 04:12, Christian Schulte <cs...@schulte.it> wrote:
> Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> >> On 16 Oct 2016, at 00:07, Christian Schulte <cs...@schulte.it> wrote:
> >> Any thoughts about how to name that new build pom?
> >
> > project.mvn or pom.mvn
> >
> > But only if we move to a non-xml DSL
> >
> > If we are still XML then I say stick with pom.xml and sniff the
> modelVersion
>
> +1
>
> Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> be cool. It's not a must have in my opinion. If this would degrade the
> possibilities of Maven 5+, I'd say it's worth giving up on it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Adding a section to the wiki to help track this
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
On 16 October 2016 at 04:12, Christian Schulte <cs...@schulte.it> wrote:
> Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> >> On 16 Oct 2016, at 00:07, Christian Schulte <cs...@schulte.it> wrote:
> >> Any thoughts about how to name that new build pom?
> >
> > project.mvn or pom.mvn
> >
> > But only if we move to a non-xml DSL
> >
> > If we are still XML then I say stick with pom.xml and sniff the
> modelVersion
>
> +1
>
> Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> be cool. It's not a must have in my opinion. If this would degrade the
> possibilities of Maven 5+, I'd say it's worth giving up on it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Some thoughts on Maven 5
Posted by Robert Scholte <rf...@apache.org>.
On Sun, 16 Oct 2016 05:12:42 +0200, Christian Schulte <cs...@schulte.it>
wrote:
> Am 10/16/16 um 02:03 schrieb Stephen Connolly:
>>> On 16 Oct 2016, at 00:07, Christian Schulte <cs...@schulte.it> wrote:
>>> Any thoughts about how to name that new build pom?
>>
>> project.mvn or pom.mvn
>>
>> But only if we move to a non-xml DSL
>>
>> If we are still XML then I say stick with pom.xml and sniff the
>> modelVersion
>
> +1
>
> Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> be cool. It's not a must have in my opinion. If this would degrade the
> possibilities of Maven 5+, I'd say it's worth giving up on it.
>
>
I've been working on an improvement of modello which makes it possible to
read a file once, being able to detect the version and verify if all
elements and values indeed match that version. Once we want to start on
the multi-version support I should have a look at it again and apply it.
Robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/16/16 um 02:03 schrieb Stephen Connolly:
>> On 16 Oct 2016, at 00:07, Christian Schulte <cs...@schulte.it> wrote:
>> Any thoughts about how to name that new build pom?
>
> project.mvn or pom.mvn
>
> But only if we move to a non-xml DSL
>
> If we are still XML then I say stick with pom.xml and sniff the modelVersion
+1
Being able to build all Maven 2+ kinds of projects using Maven 5+ would
be cool. It's not a must have in my opinion. If this would degrade the
possibilities of Maven 5+, I'd say it's worth giving up on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my iPhone
> On 16 Oct 2016, at 00:07, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 10/16/16 um 00:57 schrieb Stephen Connolly:
>> We only have to generate a "consumer pom" in modelVersion 4.0.0... and that
>> need only be best effort, and will be generated off the PDT ... the new Pom
>> schema is what drives generating the PDT
>
> If a scope is used not known to POM 4.0.0, just discard it during
> generating POM 4.0.0.
Nope. No need. The consumer Pom will only list the direct dependencies from the PDT for the "primary" artifact... they will all be just compile scope.
> Things like that. Someone wanting to support
> building with Maven < 5 as well can provide a 4.0.0 POM manually besides
> the new build pom.
My question is really:
Say I have a bunch of projects, half need Maven 3 half need Maven 5... do I have to use something like rbenv to switch Maven every time I Move directory? Or can I just leave Maven home as Maven 5 and it will work for both projects?
> Any thoughts about how to name that new build pom?
project.mvn or pom.mvn
But only if we move to a non-xml DSL
If we are still XML then I say stick with pom.xml and sniff the modelVersion
> maven.xml? So someone can have pom.xml besides maven.xml and can build
> with Maven < 5 and >= 5. For remote deployment Maven >= 5 should be
> used. We cannot stop someone from deploying with Maven < 5 and then one
> more time again with Maven >= 5. Maybe repository managers need to be
> aware of that somehow. Disallow deployments with Maven < 5 or disallow
> deployments with Maven >= 5 if already deployed with Maven < 5. Or just
> name the new file 'pom.xml' again to avoid that situation right from the
> start. Maven < 5 just cannot parse it and fails. Best we can do, I think.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/16/16 um 00:57 schrieb Stephen Connolly:
> We only have to generate a "consumer pom" in modelVersion 4.0.0... and that
> need only be best effort, and will be generated off the PDT ... the new Pom
> schema is what drives generating the PDT
If a scope is used not known to POM 4.0.0, just discard it during
generating POM 4.0.0. Things like that. Someone wanting to support
building with Maven < 5 as well can provide a 4.0.0 POM manually besides
the new build pom. Any thoughts about how to name that new build pom?
maven.xml? So someone can have pom.xml besides maven.xml and can build
with Maven < 5 and >= 5. For remote deployment Maven >= 5 should be
used. We cannot stop someone from deploying with Maven < 5 and then one
more time again with Maven >= 5. Maybe repository managers need to be
aware of that somehow. Disallow deployments with Maven < 5 or disallow
deployments with Maven >= 5 if already deployed with Maven < 5. Or just
name the new file 'pom.xml' again to avoid that situation right from the
start. Maven < 5 just cannot parse it and fails. Best we can do, I think.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Stephen Connolly <st...@gmail.com>.
On Saturday 15 October 2016, Christian Schulte <cs...@schulte.it> wrote:
> Am 10/15/16 um 15:20 schrieb Stephen Connolly:
> > * does Maven 5 build Maven 2/3 projects?
>
> No need for this, IMHO. Maven 2 could not build Maven 1 projects. Maven
> 3 could build Maven 2 projects but added warnings for various things and
> some internal model transformations like for the 'reporting' section.
> I'd consider that new schema not a new model version, but a whole new
> model. It's hard to generate a 4.0.0 POM from that already.
> Compatibility with POM 4.0.0 should not stop us from changing things. If
> we cannot generate a POM 4.0.0 from the new model, then let's get rid of
> that POM 4.0.0 and not make that influence the new model. Just my
> opinion, of course.
We only have to generate a "consumer pom" in modelVersion 4.0.0... and that
need only be best effort, and will be generated off the PDT ... the new Pom
schema is what drives generating the PDT
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: Some thoughts on Maven 5
Posted by Christian Schulte <cs...@schulte.it>.
Am 10/15/16 um 15:20 schrieb Stephen Connolly:
> * does Maven 5 build Maven 2/3 projects?
No need for this, IMHO. Maven 2 could not build Maven 1 projects. Maven
3 could build Maven 2 projects but added warnings for various things and
some internal model transformations like for the 'reporting' section.
I'd consider that new schema not a new model version, but a whole new
model. It's hard to generate a 4.0.0 POM from that already.
Compatibility with POM 4.0.0 should not stop us from changing things. If
we cannot generate a POM 4.0.0 from the new model, then let's get rid of
that POM 4.0.0 and not make that influence the new model. Just my
opinion, of course.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts on Maven 5
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
Stephen Connolly wrote:
> So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order:
May I suggest support for custom "transformation rules" when inheriting
a value from the parent POM. Have a look at what I outlined in MNG-5951 [1].
The current solution for project/src/url, project/scm/connection, etc.
[2] is horrible:
1.) Having to define attributes like
@child.scm.developerConnection.inherit.append.path on the parent rather
than the child element they apply to leads to ridiculously long
attribute names, but had to be done to avoid changing the Modello model
[3]. Placing those on the element they actually refer to would avoid any
ambiguity.
2.) Attributes like @child.scm.developerConnection.inherit.append.path
solve special cases for special elements. IMHO, there should be a
generic and customizable way to describe how a POM's values are inherited.
Just my 2 cents,
Andreas
[1]
<https://issues.apache.org/jira/browse/MNG-5951?focusedCommentId=15190890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15190890>
[2] <https://issues.apache.org/jira/browse/MNG-6059>
[3]
<https://issues.apache.org/jira/browse/MNG-6059?focusedCommentId=15373650&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15373650>