f custom bindings via Guice modules.
> However since the Guice API is not exported from the core classloader, see
> here <https://maven.apache.org/ref/3.9.0/maven-core/core-extensions.html>,
> this is not possible unless we explicitly export the Guice API to all
> plugins/extensions.
&
Hi All,
As promoted on the documentation of sisu here
<https://eclipse-sisu.github.io/sisu-project/plexus/index.html#custombinding>,
we allow the definition of custom bindings via Guice modules.
However since the Guice API is not exported from the core classloader, see
here
On Sat, 14 Oct 2023 at 10:51, Tamás Cservenák wrote:
>
> Howdy,
>
> ok, so I think agreed on the name (and artifactId) of the two new module:
> * maven-resolver-transport-jdk (uses Java11+ java.net.http.HttpClient)
> * maven-resolver-transport-jetty (uses Jetty HttpClient, probably 12.x)
no need
> Cannot rename the misleading "-http" one, as that would cause
> disruption with existing code, we have to live with it for now
Isn't this something maven has relocations[1] for?
[1] https://maven.apache.org/guides/mini/guide-relocation.html
Am 14.10.23 um 02:51 schrieb Tamás Cservenák:
Howdy
Howdy,
ok, so I think agreed on the name (and artifactId) of the two new module:
* maven-resolver-transport-jdk (uses Java11+ java.net.http.HttpClient)
* maven-resolver-transport-jetty (uses Jetty HttpClient, probably 12.x)
and the existing ones are:
* maven-resolver-transport-classpath (CP tran
Le ven. 13 oct. 2023 à 11:07, Tamás Cservenák a
écrit :
> Howdy,
>
> Maven Central supports HTTP/2 for quite some time.
> Google Mirror of Maven Central in the EU has supported HTTP/3 since a while
> ago.
>
> And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for
> example in th
uot; (but offer some transition period
> > > supporting "native" CLI name as well)...
> > >
> > > Re CLI name, we could offer indirection, like following "meta names"
> that
> > > may mean one or more actual transport implementati
btw be careful with jdk httpclient as it doesn't really a way to
cleanup resources (see https://bugs.openjdk.org/browse/JDK-8304165)
could be an issue with mvnd
On Fri, 13 Oct 2023 at 19:20, Christoph Läubrich wrote:
>
> You can find JDK http client debugging / configuration options here:
>
> htt
e transition period
> > > supporting "native" CLI name as well)...
> > >
> > > Re CLI name, we could offer indirection, like following "meta names" that
> > > may mean one or more actual transport implementations (am talking about
> > CLI
&g
You can find JDK http client debugging / configuration options here:
https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html
sadly they seem not configurable per cbut only globally but probably
someone like to suggest this to the JDK team (e.g. something like
build
quot; that
> > may mean one or more actual transport implementations (am talking about
> CLI
> > param maven.resolver.transport):
> > - "http": means jdk, jetty, http
> > - "http1": means jdk, jetty, http
> > - "http2": means jdk, jetty
&g
Howdy,
Maven Central supports HTTP/2 for quite some time.
Google Mirror of Maven Central in the EU has supported HTTP/3 since a while
ago.
And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for
example in the sense of used ports, that may be important on farm-sized CI,
also ther
Less is better in terms of stack so jre client is the way forward for me,
it is fast, reliable and keeps getting enhancements.
On http2/3 I dont see it very relevant cause it still gets a lot of issues
and should be blacklisted for a while until serious mitigations are set up
on servers.
In terms
IMHO in contrary: that comparison is perfectly valid as:
- this is what Maven end user gets/experiences
- you should know that doing checksum extraction in Wagon today is nearly
impossible (we could put another 2 year effort into Wagon, but it would
only make it "on par" with native transport, mayb
I agree that this is a full rewrite, sadly.
Have you evaluated what degree of logging both JEtty Client and the JDK Client
offer? I consider the JDK client likely as useless in this regard. Don't know
about Jetty. At least AHC saved me a lot of trouble...
On 2023/10/13 08:23:33 Tamás Cservenák
You perfectly know that the comparison is not fair because checksum transport
is handled differently. You have to create identical conditions.
On 2023/10/13 08:11:32 Tamás Cservenák wrote:
> Howdy,
>
> Re perf (and this was already discussed about a year ago, please do not
> derail discussion):
And just add more context about transports:
Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
3.9). Numbers show that "native" is far superior over Wagon (I think we can
all agree on this).
Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
of the bes
Howdy,
Re perf (and this was already discussed about a year ago, please do not
derail discussion): look around
https://github.com/apache/maven-resolver/pull/231 and related JIRAs, there
are the numbers. TL;DR: jetty and jdk clients are consistently fastest and
are "side by side" (with the benefit
Regardless of the names, the following questions code to my mind:
* Does it make sense to put effort into too many clients?
* How many users will actually switch the client? I bet < 10%
olegk@ and me assessed many times on JIRA that HTTP/2 will have little
performance benefit for our use case of
Inline
On Thu, Oct 12, 2023 at 9:52 PM Guillaume Nodet wrote:
> Is wagon something we still want to push forward ?
>
>
Definitely not. maven-resolver-transport-wagon JAR should not be added to
Maven4 (while Wagon itself AFAIK is sadly still a must due spaghetti in
Maven3 Core that is brought ove
"http": means jdk, jetty, http
> - "http1": means jdk, jetty, http
> - "http2": means jdk, jetty
> - "http3": means jetty
>
> etc
>
> Hence, I'd:
> - not rename (change artifactId) the existing Apache HttpClient 4.x backed
&g
ort implementations (am talking about CLI
param maven.resolver.transport):
- "http": means jdk, jetty, http
- "http1": means jdk, jetty, http
- "http2": means jdk, jetty
- "http3": means jetty
etc
Hence, I'd:
- not rename (change artifactId) the existi
uses Apache HttpClient 4.x, HTTP/1.1
capable)
* maven-resolver-transport-wagon (uses Wagon, so is not only HTTP,
HTTP/1.1
capable)
Is wagon something we still want to push forward ?
And now the two new contenders:
* Java11+ java.net.http.HttpClient based (HTTP/2 capable)
* Java11+ Jetty
maven-resolver-transport-wagon (uses Wagon, so is not only HTTP,
> > HTTP/1.1
> > > > capable)
> > > >
> > >
> > > Is wagon something we still want to push forward ?
> > >
> > >
> > > >
> > > > And now the two new co
t 4.x, HTTP/1.1
> > > capable)
> > > * maven-resolver-transport-wagon (uses Wagon, so is not only HTTP,
> HTTP/1.1
> > > capable)
> > >
> >
> > Is wagon something we still want to push forward ?
> >
> >
> > >
> >
nd now the two new contenders:
> > * Java11+ java.net.http.HttpClient based (HTTP/2 capable)
> > * Java11+ Jetty12 based (HTTP/2 capable)
> >
> > So, the major question is how to name these modules (== artifactId)?
> >
> > * maven-resolver-transport-java11?
&g
gon (uses Wagon, so is not only HTTP, HTTP/1.1
> capable)
>
Is wagon something we still want to push forward ?
>
> And now the two new contenders:
> * Java11+ java.net.http.HttpClient based (HTTP/2 capable)
> * Java11+ Jetty12 based (HTTP/2 capable)
>
> So, the major questi
+ java.net.http.HttpClient based (HTTP/2 capable)
* Java11+ Jetty12 based (HTTP/2 capable)
So, the major question is how to name these modules (== artifactId)?
* maven-resolver-transport-java11?
* maven-resolver-transport-jetty12?
Maybe some form of proto+imple?
* maven-resolver-transport-http2-java11 (or shorter
maven
> | +- org.codehaus.groovy:groovy-servlet:jar:3.0.9:runtime
> > | +- org.codehaus.groovy:groovy-sql:jar:3.0.9:runtime
> > | +- org.codehaus.groovy:groovy-swing:jar:3.0.9:runtime
> > | +- org.codehaus.groovy:groovy-templates:jar:3.0.9:runtime
> > | \- org.codehaus.groo
ar:3.0.9:runtime
> | +- org.codehaus.groovy:groovy-templates:jar:3.0.9:runtime
> | \- org.codehaus.groovy:groovy-xml:jar:3.0.9:runtime
>
> So every user of m-invoker-p downloads a lot of unneeded stuff.
>
> I don't believe that someone needs sql, servlet, swing .. etc in in
don't believe that someone needs sql, servlet, swing .. etc in invoker
verify scripts.
I'm not feel good about adding the next exclusions.
My prefer way is add only some of common used modules like:
- groovy-xml
If someone needs a more special case can add it in your projects
asfgit closed pull request #79:
URL: https://github.com/apache/maven-doxia/pull/79
--
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.
To unsubscribe, e-mail: dev-unsubscr...
michael-o opened a new pull request #79:
URL: https://github.com/apache/maven-doxia/pull/79
This closes #79
--
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.
To unsubscribe,
Oops sent this to the wrong emailSent from my iPhoneBegin forwarded message:From: Claudio Corsi Date: December 15, 2020 at 20:38:30 ESTTo: dev-h...@maven.apache.orgSubject: [maven-compiler-plugin] Issue with compiling test source using modules using a multi-version maven project.Hi All,I am
Hi
I reported issue MJAVADOC-617 and also create a pull request with the fix for
it.
Can somebody review this PR or give advice how to improve it so that it could
be merged?
https://issues.apache.org/jira/browse/MJAVADOC-617
https://github.com/apache/maven-javadoc-plugin/pull/27
Thanks
Reto W
Nice, thanks :)
ake Maven
> more forgiving for mussing modules in a multi-module project?
>
> Background:
>
> https://paulhammant.com/2017/02/08/further-experiments-with-expanding-contracting-monorepos/
>
> - Paul
>
make Maven
more forgiving for mussing modules in a multi-module project?
Background:
https://paulhammant.com/2017/02/08/further-experiments-with-expanding-contracting-monorepos/
- Paul
in repository https://gitbox.apache.org/repos/asf/maven-surefire.git
> > >
> > > commit f333b7d9e89ddfe086fd1cb930df0f77a0edbc96
> > > Author: Lukas Krecan
> > > AuthorDate: Sun Jul 1 08:54:22 2018 +0200
> > >
> > > [SUREFIRE-1531] Option to disable Java 9 modules
>
AuthorDate: Sun Jul 1 08:54:22 2018 +0200
> >
> > [SUREFIRE-1531] Option to disable Java 9 modules
> > ---
> > .../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
> > .../plugin/surefire/AbstractSurefireMojo.java | 53
> > ++
: Lukas Krecan
AuthorDate: Sun Jul 1 08:54:22 2018 +0200
[SUREFIRE-1531] Option to disable Java 9 modules
---
.../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
.../plugin/surefire/AbstractSurefireMojo.java | 53
2018 13:42:44 +0200, Christian Stein
> wrote:
>
> Hi everybody,
>>
>> I filed a PR against AbstractCompilerMojo and TestCompilerMojo some days
>> ago [1] and would like to discuss it. The PR introduces support for test
>> sources organized as modules and solve
urces organized as modules and solves the inline comment reading " //
maybe some extra analysis required " in the TestCompilerMojo.
A successfully running test case using JUnit 4 as an automatic module is
included in the PR.
Cheers,
Christian
[1] https://github.com/apache/maven-plugins
Hi everybody,
I filed a PR against AbstractCompilerMojo and TestCompilerMojo some days
ago [1] and would like to discuss it. The PR introduces support for test
sources organized as modules and solves the inline comment reading " //
maybe some extra analysis required " in the TestCompil
GitHub user spyhunter99 opened a pull request:
https://github.com/apache/maven-plugins/pull/129
MPDF-81 merging in the needed doxia modules required for copyright ovâ¦
â¦errides, Add property based overrides for the copyright headers. Most of
the real changes were in
From what I tested, ServiceLoader doesn't allow a custom classloading
scheme for named modules (step 1 of
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-).
Its own scheme relies on checking modules loaded by the
y means
> that potential providers, located in named modules loaded for example by
> Maven core classloader or extension classloader, will not be available
> to plugins using ServiceLoader. So this is bigger than platform
> classloader. As Robert said, I think there needs t
Le 25/06/2017 à 22:03, Chas Honton a écrit :
Under what circumstances would a plugin not want the platform classloader?
Chas
Thinking about this more, with the current situation, it actually means
that potential providers, located in named modules loaded for example by
Maven core
So I don't think we should switch to it by default. I think the plugin is
> well aware which classloaders / modules it wants to use (it should be), so I
> think we need to find a mechanism for plugins to select their classloaders
> and modules.
>
> thanks,
> Robert
>
&
Hi Guillaume,
I don't know all the details about the Platform classloader, but it has
been introduced with a reason.
So I don't think we should switch to it by default. I think the plugin is
well aware which classloaders / modules it wants to use (it should be), so
I think we ne
Hi,
With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change
Yep. We can be opinionated, but we should allow others to follow their own
opinions (even if they are "wrong")... we just don't have to make it easy!
On Tue 21 Feb 2017 at 22:16, Hervé BOUTEMY wrote:
> Maven tool can't check everything against developper's will: we already
> have
> bad reputatio
Maven tool can't check everything against developper's will: we already have
bad reputation because we put contraints on the build.
We can't force people, we can't enforce rules.
We can define good conventions and ease their use.
Regards,
Hervé
Le mardi 21 février 2017, 03:41:12 CET Christian
Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY:
> then I'm not sure checking rules on what is inside an artifact while
> publishing in Central is the right thing to do: we don't do it currently
> (checking that package names are consistent with groupId), then I feel we
> should not do it either for
nsidered a dependency meaning we cannot allow automodules, but only
named modules.
Robert
In fact, modapp matches one of my ideas for POM5 where GA are not always
required anymore, e.g. if they are not distributed as dependency.
The inclusion of the Module-Name metadata is frankly, more than I
IMHO, this means that there is the vast majority of "normal" case
then there is life, where exceptionnally everything is mixed:
- publishing a temporary fork (for example to have some local patches)
- really forking or moving
then I'm not sure checking rules on what is inside an artifact while
pu
Am 02/18/17 um 12:25 schrieb Robert Scholte:
> The idea from Hervé and Rémi is about having a publish rule in Central if
> you want to publish a modular jar there which will prevent module name
> collisions.
> Because the groupId is already owned by a specific organisation, you could
> use th
ffect the GA, not the module name.
>
> So to be clear, Hervé and Rémi are *not* talking about automodules and how
> they should get their name, but only about named modules.
>
> Robert
>
> On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox wrote:
> > Hervé: I feel lik
us/2017/01/23/advice-for-jigsaw-regarding-auto-modules/
On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser
wrote:
I just read it all .. sigh. Looks like our concerns got ignored to me
Manfred
Robert Scholte wrote on 2017-02-16 09:23:
> FYI,
>
> Robert
>
> --- Forwarded
i are *not* talking about automodules and how
they should get their name, but only about named modules.
Robert
On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox wrote:
Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module
the recent publication shows that it has happened now)
> >
> > Then Remi and I discussed and looked for ideas on what lighter proposal to
> > do
> > for the namespace concern when sharing modules publicly
> >
> > And I proposed a simplified idea
ion from Remi Forax in France, where
> > the
> > fact that nothing was taken into consideration looked something that was
> > happenning (and the recent publication shows that it has happened now)
> >
> > Then Remi and I discussed and looked for ideas on what lighter
d for ideas on what lighter proposal to
>> do
>> for the namespace concern when sharing modules publicly
>>
>> And I proposed a simplified idea that looked promising when we challenged
>> it:
>> for modules that are to be shared on Maven Central,
>> ha
at was
> happenning (and the recent publication shows that it has happened now)
>
> Then Remi and I discussed and looked for ideas on what lighter proposal to
> do
> for the namespace concern when sharing modules publicly
>
> And I proposed a simplified idea that looked prom
do
for the namespace concern when sharing modules publicly
And I proposed a simplified idea that looked promising when we challenged it:
for modules that are to be shared on Maven Central,
handwritten full module name should *start with groupId*
applied to the example for Hibernate
future. Maybe it would be good if all Apache project and others
that are going to publish modules start with using the full namespace in the
module name. Problem is of course that the examples I saw so far all do NOT do
that so we will end up with a mess anyway..
Manfred
Brian Fox wrote on 2017-02
On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko wrote:
> Can't we just block auto-named modules from the build? We control
> dependencies and should be able to look inside and barf if we don't like
> anything, no?
>
Yes but this only applies to things that are modularize
Can't we just block auto-named modules from the build? We control
dependencies and should be able to look inside and barf if we don't like
anything, no?
I realize this does not set good defaults for non-maven projects, so
there will be some friction there, but hopefully maven userb
ren't sure what this was all about, see here:
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/
On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser
wrote:
> I just read it all .. sigh. Looks like our concerns got ignored to me
>
> Manfred
>
> Robert
I just read it all .. sigh. Looks like our concerns got ignored to me
Manfred
Robert Scholte wrote on 2017-02-16 09:23:
> FYI,
>
> Robert
>
> --- Forwarded message ---
> From: mark.reinh...@oracle.com
> To: jpms-spec-expe...@openjdk.java.net
> Cc:
> S
FYI,
Robert
--- Forwarded message ---
From: mark.reinh...@oracle.com
To: jpms-spec-expe...@openjdk.java.net
Cc:
Subject: How to name modules, automatic and otherwise
Date: Thu, 16 Feb 2017 17:48:27 +0100
This note is in reply to the concerns about automatic modules raised by
Robert
Fixed. You should be able to configure the Jenkins jobs
Robert
On Tue, 13 Dec 2016 18:43:53 +0100, Robert Scholte
wrote:
As pmc-chair I should be able to grant access[1], but I don't. I've
asked infrastructure@a.o for help
Robert
[1] https://wiki.apache.org/general/Jenkins
On Tue, 13
As pmc-chair I should be able to grant access[1], but I don't. I've asked
infrastructure@a.o for help
Robert
[1] https://wiki.apache.org/general/Jenkins
On Tue, 13 Dec 2016 05:19:25 +0100, Christian Schulte
wrote:
Would it be possible to assign me role in Jenkins allowing me to fix
thin
Would it be possible to assign me role in Jenkins allowing me to fix
things myself? I renamed 'maven-aether-provider' to
'maven-resolver-provider' and all hell breaks loose on Jenkins. I have a
strong need on a reliable CI system :-). I'd like to stop this one from
failing, for example, but cannot
Github user axel3rd closed the pull request at:
https://github.com/apache/maven-plugins/pull/93
---
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
GitHub user axel3rd opened a pull request:
https://github.com/apache/maven-plugins/pull/93
[MPIR-349] Bad modules links in 'index/modules' report when
'distributionManagement.site.url' comes from settings.xml
Detail : [MPIR-349](https://issues.apache.org/jira/b
> >> > [DOXIA-482] added an API to define if comments from source markup are
> >> > emitted as Doxia comment events
> >>
> >> > Modified:
> >> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxi
> >>
> >> &g
>
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/dox
> ia/parser/XhtmlBaseParser.java
>
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/
> org/apache/maven/doxia/module/apt/AptParser.java
>
maven/doxia/doxia/trunk
xia/trunk/doxia-core/src/main/java/org/apache/maven/dox
> > ia/parser/AbstractXmlParser.java
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/dox
> > ia/parser/Parser.java
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven
rser/XhtmlBaseParser.java
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
maven/doxia/doxia/t
thanks Rory!
that's the info I was searching for. As replied to Paul, I was hoping for
a better approach.
I will implement it just to be able to get experience with modules, but
once I have a complete picture of the impacts I'll inform the jigsaw team
and hopefully we can think
nks,
Robert
Op Fri, 13 Nov 2015 15:20:19 +0100 schreef Arnaud Héritier
:
Hi all,
This week I was at Devoxx conférence where there were various talks
about
the incoming JDK 9 and the new Java Modules. If this is a subject
that you
are interested in and want to know more (and especially how
00:21 (GMT+01:00)
Aan: Maven Developers List
Onderwerp: Re: Java 9 - Java Modules aka Jigsaw
Robert, I was watching the video and the message is important.
They want the devs using standard Java API.
It's a little paranoea around to replace Base64. Yes it's used a lot but
easy
obile.
Oorspronkelijk bericht Van: Paul Benedict
Datum:18-11-2015 23:34 (GMT+01:00)
Aan: Maven Developers List Cc:
"Rory O'Donnell Oracle, Dublin Ireland" , Dalibor
Topic Onderwerp: Re: Java 9 - Java
Modules aka Jigsaw
Robert, also see the "Greetings Worl
;
>> On 11/16/15, Tibor Digana wrote:
>>
>>> @Arno What it means for you to "how it will break maven".
>>> Does it mean J9 deprecates Maven. Too much effort for the Oracle, is not
>>> it?
>>>
>>> On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Hér
node+s40175n5851980...@n5.nabble.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >> This week I was at Devoxx conférence where there were various talks
> > >> about
> > >> the incoming JDK 9 and the new Java Modules. If this is a su
r-support\target\maven-builder-support-3.3.10-SNAPSHOT.jar
>>
>> thanks,
>> Robert
>>
>> Op Fri, 13 Nov 2015 15:20:19 +0100 schreef Arnaud Héritier <
>> aherit...@gmail.com>:
>>
>>
>> Hi all,
>>>
>>> This week I was at Devoxx c
Hi all,
>>
>> This week I was at Devoxx conférence where there were various talks
>> about
>> the incoming JDK 9 and the new Java Modules. If this is a subject that you
>> are interested in and want to know more (and especially how it will break
>>
e various talks
about
the incoming JDK 9 and the new Java Modules. If this is a subject that
you
are interested in and want to know more (and especially how it will break
maven) I recommend you to watch the recording of the following sessions
Keynote by Mark Reinhold
https://www.youtube.com/watc
<
ml-node+s40175n5851980...@n5.nabble.com> wrote:
Hi all,
This week I was at Devoxx conférence where there were various talks
about
the incoming JDK 9 and the new Java Modules. If this is a subject that
you
are interested in and want to know more (and especially how it will
break
mave
is
not
> > it?
> >
> > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
> > ml-node+s40175n5851980...@n5.nabble.com> wrote:
> >
> >> Hi all,
> >>
> >> This week I was at Devoxx conférence where there were various
talk
> > @Arno What it means for you to "how it will break maven".
>>> > > Does it mean J9 deprecates Maven. Too much effort for the Oracle, is
>>> not
>>> > > it?
>>> > >
>>> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [vi
uch effort for the Oracle, is
>> not
>> > > it?
>> > >
>> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
>> > > ml-node+s40175n5851980...@n5.nabble.com> wrote:
>> > >
>> > >> Hi all,
>> > >&g
; > > Does it mean J9 deprecates Maven. Too much effort for the Oracle, is
> not
> > > it?
> > >
> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
> > > ml-node+s40175n5851980...@n5.nabble.com> wrote:
> > >
> > >> Hi all
Does it mean J9 deprecates Maven. Too much effort for the Oracle, is not
> > it?
> >
> > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
> > ml-node+s40175n5851980...@n5.nabble.com> wrote:
> >
> >> Hi all,
> >>
> >> This week I
; Hi all,
>>
>> This week I was at Devoxx conférence where there were various talks
>> about
>> the incoming JDK 9 and the new Java Modules. If this is a subject that
>> you
>> are interested in and want to know more (and especially how it will break
>> mav
Hi all,
This week I was at Devoxx conférence where there were various talks about
the incoming JDK 9 and the new Java Modules. If this is a subject that you
are interested in and want to know more (and especially how it will break
maven) I recommend you to watch the recording of the following
Looks like this is a bug in our code - which I've now resolved. Seems the
LifeCycleParticipants are handled ONCE per session, I had a bad assumption
they might be run for each project.
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Sun, Mar 22, 20
Quick reply from phone. No - it doesn't work in both versions, I've not
tried going back further yet tho.
On 22/03/2015 8:52 am, "Jason van Zyl" wrote:
> Are you saying it works in 3.2.5 and doesn't in 3.3.1? Or that the
> behaviour is the same?
>
> On Mar 20, 2015, at 11:52 PM, Mark Derricutt
Are you saying it works in 3.2.5 and doesn't in 3.3.1? Or that the behaviour is
the same?
On Mar 20, 2015, at 11:52 PM, Mark Derricutt wrote:
> On 21 Mar 2015, at 15:23, Jason van Zyl wrote:
>
>> Put a test project somewhere and I'm happy to look, I need something I can
>> debug through to tr
1 - 100 of 423 matches
Mail list logo
