Le ven. 17 juil. 2020 à 09:31, Hervé BOUTEMY a
écrit :
> Le vendredi 17 juillet 2020, 08:22:10 CEST Romain Manni-Bucau a écrit :
> > Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY a
>
> > > I don't get what "mvn my-test" means: there is no "my-test" phase
> > > and I don't understand how your cust
Le vendredi 17 juillet 2020, 08:22:10 CEST Romain Manni-Bucau a écrit :
> Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY a
> > I don't get what "mvn my-test" means: there is no "my-test" phase
> > and I don't understand how your custom lifecycle shares some phases with
> > default lifecycle, but ha
Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY a
écrit :
> Le jeudi 16 juillet 2020, 07:50:52 CEST Romain Manni-Bucau a écrit :
> > Le jeu. 16 juil. 2020 à 00:09, Hervé BOUTEMY a
> >
> > écrit :
> > > Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit :
> > > > Le mar. 14 juil. 202
Le jeudi 16 juillet 2020, 07:50:52 CEST Romain Manni-Bucau a écrit :
> Le jeu. 16 juil. 2020 à 00:09, Hervé BOUTEMY a
>
> écrit :
> > Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit :
> > > Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY a
> > >
> > > écrit :
> > > > in this exa
Le jeu. 16 juil. 2020 à 00:09, Hervé BOUTEMY a
écrit :
> Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit :
> > Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY a
> >
> > écrit :
> > > in this example, you strictly define a new "my-mapping" packaging, like
> > > done in Maven core
Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit :
> Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY a
>
> écrit :
> > in this example, you strictly define a new "my-mapping" packaging, like
> > done in Maven core for every default packagings [1] with documentation in
> > [2]: don'
Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY a
écrit :
> in this example, you strictly define a new "my-mapping" packaging, like
> done in Maven core for every default packagings [1] with documentation in
> [2]: don't call it bindings, but simply "packaging-bindings.xml" and it's
> more clear
>
in this example, you strictly define a new "my-mapping" packaging, like done in
Maven core for every default packagings [1] with documentation in [2]: don't
call it bindings, but simply "packaging-bindings.xml" and it's more clear
the more I think about it, the more I feel that what we need is
Le dim. 12 juil. 2020 à 23:04, Hervé BOUTEMY a
écrit :
> Le dimanche 12 juillet 2020, 18:10:59 CEST Romain Manni-Bucau a écrit :
> > Side topic - still thinking out loud - which is also covered by custom
> > lifecycles: aliases. A common need is to alias a complex command ("mvn
> > docker" execut
Le dim. 12 juil. 2020 à 23:01, Hervé BOUTEMY a
écrit :
> Le dimanche 12 juillet 2020, 11:58:08 CEST Romain Manni-Bucau a écrit :
> > Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY a
> >
> > écrit :
> > > Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
> > > > Le sam. 11 jui
Le dimanche 12 juillet 2020, 18:10:59 CEST Romain Manni-Bucau a écrit :
> Side topic - still thinking out loud - which is also covered by custom
> lifecycles: aliases. A common need is to alias a complex command ("mvn
> docker" executing "mvn dependency:build-classpath git-commit:generate
> docker:
Le dimanche 12 juillet 2020, 11:58:08 CEST Romain Manni-Bucau a écrit :
> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY a
>
> écrit :
> > Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
> > > Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY a
> > >
> > > écrit :
> > > > Le sa
Just to illustrate the proposal - likely to rework on config side to avoid
to kind of expose maven IoC (as we were playing with application contexts
10 years ago ;)) here is a small repo:
https://github.com/rmannibucau/custom-lifecycle-extension.
A sample project ([1]) defines a custom packaging (
Side topic - still thinking out loud - which is also covered by custom
lifecycles: aliases. A common need is to alias a complex command ("mvn
docker" executing "mvn dependency:build-classpath git-commit:generate
docker:bundle docker-java:cds" to give an idea), with default or merged
lifecycles it i
Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY a
écrit :
> Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
> > Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY a
> >
> > écrit :
> > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> > > > Le sam. 11 juil.
Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
> Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY a
>
> écrit :
> > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY a
> > >
> > > écrit :
> > > > are rea
Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY a
écrit :
> Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY a
> >
> > écrit :
> > > are really your plugin bindings so specific to your build that they
> could
> > > not be reused
Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY a
>
> écrit :
> > are really your plugin bindings so specific to your build that they could
> > not be reused and need full ad-hoc definition?
>
> Think so
>
> > I imagined to pr
Le samedi 11 juillet 2020, 12:39:01 CEST Robert Scholte a écrit :
> such solution confirms that packaging is used for 2 different things, which
> should be split in the next pom definition:
no, it can't be split
because this value is the link from the objective (I want to build a jar or a
war) to
Le sam. 11 juil. 2020 à 14:43, Robert Scholte a
écrit :
> Packaging should refer to the type of resulting main artifact.
> I see quite often that the jar-lifecycle is used, whereas the result is
> not a jar. They try to fix this by changing the phase the none for several
> goals.
> Also, I know i
Packaging should refer to the type of resulting main artifact.
I see quite often that the jar-lifecycle is used, whereas the result is not a
jar. They try to fix this by changing the phase the none for several goals.
Also, I know it is possible to generate a war with the soapui-maven-plugin
based
Le sam. 11 juil. 2020 à 12:39, Robert Scholte a
écrit :
> such solution confirms that packaging is used for 2 different things,
> which should be split in the next pom definition:
> packaging: the resulting artifact
> binding: the bindings to use for the default/build lifecycle.
>
This just repl
Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY a
écrit :
> are really your plugin bindings so specific to your build that they could
> not be reused and need full ad-hoc definition?
>
Think so
> I imagined to provide composite packaging:
> war+front+living-doc+docker
>
> in fact, "front", "livin
such solution confirms that packaging is used for 2 different things, which
should be split in the next pom definition:
packaging: the resulting artifact
binding: the bindings to use for the default/build lifecycle.
Robert
On 11-7-2020 12:09:49, Hervé BOUTEMY wrote:
are really your plugin bindin
are really your plugin bindings so specific to your build that they could not
be reused and need full ad-hoc definition?
I imagined to provide composite packaging:
war+front+living-doc+docker
in fact, "front", "living-doc", "docker" could provide secondary sets of
reusable plugins bindings: ea
Looked a bit on how to impl this kind of extension and it would help if
maven wouldn't assume everything is hardcoded in components.xml (or eq) or
if sisu would enable to reuse its plexus scanner which has a very low
visibility today. It is also weird to not have access to the guice injector
in com
Here is a sample public build: https://github.com/talend/component-runtime
Interesting modules are - just listing one per type - if master looks weird
tag 1.1.19 can be a fallback:
1.
https://github.com/Talend/component-runtime/blob/master/component-starter-server/pom.xml
2.
https://github.com/Tal
Le samedi 4 juillet 2020, 23:15:19 CEST Romain Manni-Bucau a écrit :
> Le sam. 4 juil. 2020 à 18:09, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> a écrit :
> > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau
> >
> > wrote:
> > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > >
>
Le sam. 4 juil. 2020 à 18:09, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :
> On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau
> wrote:
>
> > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> a écrit :
> >
> > > On Sat 4 Jul 2020 at 10:21, Romain
Hi Romain,
Do you expect another phases (life cycle) for specific technologies or
packaging.
What phases would you expect in case of frontend technologies, e.g.
JavaScript-like Angular, ReactJS, Vue?
What phases in case of scrip-like technologies and native technologies?
Should these phases be har
On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau
wrote:
> Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> stephen.alan.conno...@gmail.com> a écrit :
>
> > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau
> > wrote:
> >
> > > Well, there are two points I'd like to emphasis:
> > >
> > > 1. I dont t
Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :
> On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau
> wrote:
>
> > Well, there are two points I'd like to emphasis:
> >
> > 1. I dont think we should wait for 2 majors to get that as a feature,
> would
> > be
On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau
wrote:
> Well, there are two points I'd like to emphasis:
>
> 1. I dont think we should wait for 2 majors to get that as a feature, would
> be too late IMHO
Well does my dynamic phases PR do what you need?
> 2. Pom model is based on inheritance w
Well, there are two points I'd like to emphasis:
1. I dont think we should wait for 2 majors to get that as a feature, would
be too late IMHO
2. Pom model is based on inheritance whereas years showed composition and
reuse is saner so IMHO it does not belong to pom but .mvn
Le sam. 4 juil. 2020 à
Stephen had an idea for it in Model 5.0.0[1], and IIRC I still had my concerns.
It is still a draft with a lot of ideas, that hasn't really been discussed yet,
because it was still out of reach.
However, we're getting closer
Robert
[1]
https://cwiki.apache.org/confluence/display/MAVEN/POM+Mode
I agree I mixed both in my explanationcause they only make sense
together for a build as shown by the pre/post recurrent request which aims
to enrich the lifecycle to bind custom plugins.
Today projects are no more just about creating a jar - war are no more
about java etc... - most of the tim
first: thanks for sharing
from a high level point of view, the risk I see is to loose our conventions.
But let's try and see before judging
I think there are 2 topics currently mixed:
- default lifecycle phases:
do you want to add or remove phases? [1]
- default plugin bindings:
clearly, you
Hi everyone,
Wonder if we already discussed defining the lifecycle in the project (maybe
in $root/.mvn).
High level the need is to be able to change the default lifecycle in the
root pom without having to define a custom extension - in other words it is
about having a built-in extension.
The typic
38 matches
Mail list logo
