Le mardi 16 mai 2017, 22:20:35 CEST Stephen Connolly a écrit :
> On Tue 16 May 2017 at 22:40, Hervé BOUTEMY wrote:
> > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY
> >
> > wrote:
> > > > thank you Robert: this is exactly the logi
On Tue 16 May 2017 at 22:40, Hervé BOUTEMY wrote:
> Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY
> wrote:
> > > thank you Robert: this is exactly the logic I was looking for, and
> > > explanation
> > > of changes over time to impr
Github user hboutemy commented on the issue:
https://github.com/apache/maven/pull/118
AFAIK, you have colors on messages, but not on levels: the specific logger
is necessary for levels.
It's also necessary for colored error rendering.
Just look at MavenSimpleLogger and you'll s
this idea of putting everything in git is funny: not sure this will go very
far from this poc, but let's imagine...
on classes branch, splitting the jar into individual .class has IMHO a big
drawback: we loose original jar and its signature
On the other branches, the current poc shows commits f
Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> On Sun 14 May 2017 at 08:51, Hervé BOUTEMY wrote:
> > thank you Robert: this is exactly the logic I was looking for, and
> > explanation
> > of changes over time to improve user experience through reproducibility.
> >
> > Now the qu
Hi,
Just a pre-announcement: I'd like to release these plugins within a couple
of days.
maven-compiler-plugin is required because for Java9 a flag required for
testing has been replaced. The old flag is now removed, so some Jigsaw
testers are blocked.
maven-invoker-plugin will be a 3.0.
On 16 May 2017 at 06:53, Michael Osipov wrote:
> MNG-6167
+1
Hi Karl Heinz,
regarding both install/deploy plugin in combination with
artifact-transfer: we should somehow make this a 2-phase strategy in the
future: first phase upload pom, main artifact and attached artifacts (in
parallel when possible), second phase download + upload metadata files. I
The Apache Maven team is pleased to announce the release of the
Apache Maven Dependency Plugin Version 3.0.1.
https://maven.apache.org/plugins/maven-dependency-plugin/
Important Note since 3.0.0:
* Maven 3.X only
* JDK 6 minimum requirement
You should specify the version in your project's p
On Tue, 16 May 2017 19:00:14 +0200, Michael Osipov
wrote:
Am 2017-05-15 um 20:57 schrieb Robert Scholte:
IIRC 8, 9 and 10 change the current behavior of Maven a lot.
I think we should transform the use cases first to ITs based on
mock-repository-manager, which should make it a lot easier to
> The more I think about it, the more I'm convinced we should also remove
> the archetypeCatalog parameter. Right now it is only causing confusion.
>
Yes, you're probably right. It should just work - you shouldn't have to
specify what sort of catalog to be used.
/Anders
> Does it still make sen
Hi,
The vote has passed with the following result:
+1 : Hervé Boutemy, Michael Osipov, Karl Heinz Marbaise
PMC quorum: reached.
I will promote the artifacts to the central repo.
Kind regards
Karl Heinz Marbaise
-
To unsubscr
Github user llebegue closed the pull request at:
https://github.com/apache/maven-release/pull/7
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Looks like ARCHETYPE-520[1] to me. I've created an integration-test for
it, so that should work with 3.0.1
The more I think about it, the more I'm convinced we should also remove
the archetypeCatalog parameter. Right now it is only causing confusion.
Does it still make sense to have "internal
Am 2017-05-15 um 20:57 schrieb Robert Scholte:
IIRC 8, 9 and 10 change the current behavior of Maven a lot.
I think we should transform the use cases first to ITs based on
mock-repository-manager, which should make it a lot easier to understand
what's happening.
Next we need to decide what to ch
Github user ebourg commented on the issue:
https://github.com/apache/maven/pull/118
Is the StaticLoggerBinder implementation necessary? I built Maven without
and it seemed to work, the resulting version was able to build a couple of
random projects and the console output was colored.
Karl Heinz,
the vote is over, do you want to continue with the release?
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Who seconds MNG-6167 for 3.5.1?
All ITs pass locally and on Jenkins.
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
GitHub user ebourg opened a pull request:
https://github.com/apache/maven/pull/118
Upgrade SLF4J to 1.7.25 and expelled the groovy monkey
The changes to SLF4J required to support maven-slf4j-provider have been
[released ](https://jira.qos.ch/browse/SLF4J-394) in the version 1.7.25.
I would expect "remote" not be the central repo but what repo(s) (or
mirrors) are configured in settings.xml.
Robert, what's your view of how this works in the plugin now?
/Anders
On Tue, May 16, 2017 at 11:06 AM, Amélie Deltour
wrote:
> Hi Anders,
>
> Thanks for your clarification.
> In under
Hi Anders,
Thanks for your clarification.
In understand well the idea behind the 3.x version and the concern for more security and
avoid to fetch anything directly from the Internet. Every "external" access
should go throud the repositories configured in the Maven settings.xml, I completely
ag
21 matches
Mail list logo