Re: custom default lifecycle per project

[Hervé BOUTEMY]

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 provide composite packaging:
> > war+front+living-doc+docker
> > 
> > in fact, "front", "living-doc", "docker" could provide secondary sets of
> > reusable plugins bindings: each build would compose (with "+") based on
> > his
> > requirements
> 
> Ok but "front" means already 5-6 different bindings at least
nice, that proves that this "sub-packaging" is useful: what would be the 
bindings, please,  to make this case very concrete?

> and
> "living-doc" is per project by design (depends your stack, leads to
> different set of plugins).
let's dig a little bit: can you provide a few examples of stacks and 
corresponding bindings, please?
perhaps "living-doc" is too generic, and should be more specific per stack

> 
> I envision a reusable solution can be a thing but it is way more complex
> than having these dynamic bindings which are straight forward on user side
> so I prefer to let the user adapt maven to his need rather than the
> opposite.
> 
> Also note that your proposal makes us moving one step forward but we stay
> blocked: how do you merge phases and plugin order? This can also depends on
> projetcs and "+" only allows one order whereas order can be different
> between main and test plugins so you would need a complete dsl, not that
> easy compared to being explicit imo.
sure, this part is only one step
I need examples of such "merge phase" and order requirements to better see 
what mechanisms would be useful

> 
> > this could be injected by the LifecycleBindingsInjector [1]
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1]
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/a
> > pache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63> 
> > Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > > 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 components and have to go through the plexuscontainer to lookup
> > > beans.
> > > 
> > > As code often says more than words, here a small hello world showing
> > > that
> > > reusing this part of maven "core" is not that trivial:
> > > 
> > > @Component(role = AbstractMavenLifecycleParticipant.class)
> > > public class CustomLifecycleExtension extends
> > > AbstractMavenLifecycleParticipant {
> > > 
> > > @Inject
> > > private PlexusContainer container;
> > > 
> > > @Override
> > > public void afterProjectsRead(final MavenSession session) throws
> > > 
> > > MavenExecutionException {
> > > 
> > > final Path root =
> > > 
> > > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > > 
> > > final Path configFolder = root.resolve(".extensions/custom");
> > > 
> > > final Path mappings = configFolder.resolve("mappings.xml");
> > > if (Files.exists(mappings)) {
> > > 
> > > final ComponentSetDescriptor componentSet =
> > > 
> > > readAs(mappings, ComponentSetDescriptor.class, null);
> > > 
> > > System.out.println(componentSet);
> > > 
> > > }
> > > 
> > > super.afterProjectsRead(session);
> > > 
> > > }
> > > 
> > > private  T readAs(final Path path, final Class type, final
> > > 
> > > String wrapper) {
> > > 
> > > try {
> > > 
> > > final ClassRealm container =
> > 
> > this.container.getContainerRealm();
> > 
> > > final Class converterType = container
> > > 
> > > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final
> > > Class
> > > typeLiteralType = container
> > > 
> > > .loadClass("com.google.inject.TypeLiteral");
> > > 
> > > final Object converter =
> > 
> > this.container.lookup(converterType);
> > 
> > > return type.cast(converterType.getMethod("convert",
> > > 
> > > typeLiteralType, String.class).invoke(
> > > 
> > > converter,
> > > typeLiteralType.getMethod("get",
> > > 
> > > Class.class).invoke(null, type),
> > > 
> > > (wrapper != null ? "<" + wrapper + ">" : "") +
> > > 
> > > new String(Files.readAllBytes(path),
> > > 
> > > StandardCharsets.UTF_8)
> > > 
> > > .replaceFirst("<\\?[^>]+\\?>",
> > > 
> > > "").trim() + (wrapper != null ? "" : ""))); } catch
> > > (final Exception e) {
> > > 
> > > 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

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 the way to attain the objective (what are the build tasks to do it?)

> packaging: the resulting artifact
there are many resulting artifacts from one POM build
I know there is one eventual "main" one; is there anywhere that something is 
coded to really get the main artifact? any pointer?

> binding: the bindings to use for the default/build lifecycle.

if we update the semantics of this POM packaging field, yes, every code that 
uses the value will have to be updated to take account of the update: no magic

Of course, we can also wait for POM v5 to add new build fields

> 
> Robert
> On 11-7-2020 12:09:49, Hervé BOUTEMY  wrote:
> 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: each build would compose (with "+") based on his
> requirements
> 
> this could be injected by the LifecycleBindingsInjector [1]
> 
> WDYT?
> 
> Regards,
> 
> Hervé
> 
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/ap
> ache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63
> Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > 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 components and have to go through the plexuscontainer to lookup beans.
> > 
> > As code often says more than words, here a small hello world showing that
> > reusing this part of maven "core" is not that trivial:
> > 
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusContainer container;
> > 
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> > 
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> > 
> > super.afterProjectsRead(session);
> > }
> > 
> > private T readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > final ClassRealm container = this.container.getContainerRealm();
> > final Class converterType = container
> > 
> > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> > typeLiteralType = container
> > .loadClass("com.google.inject.TypeLiteral");
> > final Object converter = this.container.lookup(converterType);
> > return type.cast(converterType.getMethod("convert",
> > typeLiteralType, String.class).invoke(
> > converter,
> > typeLiteralType.getMethod("get",
> > Class.class).invoke(null, type),
> > (wrapper != null ? "" : "") +
> > new String(Files.readAllBytes(path),
> > StandardCharsets.UTF_8)
> > .replaceFirst("]+\\?>",
> > "").trim() + (wrapper != null ? "" : ""))); } catch
> > (final Exception e) {
> > throw new IllegalStateException(e);
> > }
> > }
> > }
> > 
> > Indeed it can't work since componentsetdescriptor uses plexusconfiguration
> > which is not instantiable but it shows the workarounds needed to just
> > lookup plexus converter and reuse plexus xml binding.
> > 
> > The code should just look like that IMHO:
> > 
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusBeanConverter converter;
> > 
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> > 
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> > 
> > super.afterProjectsRead(session);
> > }
> > 
> > private T readAs(final Path path, final Class type, final
> > String wrapper) {

Re: Welcome the new Maven committers: Maarten Mulders en Martin Kanters

[Martin Kanters]

Thanks for the warm welcome! Happy to be part of the team!


Op za 11 jul. 2020 om 10:18 schreef Arnaud Héritier :

> Welcome in the team!
>
> Le ven. 10 juil. 2020 à 21:13, Robert Scholte  a
> écrit :
>
> > Hi,
> >
> > On behalf of the Apache Maven PMC I am pleased to announce that
> > Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> > committers
> > and they've both accepted this invitation.
> >
> > Welcome on board and have a lot of fun!
> >
> > Thanks,
> > Robert Scholte
> >
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

[GitHub] [maven-site-plugin] mthmulders commented on pull request #32: install dependabot

[GitBox]

mthmulders commented on pull request #32:
URL: https://github.com/apache/maven-site-plugin/pull/32#issuecomment-657116214


   > As a general principle I prefer automation over convention. E.g. if we 
shouldn't use squash commits, then the squash commit button should be disabled 
on the repo rather than expecting devs not to press it. There are many other 
examples of this. If there are accepted conventions for code commits, it would 
be worth investing some time to enforce in our systems.
   
   Totally agree with this. If having a JIRA issue is relevant, I could spend 
some time trying to automate it with a Github action that could follow 
Dependabot. We'd probably need some kind of non-personal account to ASF JIRA 
but let's build that bridge when we get there.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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 it is possible to generate a war with the soapui-maven-plugin
> based on a soapui config file, so this one should have packaging: war,
> binding: pom
>

I dont think it makes sense today, it is common to have 4-5 different
"packaging" per module - strictly speaking we always had pom and jar for
jat packaging. Nowdays we have jar, zip, openapi.json, docker, remote image
(oci) *per* module (often the project itself) and it is a good thing
compared to be forced to split in 5 fake module just to respect 1
package/module IMHO so let's drop packaging notion which is no more
matching the way we work/dev today and focus on lifecycle/binding only IMHO.



> Robert
> On 11-7-2020 12:59:23, Romain Manni-Bucau  wrote:
> 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 replace the term packaging by binding. At the end you define a
> chain of plugins for a module which leads to artifacts, whatever terms you
> use this does not change much (and is the only goal of a build right? ;)).
> Today packaging defines a binding and the actual packaging is just one
> plugin of the binding loaded from packaging string so IMHO it is the same.
>
>
>
> > Robert
> > On 11-7-2020 12:09:49, Hervé BOUTEMY wrote:
> > 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: each build would compose (with "+") based on
> his
> > requirements
> >
> > this could be injected by the LifecycleBindingsInjector [1]
> >
> > WDYT?
> >
> > Regards,
> >
> > Hervé
> >
> > [1]
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63
> >
> > Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > > 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 components and have to go through the plexuscontainer to lookup
> beans.
> > >
> > > As code often says more than words, here a small hello world showing
> that
> > > reusing this part of maven "core" is not that trivial:
> > >
> > > @Component(role = AbstractMavenLifecycleParticipant.class)
> > > public class CustomLifecycleExtension extends
> > > AbstractMavenLifecycleParticipant {
> > > @Inject
> > > private PlexusContainer container;
> > >
> > > @Override
> > > public void afterProjectsRead(final MavenSession session) throws
> > > MavenExecutionException {
> > > final Path root =
> > > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > > final Path configFolder = root.resolve(".extensions/custom");
> > >
> > > final Path mappings = configFolder.resolve("mappings.xml");
> > > if (Files.exists(mappings)) {
> > > final ComponentSetDescriptor componentSet =
> > > readAs(mappings, ComponentSetDescriptor.class, null);
> > > System.out.println(componentSet);
> > > }
> > >
> > > super.afterProjectsRead(session);
> > > }
> > >
> > > private T readAs(final Path path, final Class type, final
> > > String wrapper) {
> > > try {
> > > final ClassRealm container = this.container.getContainerRealm();
> > > final Class converterType = container
> > >
> > > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> > > typeLiteralType = container
> > > .loadClass("com.google.inject.TypeLiteral");
> > > final Object converter = this.container.lookup(converterType);
> > > return type.cast(converterType.getMethod("convert",
> > > typeLiteralType, String.class).invoke(
> > > converter,
> > > typeLiteralType.getMethod("get",
> > > Class.class).invoke(null, type),
> > > (wrapper != null ? "" : "") +
> > > new String(Files.readAllBytes(path),
> > > StandardCharsets.UTF_8)
> > > .replaceFirst("]+\\?>",
> > > "").trim() + (wrapper != null ? "" : ""))); } catch
> > > (final Exception e) {
> > > throw new IllegalStateException(e);
> > > }
> > > }
> > > }
> > >
> > > Indeed it can't work since componentsetdescriptor uses
> > plexusconfiguration
> > > which is not instantiable but it shows the workarounds needed to just
> > 

[GitHub] [maven-project-utils] pzygielo commented on a change in pull request #3: update JIRA URL

[GitBox]

pzygielo commented on a change in pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3#discussion_r453213245



##
File path: pom.xml
##
@@ -46,7 +46,7 @@ under the License.
   
   
 jira
-https://issues.apache.org/jira/browse/MSHARED/component/12329913
+
https://issues.apache.org/jira/browse/MSHARED-933?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-project-utils

Review comment:
   IMO it would be better without reference to specific issue, ie. 
`https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-project-utils`.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] slachiewicz merged pull request #2: fill in undeclared dependencies

[GitBox]

slachiewicz merged pull request #2:
URL: https://github.com/apache/maven-project-utils/pull/2


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] slachiewicz merged pull request #1: update test dependencies

[GitBox]

slachiewicz merged pull request #1:
URL: https://github.com/apache/maven-project-utils/pull/1


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] slachiewicz merged pull request #3: update JIRA URL

[GitBox]

slachiewicz merged pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Second MRESOLVER-123

[Michael Osipov]

Am 2020-07-11 um 15:52 schrieb Elliotte Rusty Harold:

I don't think we can safely or should assume devs use private repo
managers, or that those that do improve performance.


Why not? This is actually what we are recommending in tickets, SO and 
our website.



Instead of locking, would it be possible to implement some sort of
queue system for artifact downloads or use asynchronous futures?


Everything is possible as long as someone implements it. The queue would 
lock until the artifact has been consumed. What difference would that 
make? The artifact download is already async in terms of that parallel 
threads with tasks are spawned.


I do not intend to put anymore to time to something more sophisticated 
like a queue for now, I did already invest a lot. This issue has plagued 
many users.


I am open to new issues until someone can implement them in time.

Michael



On Fri, Jul 10, 2020 at 3:46 AM Michael Osipov  wrote:


Folks,

MRESOLVER-123 [1] solves a very long standing issue in Resolver: Thread
concurrency in a single JVM while downloading artifacts/metadata. It has
been verified to work with several usecases provided by reporters. This
approach has one drawback: Since it is a global lock it introduces
somwhat of a lock contention. The slower your connection link the longer
the lock is held. Ideally, folks use repo managers in private networks
to solve this issue. Also, read/write reeentrancy seems to work fine
based on the logs provided. At the end I prefer build stability over
performance.

Please have a look and raise objects if you have any. If you don't hear
any I will merge next week and start release process of Resolver 1.5.0.

A midterm goal would be to provide a group id based locking which should
drastically reduce contention, but no promises here for an ETA. As for
the multi JVM safety, Takari local repository failed to provide a
working solution, project seems to be abandoned. I have considered to
investigate a Redisson-based approach for this. Though, this solely
depends on the community how necessary this really is.

Michael

[1] https://github.com/apache/maven-resolver/pull/65

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] elharo opened a new pull request #3: update JIRA URL

[GitBox]

elharo opened a new pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] elharo opened a new pull request #2: fill in undeclared dependencies

[GitBox]

elharo opened a new pull request #2:
URL: https://github.com/apache/maven-project-utils/pull/2


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-project-utils] elharo opened a new pull request #1: update test dependencies

[GitBox]

elharo opened a new pull request #1:
URL: https://github.com/apache/maven-project-utils/pull/1


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Second MRESOLVER-123

[Elliotte Rusty Harold]

I don't think we can safely or should assume devs use private repo
managers, or that those that do improve performance.

Instead of locking, would it be possible to implement some sort of
queue system for artifact downloads or use asynchronous futures?

On Fri, Jul 10, 2020 at 3:46 AM Michael Osipov  wrote:
>
> Folks,
>
> MRESOLVER-123 [1] solves a very long standing issue in Resolver: Thread
> concurrency in a single JVM while downloading artifacts/metadata. It has
> been verified to work with several usecases provided by reporters. This
> approach has one drawback: Since it is a global lock it introduces
> somwhat of a lock contention. The slower your connection link the longer
> the lock is held. Ideally, folks use repo managers in private networks
> to solve this issue. Also, read/write reeentrancy seems to work fine
> based on the logs provided. At the end I prefer build stability over
> performance.
>
> Please have a look and raise objects if you have any. If you don't hear
> any I will merge next week and start release process of Resolver 1.5.0.
>
> A midterm goal would be to provide a group id based locking which should
> drastically reduce contention, but no promises here for an ETA. As for
> the multi JVM safety, Takari local repository failed to provide a
> working solution, project seems to be abandoned. I have considered to
> investigate a Redisson-based approach for this. Though, this solely
> depends on the community how necessary this really is.
>
> Michael
>
> [1] https://github.com/apache/maven-resolver/pull/65
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: custom default lifecycle per project

[Robert Scholte]

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 on a soapui config file, so this one should have packaging: war, binding: 
pom

Robert 
On 11-7-2020 12:59:23, Romain Manni-Bucau  wrote:
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 replace the term packaging by binding. At the end you define a
chain of plugins for a module which leads to artifacts, whatever terms you
use this does not change much (and is the only goal of a build right? ;)).
Today packaging defines a binding and the actual packaging is just one
plugin of the binding loaded from packaging string so IMHO it is the same.



> Robert
> On 11-7-2020 12:09:49, Hervé BOUTEMY wrote:
> 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: each build would compose (with "+") based on his
> requirements
>
> this could be injected by the LifecycleBindingsInjector [1]
>
> WDYT?
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63
>
> Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > 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 components and have to go through the plexuscontainer to lookup beans.
> >
> > As code often says more than words, here a small hello world showing that
> > reusing this part of maven "core" is not that trivial:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusContainer container;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> >
> > super.afterProjectsRead(session);
> > }
> >
> > private T readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > final ClassRealm container = this.container.getContainerRealm();
> > final Class converterType = container
> >
> > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> > typeLiteralType = container
> > .loadClass("com.google.inject.TypeLiteral");
> > final Object converter = this.container.lookup(converterType);
> > return type.cast(converterType.getMethod("convert",
> > typeLiteralType, String.class).invoke(
> > converter,
> > typeLiteralType.getMethod("get",
> > Class.class).invoke(null, type),
> > (wrapper != null ? "" : "") +
> > new String(Files.readAllBytes(path),
> > StandardCharsets.UTF_8)
> > .replaceFirst("]+\\?>",
> > "").trim() + (wrapper != null ? "" : ""))); } catch
> > (final Exception e) {
> > throw new IllegalStateException(e);
> > }
> > }
> > }
> >
> > Indeed it can't work since componentsetdescriptor uses
> plexusconfiguration
> > which is not instantiable but it shows the workarounds needed to just
> > lookup plexus converter and reuse plexus xml binding.
> >
> > The code should just look like that IMHO:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusBeanConverter converter;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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 replace the term packaging by binding. At the end you define a
chain of plugins for a module which leads to artifacts, whatever terms you
use this does not change much (and is the only goal of a build right? ;)).
Today packaging defines a binding and the actual packaging is just one
plugin of the binding loaded from packaging string so IMHO it is the same.



> Robert
> On 11-7-2020 12:09:49, Hervé BOUTEMY  wrote:
> 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: each build would compose (with "+") based on his
> requirements
>
> this could be injected by the LifecycleBindingsInjector [1]
>
> WDYT?
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63
>
> Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > 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 components and have to go through the plexuscontainer to lookup beans.
> >
> > As code often says more than words, here a small hello world showing that
> > reusing this part of maven "core" is not that trivial:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusContainer container;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> >
> > super.afterProjectsRead(session);
> > }
> >
> > private T readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > final ClassRealm container = this.container.getContainerRealm();
> > final Class converterType = container
> >
> > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> > typeLiteralType = container
> > .loadClass("com.google.inject.TypeLiteral");
> > final Object converter = this.container.lookup(converterType);
> > return type.cast(converterType.getMethod("convert",
> > typeLiteralType, String.class).invoke(
> > converter,
> > typeLiteralType.getMethod("get",
> > Class.class).invoke(null, type),
> > (wrapper != null ? "" : "") +
> > new String(Files.readAllBytes(path),
> > StandardCharsets.UTF_8)
> > .replaceFirst("]+\\?>",
> > "").trim() + (wrapper != null ? "" : ""))); } catch
> > (final Exception e) {
> > throw new IllegalStateException(e);
> > }
> > }
> > }
> >
> > Indeed it can't work since componentsetdescriptor uses
> plexusconfiguration
> > which is not instantiable but it shows the workarounds needed to just
> > lookup plexus converter and reuse plexus xml binding.
> >
> > The code should just look like that IMHO:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusBeanConverter converter;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> >
> > super.afterProjectsRead(session);
> > }
> >
> > private T readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > return type.cast(
> > converter.convert(TypeLiteral.get(type),
> > (wrapper != null ? "" : "") +
> > new
> > String(Files.readAllBytes(path), StandardCharsets.UTF_8)
> >
> > .replaceFirst("]+\\?>", "").trim() +
> > (wrapper != 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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", "living-doc", "docker" could provide secondary sets of
> reusable plugins bindings: each build would compose (with "+") based on his
> requirements
>

Ok but "front" means already 5-6 different bindings at least and
"living-doc" is per project by design (depends your stack, leads to
different set of plugins).

I envision a reusable solution can be a thing but it is way more complex
than having these dynamic bindings which are straight forward on user side
so I prefer to let the user adapt maven to his need rather than the
opposite.

Also note that your proposal makes us moving one step forward but we stay
blocked: how do you merge phases and plugin order? This can also depends on
projetcs and "+" only allows one order whereas order can be different
between main and test plugins so you would need a complete dsl, not that
easy compared to being explicit imo.


> this could be injected by the LifecycleBindingsInjector [1]
>
> WDYT?
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63
>
> Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > 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 components and have to go through the plexuscontainer to lookup beans.
> >
> > As code often says more than words, here a small hello world showing that
> > reusing this part of maven "core" is not that trivial:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusContainer container;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > readAs(mappings, ComponentSetDescriptor.class, null);
> > System.out.println(componentSet);
> > }
> >
> > super.afterProjectsRead(session);
> > }
> >
> > private  T readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > final ClassRealm container =
> this.container.getContainerRealm();
> > final Class converterType = container
> >
> > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> > typeLiteralType = container
> > .loadClass("com.google.inject.TypeLiteral");
> > final Object converter =
> this.container.lookup(converterType);
> > return type.cast(converterType.getMethod("convert",
> > typeLiteralType, String.class).invoke(
> > converter,
> > typeLiteralType.getMethod("get",
> > Class.class).invoke(null, type),
> > (wrapper != null ? "<" + wrapper + ">" : "") +
> > new String(Files.readAllBytes(path),
> > StandardCharsets.UTF_8)
> > .replaceFirst("<\\?[^>]+\\?>",
> > "").trim() + (wrapper != null ? "" : ""))); } catch
> > (final Exception e) {
> > throw new IllegalStateException(e);
> > }
> > }
> > }
> >
> > Indeed it can't work since componentsetdescriptor uses
> plexusconfiguration
> > which is not instantiable but it shows the workarounds needed to just
> > lookup plexus converter and reuse plexus xml binding.
> >
> > The code should just look like that IMHO:
> >
> > @Component(role = AbstractMavenLifecycleParticipant.class)
> > public class CustomLifecycleExtension extends
> > AbstractMavenLifecycleParticipant {
> > @Inject
> > private PlexusBeanConverter converter;
> >
> > @Override
> > public void afterProjectsRead(final MavenSession session) throws
> > MavenExecutionException {
> > final Path root =
> > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > final Path configFolder = root.resolve(".extensions/custom");
> >
> > final Path mappings = configFolder.resolve("mappings.xml");
> > if (Files.exists(mappings)) {
> > final ComponentSetDescriptor componentSet =
> > 

Re: custom default lifecycle per project

[Robert Scholte]

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 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: each build would compose (with "+") based on his 
requirements

this could be injected by the LifecycleBindingsInjector [1]

WDYT?

Regards,

Hervé

[1] 
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63

Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> 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 components and have to go through the plexuscontainer to lookup beans.
>
> As code often says more than words, here a small hello world showing that
> reusing this part of maven "core" is not that trivial:
>
> @Component(role = AbstractMavenLifecycleParticipant.class)
> public class CustomLifecycleExtension extends
> AbstractMavenLifecycleParticipant {
> @Inject
> private PlexusContainer container;
>
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> final Path root =
> session.getRequest().getMultiModuleProjectDirectory().toPath();
> final Path configFolder = root.resolve(".extensions/custom");
>
> final Path mappings = configFolder.resolve("mappings.xml");
> if (Files.exists(mappings)) {
> final ComponentSetDescriptor componentSet =
> readAs(mappings, ComponentSetDescriptor.class, null);
> System.out.println(componentSet);
> }
>
> super.afterProjectsRead(session);
> }
>
> private T readAs(final Path path, final Class type, final
> String wrapper) {
> try {
> final ClassRealm container = this.container.getContainerRealm();
> final Class converterType = container
>
> .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> typeLiteralType = container
> .loadClass("com.google.inject.TypeLiteral");
> final Object converter = this.container.lookup(converterType);
> return type.cast(converterType.getMethod("convert",
> typeLiteralType, String.class).invoke(
> converter,
> typeLiteralType.getMethod("get",
> Class.class).invoke(null, type),
> (wrapper != null ? "" : "") +
> new String(Files.readAllBytes(path),
> StandardCharsets.UTF_8)
> .replaceFirst("]+\\?>",
> "").trim() + (wrapper != null ? "" : ""))); } catch
> (final Exception e) {
> throw new IllegalStateException(e);
> }
> }
> }
>
> Indeed it can't work since componentsetdescriptor uses plexusconfiguration
> which is not instantiable but it shows the workarounds needed to just
> lookup plexus converter and reuse plexus xml binding.
>
> The code should just look like that IMHO:
>
> @Component(role = AbstractMavenLifecycleParticipant.class)
> public class CustomLifecycleExtension extends
> AbstractMavenLifecycleParticipant {
> @Inject
> private PlexusBeanConverter converter;
>
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> final Path root =
> session.getRequest().getMultiModuleProjectDirectory().toPath();
> final Path configFolder = root.resolve(".extensions/custom");
>
> final Path mappings = configFolder.resolve("mappings.xml");
> if (Files.exists(mappings)) {
> final ComponentSetDescriptor componentSet =
> readAs(mappings, ComponentSetDescriptor.class, null);
> System.out.println(componentSet);
> }
>
> super.afterProjectsRead(session);
> }
>
> private T readAs(final Path path, final Class type, final
> String wrapper) {
> try {
> return type.cast(
> converter.convert(TypeLiteral.get(type),
> (wrapper != null ? "" : "") +
> new
> String(Files.readAllBytes(path), StandardCharsets.UTF_8)
>
> .replaceFirst("]+\\?>", "").trim() +
> (wrapper != null ? "
> + ">" : "")));
> } catch (final Exception e) {
> throw new IllegalStateException(e);
> }
> }
> }
>
> Once this part is fixed (using a custom parser) the next one is how to
> contribute global components from an extension.
>
> I'll ignore the parsing - currently I have a custom sax parser but I hope
> to be able to drop it soon - it is quite easy to contribute back the new
> mapping - note i dropped the lifecycle particupant which does not really
> help there cause only contributing mappings when the extension is created
> makes sense:
>
> @Component(role = StartupContributor.class, instantiationStrategy =
> Strategies.LOAD_ON_START)
> public class 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

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: each build would compose (with "+") based on his 
requirements

this could be injected by the LifecycleBindingsInjector [1]

WDYT?

Regards,

Hervé

[1] 
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63

Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> 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 components and have to go through the plexuscontainer to lookup beans.
> 
> As code often says more than words, here a small hello world showing that
> reusing this part of maven "core" is not that trivial:
> 
> @Component(role = AbstractMavenLifecycleParticipant.class)
> public class CustomLifecycleExtension extends
> AbstractMavenLifecycleParticipant {
> @Inject
> private PlexusContainer container;
> 
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> final Path root =
> session.getRequest().getMultiModuleProjectDirectory().toPath();
> final Path configFolder = root.resolve(".extensions/custom");
> 
> final Path mappings = configFolder.resolve("mappings.xml");
> if (Files.exists(mappings)) {
> final ComponentSetDescriptor componentSet =
> readAs(mappings, ComponentSetDescriptor.class, null);
> System.out.println(componentSet);
> }
> 
> super.afterProjectsRead(session);
> }
> 
> private  T readAs(final Path path, final Class type, final
> String wrapper) {
> try {
> final ClassRealm container = this.container.getContainerRealm();
> final Class converterType = container
>
> .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); final Class
> typeLiteralType = container
> .loadClass("com.google.inject.TypeLiteral");
> final Object converter = this.container.lookup(converterType);
> return type.cast(converterType.getMethod("convert",
> typeLiteralType, String.class).invoke(
> converter,
> typeLiteralType.getMethod("get",
> Class.class).invoke(null, type),
> (wrapper != null ? "<" + wrapper + ">" : "") +
> new String(Files.readAllBytes(path),
> StandardCharsets.UTF_8)
> .replaceFirst("<\\?[^>]+\\?>",
> "").trim() + (wrapper != null ? "" : ""))); } catch
> (final Exception e) {
> throw new IllegalStateException(e);
> }
> }
> }
> 
> Indeed it can't work since componentsetdescriptor uses plexusconfiguration
> which is not instantiable but it shows the workarounds needed to just
> lookup plexus converter and reuse plexus xml binding.
> 
> The code should just look like that IMHO:
> 
> @Component(role = AbstractMavenLifecycleParticipant.class)
> public class CustomLifecycleExtension extends
> AbstractMavenLifecycleParticipant {
> @Inject
> private PlexusBeanConverter converter;
> 
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> final Path root =
> session.getRequest().getMultiModuleProjectDirectory().toPath();
> final Path configFolder = root.resolve(".extensions/custom");
> 
> final Path mappings = configFolder.resolve("mappings.xml");
> if (Files.exists(mappings)) {
> final ComponentSetDescriptor componentSet =
> readAs(mappings, ComponentSetDescriptor.class, null);
> System.out.println(componentSet);
> }
> 
> super.afterProjectsRead(session);
> }
> 
> private  T readAs(final Path path, final Class type, final
> String wrapper) {
> try {
> return type.cast(
> converter.convert(TypeLiteral.get(type),
> (wrapper != null ? "<" + wrapper + ">" : "") +
> new
> String(Files.readAllBytes(path), StandardCharsets.UTF_8)
> 
> .replaceFirst("<\\?[^>]+\\?>", "").trim() +
> (wrapper != null ? " + ">" : "")));
> } catch (final Exception e) {
> throw new IllegalStateException(e);
> }
> }
> }
> 
> Once this part is fixed (using a custom parser) the next one is how to
> contribute global components from an extension.
> 
> I'll ignore the parsing - currently I have a 

Re: Welcome the new Maven committers: Maarten Mulders en Martin Kanters

[Arnaud Héritier]

Welcome in the team!

Le ven. 10 juil. 2020 à 21:13, Robert Scholte  a
écrit :

> Hi,
>
> On behalf of the Apache Maven PMC I am pleased to announce that
> Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> committers
> and they've both accepted this invitation.
>
> Welcome on board and have a lot of fun!
>
> Thanks,
> Robert Scholte
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Welcome the new Maven committers: Maarten Mulders en Martin Kanters

[Christian Stein]

Happy coding and testing, Maarten and Martin!

On Fri, Jul 10, 2020 at 9:13 PM Robert Scholte  wrote:

> Hi,
>
> On behalf of the Apache Maven PMC I am pleased to announce that
> Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> committers
> and they've both accepted this invitation.
>
> Welcome on board and have a lot of fun!
>
> Thanks,
> Robert Scholte
>

Re: Welcome the new Maven committers: Maarten Mulders en Martin Kanters

[Hervé BOUTEMY]

welcome Maarten en/and Martin :)

When is the next Apachecon, to meet everybody?

Regards,

Hervé

Le vendredi 10 juillet 2020, 21:12:59 CEST Robert Scholte a écrit :
> Hi,
> 
> On behalf of the Apache Maven PMC I am pleased to announce that
> Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> committers and they've both accepted this invitation.
> 
> Welcome on board and have a lot of fun!
> 
> Thanks,
> Robert Scholte





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducible builds, jars, bundles

[Hervé BOUTEMY]

yes, it has to be sorted at plugin level
And even more precisely at each goal level: it seems only some goal produce 
non-reproducible content, or even only some options of some goals

I Felix could produce a doc on how to configure for Reproducible Builds, that 
would be awesome, since this plugin is one of the most complex to configure: 
I'd happily update to link to that documentation in the table from 
https://maven.apache.org/guides/mini/guide-reproducible-builds.html

Regards,

Hervé

Le vendredi 10 juillet 2020, 22:20:39 CEST Romain Manni-Bucau a écrit :
> So maybe ask on felix@ instead of maven@ - that said pretty sure you can
> sort it, one fun hack to test can be to use maven shade with a custom
> transformer to do it.
> 
> Le ven. 10 juil. 2020 à 21:29, Gary Gregory  a
> 
> écrit :
> > Romain,
> > 
> > Yeah, I found the same code fragment but it is not clear to me if keeping
> > that set sorted would have unintended consequences.
> > 
> > I pointed folks in the PRs to this thread so I am hopping a plugin
> > maintainer will opine here.
> > 
> > Gary
> > 
> > On Fri, Jul 10, 2020, 10:53 Romain Manni-Bucau 
> > 
> > wrote:
> > > Hi Gary,
> > > 
> > > Maybe I misunderstood something but isn't it that felix bundle plugin
> > 
> > does
> > 
> > > not sort the maven resources ([1]?
> > > 
> > > [1]
> > 
> > https://github.com/apache/felix-dev/blob/7f4d31b384d9d83c772680a8627df18ff
> > 078eaa4/tools/maven-bundle-plugin/src/main/java/org/apache/felix/bundleplu
> > gin/BundlePlugin.java#L2036> 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > 
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> > 
> > > Le ven. 10 juil. 2020 à 16:44, Gary Gregory  a
> > > 
> > > écrit :
> > > > Hi All,
> > > > 
> > > > Over at Apache Commons, we are looking at creating reproducible builds
> > > 
> > > via:
> > > > https://github.com/apache/commons-parent/pull/9
> > > > 
> > > > As discussed in that thread, a bundle's "Include-Resource" manifest
> > > 
> > > header
> > > 
> > > > has a value with file system elements in different orders depending on
> > > 
> > > file
> > > 
> > > > system used to generate the jar, IOW, not bit by bit reproducible.
> > > > 
> > > > Folks in that discussion and in another here
> > > > https://github.com/apache/commons-lang/pull/578, suggested that the
> > > 
> > > issue
> > > 
> > > > might reside in Maven relying on the file system order and not in
> > > > maven-bundle-plugin or the bnd library as initially considered.
> > > > 
> > > > May you please provide any guidance?
> > > > 
> > > > Thank you,
> > > > Gary





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org