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
