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
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)
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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",
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
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:
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
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
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
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
23 matches
Mail list logo
