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 <
s...@st.informatik.tu-darmstadt.de> wrote:
> Step
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. (m
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
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 hjso
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 {
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
On Sat, Oct 15, 2016 at 4:41 PM, 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
On Sun, 16 Oct 2016 05:12:42 +0200, Christian Schulte
wrote:
Am 10/16/16 um 02:03 schrieb Stephen Connolly:
On 16 Oct 2016, at 00:07, Christian Schulte 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 X
On 17 October 2016 at 01:25, Christian Schulte 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
> appea
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
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
Am 10/15/16 um 16:26 schrieb Stephen Connolly:
> Thinking out loud... perhaps something like
>
> [version="..."] packaging="...">
> [ [relativePath="...']/>
>
> []
> []
> ...
> []
Looking at this from a syntax point of view only, we will run into those
"XML element declaration order h
___
> Von: Stephen Connolly >
> 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 201
Hi Stephen,
My Username is "cdutz".
Chris
Von: Stephen Connolly
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
>
> 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 >
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven D
omment on the page:
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
>
> Chris
>
>
> Von: Stephen Connolly >
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven Developers List
> Betreff: Re: Some though
endet: 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 wrote:
> Am 10/16/16
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 wrote:
> Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> >> On 16 Oct 2016, at 00:07, Christian Schulte wrote:
> >> Any thou
Am 10/16/16 um 02:03 schrieb Stephen Connolly:
>> On 16 Oct 2016, at 00:07, Christian Schulte 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 mode
Sent from my iPhone
> On 16 Oct 2016, at 00:07, Christian Schulte 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 i
On Sunday 16 October 2016, Christian Schulte 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 genera
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 disc
Ahh *version* ok... (glad I asked)
On Saturday 15 October 2016, Robert Scholte 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.c
On Saturday 15 October 2016, Christian Schulte 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 an
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' se
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
wrote:
I assume that is any issues in the FDPFC component... or is there
additional issues I need to scan?
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 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 <
>
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 wrote:
> We should have a
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
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
parti
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 pa
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, a
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
Thinking out loud... perhaps something like
[]
[]
...
[]
[
...
]
[
...
]
...
[
...
]
[
...
]
[
...
]
...
[
...
]
[
]
[
]
[
[]
[
...
]
Sent from my iPhone
> On 15 Oct 2016, at 14:20, 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:
>
> * scope becomes a build time only concern.
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 declar
35 matches
Mail list logo
