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
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 Mul
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 rath
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
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/123299
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
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
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
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 po
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 abov
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 abov
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 abov
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 Osipo
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
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 o
20 matches
Mail list logo
