Noting an idea for Maven 5.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Noting an idea for Maven 5.0.0

stephenconnolly
So I am thinking the lifecycle should support the concept of *optional*
phases.

If no subsequent phase depends on the output of an optional phase, and the
optional phase was not explicitly called out on the invocation request,
then Maven could drop the phase.

By way of example, all the current test phases: generate-test-resources,
test-compile, test, etc could be optional. The verify phase would depend on
the result of the test phase.

This means that: `mvn package` could bypass even doing anything with the
tests (unless somebody bound jar:test-jar to the package phase - which
would mean that test-compile was required but not test)

If you wanted the tests run, you either go `mvn test package` (I think we
can dedup redundant phases from the request) or `mvn verify`

What this gets us is the ability to build targeted portions of the reactor
without requiring that stuff be installed.

Another idea I have is to allow @groupId:artifactId or @module/path (with
wild cards for each) as suffixes to goals and phases...

So

mvn test@foo:bar-*

Would load the whole reactor and apply the test phase to all modules in
groupId foo with artifactIds starting with bar- but ensuring that any
within reactor requirements have been minimally built...

so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
include bringing manchu-api as far as the package phase (when the jar file
is produced)

If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar) then
the reactor would also include bringing manchu-impl as far as
process-classes (when the classes dir is "produced" because the requirement
is for either classes or jar)

Of course all the above magically needs a simple sintax for users and easy
to understand docs... both of which we may not be able to achieve... but
the above goal is something I think we would love to have in 5.0.0... (and
a pink fluffy unicorn too)
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Noting an idea for Maven 5.0.0

rfscholte
This kind of overlaps with MNG-6118, which is also about the path to the  
end-result.
I haven't thought about excluding some pieces of the lifecycle by default,  
but we should focus more on the result.

Maven should react much better on the execute location within a  
multimodule project and what you really want to happen here.
As an example I use starting jetty on the war of a multimodule project,  
which is now requires 2 steps: mvn install from root and jetty:run n th  
specific module.

I think MNG-6118 would be a first step before getting this up and running.

Robert

[1]  
https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/MNG-6118

On Sat, 18 Mar 2017 16:46:28 +0100, Stephen Connolly  
<[hidden email]> wrote:

> So I am thinking the lifecycle should support the concept of *optional*
> phases.
>
> If no subsequent phase depends on the output of an optional phase, and  
> the
> optional phase was not explicitly called out on the invocation request,
> then Maven could drop the phase.
>
> By way of example, all the current test phases: generate-test-resources,
> test-compile, test, etc could be optional. The verify phase would depend  
> on
> the result of the test phase.
>
> This means that: `mvn package` could bypass even doing anything with the
> tests (unless somebody bound jar:test-jar to the package phase - which
> would mean that test-compile was required but not test)
>
> If you wanted the tests run, you either go `mvn test package` (I think we
> can dedup redundant phases from the request) or `mvn verify`
>
> What this gets us is the ability to build targeted portions of the  
> reactor
> without requiring that stuff be installed.
>
> Another idea I have is to allow @groupId:artifactId or @module/path (with
> wild cards for each) as suffixes to goals and phases...
>
> So
>
> mvn test@foo:bar-*
>
> Would load the whole reactor and apply the test phase to all modules in
> groupId foo with artifactIds starting with bar- but ensuring that any
> within reactor requirements have been minimally built...
>
> so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
> include bringing manchu-api as far as the package phase (when the jar  
> file
> is produced)
>
> If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar)  
> then
> the reactor would also include bringing manchu-impl as far as
> process-classes (when the classes dir is "produced" because the  
> requirement
> is for either classes or jar)
>
> Of course all the above magically needs a simple sintax for users and  
> easy
> to understand docs... both of which we may not be able to achieve... but
> the above goal is something I think we would love to have in 5.0.0...  
> (and
> a pink fluffy unicorn too)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Noting an idea for Maven 5.0.0

stephenconnolly
Oh there's a lot to go before we can get here... I just had the idea of
where my end goal was and needed to write it down for when we get 3.5.0 out
the door and I've got the scope for 3.5.1 agreed and I have some time to
pick up my spec for 5.0.0 wiki page to bring it to a completed proposal

On Sat 18 Mar 2017 at 16:29, Robert Scholte <[hidden email]> wrote:

> This kind of overlaps with MNG-6118, which is also about the path to the
> end-result.
> I haven't thought about excluding some pieces of the lifecycle by default,
> but we should focus more on the result.
>
> Maven should react much better on the execute location within a
> multimodule project and what you really want to happen here.
> As an example I use starting jetty on the war of a multimodule project,
> which is now requires 2 steps: mvn install from root and jetty:run n th
> specific module.
>
> I think MNG-6118 would be a first step before getting this up and running.
>
> Robert
>
> [1]
>
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/MNG-6118
>
> On Sat, 18 Mar 2017 16:46:28 +0100, Stephen Connolly
> <[hidden email]> wrote:
>
> > So I am thinking the lifecycle should support the concept of *optional*
> > phases.
> >
> > If no subsequent phase depends on the output of an optional phase, and
> > the
> > optional phase was not explicitly called out on the invocation request,
> > then Maven could drop the phase.
> >
> > By way of example, all the current test phases: generate-test-resources,
> > test-compile, test, etc could be optional. The verify phase would depend
> > on
> > the result of the test phase.
> >
> > This means that: `mvn package` could bypass even doing anything with the
> > tests (unless somebody bound jar:test-jar to the package phase - which
> > would mean that test-compile was required but not test)
> >
> > If you wanted the tests run, you either go `mvn test package` (I think we
> > can dedup redundant phases from the request) or `mvn verify`
> >
> > What this gets us is the ability to build targeted portions of the
> > reactor
> > without requiring that stuff be installed.
> >
> > Another idea I have is to allow @groupId:artifactId or @module/path (with
> > wild cards for each) as suffixes to goals and phases...
> >
> > So
> >
> > mvn test@foo:bar-*
> >
> > Would load the whole reactor and apply the test phase to all modules in
> > groupId foo with artifactIds starting with bar- but ensuring that any
> > within reactor requirements have been minimally built...
> >
> > so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
> > include bringing manchu-api as far as the package phase (when the jar
> > file
> > is produced)
> >
> > If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar)
> > then
> > the reactor would also include bringing manchu-impl as far as
> > process-classes (when the classes dir is "produced" because the
> > requirement
> > is for either classes or jar)
> >
> > Of course all the above magically needs a simple sintax for users and
> > easy
> > to understand docs... both of which we may not be able to achieve... but
> > the above goal is something I think we would love to have in 5.0.0...
> > (and
> > a pink fluffy unicorn too)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone