subject:"$\{modules\}"

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 transport, is not HTTP, just FTR)
* maven-resolver-transport-file (file transport, is not HTTP, just FTR)
* maven-resolver-transport-http (uses Apache HttpClient 4.x, HTTP/1.1
capable)

Cannot rename the misleading "-http" one, as that would cause disruption
with existing code, we have to live with it for now (to be renamed in
resolver 3.0 or so) :(

As for CLI names and Maven4 inclusion in distro (these are Maven4 changes,
not resolver changes), I'd propose:
* "jdk" included in distro
* "jetty" not included in distro (users can add it via .mvn/extensions.xml)
* "apache" (and deprecated CLI synonym "native") included in distro
* maven-resolver-transport-wagon is to be dropped from Maven4 (not shipped
by default, users can add it as core extension and make it work via
standard resolver priority mechanism. Wagon itself IS present in the Maven4
core, as it is required for Maven3 compatibility provided by Maven4).

Transport priorities (how Resolver selects transport if multiple one exists
for same protocol):
wagon = -1.0f (unchanged, same as today)
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporterFactory.java#L47
apache = 5.0f (unchanged, same as today)
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporterFactory.java#L51
jdk = 10.0f (proposed, to prevail "apache" transport, both will be present
in distro)
jetty = 15.0f (proposed, to prevail "jdk" transport, if present)

Note re priorities: Resolver "prioritized components" mechanism was present
since day 0 of resolver, and its purpose was to select a given
implementation if multiple ones are suited (like in our case,
TransportFactory for HTTP URL). Before Maven 3.9, wagon transport was the
ONLY HTTP capable transport present on classpath, so selection was trivial.
In Maven 3.9 both wagon and apache transports were present in distro, and
apache "prevails" by default (due default priorities, while CLI switches
tweak priorities). To not introduce changes in this area, the idea is to
position jdk transport above apache (hence priority 10, to prevail apache,
become default), while jetty priority of 15 (it is not present in distro by
default) is simply to make it "if present, it prevails". So to say, to
simplify users' lives who took effort to set it as a core extension (and to
not have to tweak more than that).

Note1: Essentially we can play "same game" as we did with Maven 3.9: we
will switch default transport AGAIN IF user uses Java11+ (but this time
from apache/native to jdk), providing fallback for users hitting a blocker
bug in the form of `-Dmaven.resolver.transport=apache`, and for those still
relying on Wagon (ie. using legacy config), they would need two steps a)
make wagon transport be in .mvn/extensions.xml and b) use
`-Dmaven.resolver.transport=wagon`. I believe this is acceptable, while we
are in "alpha" with Maven 4. Of course, this last paragraph is just a
proposal, does not have to happen (we can make it in 4.1 or alike).
Note2: the "...if user uses Java11+" is nicely handled by Sisu. If Maven4
remains Java8 bytecode level, and the user uses Java8 to run Maven4, Sisu
will silently omit jdk transport (as Java8 will be unable to load the
Java11 bytecode).

If anyone objects, please yell here. Otherwise will continue along
these lines.

Thanks
T

On Fri, Oct 13, 2023 at 1:12 PM Romain Manni-Bucau 
wrote:

> 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 the sense of used ports, that may be important on farm-sized
> CI,
> > also there is noticeable perf improvement as well), the real boost will
> be
> > probably HTTP/3. Sadly, a year or more ago, when I did perf testing,
> > Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today.
> >
>
> Until you protect servers against ddos, so we shouldnt benefit from there
> and boost is not really in these protocol but more in nio usage where you
> get way faster than current sync whetever protocol you use.
>
>
>
> > I agree also:
> > - jdk/jre client is clearly way to go forward (and is even
> dependency-less,
> > so would make Maven distro even lighter, but unlike
> wagon-http-lightweight,
> > is fully featured)
> > - jetty client is "way forward" for those who may want early adoption on
> > things like HTTP/3 etc

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 the sense of used ports, that may be important on farm-sized CI,
> also there is noticeable perf improvement as well), the real boost will be
> probably HTTP/3. Sadly, a year or more ago, when I did perf testing,
> Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today.
>

Until you protect servers against ddos, so we shouldnt benefit from there
and boost is not really in these protocol but more in nio usage where you
get way faster than current sync whetever protocol you use.



> I agree also:
> - jdk/jre client is clearly way to go forward (and is even dependency-less,
> so would make Maven distro even lighter, but unlike wagon-http-lightweight,
> is fully featured)
> - jetty client is "way forward" for those who may want early adoption on
> things like HTTP/3 etc (at the cost of more deps)
>
>
> On Fri, Oct 13, 2023 at 10:50 AM Romain Manni-Bucau  >
> wrote:
>
> > 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 of style, virtual threads are just a default async style which
> is
> > not mainstream and will not for years. It also foes not prevent locking,
> in
> > particular with our current codebase so a full rewrite is relevant if
> there
> > is any will and if not becoming lighter is what is the most relevant.
> >
> > All that to say that staying on jre client, keeping an abstractio  is
> what
> > I see as relevant.
> > Other impl can be extensions in an extra repo but sound additional
> > maintenance without end user gain from my window.
> >
> >
> > Le ven. 13 oct. 2023 à 10:30, Michael Osipov  a
> > écrit :
> >
> > > 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 wrote:
> > > > 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 best HTTP libraries I used), and this implies we are stuck
> with
> > > > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> > > Ironically,
> > > > the moment we provided "superior" HTTP transport in Maven, we got
> stuck
> > > at
> > > > the same time. While there is AHC 5.x (sync, that is not HTTP/2
> > capable,
> > > > and async, both require heavy rewrite), switching to it requires
> _full
> > > > rewrite_ as mentioned. Plus the "go async" if you want to leverage
> any
> > > new
> > > > protocol. Basically it is like writing resolver transport from
> scratch.
> > > >
> > > > Hence, I think it is more sane to invest our effort into something
> more
> > > > stable, that at the same time gives us (promises us) future headroom
> as
> > > > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience)
> Jetty
> > > > HttpClient are such things. There is no need for _full rewrite_
> between
> > > > major versions.
> > > >
> > > > In the longer term, this will actually lower the needed effort to
> > > maintain
> > > > these resolver transports, while at the same time prevent us being
> > > cornered
> > > > again.
> > > >
> > > > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > > > 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 of Jetty doing
> > HTTP/3
> > > as
> > > > > well, but with the downside of huge dep trail), while Wagon is
> > > consistently
> > > > > the slowest. Differences wildly differ but are very notable.
> > > > >
> > > > > Personally, I am not interested in doing a full rewrite of existing
> > AHC
> > > > > transport (as the expected amount of bugs doing this is pretty much
> > on
> > > par
> > > > > with doing fully new transport from scratch). I'd rather just
> choose
> > a
> > > > > library with a

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

Le ven. 13 oct. 2023 à 11:12, Tamás Cservenák  a
écrit :

> I prefer "jdk" over "jre", as IMHO using the term "jre" would be confusing
> for users.
> When Oracle dropped delivering standalone "jre", users stopped using the
> term as well. Also, a long time ago, there was constant confusion
> that Maven needed JDK and not JRE to run, as users were by mistake
> installing JREs and failed to get full Maven functionality... (am talking
> about 2000s :) ).
>
> IMHO, if we start using the term "jre" today, that might just confuse
> users...
>

It still exists and anyone doing images (oci) cares. Jdk still implies dev
env whereas here we deliver a plain runtime lib. Jvm can be an in between
alternative but jdk sounds too connotated.


> my 5 cents.
>
> On Fri, Oct 13, 2023 at 9:50 AM Romain Manni-Bucau 
> wrote:
>
> > s/jdk/jre/ otherwise agree
> >
> > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > I am leaning toward:
> > > maven-resolver-transport-jetty (name "jetty") <- NEW
> > > maven-resolver-transport-jdk (name "jdk") <- NEW
> > > maven-resolver-transport-http (name "http", CLI name "native") w/o
> module
> > > rename
> > > maven-resolver-transport-file
> > > maven-resolver-transport-classpath
> > >
> > > As I agree with above mentioned reasons (jetty version, etc) but I
> would
> > > not go for existing -http module rename, as we promised "simple
> upgrade"
> > > for Resolver 1.x users... In short, code that works with 1.x resolver
> > > should still work unchanged with 2.x resolver (if it does not use
> > > deprecated stuff that is about to be dropped).
> > >
> > > The "name" is actually Sisu component name (ATNamed), but is also a
> short
> > > name used on Maven CLI to select transport. Again, "native" is cuckoo
> egg
> > > here, rest is nicely aligned.
> > >
> > > Maven4 could advertise existing maven-resolver-transport-http as CLI
> name
> > > "something else" instead of "native" (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 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 existing Apache HttpClient 4.x
> > backed
> > > transport module (would break code using 1.x)
> > > - name new modules simply -jetty and -jdk (with corresponding "names"
> as
> > > well, have those aligned)
> > > - transition badly named "native" on CLI into something else (but
> what?)
> > >
> > > On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich <
> m...@laeubi-soft.de>
> > > wrote:
> > >
> > > > maybe better
> > > >
> > > > - jdk impl -> jdk
> > > > - jetty -> jetty
> > > > - current apache -> apache
> > > >
> > > > Am 13.10.23 um 02:30 schrieb Olivier Lamy:
> > > > > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák  >
> > > > wrote:
> > > > >>
> > > > >> Currently the names are like these:
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
> > > > >>
> > > > >> So "wagon", "native" (for maven-resolver-transport-http), and
> "auto"
> > > (to
> > > > >> apply Resolver built-in auto selection.
> > > > >> Hence, I envision "jetty" and "jdk"?
> > > > >
> > > > > jetty sounds good.
> > > > > But frankly native looks wrong to me (wrong marketing :)) as it is
> > > > > using apache httpclient so this would deserve to be named with what
> > is
> > > > > reality used.
> > > > > r

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Olivier Lamy

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:
>
> 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
> builder.setProperty(...) )
>
>
> Am 13.10.23 um 10:28 schrieb Michael Osipov:
> > 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 wrote:
> >> 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 best HTTP libraries I used), and this implies we are stuck with
> >> HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
> >> the moment we provided "superior" HTTP transport in Maven, we got stuck at
> >> the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> >> and async, both require heavy rewrite), switching to it requires _full
> >> rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
> >> protocol. Basically it is like writing resolver transport from scratch.
> >>
> >> Hence, I think it is more sane to invest our effort into something more
> >> stable, that at the same time gives us (promises us) future headroom as
> >> well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> >> HttpClient are such things. There is no need for _full rewrite_ between
> >> major versions.
> >>
> >> In the longer term, this will actually lower the needed effort to maintain
> >> these resolver transports, while at the same time prevent us being cornered
> >> again.
> >>
> >> On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
> >> wrote:
> >>
> >>> 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 of Jetty doing HTTP/3 as
> >>> well, but with the downside of huge dep trail), while Wagon is 
> >>> consistently
> >>> the slowest. Differences wildly differ but are very notable.
> >>>
> >>> Personally, I am not interested in doing a full rewrite of existing AHC
> >>> transport (as the expected amount of bugs doing this is pretty much on par
> >>> with doing fully new transport from scratch). I'd rather just choose a
> >>> library with a more stable API, like Jetty is. Moreover, forcing "async"
> >>> style in 2023 is something I'd avoid in today's written Java code (esp 
> >>> with
> >>> 21 virtual threads). But sure, if you want to do it, go for it (this work
> >>> would at least move Maven as a project forward, not backward).
> >>>
> >>> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> >>> wrote:
> >>>
>  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 transport. I'd like to see a move
>  to Apache HttpClient 5 Async which does everything, but that is work.
>  Having both AHC async and Jetty HTTP Client is a logical overlap and
>  unnecessary maintenance burden. While I know nothing about the Jetty
>  Client, the AHC (any version) has exceptional logging output down to 
>  bytes
>  of streams which helps very often to analyze problem with users.
> 
>  I personally refuse and close out issue on JIRA where the user is not
>  able to present that kind of debugging information. Poking in the dark.
> 
>  M
> 
>  -
>  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
> >
>
>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Olivier Lamy

On Fri, 13 Oct 2023 at 19:12, Tamás Cservenák  wrote:
>
> I prefer "jdk" over "jre", as IMHO using the term "jre" would be confusing
> for users.
> When Oracle dropped delivering standalone "jre", users stopped using the
> term as well. Also, a long time ago, there was constant confusion
> that Maven needed JDK and not JRE to run, as users were by mistake
> installing JREs and failed to get full Maven functionality... (am talking
> about 2000s :) ).

yup jdk makes more sense to me as well (as anyway Maven users have a
jdk as they are compiling sources.

Regarding logs with Jetty, no worries you can even get more than what
you really need :)
Jetty have a nice easy to use async API (it's the natural usage of it)

http2 sounds a good nice to have (even if it doesn't improve so much
performance at least this can reduce load on server by reducing
concurrent connection number)
http3 not sure it;s something to focus on at least now...


>
> IMHO, if we start using the term "jre" today, that might just confuse
> users...
>
> my 5 cents.
>
> On Fri, Oct 13, 2023 at 9:50 AM Romain Manni-Bucau 
> wrote:
>
> > s/jdk/jre/ otherwise agree
> >
> > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > I am leaning toward:
> > > maven-resolver-transport-jetty (name "jetty") <- NEW
> > > maven-resolver-transport-jdk (name "jdk") <- NEW
> > > maven-resolver-transport-http (name "http", CLI name "native") w/o module
> > > rename
> > > maven-resolver-transport-file
> > > maven-resolver-transport-classpath
> > >
> > > As I agree with above mentioned reasons (jetty version, etc) but I would
> > > not go for existing -http module rename, as we promised "simple upgrade"
> > > for Resolver 1.x users... In short, code that works with 1.x resolver
> > > should still work unchanged with 2.x resolver (if it does not use
> > > deprecated stuff that is about to be dropped).
> > >
> > > The "name" is actually Sisu component name (ATNamed), but is also a short
> > > name used on Maven CLI to select transport. Again, "native" is cuckoo egg
> > > here, rest is nicely aligned.
> > >
> > > Maven4 could advertise existing maven-resolver-transport-http as CLI name
> > > "something else" instead of "native" (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 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 existing Apache HttpClient 4.x
> > backed
> > > transport module (would break code using 1.x)
> > > - name new modules simply -jetty and -jdk (with corresponding "names" as
> > > well, have those aligned)
> > > - transition badly named "native" on CLI into something else (but what?)
> > >
> > > On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich 
> > > wrote:
> > >
> > > > maybe better
> > > >
> > > > - jdk impl -> jdk
> > > > - jetty -> jetty
> > > > - current apache -> apache
> > > >
> > > > Am 13.10.23 um 02:30 schrieb Olivier Lamy:
> > > > > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák 
> > > > wrote:
> > > > >>
> > > > >> Currently the names are like these:
> > > > >>
> > > >
> > >
> > https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
> > > > >>
> > > > >> So "wagon", "native" (for maven-resolver-transport-http), and "auto"
> > > (to
> > > > >> apply Resolver built-in auto selection.
> > > > >> Hence, I envision "jetty" and "jdk"?
> > > > >
> > > > > jetty sounds good.
> > > > > But frankly native looks wrong to m

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Christoph Läubrich


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 
builder.setProperty(...) )



Am 13.10.23 um 10:28 schrieb Michael Osipov:

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 wrote:

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 best HTTP libraries I used), and this implies we are stuck with
HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
the moment we provided "superior" HTTP transport in Maven, we got stuck at
the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
and async, both require heavy rewrite), switching to it requires _full
rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
protocol. Basically it is like writing resolver transport from scratch.

Hence, I think it is more sane to invest our effort into something more
stable, that at the same time gives us (promises us) future headroom as
well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
HttpClient are such things. There is no need for _full rewrite_ between
major versions.

In the longer term, this will actually lower the needed effort to maintain
these resolver transports, while at the same time prevent us being cornered
again.

On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
wrote:


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 of Jetty doing HTTP/3 as
well, but with the downside of huge dep trail), while Wagon is consistently
the slowest. Differences wildly differ but are very notable.

Personally, I am not interested in doing a full rewrite of existing AHC
transport (as the expected amount of bugs doing this is pretty much on par
with doing fully new transport from scratch). I'd rather just choose a
library with a more stable API, like Jetty is. Moreover, forcing "async"
style in 2023 is something I'd avoid in today's written Java code (esp with
21 virtual threads). But sure, if you want to do it, go for it (this work
would at least move Maven as a project forward, not backward).

On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
wrote:


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 transport. I'd like to see a move
to Apache HttpClient 5 Async which does everything, but that is work.
Having both AHC async and Jetty HTTP Client is a logical overlap and
unnecessary maintenance burden. While I know nothing about the Jetty
Client, the AHC (any version) has exceptional logging output down to bytes
of streams which helps very often to analyze problem with users.

I personally refuse and close out issue on JIRA where the user is not
able to present that kind of debugging information. Poking in the dark.

M

-
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



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

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

I prefer "jdk" over "jre", as IMHO using the term "jre" would be confusing
for users.
When Oracle dropped delivering standalone "jre", users stopped using the
term as well. Also, a long time ago, there was constant confusion
that Maven needed JDK and not JRE to run, as users were by mistake
installing JREs and failed to get full Maven functionality... (am talking
about 2000s :) ).

IMHO, if we start using the term "jre" today, that might just confuse
users...

my 5 cents.

On Fri, Oct 13, 2023 at 9:50 AM Romain Manni-Bucau 
wrote:

> s/jdk/jre/ otherwise agree
>
> Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > I am leaning toward:
> > maven-resolver-transport-jetty (name "jetty") <- NEW
> > maven-resolver-transport-jdk (name "jdk") <- NEW
> > maven-resolver-transport-http (name "http", CLI name "native") w/o module
> > rename
> > maven-resolver-transport-file
> > maven-resolver-transport-classpath
> >
> > As I agree with above mentioned reasons (jetty version, etc) but I would
> > not go for existing -http module rename, as we promised "simple upgrade"
> > for Resolver 1.x users... In short, code that works with 1.x resolver
> > should still work unchanged with 2.x resolver (if it does not use
> > deprecated stuff that is about to be dropped).
> >
> > The "name" is actually Sisu component name (ATNamed), but is also a short
> > name used on Maven CLI to select transport. Again, "native" is cuckoo egg
> > here, rest is nicely aligned.
> >
> > Maven4 could advertise existing maven-resolver-transport-http as CLI name
> > "something else" instead of "native" (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 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 existing Apache HttpClient 4.x
> backed
> > transport module (would break code using 1.x)
> > - name new modules simply -jetty and -jdk (with corresponding "names" as
> > well, have those aligned)
> > - transition badly named "native" on CLI into something else (but what?)
> >
> > On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich 
> > wrote:
> >
> > > maybe better
> > >
> > > - jdk impl -> jdk
> > > - jetty -> jetty
> > > - current apache -> apache
> > >
> > > Am 13.10.23 um 02:30 schrieb Olivier Lamy:
> > > > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák 
> > > wrote:
> > > >>
> > > >> Currently the names are like these:
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
> > > >>
> > > >> So "wagon", "native" (for maven-resolver-transport-http), and "auto"
> > (to
> > > >> apply Resolver built-in auto selection.
> > > >> Hence, I envision "jetty" and "jdk"?
> > > >
> > > > jetty sounds good.
> > > > But frankly native looks wrong to me (wrong marketing :)) as it is
> > > > using apache httpclient so this would deserve to be named with what
> is
> > > > reality used.
> > > > reading from the outside using native currently gives a false idea
> > > > about what is really used. native for me means C code  :)
> > > > native sounds more appropriate for the "jdk native" implementation.
> > > > maybe the naming could be fixed now with 2.0.0 upgrade.
> > > > such:
> > > > - jdk impl -> native
> > > >   - jetty -> jetty
> > > > - current apache -> htttpciient
> > > >
> > > > to have some backward compact maybe auto could use htttpciient
> > > >
> > > > just some thought from the peanut gallery.
> > > >
> > > >>
> > > >> T
> > > >>
> > > >> On Thu, Oct 12,

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 there is noticeable perf improvement as well), the real boost will be
probably HTTP/3. Sadly, a year or more ago, when I did perf testing,
Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today.

I agree also:
- jdk/jre client is clearly way to go forward (and is even dependency-less,
so would make Maven distro even lighter, but unlike wagon-http-lightweight,
is fully featured)
- jetty client is "way forward" for those who may want early adoption on
things like HTTP/3 etc (at the cost of more deps)


On Fri, Oct 13, 2023 at 10:50 AM Romain Manni-Bucau 
wrote:

> 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 of style, virtual threads are just a default async style which is
> not mainstream and will not for years. It also foes not prevent locking, in
> particular with our current codebase so a full rewrite is relevant if there
> is any will and if not becoming lighter is what is the most relevant.
>
> All that to say that staying on jre client, keeping an abstractio  is what
> I see as relevant.
> Other impl can be extensions in an extra repo but sound additional
> maintenance without end user gain from my window.
>
>
> Le ven. 13 oct. 2023 à 10:30, Michael Osipov  a
> écrit :
>
> > 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 wrote:
> > > 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 best HTTP libraries I used), and this implies we are stuck with
> > > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> > Ironically,
> > > the moment we provided "superior" HTTP transport in Maven, we got stuck
> > at
> > > the same time. While there is AHC 5.x (sync, that is not HTTP/2
> capable,
> > > and async, both require heavy rewrite), switching to it requires _full
> > > rewrite_ as mentioned. Plus the "go async" if you want to leverage any
> > new
> > > protocol. Basically it is like writing resolver transport from scratch.
> > >
> > > Hence, I think it is more sane to invest our effort into something more
> > > stable, that at the same time gives us (promises us) future headroom as
> > > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> > > HttpClient are such things. There is no need for _full rewrite_ between
> > > major versions.
> > >
> > > In the longer term, this will actually lower the needed effort to
> > maintain
> > > these resolver transports, while at the same time prevent us being
> > cornered
> > > again.
> > >
> > > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
> > > wrote:
> > >
> > > > 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 of Jetty doing
> HTTP/3
> > as
> > > > well, but with the downside of huge dep trail), while Wagon is
> > consistently
> > > > the slowest. Differences wildly differ but are very notable.
> > > >
> > > > Personally, I am not interested in doing a full rewrite of existing
> AHC
> > > > transport (as the expected amount of bugs doing this is pretty much
> on
> > par
> > > > with doing fully new transport from scratch). I'd rather just choose
> a
> > > > library with a more stable API, like Jetty is. Moreover, forcing
> > "async"
> > > > style in 2023 is something I'd avoid in today's written Java code
> (esp
> > with
> > > > 21 virtual threads). But sure, if you want to do it, go for it (this
> > work
> > > > would at least move Maven as a project forward, not backward).
> > > >
> > > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> > > > wrote:
> > > >
> > > >> Regardless of the names, the following questions code to my mind:
> > > >>
> > > >> * Does it make sense to put effort into too many clients?
> >

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 of style, virtual threads are just a default async style which is
not mainstream and will not for years. It also foes not prevent locking, in
particular with our current codebase so a full rewrite is relevant if there
is any will and if not becoming lighter is what is the most relevant.

All that to say that staying on jre client, keeping an abstractio  is what
I see as relevant.
Other impl can be extensions in an extra repo but sound additional
maintenance without end user gain from my window.


Le ven. 13 oct. 2023 à 10:30, Michael Osipov  a écrit :

> 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 wrote:
> > 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 best HTTP libraries I used), and this implies we are stuck with
> > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> Ironically,
> > the moment we provided "superior" HTTP transport in Maven, we got stuck
> at
> > the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> > and async, both require heavy rewrite), switching to it requires _full
> > rewrite_ as mentioned. Plus the "go async" if you want to leverage any
> new
> > protocol. Basically it is like writing resolver transport from scratch.
> >
> > Hence, I think it is more sane to invest our effort into something more
> > stable, that at the same time gives us (promises us) future headroom as
> > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> > HttpClient are such things. There is no need for _full rewrite_ between
> > major versions.
> >
> > In the longer term, this will actually lower the needed effort to
> maintain
> > these resolver transports, while at the same time prevent us being
> cornered
> > again.
> >
> > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
> > wrote:
> >
> > > 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 of Jetty doing HTTP/3
> as
> > > well, but with the downside of huge dep trail), while Wagon is
> consistently
> > > the slowest. Differences wildly differ but are very notable.
> > >
> > > Personally, I am not interested in doing a full rewrite of existing AHC
> > > transport (as the expected amount of bugs doing this is pretty much on
> par
> > > with doing fully new transport from scratch). I'd rather just choose a
> > > library with a more stable API, like Jetty is. Moreover, forcing
> "async"
> > > style in 2023 is something I'd avoid in today's written Java code (esp
> with
> > > 21 virtual threads). But sure, if you want to do it, go for it (this
> work
> > > would at least move Maven as a project forward, not backward).
> > >
> > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> > > wrote:
> > >
> > >> 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 transport. I'd like to see a
> move
> > >> to Apache HttpClient 5 Async which does everything, but that is work.
> > >> Having both AHC async and Jetty HTTP Client is a logical overlap and
> > >> unnecessary maintenance burden. While I know nothing about the Jetty
> > >> Client, the AHC (any version) has exceptional logging output down to
> bytes
> > >> of streams which helps very often to analyze problem with users.
> > >>
> > >> I personally refuse and close out issue on JIRA where the user is not
> > >> able to present that kind of debugging information. Poking in the
> dark.
> > >>
> > >> M
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> >
>
>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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, maybe, IMHO, not worth it)
- both are still HTTP/1.1 only
- IMHO, Wagon benefit (of being protocol agnostic) is also it's biggest
downside/hurdle as well: whatever new requirement comes in (like checksum
extraction was), it is way simpler solved in implementations like "native"
(direct use of client library), instead of gleaning thru layers and layers
of abstraction and probably adding new layers to solve it (while those
layers are what makes "protocol agnostic" thing possible).

Today:
- resolver needs fast, performant and robust transport, dedicated for that
purpose only, we don't want a "swiss army knife" that does everything.
- The 2000s with "remote repositories made out of sticks" (httpd + mod_dav,
etc) are gone, we can all agree that HTTP protocol is the main transport
protocol for artifact transport. Hence, ssh, sftp, DAV, and any other
exotic thing loses its importance, as today it is only one liner Docker CLI
to spin up a fully fledged MRM.

As for logging, for JDK I have no idea (and am somewhat aligned with you
here, "probably useless"), while for Jetty I am pretty much sure Jetty devs
would not hinder, or better, shoot themselves in their foot, by having
their supported product produce obfuscated, unusable or scarce debug logs
:) So for Jetty and debug, I'd not be worried.

On Fri, Oct 13, 2023 at 10:27 AM Michael Osipov  wrote:

> 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): 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 of Jetty doing HTTP/3 as well, but
> > with the downside of huge dep trail), while Wagon is consistently the
> > slowest. Differences wildly differ but are very notable.
> >
> > Personally, I am not interested in doing a full rewrite of existing AHC
> > transport (as the expected amount of bugs doing this is pretty much on
> par
> > with doing fully new transport from scratch). I'd rather just choose a
> > library with a more stable API, like Jetty is. Moreover, forcing "async"
> > style in 2023 is something I'd avoid in today's written Java code (esp
> with
> > 21 virtual threads). But sure, if you want to do it, go for it (this work
> > would at least move Maven as a project forward, not backward).
> >
> > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> wrote:
> >
> > > 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 transport. I'd like to see a
> move
> > > to Apache HttpClient 5 Async which does everything, but that is work.
> > > Having both AHC async and Jetty HTTP Client is a logical overlap and
> > > unnecessary maintenance burden. While I know nothing about the Jetty
> > > Client, the AHC (any version) has exceptional logging output down to
> bytes
> > > of streams which helps very often to analyze problem with users.
> > >
> > > I personally refuse and close out issue on JIRA where the user is not
> able
> > > to present that kind of debugging information. Poking in the dark.
> > >
> > > M
> > >
> > > -
> > > 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
>
>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Michael Osipov

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 wrote:
> 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 best HTTP libraries I used), and this implies we are stuck with
> HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
> the moment we provided "superior" HTTP transport in Maven, we got stuck at
> the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> and async, both require heavy rewrite), switching to it requires _full
> rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
> protocol. Basically it is like writing resolver transport from scratch.
> 
> Hence, I think it is more sane to invest our effort into something more
> stable, that at the same time gives us (promises us) future headroom as
> well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> HttpClient are such things. There is no need for _full rewrite_ between
> major versions.
> 
> In the longer term, this will actually lower the needed effort to maintain
> these resolver transports, while at the same time prevent us being cornered
> again.
> 
> On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
> wrote:
> 
> > 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 of Jetty doing HTTP/3 as
> > well, but with the downside of huge dep trail), while Wagon is consistently
> > the slowest. Differences wildly differ but are very notable.
> >
> > Personally, I am not interested in doing a full rewrite of existing AHC
> > transport (as the expected amount of bugs doing this is pretty much on par
> > with doing fully new transport from scratch). I'd rather just choose a
> > library with a more stable API, like Jetty is. Moreover, forcing "async"
> > style in 2023 is something I'd avoid in today's written Java code (esp with
> > 21 virtual threads). But sure, if you want to do it, go for it (this work
> > would at least move Maven as a project forward, not backward).
> >
> > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> > wrote:
> >
> >> 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 transport. I'd like to see a move
> >> to Apache HttpClient 5 Async which does everything, but that is work.
> >> Having both AHC async and Jetty HTTP Client is a logical overlap and
> >> unnecessary maintenance burden. While I know nothing about the Jetty
> >> Client, the AHC (any version) has exceptional logging output down to bytes
> >> of streams which helps very often to analyze problem with users.
> >>
> >> I personally refuse and close out issue on JIRA where the user is not
> >> able to present that kind of debugging information. Poking in the dark.
> >>
> >> M
> >>
> >> -
> >> 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

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Michael Osipov

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): 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 of Jetty doing HTTP/3 as well, but
> with the downside of huge dep trail), while Wagon is consistently the
> slowest. Differences wildly differ but are very notable.
> 
> Personally, I am not interested in doing a full rewrite of existing AHC
> transport (as the expected amount of bugs doing this is pretty much on par
> with doing fully new transport from scratch). I'd rather just choose a
> library with a more stable API, like Jetty is. Moreover, forcing "async"
> style in 2023 is something I'd avoid in today's written Java code (esp with
> 21 virtual threads). But sure, if you want to do it, go for it (this work
> would at least move Maven as a project forward, not backward).
> 
> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov  wrote:
> 
> > 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 transport. I'd like to see a move
> > to Apache HttpClient 5 Async which does everything, but that is work.
> > Having both AHC async and Jetty HTTP Client is a logical overlap and
> > unnecessary maintenance burden. While I know nothing about the Jetty
> > Client, the AHC (any version) has exceptional logging output down to bytes
> > of streams which helps very often to analyze problem with users.
> >
> > I personally refuse and close out issue on JIRA where the user is not able
> > to present that kind of debugging information. Poking in the dark.
> >
> > M
> >
> > -
> > 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

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 best HTTP libraries I used), and this implies we are stuck with
HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
the moment we provided "superior" HTTP transport in Maven, we got stuck at
the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
and async, both require heavy rewrite), switching to it requires _full
rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
protocol. Basically it is like writing resolver transport from scratch.

Hence, I think it is more sane to invest our effort into something more
stable, that at the same time gives us (promises us) future headroom as
well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
HttpClient are such things. There is no need for _full rewrite_ between
major versions.

In the longer term, this will actually lower the needed effort to maintain
these resolver transports, while at the same time prevent us being cornered
again.

On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák 
wrote:

> 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 of Jetty doing HTTP/3 as
> well, but with the downside of huge dep trail), while Wagon is consistently
> the slowest. Differences wildly differ but are very notable.
>
> Personally, I am not interested in doing a full rewrite of existing AHC
> transport (as the expected amount of bugs doing this is pretty much on par
> with doing fully new transport from scratch). I'd rather just choose a
> library with a more stable API, like Jetty is. Moreover, forcing "async"
> style in 2023 is something I'd avoid in today's written Java code (esp with
> 21 virtual threads). But sure, if you want to do it, go for it (this work
> would at least move Maven as a project forward, not backward).
>
> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov 
> wrote:
>
>> 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 transport. I'd like to see a move
>> to Apache HttpClient 5 Async which does everything, but that is work.
>> Having both AHC async and Jetty HTTP Client is a logical overlap and
>> unnecessary maintenance burden. While I know nothing about the Jetty
>> Client, the AHC (any version) has exceptional logging output down to bytes
>> of streams which helps very often to analyze problem with users.
>>
>> I personally refuse and close out issue on JIRA where the user is not
>> able to present that kind of debugging information. Poking in the dark.
>>
>> M
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 of Jetty doing HTTP/3 as well, but
with the downside of huge dep trail), while Wagon is consistently the
slowest. Differences wildly differ but are very notable.

Personally, I am not interested in doing a full rewrite of existing AHC
transport (as the expected amount of bugs doing this is pretty much on par
with doing fully new transport from scratch). I'd rather just choose a
library with a more stable API, like Jetty is. Moreover, forcing "async"
style in 2023 is something I'd avoid in today's written Java code (esp with
21 virtual threads). But sure, if you want to do it, go for it (this work
would at least move Maven as a project forward, not backward).

On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov  wrote:

> 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 transport. I'd like to see a move
> to Apache HttpClient 5 Async which does everything, but that is work.
> Having both AHC async and Jetty HTTP Client is a logical overlap and
> unnecessary maintenance burden. While I know nothing about the Jetty
> Client, the AHC (any version) has exceptional logging output down to bytes
> of streams which helps very often to analyze problem with users.
>
> I personally refuse and close out issue on JIRA where the user is not able
> to present that kind of debugging information. Poking in the dark.
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Michael Osipov

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 transport. I'd like to see a move to 
Apache HttpClient 5 Async which does everything, but that is work. Having both 
AHC async and Jetty HTTP Client is a logical overlap and unnecessary 
maintenance burden. While I know nothing about the Jetty Client, the AHC (any 
version) has exceptional logging output down to bytes of streams which helps 
very often to analyze problem with users.

I personally refuse and close out issue on JIRA where the user is not able to 
present that kind of debugging information. Poking in the dark.

M

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

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

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 over to Maven4). This will make Wagon
"invisible" for Resolver. If someone really needs it, can add it (as any
other "extra", not shipped by default resolver transport).

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

s/jdk/jre/ otherwise agree

Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák  a
écrit :

> Howdy,
>
> I am leaning toward:
> maven-resolver-transport-jetty (name "jetty") <- NEW
> maven-resolver-transport-jdk (name "jdk") <- NEW
> maven-resolver-transport-http (name "http", CLI name "native") w/o module
> rename
> maven-resolver-transport-file
> maven-resolver-transport-classpath
>
> As I agree with above mentioned reasons (jetty version, etc) but I would
> not go for existing -http module rename, as we promised "simple upgrade"
> for Resolver 1.x users... In short, code that works with 1.x resolver
> should still work unchanged with 2.x resolver (if it does not use
> deprecated stuff that is about to be dropped).
>
> The "name" is actually Sisu component name (ATNamed), but is also a short
> name used on Maven CLI to select transport. Again, "native" is cuckoo egg
> here, rest is nicely aligned.
>
> Maven4 could advertise existing maven-resolver-transport-http as CLI name
> "something else" instead of "native" (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 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 existing Apache HttpClient 4.x backed
> transport module (would break code using 1.x)
> - name new modules simply -jetty and -jdk (with corresponding "names" as
> well, have those aligned)
> - transition badly named "native" on CLI into something else (but what?)
>
> On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich 
> wrote:
>
> > maybe better
> >
> > - jdk impl -> jdk
> > - jetty -> jetty
> > - current apache -> apache
> >
> > Am 13.10.23 um 02:30 schrieb Olivier Lamy:
> > > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák 
> > wrote:
> > >>
> > >> Currently the names are like these:
> > >>
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
> > >>
> > >> So "wagon", "native" (for maven-resolver-transport-http), and "auto"
> (to
> > >> apply Resolver built-in auto selection.
> > >> Hence, I envision "jetty" and "jdk"?
> > >
> > > jetty sounds good.
> > > But frankly native looks wrong to me (wrong marketing :)) as it is
> > > using apache httpclient so this would deserve to be named with what is
> > > reality used.
> > > reading from the outside using native currently gives a false idea
> > > about what is really used. native for me means C code  :)
> > > native sounds more appropriate for the "jdk native" implementation.
> > > maybe the naming could be fixed now with 2.0.0 upgrade.
> > > such:
> > > - jdk impl -> native
> > >   - jetty -> jetty
> > > - current apache -> htttpciient
> > >
> > > to have some backward compact maybe auto could use htttpciient
> > >
> > > just some thought from the peanut gallery.
> > >
> > >>
> > >> T
> > >>
> > >> On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy 
> wrote:
> > >>
> > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet 
> > wrote:
> > >>>>
> > >>>> Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák 
> a
> > >>>> écrit :
> > >>>>
> > >>>>> Howdy,
> > >>>>>
> > >>>>> As part of the new Resolver major version, one of the goals is to
> > >>> introduce
> > >>>>> HTTP/2 capable transports. And as always, naming...
> > >>>>>
> > >>>>> Current transport module names (==artifactId) are (already quite
> long
> > >>> for
> > >>>>> my taste):
> > >>>>> * maven-resolver-transport-classpath (CP transport, is not HTTP,
> just
> > >>> FTR)
> > >>>>> * maven-resolver-transport-file (file transport, is not HTTP, just
> > FTR)
> >

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

Howdy,

I am leaning toward:
maven-resolver-transport-jetty (name "jetty") <- NEW
maven-resolver-transport-jdk (name "jdk") <- NEW
maven-resolver-transport-http (name "http", CLI name "native") w/o module
rename
maven-resolver-transport-file
maven-resolver-transport-classpath

As I agree with above mentioned reasons (jetty version, etc) but I would
not go for existing -http module rename, as we promised "simple upgrade"
for Resolver 1.x users... In short, code that works with 1.x resolver
should still work unchanged with 2.x resolver (if it does not use
deprecated stuff that is about to be dropped).

The "name" is actually Sisu component name (ATNamed), but is also a short
name used on Maven CLI to select transport. Again, "native" is cuckoo egg
here, rest is nicely aligned.

Maven4 could advertise existing maven-resolver-transport-http as CLI name
"something else" instead of "native" (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 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 existing Apache HttpClient 4.x backed
transport module (would break code using 1.x)
- name new modules simply -jetty and -jdk (with corresponding "names" as
well, have those aligned)
- transition badly named "native" on CLI into something else (but what?)

On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich 
wrote:

> maybe better
>
> - jdk impl -> jdk
> - jetty -> jetty
> - current apache -> apache
>
> Am 13.10.23 um 02:30 schrieb Olivier Lamy:
> > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák 
> wrote:
> >>
> >> Currently the names are like these:
> >>
> https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
> >>
> >> So "wagon", "native" (for maven-resolver-transport-http), and "auto" (to
> >> apply Resolver built-in auto selection.
> >> Hence, I envision "jetty" and "jdk"?
> >
> > jetty sounds good.
> > But frankly native looks wrong to me (wrong marketing :)) as it is
> > using apache httpclient so this would deserve to be named with what is
> > reality used.
> > reading from the outside using native currently gives a false idea
> > about what is really used. native for me means C code  :)
> > native sounds more appropriate for the "jdk native" implementation.
> > maybe the naming could be fixed now with 2.0.0 upgrade.
> > such:
> > - jdk impl -> native
> >   - jetty -> jetty
> > - current apache -> htttpciient
> >
> > to have some backward compact maybe auto could use htttpciient
> >
> > just some thought from the peanut gallery.
> >
> >>
> >> T
> >>
> >> On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy  wrote:
> >>
> >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet 
> wrote:
> >>>>
> >>>> Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák  a
> >>>> écrit :
> >>>>
> >>>>> Howdy,
> >>>>>
> >>>>> As part of the new Resolver major version, one of the goals is to
> >>> introduce
> >>>>> HTTP/2 capable transports. And as always, naming...
> >>>>>
> >>>>> Current transport module names (==artifactId) are (already quite long
> >>> for
> >>>>> my taste):
> >>>>> * maven-resolver-transport-classpath (CP transport, is not HTTP, just
> >>> FTR)
> >>>>> * maven-resolver-transport-file (file transport, is not HTTP, just
> FTR)
> >>>>> * maven-resolver-transport-http (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)
> >>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-13 Thread Christoph Läubrich

maybe better

- jdk impl -> jdk
- jetty -> jetty
- current apache -> apache

Am 13.10.23 um 02:30 schrieb Olivier Lamy:

On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák wrote:

Currently the names are like these:
https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109

So "wagon", "native" (for maven-resolver-transport-http), and "auto" (to
apply Resolver built-in auto selection.
Hence, I envision "jetty" and "jdk"?

jetty sounds good.
But frankly native looks wrong to me (wrong marketing :)) as it is
using apache httpclient so this would deserve to be named with what is
reality used.
reading from the outside using native currently gives a false idea
about what is really used. native for me means C code :)
native sounds more appropriate for the "jdk native" implementation.
maybe the naming could be fixed now with 2.0.0 upgrade.
such:
- jdk impl -> native
- jetty -> jetty
- current apache -> htttpciient

to have some backward compact maybe auto could use htttpciient

just some thought from the peanut gallery.

On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy wrote:

On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet wrote:

Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák a
écrit :

Howdy,

As part of the new Resolver major version, one of the goals is to

introduce

HTTP/2 capable transports. And as always, naming...

Current transport module names (==artifactId) are (already quite long

for

my taste):
* maven-resolver-transport-classpath (CP transport, is not HTTP, just

FTR)

* maven-resolver-transport-file (file transport, is not HTTP, just FTR)
* maven-resolver-transport-http (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+ 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-resolver-transport-h2-java11)

Http is enough imho. Which version is supported by which implementation

an internal detail. Unless there are HTTP/2 server which does not

support

HTTP/1.1 in which case it could become relevant. Or any client

supporting

HTTP/2 and not HTTP/1.1...

* maven-resolver-transport-http2-jetty (or shorter
maven-resolver-transport-h2-jetty)

agree on the no need of Jetty version.
We should be able to use Jetty transport for http1 as well (the Jetty
client can support multiple protocols including http3).
maybe maven-resolver-transport-jetty (as it shouldn't have an http2
limitation)

what will be the names to use in poms or cli to activate those
transporters?
Maybe we should keep them short to not have an extra long
configuration esp when using cli.

I like the longest better because they are more descriptive of what they
actually are.
So protocol + client sounds fine.

But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
Also, the Jetty version matters, so once in future there will be

Jetty13

etc...

Do we really care ? We need different providers if they provide different
things. I don't think jetty 12 provides anything different than jetty

13.

In addition, we won't be able to ship both jetty 12 and jetty 13 at the
same time, so I think we can keep a single one, which means we can drop

the

version.
Which version we ship is a separate discussion and it impacts the runtime
JDK requirements I suppose.

Same for java11, maybe jdk would be better to indicate this is the http
client from the jdk (if you're using jdk 17, that one will be used, not

the

one from jdk 11). I do understand it has been introduced in JDK 11, but
still...

So in short, i'd go for:
maven-resolver-transport-http-jetty
maven-resolver-transport-http-jdk
maven-resolver-transport-http-httpclient
maven-resolver-transport-file
maven-resolver-transport-classpath

Cheers
Guillaume

Ideas welcome.

Thanks
T

PS: Given java.net.http.HttpClient based transport will be

dependency-less,

it reminds me of good old wagon-http-lightweight, but unlike wagon one
(that was quite limited), this will be fully capable transport.

Guillaume Nodet

-
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.

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-12 Thread Olivier Lamy

On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák  wrote:
>
> Currently the names are like these:
> https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
>
> So "wagon", "native" (for maven-resolver-transport-http), and "auto" (to
> apply Resolver built-in auto selection.
> Hence, I envision "jetty" and "jdk"?

jetty sounds good.
But frankly native looks wrong to me (wrong marketing :)) as it is
using apache httpclient so this would deserve to be named with what is
reality used.
reading from the outside using native currently gives a false idea
about what is really used. native for me means C code  :)
native sounds more appropriate for the "jdk native" implementation.
maybe the naming could be fixed now with 2.0.0 upgrade.
such:
- jdk impl -> native
 - jetty -> jetty
- current apache -> htttpciient

to have some backward compact maybe auto could use htttpciient

just some thought from the peanut gallery.

>
> T
>
> On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy  wrote:
>
> > On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet  wrote:
> > >
> > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Howdy,
> > > >
> > > > As part of the new Resolver major version, one of the goals is to
> > introduce
> > > > HTTP/2 capable transports. And as always, naming...
> > > >
> > > > Current transport module names (==artifactId) are (already quite long
> > for
> > > > my taste):
> > > > * maven-resolver-transport-classpath (CP transport, is not HTTP, just
> > FTR)
> > > > * maven-resolver-transport-file (file transport, is not HTTP, just FTR)
> > > > * maven-resolver-transport-http (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+ 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-resolver-transport-h2-java11)
> > > >
> > >
> > > Http is enough imho. Which version is supported by which implementation
> > is
> > > an internal detail.  Unless there are HTTP/2 server which does not
> > support
> > > HTTP/1.1 in which case it could become relevant.  Or any client
> > supporting
> > > HTTP/2 and not HTTP/1.1...
> > >
> > >
> > >
> > > > * maven-resolver-transport-http2-jetty (or shorter
> > > > maven-resolver-transport-h2-jetty)
> > > >
> >
> >
> > agree on the no need of Jetty version.
> > We should be able to use Jetty transport for http1 as well (the Jetty
> > client can support multiple protocols including http3).
> > maybe maven-resolver-transport-jetty (as it shouldn't have an http2
> > limitation)
> >
> > what will be the names to use in poms or cli to activate those
> > transporters?
> > Maybe we should keep them short to not have an extra long
> > configuration esp when using cli.
> >
> > >
> > > I like the longest better because they are more descriptive of what they
> > > actually are.
> > > So protocol + client sounds fine.
> > >
> > >
> > > >
> > > > But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
> > > > Also, the Jetty version matters, so once in future there will be
> > Jetty13
> > > > etc...
> > > >
> > >
> > > Do we really care ? We need different providers if they provide different
> > > things.  I don't think jetty 12 provides anything different than jetty
> > 13.
> > > In addition, we won't be able to ship both jetty 12 and jetty 13 at the
> > > same time, so I think we can keep a single one, which means we can drop
> >

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-12 Thread Tamás Cservenák

Currently the names are like these:
https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109

So "wagon", "native" (for maven-resolver-transport-http), and "auto" (to
apply Resolver built-in auto selection.
Hence, I envision "jetty" and "jdk"?

T

On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy  wrote:

> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet  wrote:
> >
> > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > As part of the new Resolver major version, one of the goals is to
> introduce
> > > HTTP/2 capable transports. And as always, naming...
> > >
> > > Current transport module names (==artifactId) are (already quite long
> for
> > > my taste):
> > > * maven-resolver-transport-classpath (CP transport, is not HTTP, just
> FTR)
> > > * maven-resolver-transport-file (file transport, is not HTTP, just FTR)
> > > * maven-resolver-transport-http (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+ 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-resolver-transport-h2-java11)
> > >
> >
> > Http is enough imho. Which version is supported by which implementation
> is
> > an internal detail.  Unless there are HTTP/2 server which does not
> support
> > HTTP/1.1 in which case it could become relevant.  Or any client
> supporting
> > HTTP/2 and not HTTP/1.1...
> >
> >
> >
> > > * maven-resolver-transport-http2-jetty (or shorter
> > > maven-resolver-transport-h2-jetty)
> > >
>
>
> agree on the no need of Jetty version.
> We should be able to use Jetty transport for http1 as well (the Jetty
> client can support multiple protocols including http3).
> maybe maven-resolver-transport-jetty (as it shouldn't have an http2
> limitation)
>
> what will be the names to use in poms or cli to activate those
> transporters?
> Maybe we should keep them short to not have an extra long
> configuration esp when using cli.
>
> >
> > I like the longest better because they are more descriptive of what they
> > actually are.
> > So protocol + client sounds fine.
> >
> >
> > >
> > > But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
> > > Also, the Jetty version matters, so once in future there will be
> Jetty13
> > > etc...
> > >
> >
> > Do we really care ? We need different providers if they provide different
> > things.  I don't think jetty 12 provides anything different than jetty
> 13.
> > In addition, we won't be able to ship both jetty 12 and jetty 13 at the
> > same time, so I think we can keep a single one, which means we can drop
> the
> > version.
> > Which version we ship is a separate discussion and it impacts the runtime
> > JDK requirements I suppose.
> >
> > Same for java11, maybe jdk would be better to indicate this is the http
> > client from the jdk (if you're using jdk 17, that one will be used, not
> the
> > one from jdk 11).  I do understand it has been introduced in JDK 11, but
> > still...
> >
> > So in short, i'd go for:
> >   maven-resolver-transport-http-jetty
> >   maven-resolver-transport-http-jdk
> >   maven-resolver-transport-http-httpclient
> >   maven-resolver-transport-file
> >   maven-resolver-transport-classpath
> >
> > Cheers
> > Guillaume
> >
> >
> >
> > >
> > > Ideas welcome.
> > >
> > > Thanks
> > > T
> > >
> > > PS: Given java.net.http.HttpClient based transport will be
> dependency-less,
> > > it reminds me of good old wagon-http-lightweight, but unlike wagon one
> > > (that was quite limited), this will be fully capable transport.
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-12 Thread Olivier Lamy

On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet  wrote:
>
> Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > As part of the new Resolver major version, one of the goals is to introduce
> > HTTP/2 capable transports. And as always, naming...
> >
> > Current transport module names (==artifactId) are (already quite long for
> > my taste):
> > * maven-resolver-transport-classpath (CP transport, is not HTTP, just FTR)
> > * maven-resolver-transport-file (file transport, is not HTTP, just FTR)
> > * maven-resolver-transport-http (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+ 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-resolver-transport-h2-java11)
> >
>
> Http is enough imho. Which version is supported by which implementation is
> an internal detail.  Unless there are HTTP/2 server which does not support
> HTTP/1.1 in which case it could become relevant.  Or any client supporting
> HTTP/2 and not HTTP/1.1...
>
>
>
> > * maven-resolver-transport-http2-jetty (or shorter
> > maven-resolver-transport-h2-jetty)
> >


agree on the no need of Jetty version.
We should be able to use Jetty transport for http1 as well (the Jetty
client can support multiple protocols including http3).
maybe maven-resolver-transport-jetty (as it shouldn't have an http2 limitation)

what will be the names to use in poms or cli to activate those transporters?
Maybe we should keep them short to not have an extra long
configuration esp when using cli.

>
> I like the longest better because they are more descriptive of what they
> actually are.
> So protocol + client sounds fine.
>
>
> >
> > But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
> > Also, the Jetty version matters, so once in future there will be Jetty13
> > etc...
> >
>
> Do we really care ? We need different providers if they provide different
> things.  I don't think jetty 12 provides anything different than jetty 13.
> In addition, we won't be able to ship both jetty 12 and jetty 13 at the
> same time, so I think we can keep a single one, which means we can drop the
> version.
> Which version we ship is a separate discussion and it impacts the runtime
> JDK requirements I suppose.
>
> Same for java11, maybe jdk would be better to indicate this is the http
> client from the jdk (if you're using jdk 17, that one will be used, not the
> one from jdk 11).  I do understand it has been introduced in JDK 11, but
> still...
>
> So in short, i'd go for:
>   maven-resolver-transport-http-jetty
>   maven-resolver-transport-http-jdk
>   maven-resolver-transport-http-httpclient
>   maven-resolver-transport-file
>   maven-resolver-transport-classpath
>
> Cheers
> Guillaume
>
>
>
> >
> > Ideas welcome.
> >
> > Thanks
> > T
> >
> > PS: Given java.net.http.HttpClient based transport will be dependency-less,
> > it reminds me of good old wagon-http-lightweight, but unlike wagon one
> > (that was quite limited), this will be fully capable transport.
> >
>
>
> --
> 
> Guillaume Nodet

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

Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-12 Thread Guillaume Nodet

Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák  a
écrit :

> Howdy,
>
> As part of the new Resolver major version, one of the goals is to introduce
> HTTP/2 capable transports. And as always, naming...
>
> Current transport module names (==artifactId) are (already quite long for
> my taste):
> * maven-resolver-transport-classpath (CP transport, is not HTTP, just FTR)
> * maven-resolver-transport-file (file transport, is not HTTP, just FTR)
> * maven-resolver-transport-http (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+ 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-resolver-transport-h2-java11)
>

Http is enough imho. Which version is supported by which implementation is
an internal detail.  Unless there are HTTP/2 server which does not support
HTTP/1.1 in which case it could become relevant.  Or any client supporting
HTTP/2 and not HTTP/1.1...



> * maven-resolver-transport-http2-jetty (or shorter
> maven-resolver-transport-h2-jetty)
>

I like the longest better because they are more descriptive of what they
actually are.
So protocol + client sounds fine.


>
> But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
> Also, the Jetty version matters, so once in future there will be Jetty13
> etc...
>

Do we really care ? We need different providers if they provide different
things.  I don't think jetty 12 provides anything different than jetty 13.
In addition, we won't be able to ship both jetty 12 and jetty 13 at the
same time, so I think we can keep a single one, which means we can drop the
version.
Which version we ship is a separate discussion and it impacts the runtime
JDK requirements I suppose.

Same for java11, maybe jdk would be better to indicate this is the http
client from the jdk (if you're using jdk 17, that one will be used, not the
one from jdk 11).  I do understand it has been introduced in JDK 11, but
still...

So in short, i'd go for:
  maven-resolver-transport-http-jetty
  maven-resolver-transport-http-jdk
  maven-resolver-transport-http-httpclient
  maven-resolver-transport-file
  maven-resolver-transport-classpath

Cheers
Guillaume



>
> Ideas welcome.
>
> Thanks
> T
>
> PS: Given java.net.http.HttpClient based transport will be dependency-less,
> it reminds me of good old wagon-http-lightweight, but unlike wagon one
> (that was quite limited), this will be fully capable transport.
>


-- 

Guillaume Nodet

[DISCUSS] Maven Resolver 2.x HTTP/2 transport modules

2023-10-12 Thread Tamás Cservenák

Howdy,

As part of the new Resolver major version, one of the goals is to introduce
HTTP/2 capable transports. And as always, naming...

Current transport module names (==artifactId) are (already quite long for
my taste):
* maven-resolver-transport-classpath (CP transport, is not HTTP, just FTR)
* maven-resolver-transport-file (file transport, is not HTTP, just FTR)
* maven-resolver-transport-http (uses Apache HttpClient 4.x, HTTP/1.1
capable)
* maven-resolver-transport-wagon (uses Wagon, so is not only HTTP, HTTP/1.1
capable)

And 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?
* maven-resolver-transport-jetty12?

Maybe some form of proto+imple?

* maven-resolver-transport-http2-java11 (or shorter
maven-resolver-transport-h2-java11)
* maven-resolver-transport-http2-jetty (or shorter
maven-resolver-transport-h2-jetty)

But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well).
Also, the Jetty version matters, so once in future there will be Jetty13
etc...

Ideas welcome.

Thanks
T

PS: Given java.net.http.HttpClient based transport will be dependency-less,
it reminds me of good old wagon-http-lightweight, but unlike wagon one
(that was quite limited), this will be fully capable transport.

Re: maven-invoker-plugin and groovy modules

2022-05-21 Thread Slawomir Jaranowski

Hi,

Issue for it https://issues.apache.org/jira/browse/MINVOKER-304

sob., 14 maj 2022 o 21:53 Hervé BOUTEMY  napisał(a):

> looks like a good idea
> +1
>
> Regards,
>
> Hervé
>
> Le samedi 14 mai 2022, 15:47:25 CEST Slawomir Jaranowski a écrit :
> > Hi,
> >
> > currently in m-invoker-p we have a dependency with a lot of exclusions
> ...
> >
> > 
> >   org.codehaus.groovy
> >   groovy-all
> >   3.0.9
> >   pom
> >   runtime
> >   
> > 
> >   org.codehaus.groovy
> >   groovy-groovysh
> > 
> > 
> >   org.codehaus.groovy
> >   groovy-test
> > 
> > 
> >   org.codehaus.groovy
> >   groovy-test-junit5
> > 
> > 
> >   org.codehaus.groovy
> >   groovy-testng
> > 
> >   
> > 
> >
> > but anyway, dependency tree is:
> >
> > +- org.codehaus.groovy:groovy-all:pom:3.0.9:runtime
> >
> > |  +- org.codehaus.groovy:groovy:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-ant:jar:3.0.9:runtime
> > |
> > |  |  +- org.apache.ant:ant:jar:1.10.11:runtime
> > |  |  +- org.apache.ant:ant-junit:jar:1.10.11:runtime
> > |  |
> > |  |  |  \- com.sun:tools:jar:1.8.0:system
> > |  |
> > |  |  +- org.apache.ant:ant-launcher:jar:1.10.11:runtime
> > |  |  \- org.apache.ant:ant-antlr:jar:1.10.11:runtime
> > |
> > |  +- org.codehaus.groovy:groovy-astbuilder:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-cli-picocli:jar:3.0.9:runtime
> > |
> > |  |  \- info.picocli:picocli:jar:4.6.1:runtime
> > |
> > |  +- org.codehaus.groovy:groovy-console:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-datetime:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-docgenerator:jar:3.0.9:runtime
> > |
> > |  |  \- com.thoughtworks.qdox:qdox:jar:1.12.1:runtime
> > |
> > |  +- org.codehaus.groovy:groovy-groovydoc:jar:3.0.9:runtime
> > |
> > |  |  \- com.github.javaparser:javaparser-core:jar:3.23.0:runtime
> > |
> > |  +- org.codehaus.groovy:groovy-jmx:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-json:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-jsr223:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-macro:jar:3.0.9:runtime
> > |  +- org.codehaus.groovy:groovy-nio:jar:3.0.9:runtime
> > |  +- 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.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 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 to
> plugin
> > dependencies.
> >
> > What do you think?
> > What special groovy modules are you used in invoker groovy scripts?
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: maven-invoker-plugin and groovy modules

2022-05-14 Thread Hervé BOUTEMY

looks like a good idea
+1

Regards,

Hervé

Le samedi 14 mai 2022, 15:47:25 CEST Slawomir Jaranowski a écrit :
> Hi,
> 
> currently in m-invoker-p we have a dependency with a lot of exclusions ...
> 
> 
>   org.codehaus.groovy
>   groovy-all
>   3.0.9
>   pom
>   runtime
>   
> 
>   org.codehaus.groovy
>   groovy-groovysh
> 
> 
>   org.codehaus.groovy
>   groovy-test
> 
> 
>   org.codehaus.groovy
>   groovy-test-junit5
> 
> 
>   org.codehaus.groovy
>   groovy-testng
> 
>   
> 
> 
> but anyway, dependency tree is:
> 
> +- org.codehaus.groovy:groovy-all:pom:3.0.9:runtime
> 
> |  +- org.codehaus.groovy:groovy:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-ant:jar:3.0.9:runtime
> |  
> |  |  +- org.apache.ant:ant:jar:1.10.11:runtime
> |  |  +- org.apache.ant:ant-junit:jar:1.10.11:runtime
> |  |  
> |  |  |  \- com.sun:tools:jar:1.8.0:system
> |  |  
> |  |  +- org.apache.ant:ant-launcher:jar:1.10.11:runtime
> |  |  \- org.apache.ant:ant-antlr:jar:1.10.11:runtime
> |  
> |  +- org.codehaus.groovy:groovy-astbuilder:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-cli-picocli:jar:3.0.9:runtime
> |  
> |  |  \- info.picocli:picocli:jar:4.6.1:runtime
> |  
> |  +- org.codehaus.groovy:groovy-console:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-datetime:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-docgenerator:jar:3.0.9:runtime
> |  
> |  |  \- com.thoughtworks.qdox:qdox:jar:1.12.1:runtime
> |  
> |  +- org.codehaus.groovy:groovy-groovydoc:jar:3.0.9:runtime
> |  
> |  |  \- com.github.javaparser:javaparser-core:jar:3.23.0:runtime
> |  
> |  +- org.codehaus.groovy:groovy-jmx:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-json:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-jsr223:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-macro:jar:3.0.9:runtime
> |  +- org.codehaus.groovy:groovy-nio:jar:3.0.9:runtime
> |  +- 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.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 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 to plugin
> dependencies.
> 
> What do you think?
> What special groovy modules are you used in invoker groovy scripts?





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

maven-invoker-plugin and groovy modules

2022-05-14 Thread Slawomir Jaranowski

Hi,

currently in m-invoker-p we have a dependency with a lot of exclusions ...


  org.codehaus.groovy
  groovy-all
  3.0.9
  pom
  runtime
  

  org.codehaus.groovy
  groovy-groovysh


  org.codehaus.groovy
  groovy-test


  org.codehaus.groovy
  groovy-test-junit5


  org.codehaus.groovy
  groovy-testng

  


but anyway, dependency tree is:

+- org.codehaus.groovy:groovy-all:pom:3.0.9:runtime
|  +- org.codehaus.groovy:groovy:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-ant:jar:3.0.9:runtime
|  |  +- org.apache.ant:ant:jar:1.10.11:runtime
|  |  +- org.apache.ant:ant-junit:jar:1.10.11:runtime
|  |  |  \- com.sun:tools:jar:1.8.0:system
|  |  +- org.apache.ant:ant-launcher:jar:1.10.11:runtime
|  |  \- org.apache.ant:ant-antlr:jar:1.10.11:runtime
|  +- org.codehaus.groovy:groovy-astbuilder:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-cli-picocli:jar:3.0.9:runtime
|  |  \- info.picocli:picocli:jar:4.6.1:runtime
|  +- org.codehaus.groovy:groovy-console:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-datetime:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-docgenerator:jar:3.0.9:runtime
|  |  \- com.thoughtworks.qdox:qdox:jar:1.12.1:runtime
|  +- org.codehaus.groovy:groovy-groovydoc:jar:3.0.9:runtime
|  |  \- com.github.javaparser:javaparser-core:jar:3.23.0:runtime
|  +- org.codehaus.groovy:groovy-jmx:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-json:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-jsr223:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-macro:jar:3.0.9:runtime
|  +- org.codehaus.groovy:groovy-nio:jar:3.0.9:runtime
|  +- 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.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 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 to plugin
dependencies.

What do you think?
What special groovy modules are you used in invoker groovy scripts?


-- 
Sławomir Jaranowski

[GitHub] [maven-doxia] asfgit closed pull request #79: [DOXIA-630] Remove all deprecated modules

2021-12-30 Thread GitBox



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...@maven.apache.org

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-doxia] michael-o opened a new pull request #79: [DOXIA-630] Remove all deprecated modules

2021-12-29 Thread GitBox



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, e-mail: dev-unsubscr...@maven.apache.org

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

Fwd: [maven-compiler-plugin] Issue with compiling test source using modules using a multi-version maven project.

2020-12-15 Thread Claudio Corsi

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 using maven to develop a java agent that uses a multi-version jar file.  This is being developed within a single project module instead of using multiple modules.  The issue is that my initial jar file will default compilation target is jdk 7 and it includes classes for jdk 9.  The issue is that I am creating a test that is using modules and when I try to build the module specific test code.  I get the UnsupportedOperationException that includes the message:Can't compile test sources when main sources are missing a module descriptorThis is generated within the TestCompilerMojo#preparePaths method.  I tried to get around this issue by adding compiler specific attributes in the pom file but alas I was not able to get around this issue.  I then forked the maven-compiler-plugin code and updated the code.  I was able to get around this issue by adding the following code to the mentioned method.    // It is possible that we are building a multi-version jar file in which the main classes are not module based.    if ( ! mainModuleDescriptorClassFile.exists() && release != null )    {    // @todo does it really matter that we check the version?    int version = Integer.valueOf( release );    if ( version >= 9 )    {    String releaseOutputDirectory = String.format( "%s%sMETA-INF%sversions%s%d",    getProject().getBuild().getOutputDirectory(), File.separator, File.separator,    File.separator, version );    // @todo how to add the releaseOutputDirectory automatically?    // testPath.add( releaseOutputDirectory );    mainModuleDescriptorClassFile =  new File ( releaseOutputDirectory, "module-info.class" );    if ( getLog().isDebugEnabled() )    {    getLog().debug( "Updated main module " + mainModuleDescriptorClassFile );    }    }    }This was add after the initial for loop for the master branch (3.9.0-SNAPSHOT).  I was able to get around the initial exception but alas I was still having issues building the test source.  I then was able to get around the issue by adding the following compilerArgs to my pom file:      --module-path    ${project.basedir}/target/classes/META-INF/versions/9  This allowed me to build the test source for that specific test module.I then was wondering if there is a better solution to this issue and I noticed that if I added the releaseOutputDirectory to the testPath collection then the above compilerArgs would not be required to be able to build the test sources.  My question then is, "Is their a better way then adding the directory to the testPath?".   I worry that the above solution will not work in all cases and can be a maintenance nightmare.  It seems that being forced to include the compileArgs to the test source build is a better overall solution.  Any opinions or comments on the above proposal?I've attach the test pom and patched TestCompilerMojo files.Thanks,--Claudio

TestCompilerMojo.java
Description: Binary data


pom.xml
Description: XML document

MJAVADOC-617 aggregate-jar does nothing if aggregator modules are referenced using relative pathes ...

2019-09-03 Thread Reto Weiss

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 Weiss

Re: Hacking my own version of Maven that'd forgive missing sub-modules

2019-08-17 Thread Paul Hammant

Nice, thanks :)

Re: Hacking my own version of Maven that'd forgive missing sub-modules

2019-08-17 Thread Romain Manni-Bucau

Hello Paul,

Did you check maven extensions? You can rewrite the pom programmatically -
and respect maven rules whatever initial state is in the pom - without
patching maven core implementing a AbstractMavenLifecycleParticipant.


See
https://maven.apache.org/ref/3.5.0/apidocs/org/apache/maven/AbstractMavenLifecycleParticipant.html
and
https://github.com/rmannibucau/maven-log-configurer-extension/blob/master/src/main/java/com/github/rmannibucau/maven/log/configurer/LogConfigurer.java
for a sample.

Hope it helps.

Le sam. 17 août 2019 à 11:49, Paul Hammant  a écrit :

> Class
> maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder is
> where "Child module  of  does not exist" causes the build
> to cease.  I'd like to make that optional for myself for huge-monorepo and
> sparse-checkout-coolness reasons.  Is that the best place to 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
>

Hacking my own version of Maven that'd forgive missing sub-modules

2019-08-17 Thread Paul Hammant

Class
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder is
where "Child module  of  does not exist" causes the build
to cease.  I'd like to make that optional for myself for huge-monorepo and
sparse-checkout-coolness reasons.  Is that the best place to 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

Re: [maven-surefire] 01/01: [SUREFIRE-1531] Option to disable Java 9 modules

2018-11-17 Thread Enrico Olivelli

+1

Enrico

Il sab 17 nov 2018, 18:01 Tibor Digana  ha scritto:

> Hi Robert,
> Sorry I have not seen your email before.
> " useModulePath " sounds good. I will rename the property if no objections.
>
> BR
> Tibor
>
> On Sat, Nov 17, 2018 at 1:00 PM Robert Scholte 
> wrote:
>
> > On Sat, 17 Nov 2018 11:34:43 +0100,  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > tibordigana pushed a commit to branch SUREFIRE-1531
> > > 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
> > > ---
> > >  .../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
> > >  .../plugin/surefire/AbstractSurefireMojo.java  | 53
> > > +++---
> > >  .../AbstractSurefireMojoJava7PlusTest.java | 12 +
> > >  .../plugin/surefire/AbstractSurefireMojoTest.java  | 12 +
> > >  .../maven/plugin/surefire/MojoMocklessTest.java| 12 +
> > >  .../maven/plugin/surefire/SurefirePlugin.java  | 23 ++
> > >  6 files changed, 119 insertions(+), 16 deletions(-)
> > >
> > > diff --git
> > >
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> >
> > >
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > > index 52f9052..42b4cc6 100644
> > > ---
> > >
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > > +++
> > >
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > > @@ -370,6 +370,17 @@ public class IntegrationTestMojo
> > >  @Parameter( property = "failsafe.shutdown", defaultValue =
> > > "testset" )
> > >  private String shutdown;
> > > +/**
> > > + * Disables Jigsaw (Java 9) modular path even if
> > > module-info.java is used in project.
> > > + * 
> > > + * Enabled by default.
> > > + * If enabled, module-info.java exists and executes with
> > JDK
> > > 9+, modular path is used.
> > > + *
> > > + * @since 3.0.0-M2
> > > + */
> > > +@Parameter( property = "failsafe.useJigsawModules", defaultValue =
> > > "true" )
> > > +private boolean useJigsawModules;
> > > +
> >
> >
> > I think we should avoid referring to Jigsaw, that was the name of the
> > project.
> > I'd prefer useJavaModules instead, or maybe even useModulePath.
> >
> >
> > >  @Override
> > >  protected int getRerunFailingTestsCount()
> > >  {
> > > @@ -801,6 +812,18 @@ public class IntegrationTestMojo
> > >  }
> > > @Override
> > > +protected boolean useJigsawModules()
> > > +{
> > > +return useJigsawModules;
> > > +}
> > > +
> > > +@Override
> > > +protected void setUseJigsawModules( boolean useJigsawModules )
> > > +{
> > > +this.useJigsawModules = useJigsawModules;
> > > +}
> > > +
> > > +@Override
> > >  protected final List suiteXmlFiles()
> > >  {
> > >  return hasSuiteXmlFiles() ? Arrays.asList( suiteXmlFiles ) :
> > > Collections.emptyList();
> > > diff --git
> > >
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> >
> > >
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > > index 319f21d..4a1a213 100644
> > > ---
> > >
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > > +++
> > >
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > > @@ -104,6 +104,7 @@ import java.util.SortedSet;
> > >  import java.util.TreeSet;
> > >  import java.util.concurrent.ConcurrentHashMap;
> > > +import static java.lang.Boolean.TRUE;
> > >  import static java.lang.Thread.

Re: [maven-surefire] 01/01: [SUREFIRE-1531] Option to disable Java 9 modules

2018-11-17 Thread Tibor Digana

Hi Robert,
Sorry I have not seen your email before.
" useModulePath " sounds good. I will rename the property if no objections.

BR
Tibor

On Sat, Nov 17, 2018 at 1:00 PM Robert Scholte  wrote:

> On Sat, 17 Nov 2018 11:34:43 +0100,  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > tibordigana pushed a commit to branch SUREFIRE-1531
> > 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
> > ---
> >  .../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
> >  .../plugin/surefire/AbstractSurefireMojo.java  | 53
> > +++---
> >  .../AbstractSurefireMojoJava7PlusTest.java | 12 +
> >  .../plugin/surefire/AbstractSurefireMojoTest.java  | 12 +
> >  .../maven/plugin/surefire/MojoMocklessTest.java| 12 +
> >  .../maven/plugin/surefire/SurefirePlugin.java  | 23 ++
> >  6 files changed, 119 insertions(+), 16 deletions(-)
> >
> > diff --git
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
>
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > index 52f9052..42b4cc6 100644
> > ---
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > +++
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > @@ -370,6 +370,17 @@ public class IntegrationTestMojo
> >  @Parameter( property = "failsafe.shutdown", defaultValue =
> > "testset" )
> >  private String shutdown;
> > +/**
> > + * Disables Jigsaw (Java 9) modular path even if
> > module-info.java is used in project.
> > + * 
> > + * Enabled by default.
> > + * If enabled, module-info.java exists and executes with
> JDK
> > 9+, modular path is used.
> > + *
> > + * @since 3.0.0-M2
> > + */
> > +@Parameter( property = "failsafe.useJigsawModules", defaultValue =
> > "true" )
> > +private boolean useJigsawModules;
> > +
>
>
> I think we should avoid referring to Jigsaw, that was the name of the
> project.
> I'd prefer useJavaModules instead, or maybe even useModulePath.
>
>
> >  @Override
> >  protected int getRerunFailingTestsCount()
> >  {
> > @@ -801,6 +812,18 @@ public class IntegrationTestMojo
> >  }
> > @Override
> > +protected boolean useJigsawModules()
> > +{
> > +return useJigsawModules;
> > +}
> > +
> > +@Override
> > +protected void setUseJigsawModules( boolean useJigsawModules )
> > +{
> > +this.useJigsawModules = useJigsawModules;
> > +}
> > +
> > +@Override
> >  protected final List suiteXmlFiles()
> >  {
> >  return hasSuiteXmlFiles() ? Arrays.asList( suiteXmlFiles ) :
> > Collections.emptyList();
> > diff --git
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
>
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > index 319f21d..4a1a213 100644
> > ---
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > +++
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > @@ -104,6 +104,7 @@ import java.util.SortedSet;
> >  import java.util.TreeSet;
> >  import java.util.concurrent.ConcurrentHashMap;
> > +import static java.lang.Boolean.TRUE;
> >  import static java.lang.Thread.currentThread;
> >  import static java.util.Arrays.asList;
> >  import static java.util.Collections.addAll;
> > @@ -728,6 +729,9 @@ public abstract class AbstractSurefireMojo
> >  @Parameter( property = "dependenciesToScan" )
> >  private String[] dependenciesToScan;
> > +/**
> > + *
> > + */
> >  @Component
> >  private ToolchainManager toolchainManager;
> > @@ -787,6 +791,10 @@ public abstract class AbstractSurefireMojo
> > protected abstract String getReportSchemaLocation();
> > +protected abstract boolean useJigsawModules();
&

Re: [maven-surefire] 01/01: [SUREFIRE-1531] Option to disable Java 9 modules

2018-11-17 Thread Robert Scholte


On Sat, 17 Nov 2018 11:34:43 +0100,  wrote:


This is an automated email from the ASF dual-hosted git repository.

tibordigana pushed a commit to branch SUREFIRE-1531
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
---
 .../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
 .../plugin/surefire/AbstractSurefireMojo.java  | 53  
+++---

 .../AbstractSurefireMojoJava7PlusTest.java | 12 +
 .../plugin/surefire/AbstractSurefireMojoTest.java  | 12 +
 .../maven/plugin/surefire/MojoMocklessTest.java| 12 +
 .../maven/plugin/surefire/SurefirePlugin.java  | 23 ++
 6 files changed, 119 insertions(+), 16 deletions(-)

diff --git  
a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java  
b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java

index 52f9052..42b4cc6 100644
---  
a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
+++  
b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java

@@ -370,6 +370,17 @@ public class IntegrationTestMojo
 @Parameter( property = "failsafe.shutdown", defaultValue =  
"testset" )

 private String shutdown;
+/**
+ * Disables Jigsaw (Java 9) modular path even if  
module-info.java is used in project.

+ * 
+ * Enabled by default.
+ * If enabled, module-info.java exists and executes with JDK  
9+, modular path is used.

+ *
+ * @since 3.0.0-M2
+ */
+@Parameter( property = "failsafe.useJigsawModules", defaultValue =  
"true" )

+private boolean useJigsawModules;
+



I think we should avoid referring to Jigsaw, that was the name of the  
project.

I'd prefer useJavaModules instead, or maybe even useModulePath.



 @Override
 protected int getRerunFailingTestsCount()
 {
@@ -801,6 +812,18 @@ public class IntegrationTestMojo
 }
@Override
+protected boolean useJigsawModules()
+{
+return useJigsawModules;
+}
+
+@Override
+protected void setUseJigsawModules( boolean useJigsawModules )
+{
+this.useJigsawModules = useJigsawModules;
+}
+
+@Override
 protected final List suiteXmlFiles()
 {
 return hasSuiteXmlFiles() ? Arrays.asList( suiteXmlFiles ) :  
Collections.emptyList();
diff --git  
a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java  
b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java

index 319f21d..4a1a213 100644
---  
a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
+++  
b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java

@@ -104,6 +104,7 @@ import java.util.SortedSet;
 import java.util.TreeSet;
 import java.util.concurrent.ConcurrentHashMap;
+import static java.lang.Boolean.TRUE;
 import static java.lang.Thread.currentThread;
 import static java.util.Arrays.asList;
 import static java.util.Collections.addAll;
@@ -728,6 +729,9 @@ public abstract class AbstractSurefireMojo
 @Parameter( property = "dependenciesToScan" )
 private String[] dependenciesToScan;
+/**
+ *
+ */
 @Component
 private ToolchainManager toolchainManager;
@@ -787,6 +791,10 @@ public abstract class AbstractSurefireMojo
protected abstract String getReportSchemaLocation();
+protected abstract boolean useJigsawModules();
+
+protected abstract void setUseJigsawModules( boolean  
useJigsawModules );

+
 /**
  * This plugin MOJO artifact.
  *
@@ -954,7 +962,7 @@ public abstract class AbstractSurefireMojo
 if ( !getTestClassesDirectory().exists()
 && ( getDependenciesToScan() == null ||  
getDependenciesToScan().length == 0 ) )

 {
-if ( Boolean.TRUE.equals( getFailIfNoTests() ) )
+if ( TRUE.equals( getFailIfNoTests() ) )
 {
 throw new MojoFailureException( "No tests to run!" );
 }
@@ -1123,17 +1131,18 @@ public abstract class AbstractSurefireMojo
 RunOrderParameters runOrderParameters =
 new RunOrderParameters( getRunOrder(), getStatisticsFile(  
getConfigChecksum() ) );
+Platform platform = PLATFORM.withJdkExecAttributesForTests(  
getEffectiveJvm() );

 if ( isNotForking() )
 {
 createCopyAndReplaceForkNumPlaceholder(  
effectiveProperties, 1 ).copyToSystemProperties();

InPluginVMSurefireStarter surefireStarter =
-createInprocessStarter( provider,  
classLoaderConfiguration, runOrderParamet

Re: [compiler plugin] Support JPMS test modules

2018-04-17 Thread Christian Stein

Hi Robert,

I manually moved the changes and created [1]. Hope, that I didn't miss
a file. The included test case still runs successfully.

While moving the files I noticed that the main sources of the test project
has no external dependency. I don't think that's an issue, but I'm not sure
about it.

Cheers,
Christian

[1] https://github.com/apache/maven-compiler-plugin/pull/4

On Mon, Apr 16, 2018 at 9:32 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi Christian,
>
> could you base your commit on https://github.com/apache/mave
> n-compiler-plugin ?
> I know this is a long standing with to do whitebox testing, even though
> some others JPMS experts don't agree ;)
> My comment did indicate i had no idea at that time what to do with it, so
> maybe this is the right fix to support all combinations.
>
> thanks,
> Robert
>
> On Mon, 16 Apr 2018 13:42:44 +0200, Christian Stein <sormu...@gmail.com>
> 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 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/pull/139/files
>>
>

Re: [compiler plugin] Support JPMS test modules

2018-04-16 Thread Robert Scholte


Hi Christian,

could you base your commit on  
https://github.com/apache/maven-compiler-plugin ?
I know this is a long standing with to do whitebox testing, even though  
some others JPMS experts don't agree ;)
My comment did indicate i had no idea at that time what to do with it, so  
maybe this is the right fix to support all combinations.


thanks,
Robert

On Mon, 16 Apr 2018 13:42:44 +0200, Christian Stein <sormu...@gmail.com>  
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 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/pull/139/files


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

[compiler plugin] Support JPMS test modules

2018-04-16 Thread Christian Stein

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 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/pull/139/files

[GitHub] maven-plugins pull request #129: MPDF-81 merging in the needed doxia modules...

2017-09-08 Thread spyhunter99

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 FoAggregatedSink

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/spyhunter99/maven-plugins feature/MPDF-81

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/129.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #129


commit 27c221e8cece7a5b8574a0aeb593efbd02547ccf
Author: Alex O'Ree <alexo...@apache.org>
Date:   2017-09-09T02:14:14Z

MPDF-81 merging in the needed doxia modules required for copyright 
overrides, Add property based overrides for the copyright headers. Most of the 
real changes were in FoAggregatedSink




---

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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-26 Thread Guillaume Boué

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 given 
classloader, then its parents (with a particular rule with regard to 
module layers), and it doesn't look like customizable. It also seems 
that existing META-INF/services declarations, but located in named 
modules, are ignored. For unnamed modules, or when something other than 
ServiceLoader is used, everything is apparently the same as before in 
Java 9.


This is why I think a plugin wouldn't be able to locate providers in a 
module loaded by Maven core extension classloader: parent of the plugin 
realm is bootstrap classloader directly.


Guillaume


Le 26/06/2017 à 01:45, Igor Fedorenko a écrit :

Can you explain little more why plugins won't see classes loaded by
maven core or maven core extensions classloaders? This is implemented in
classwords and I was under impression that java9 still allowed custom
classloading schemes like what we do or like what OSGi does.




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Igor Fedorenko

Can you explain little more why plugins won't see classes loaded by
maven core or maven core extensions classloaders? This is implemented in
classwords and I was under impression that java9 still allowed custom
classloading schemes like what we do or like what OSGi does.

-- 
Regards,
Igor

On Sun, Jun 25, 2017, at 07:08 PM, Guillaume Boué wrote:
> 
> 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 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 to be a way for plugins 
> to know about modules.
> 
> Reading more into the docs, this may be possible using a ModuleLayer. 
> Each plugin would have its own module layer composed of modules found in 
> its dependencies. Their parent would be a module layer associated to 
> Maven core, and its parent would be the boot layer. This would solve the 
> ServiceLoader issue for named modules in a plugin realm, since it would 
> locate providers in all modules in the module layer of the plugin, and 
> then do the same for their parents, up to the boot layer. However, for 
> it to work, I'm not sure if this implies that everything be made modular 
> (plugins and Maven itself). I will try to do some testing on this.
> 
> Guillaume
> 
> >
> >> On Jun 25, 2017, at 12:40 PM, Robert Scholte <rfscho...@apache.org> wrote:
> >>
> >> 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 need to find a mechanism for plugins to select their 
> >> classloaders and modules.
> >>
> >> thanks,
> >> Robert
> >>
> >>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org> 
> >>> wrote:
> >>>
> >>> 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 is that some classes were moved to a named module other than
> >>> java.base, and they are not loaded with the bootstrap classloader
> >>> anymore, but with the platform classloader (which was previously the
> >>> extension classloader, see JDK-814637).
> >>>
> >>> This has consequences, like MANTRUN-200, where locating providers with
> >>> the ServiceLoader API, using the plugin class realm, will miss JDK
> >>> internal implementation classes. In the case of MANTRUN-200, it is
> >>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
> >>> because of the way ServiceLoader works
> >>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
> >>> During the search in named modules, the class realm will not be able to
> >>> use its strategy since that process relies on parent delegation
> >>> implemented as explicit calls to ClassLoader.getParent()
> >>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
> >>> which, for a class realm, corresponds to the base classloader, i.e. the
> >>> bootstrap classloader. And since the Nashorn script engine factory was
> >>> loaded with the platform classloader, it is missed.
> >>>
> >>> It seems that the fix here would be to make all class realms have as
> >>> base classloader the platform classloader starting with JDK 9, instead
> >>> of the bootstrap classloader (there is a new utility method in
> >>> ClassLoader to obtain the platform classloader). I verified that this
> >>> solves the problem described in MANTRUN-200, but before I create an MNG
> >>> issue, I'm wondering if this is the correct approach.
> >>>
> >>> What do you think of thi

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Guillaume Boué



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 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 to be a way for plugins 
to know about modules.


Reading more into the docs, this may be possible using a ModuleLayer. 
Each plugin would have its own module layer composed of modules found in 
its dependencies. Their parent would be a module layer associated to 
Maven core, and its parent would be the boot layer. This would solve the 
ServiceLoader issue for named modules in a plugin realm, since it would 
locate providers in all modules in the module layer of the plugin, and 
then do the same for their parents, up to the boot layer. However, for 
it to work, I'm not sure if this implies that everything be made modular 
(plugins and Maven itself). I will try to do some testing on this.


Guillaume




On Jun 25, 2017, at 12:40 PM, Robert Scholte <rfscho...@apache.org> wrote:

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 need to find a mechanism for plugins to select their classloaders and 
modules.

thanks,
Robert


On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org> wrote:

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 is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
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




-
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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Chas Honton

Under what circumstances would a plugin not want the platform classloader?

Chas

> On Jun 25, 2017, at 12:40 PM, Robert Scholte <rfscho...@apache.org> wrote:
> 
> 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 need to find a mechanism for plugins to select their classloaders 
> and modules.
> 
> thanks,
> Robert
> 
>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org> wrote:
>> 
>> 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 is that some classes were moved to a named module other than
>> java.base, and they are not loaded with the bootstrap classloader
>> anymore, but with the platform classloader (which was previously the
>> extension classloader, see JDK-814637).
>> 
>> This has consequences, like MANTRUN-200, where locating providers with
>> the ServiceLoader API, using the plugin class realm, will miss JDK
>> internal implementation classes. In the case of MANTRUN-200, it is
>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
>> because of the way ServiceLoader works
>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
>> During the search in named modules, the class realm will not be able to
>> use its strategy since that process relies on parent delegation
>> implemented as explicit calls to ClassLoader.getParent()
>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
>> which, for a class realm, corresponds to the base classloader, i.e. the
>> bootstrap classloader. And since the Nashorn script engine factory was
>> loaded with the platform classloader, it is missed.
>> 
>> It seems that the fix here would be to make all class realms have as
>> base classloader the platform classloader starting with JDK 9, instead
>> of the bootstrap classloader (there is a new utility method in
>> ClassLoader to obtain the platform classloader). I verified that this
>> solves the problem described in MANTRUN-200, but before I create an MNG
>> issue, I'm wondering if this is the correct approach.
>> 
>> What do you think of this change to class realms? The other possibility
>> I can think of would be to have a way in the JDK to override the search
>> in named modules, so that our ClassRealm can also delegate to its parent
>> classloader. It is possible for unnamed modules (since the search
>> process then relies on the ClassLoader.getResources method, that can be
>> overriden) but it doesn't look like (and probably intentionally so) to
>> be possible for named modules.
>> 
>> Guillaume
>> 
>> 
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le 
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>> 
>> 
>> -
>> 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
> 
> 


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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Robert Scholte


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 need to find a mechanism for plugins to select their  
classloaders and modules.


thanks,
Robert

On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org>  
wrote:



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 is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le  
logiciel antivirus Avast.

https://www.avast.com/antivirus


-
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

Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Guillaume Boué


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 is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-21 Thread Stephen Connolly

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 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 Schulte a écrit :
> > 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 module info
> >
> > If we would have checked that, there would not be this "redundant class
> > files on class path coming from different coordinates" issue.
> >
> > > it's just a basic convention for normal cases, that will be applied
> more
> > > than 90% of time: and there will be less than 10% of time where
> > > discrepency will happen, due to some special cases in code life
> > > As usual
> >
> > Issue with the module names is the same as with the package or
> > classnames. They can be deployed to different coordinates and then
> > produce conflicts later when consumed. If we can avoid this with module
> > names, we should.
> >
> > Regards,
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Fwd: How to name modules, automatic and otherwise

2017-02-21 Thread Hervé BOUTEMY

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 Schulte a écrit :
> 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 module info
> 
> If we would have checked that, there would not be this "redundant class
> files on class path coming from different coordinates" issue.
> 
> > it's just a basic convention for normal cases, that will be applied more
> > than 90% of time: and there will be less than 10% of time where
> > discrepency will happen, due to some special cases in code life
> > As usual
> 
> Issue with the module names is the same as with the package or
> classnames. They can be deployed to different coordinates and then
> produce conflicts later when consumed. If we can avoid this with module
> names, we should.
> 
> Regards,



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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-20 Thread Christian Schulte

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 module info

If we would have checked that, there would not be this "redundant class
files on class path coming from different coordinates" issue.

> 
> it's just a basic convention for normal cases, that will be applied more than 
> 90% of time: and there will be less than 10% of time where discrepency will 
> happen, due to some special cases in code life
> As usual

Issue with the module names is the same as with the package or
classnames. They can be deployed to different coordinates and then
produce conflicts later when consumed. If we can avoid this with module
names, we should.

Regards,
-- 
Christian


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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-20 Thread Robert Scholte

On Sat, 18 Feb 2017 12:46:32 +0100, Robert Scholte <rfscho...@apache.org>  
wrote:

On Thu, 16 Feb 2017 19:11:33 +0100, Brian Fox <bri...@infinity.nu> wrote:

I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.

It doesn't take away the issue that you can still refer to automodules  
and that their name can/will change in the future.

I think we should introduce 2 new packaging types:
- modlib, which does not allow references to automodules
- modapp, which allows references to automodules, but will never be  
installed or deployed.

After some rethinking we can solve this all with the current jar packaging  
type. If module-info doesn't export any packages it is considered an  
application and we can allow automodules. If there are exports defined, it  
is considered 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  
expected

we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.

Hmm, not sure about the default behavior. I think developers should  
choose their name with care, just as they should choose their groupId  
and artifactId with care.

The Module-Name will make it possible to prepare your project as modular  
jar. This also implies that in the module-info you must specify *every*  
requirement. If only one jar is not yet a named module (either by  
Module-Name or by module-info), you must omit the module-info.java;  
that's a choice, makes our lives a bit easier :)

Just have to be very clear about it towards the community.

Robert

PS: those of you who aren'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  
<manf...@simpligility.com>

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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and  
others
> [2].  I've collected my conclusions here rather than in separate  
messages

> because there are several distinct yet intertwined issues.
>
> Summary:
>
>    - Module names should not include Maven group identifiers, because
>  modules are more abstract than the artifacts that define them.
>
>- Module names should use the reverse-domain-name-prefix  
convention

>  or, preferably, the project-name-prefix convention.
>
>- We should not abandon automatic modules, since they are a key  
tool

>  for migration and adoption.
>
>- We can address the problems of automatic modules with two fairly
>  minor technical enhancements.
>
> If any of these points strikes you as controversial, please read on!
>
>* * *
>
> Module names should not include Maven group identifiers, as Robert
> Scholte and Brian Fox suggest [1], even for modules declared  
explicitly
> in `module-info.java` files.  Modules in JPMS are a construct of the  
Java
> programming language, implemented in both the compiler and the  
virtual

> machine.  As such, they are more abstract entities than the artifacts
> that define them.  This distinction is useful, both conceptually and
> practically, hence module names should remain more abstract.
>
> This distinction is useful conceptually because it makes it easier,  
as
> we read source code, to think clearly about the nature of a module.   
We
> can reason about a module's dependences, exports, services, and so  
forth
> without cluttering our minds with the details of group identifiers  
and

> version constraints.  Today, e.g., we can write, and read:
>
>  module foo.data {
>  exports com.bar.foo.data;
>  requires hibernate.core;
>  requires hibernate.jcache;
>  requires hibernate.validator;
>  }
>
> If we were to extend the syntax of module names to include group
> identifiers, and encourage people to

Re: Fwd: How to name modules, automatic and otherwise

2017-02-18 Thread Hervé BOUTEMY

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 
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 module info

it's just a basic convention for normal cases, that will be applied more than 
90% of time: and there will be less than 10% of time where discrepency will 
happen, due to some special cases in code life
As usual

Regards,

Hervé

Le dimanche 19 février 2017, 00:45:29 CET Christian Schulte a écrit :
> 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 them as well as "namespace"/prefix of the modular name to ensure that
> > within Central modular names are unique.
> > 
> > However, this collides with the idea from Mark who says that it should be
> > possible to move a modulename from one organisation to another. That
> > should only effect the GA, not the module name.
> 
> Like we did with the resolver. Changed the coordinates but did not
> change package names and class names. So the module name should not
> change as well. This means the coordinates are nothing to consider for
> the module names but package names and class names (the content - not
> the coordinates).
> 
> Regards,



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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-18 Thread Christian Schulte

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 them as well as "namespace"/prefix of the modular name to ensure that  
> within Central modular names are unique.
> 
> However, this collides with the idea from Mark who says that it should be  
> possible to move a modulename from one organisation to another. That  
> should only effect the GA, not the module name.

Like we did with the resolver. Changed the coordinates but did not
change package names and class names. So the module name should not
change as well. This means the coordinates are nothing to consider for
the module names but package names and class names (the content - not
the coordinates).

Regards,
-- 
Christian



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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-18 Thread Hervé BOUTEMY

yes, that's it
(eventually without even checking that rule automatically when publishing into 
central: just making an explicit convention to avoid stupid choice of module 
prefix that is different from groupId but another DNS entry one may own)

Regards,

Hervé

Le samedi 18 février 2017, 12:25:40 CET Robert Scholte a écrit :
> 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 them as well as "namespace"/prefix of the modular name to ensure that
> within Central modular names are unique.
> 
> However, this collides with the idea from Mark who says that it should be
> possible to move a modulename from one organisation to another. That
> should only effect 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 <bri...@infinity.nu> wrote:
> > Hervé: I feel like I don't completely understand the proposal, but I feel
> > like we can achieve your intent using the Module-Name simply by
> > defaulting
> > it to g:a and building up a good base of new stuff going into Central
> > such
> > that when people start using jigsaw, there is a good pattern in place and
> > we've hopefully avoided conflicts.
> > 
> > Am I mis-understanding your proposal?
> > 
> > On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > 
> > wrote:
> >> tuesday, I was at a Jigsaw presentation 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 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,
> >> handwritten full module name should *start with groupId*
> >> 
> >> applied to the example for Hibernate, this would just say: Hibernate
> >> project
> >> owns "org.hibernate" module namespace on [Maven] Central since they own
> >> org.hibernate groupId
> >> 
> >> Notice: automodules won't give same module names. Automodules are just
> >> transient automagic values for temporary local work, not for public
> >> shared
> >> work
> >> 
> >> Notice 2: whatever does not go to [Maven] Central has just other
> >> conventions.
> >> Knowing the impact of existing [Maven] Central content, people doing
> >> their
> >> local convention will probably "naturally" think at:
> >> - immediate compatibility, to be able to consume public artifacts
> >> - future compatibility, to be able to later publish a private artifact
> >> that
> >> may be later shared as public artifact
> >> 
> >> 
> >> I started to share this idea (which is not far from initial proposal:
> >> just
> >> not
> >> about automodule names and not using artifactId)  yesterday with Robert:
> >> the
> >> discussion just started, nobody had time yet to write the proposal down
> >> and
> >> share it with a wider audience
> >> 
> >> 
> >> WDYT?
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> >> > And it looks like they are saying .. just add the groupId (or similar
> >> > namespace) to the modulename. A bit like some artifact repeat the
> >> 
> >> groupId
> >> 
> >> > in the artifactId to be specific... seems like a wasted opportunity to
> >> > define a good usage pattern. The idea of actually supporting same
> >> 
> >> module
> >> 
> >> > names for different forks or the same thing is touted as an advantage.
> >> > Anybody that ever had to debug something like this will know its not
> >> 
> >> an
> >> 
> >> > advantage at all .. just simply path to troubleshooting nightmares.
> >> > 
> >> > I e

Re: Fwd: How to name modules, automatic and otherwise

2017-02-18 Thread Robert Scholte


On Thu, 16 Feb 2017 19:11:33 +0100, Brian Fox <bri...@infinity.nu> wrote:


I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.



It doesn't take away the issue that you can still refer to automodules and  
that their name can/will change in the future.


I think we should introduce 2 new packaging types:
- modlib, which does not allow references to automodules
- modapp, which allows references to automodules, but will never be  
installed or deployed.


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  
expected

we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.


Hmm, not sure about the default behavior. I think developers should choose  
their name with care, just as they should choose their groupId and  
artifactId with care.


The Module-Name will make it possible to prepare your project as modular  
jar. This also implies that in the module-info you must specify *every*  
requirement. If only one jar is not yet a named module (either by  
Module-Name or by module-info), you must omit the module-info.java; that's  
a choice, makes our lives a bit easier :)

Just have to be very clear about it towards the community.

Robert



PS: those of you who aren'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  
<manf...@simpligility.com>

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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and others
> [2].  I've collected my conclusions here rather than in separate  
messages

> because there are several distinct yet intertwined issues.
>
> Summary:
>
>- Module names should not include Maven group identifiers, because
>  modules are more abstract than the artifacts that define them.
>
>- Module names should use the reverse-domain-name-prefix convention
>  or, preferably, the project-name-prefix convention.
>
>- We should not abandon automatic modules, since they are a key  
tool

>  for migration and adoption.
>
>- We can address the problems of automatic modules with two fairly
>  minor technical enhancements.
>
> If any of these points strikes you as controversial, please read on!
>
>* * *
>
> Module names should not include Maven group identifiers, as Robert
> Scholte and Brian Fox suggest [1], even for modules declared  
explicitly
> in `module-info.java` files.  Modules in JPMS are a construct of the  
Java

> programming language, implemented in both the compiler and the virtual
> machine.  As such, they are more abstract entities than the artifacts
> that define them.  This distinction is useful, both conceptually and
> practically, hence module names should remain more abstract.
>
> This distinction is useful conceptually because it makes it easier, as
> we read source code, to think clearly about the nature of a module.   
We
> can reason about a module's dependences, exports, services, and so  
forth

> without cluttering our minds with the details of group identifiers and
> version constraints.  Today, e.g., we can write, and read:
>
>  module foo.data {
>  exports com.bar.foo.data;
>  requires hibernate.core;
>  requires hibernate.jcache;
>  requires hibernate.validator;
>  }
>
> If we were to extend the syntax of module names to include group
> identifiers, and encourage people to use them, then we'd be faced with
> something much more verbose:
>
>  module com.bar:foo.data {
>  exports com.bar.foo.data;
>  requires org.hibernate:hibernate.core;
>  requires org.hibernate:hibernate.jcache;
>  requires org.hibernate:hibernate.validator;
>  }
>
> Group identifiers make perfect sense in the context of a build system
> such as Maven,

Re: Fwd: How to name modules, automatic and otherwise

2017-02-18 Thread 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 them as well as "namespace"/prefix of the modular name to ensure that  
within Central modular names are unique.


However, this collides with the idea from Mark who says that it should be  
possible to move a modulename from one organisation to another. That  
should only effect 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 <bri...@infinity.nu> wrote:


Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by  
defaulting
it to g:a and building up a good base of new stuff going into Central  
such

that when people start using jigsaw, there is a good pattern in place and
we've hopefully avoided conflicts.

Am I mis-understanding your proposal?

On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:


tuesday, I was at a Jigsaw presentation 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 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,
handwritten full module name should *start with groupId*


applied to the example for Hibernate, this would just say: Hibernate
project
owns "org.hibernate" module namespace on [Maven] Central since they own
org.hibernate groupId

Notice: automodules won't give same module names. Automodules are just
transient automagic values for temporary local work, not for public  
shared

work

Notice 2: whatever does not go to [Maven] Central has just other
conventions.
Knowing the impact of existing [Maven] Central content, people doing  
their

local convention will probably "naturally" think at:
- immediate compatibility, to be able to consume public artifacts
- future compatibility, to be able to later publish a private artifact  
that

may be later shared as public artifact


I started to share this idea (which is not far from initial proposal:  
just

not
about automodule names and not using artifactId)  yesterday with Robert:
the
discussion just started, nobody had time yet to write the proposal down  
and

share it with a wider audience


WDYT?

Regards,

Hervé

Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> And it looks like they are saying .. just add the groupId (or similar
> namespace) to the modulename. A bit like some artifact repeat the  
groupId

> in the artifactId to be specific... seems like a wasted opportunity to
> define a good usage pattern. The idea of actually supporting same  
module

> names for different forks or the same thing is touted as an advantage.
> Anybody that ever had to debug something like this will know its not  
an

> advantage at all .. just simply path to troubleshooting nightmares.
>
> I expected as much but I am still disappointed and see lots of trouble
with
> this in the 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-16 10:42:
> > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko  
<i...@ifedorenko.com>

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 modularized. The bigger
issue
> > is all the existing stuff that would be used as automodules...first
they
> > are already out there and second, there's nothing to see and block.
> >
> >> I realize this does not set good defaults for non-maven projects,  
so
> >> there will be some friction there, but hopefully maven userbase is  
big
> >> enough to create sufficient pressure for non-maven projects to  
provide

> >> explicit module names.
> >
> > That's exactly my point in originally suggesting to leverage the  
g:a by

> > default, but we can do exactly the same thing by injecting the
Module-Name
> > asap to build up the right pra

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Hervé BOUTEMY

there is some level of misunderstanding

my proposal is not to force any default value: just check (for people 
publishing to Central) that chosen value starts with groupId


then, in some Maven plugin, we can independently propose magic help to propose 
auto-calculated default values to people using Maven, that will be injected in 
Module-Name: since this Maven plugin will respect the previous Central 
convention (value starts with groupId), this will be ok.

I'm not sure that proposing automagic values for target module names (ie not 
automodule names derived from file name) is safe: when a developper wants to 
really take Java 9 module names in consideration (either by migrating to a 
real module, either by defining a Module-Name property in his manifest), he 
really has to know that he's committed to this name. If the white magic 
algorithm to propose a name does not find a name that has human sense (for 
whatever reason), that will be problematic.

Notice that the fact that you seem to propose an algorigthm where the 
generated name has a colon in it surprised me: are colons accepted in a Jigsaw 
module name?


Notice 2:
I like the proposal of Module-Name MANIFEST.MF property to let a developper 
influence the name of his automodule, without migrating to Jigsaw yet: very 
nice idea

Regards,

Hervé

Le vendredi 17 février 2017, 09:01:46 CET Brian Fox a écrit :
> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
> 
> Am I mis-understanding your proposal?
> 
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > tuesday, I was at a Jigsaw presentation 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 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,
> > handwritten full module name should *start with groupId*
> > 
> > applied to the example for Hibernate, this would just say: Hibernate
> > project
> > owns "org.hibernate" module namespace on [Maven] Central since they own
> > org.hibernate groupId
> > 
> > Notice: automodules won't give same module names. Automodules are just
> > transient automagic values for temporary local work, not for public shared
> > work
> > 
> > Notice 2: whatever does not go to [Maven] Central has just other
> > conventions.
> > Knowing the impact of existing [Maven] Central content, people doing their
> > local convention will probably "naturally" think at:
> > - immediate compatibility, to be able to consume public artifacts
> > - future compatibility, to be able to later publish a private artifact
> > that
> > may be later shared as public artifact
> > 
> > 
> > I started to share this idea (which is not far from initial proposal: just
> > not
> > about automodule names and not using artifactId)  yesterday with Robert:
> > the
> > discussion just started, nobody had time yet to write the proposal down
> > and
> > share it with a wider audience
> > 
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > > And it looks like they are saying .. just add the groupId (or similar
> > > namespace) to the modulename. A bit like some artifact repeat the
> > > groupId
> > > in the artifactId to be specific... seems like a wasted opportunity to
> > > define a good usage pattern. The idea of actually supporting same module
> > > names for different forks or the same thing is touted as an advantage.
> > > Anybody that ever had to debug something like this will know its not an
> > > advantage at all .. just simply path to troubleshooting nightmares.
> > > 
> > > I expected as much but I am still disappointed and see lots of trouble
> > 
> > with
> > 
> > > this in the future. Maybe it would be good if all Apache project and
> > 
> > others
> > 
> > > that are going to publish modules start with using th

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Bernd

>
> The idea is to not default to group:artifact but to check if the artifact
> starts with a suffix of the group-ID and then skip this. So g=org.hibernate
> a=hibernate-core would become org.hibernate.core and not
> org.hibernate.hibernate.core. This is a neat trick I wished in the past in
> some repository listings as well. However there is room for conflicts:
> org.hibernate:hibernate-util and org.hibernate:util would fold to the same
> module :-( (However it is most likely better to default to the shorter
> version and ask people to specify a longer version in case of conflicts)?


2017-02-17 15:01 GMT+01:00 Brian Fox <bri...@infinity.nu>:

> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
>
> Am I mis-understanding your proposal?
>
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> wrote:
>
> > tuesday, I was at a Jigsaw presentation 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 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,
> > handwritten full module name should *start with groupId*
> >
> >
> > applied to the example for Hibernate, this would just say: Hibernate
> > project
> > owns "org.hibernate" module namespace on [Maven] Central since they own
> > org.hibernate groupId
> >
> > Notice: automodules won't give same module names. Automodules are just
> > transient automagic values for temporary local work, not for public
> shared
> > work
> >
> > Notice 2: whatever does not go to [Maven] Central has just other
> > conventions.
> > Knowing the impact of existing [Maven] Central content, people doing
> their
> > local convention will probably "naturally" think at:
> > - immediate compatibility, to be able to consume public artifacts
> > - future compatibility, to be able to later publish a private artifact
> that
> > may be later shared as public artifact
> >
> >
> > I started to share this idea (which is not far from initial proposal:
> just
> > not
> > about automodule names and not using artifactId)  yesterday with Robert:
> > the
> > discussion just started, nobody had time yet to write the proposal down
> and
> > share it with a wider audience
> >
> >
> > WDYT?
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > > And it looks like they are saying .. just add the groupId (or similar
> > > namespace) to the modulename. A bit like some artifact repeat the
> groupId
> > > in the artifactId to be specific... seems like a wasted opportunity to
> > > define a good usage pattern. The idea of actually supporting same
> module
> > > names for different forks or the same thing is touted as an advantage.
> > > Anybody that ever had to debug something like this will know its not an
> > > advantage at all .. just simply path to troubleshooting nightmares.
> > >
> > > I expected as much but I am still disappointed and see lots of trouble
> > with
> > > this in the 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-16 10:42:
> > > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com
> >
> > 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 modularized. The bigge

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Manfred Moser

Thats how I understand it as well and I like it. 

Brian Fox wrote on 2017-02-17 06:01:

> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
> 
> Am I mis-understanding your proposal?
> 
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> wrote:
> 
>> tuesday, I was at a Jigsaw presentation 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 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,
>> handwritten full module name should *start with groupId*
>>
>>
>> applied to the example for Hibernate, this would just say: Hibernate
>> project
>> owns "org.hibernate" module namespace on [Maven] Central since they own
>> org.hibernate groupId
>>
>> Notice: automodules won't give same module names. Automodules are just
>> transient automagic values for temporary local work, not for public shared
>> work
>>
>> Notice 2: whatever does not go to [Maven] Central has just other
>> conventions.
>> Knowing the impact of existing [Maven] Central content, people doing their
>> local convention will probably "naturally" think at:
>> - immediate compatibility, to be able to consume public artifacts
>> - future compatibility, to be able to later publish a private artifact that
>> may be later shared as public artifact
>>
>>
>> I started to share this idea (which is not far from initial proposal: just
>> not
>> about automodule names and not using artifactId)  yesterday with Robert:
>> the
>> discussion just started, nobody had time yet to write the proposal down and
>> share it with a wider audience
>>
>>
>> WDYT?
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
>> > And it looks like they are saying .. just add the groupId (or similar
>> > namespace) to the modulename. A bit like some artifact repeat the groupId
>> > in the artifactId to be specific... seems like a wasted opportunity to
>> > define a good usage pattern. The idea of actually supporting same module
>> > names for different forks or the same thing is touted as an advantage.
>> > Anybody that ever had to debug something like this will know its not an
>> > advantage at all .. just simply path to troubleshooting nightmares.
>> >
>> > I expected as much but I am still disappointed and see lots of trouble
>> with
>> > this in the 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-16 10:42:
>> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com>
>> 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 modularized. The bigger
>> issue
>> > > is all the existing stuff that would be used as automodules...first
>> they
>> > > are already out there and second, there's nothing to see and block.
>> > >
>> > >> I realize this does not set good defaults for non-maven projects, so
>> > >> there will be some friction there, but hopefully maven userbase is big
>> > >> enough to create sufficient pressure for non-maven projects to provide
>> > >> explicit module names.
>> > >
>> > > That's exactly my point in originally suggesting to leverage the g:a by
>> > > default, but we can do exactly the same t

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Brian Fox

Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by defaulting
it to g:a and building up a good base of new stuff going into Central such
that when people start using jigsaw, there is a good pattern in place and
we've hopefully avoided conflicts.

Am I mis-understanding your proposal?

On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:

> tuesday, I was at a Jigsaw presentation 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 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,
> handwritten full module name should *start with groupId*
>
>
> applied to the example for Hibernate, this would just say: Hibernate
> project
> owns "org.hibernate" module namespace on [Maven] Central since they own
> org.hibernate groupId
>
> Notice: automodules won't give same module names. Automodules are just
> transient automagic values for temporary local work, not for public shared
> work
>
> Notice 2: whatever does not go to [Maven] Central has just other
> conventions.
> Knowing the impact of existing [Maven] Central content, people doing their
> local convention will probably "naturally" think at:
> - immediate compatibility, to be able to consume public artifacts
> - future compatibility, to be able to later publish a private artifact that
> may be later shared as public artifact
>
>
> I started to share this idea (which is not far from initial proposal: just
> not
> about automodule names and not using artifactId)  yesterday with Robert:
> the
> discussion just started, nobody had time yet to write the proposal down and
> share it with a wider audience
>
>
> WDYT?
>
> Regards,
>
> Hervé
>
> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > And it looks like they are saying .. just add the groupId (or similar
> > namespace) to the modulename. A bit like some artifact repeat the groupId
> > in the artifactId to be specific... seems like a wasted opportunity to
> > define a good usage pattern. The idea of actually supporting same module
> > names for different forks or the same thing is touted as an advantage.
> > Anybody that ever had to debug something like this will know its not an
> > advantage at all .. just simply path to troubleshooting nightmares.
> >
> > I expected as much but I am still disappointed and see lots of trouble
> with
> > this in the 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-16 10:42:
> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com>
> 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 modularized. The bigger
> issue
> > > is all the existing stuff that would be used as automodules...first
> they
> > > are already out there and second, there's nothing to see and block.
> > >
> > >> I realize this does not set good defaults for non-maven projects, so
> > >> there will be some friction there, but hopefully maven userbase is big
> > >> enough to create sufficient pressure for non-maven projects to provide
> > >> explicit module names.
> > >
> > > That's exactly my point in originally suggesting to leverage the g:a by
> > > default, but we can do exactly the same thing by injecting the
> Module-Name
> > > asap to build up the right practices before jigsaw takes off.
> > >
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > >> > I generally agree the concerns were mostly ignored. Specifically the
> > >> > dangers in not carefully approaching and setting best practices in
> the
> &g

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Hervé BOUTEMY

tuesday, I was at a Jigsaw presentation 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 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,
handwritten full module name should *start with groupId*


applied to the example for Hibernate, this would just say: Hibernate project 
owns "org.hibernate" module namespace on [Maven] Central since they own 
org.hibernate groupId

Notice: automodules won't give same module names. Automodules are just 
transient automagic values for temporary local work, not for public shared 
work

Notice 2: whatever does not go to [Maven] Central has just other conventions. 
Knowing the impact of existing [Maven] Central content, people doing their 
local convention will probably "naturally" think at:
- immediate compatibility, to be able to consume public artifacts
- future compatibility, to be able to later publish a private artifact that 
may be later shared as public artifact


I started to share this idea (which is not far from initial proposal: just not 
about automodule names and not using artifactId)  yesterday with Robert: the 
discussion just started, nobody had time yet to write the proposal down and 
share it with a wider audience


WDYT?

Regards,

Hervé

Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> And it looks like they are saying .. just add the groupId (or similar
> namespace) to the modulename. A bit like some artifact repeat the groupId
> in the artifactId to be specific... seems like a wasted opportunity to
> define a good usage pattern. The idea of actually supporting same module
> names for different forks or the same thing is touted as an advantage.
> Anybody that ever had to debug something like this will know its not an
> advantage at all .. just simply path to troubleshooting nightmares.
> 
> I expected as much but I am still disappointed and see lots of trouble with
> this in the 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-16 10:42:
> > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com> 
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 modularized. The bigger issue
> > is all the existing stuff that would be used as automodules...first they
> > are already out there and second, there's nothing to see and block.
> > 
> >> I realize this does not set good defaults for non-maven projects, so
> >> there will be some friction there, but hopefully maven userbase is big
> >> enough to create sufficient pressure for non-maven projects to provide
> >> explicit module names.
> > 
> > That's exactly my point in originally suggesting to leverage the g:a by
> > default, but we can do exactly the same thing by injecting the Module-Name
> > asap to build up the right practices before jigsaw takes off.
> > 
> >> --
> >> Regards,
> >> Igor
> >> 
> >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> >> > I generally agree the concerns were mostly ignored. Specifically the
> >> > dangers in not carefully approaching and setting best practices in the
> >> > names, thereby willfully ignoring what happened with NPM.
> >> > 
> >> > The inclusion of the Module-Name metadata is frankly, more than I
> >> > expected
> >> > we would get. I think this does give us something to work with, first
> >> > by
> >> > making that defaulted by the Maven plugins and later by enforcing in
> >> > the
> >> > repo as appropriate. Using this correctly could help solve some of my
> >> > initial concerns that we weren't appropriately leveraging the
> >> > default-effect.
> >> > 
> >> > PS: those of you who aren'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 a

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Manfred Moser

And it looks like they are saying .. just add the groupId (or similar 
namespace) to the modulename. A bit like some artifact repeat the groupId in 
the artifactId to be specific... seems like a wasted opportunity to define a 
good usage pattern. The idea of actually supporting same module names for 
different forks or the same thing is touted as an advantage. Anybody that ever 
had to debug something like this will know its not an advantage at all .. just 
simply path to troubleshooting nightmares.

I expected as much but I am still disappointed and see lots of trouble with 
this in the 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-16 10:42:

> On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com> 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 modularized. The bigger issue
> is all the existing stuff that would be used as automodules...first they
> are already out there and second, there's nothing to see and block.
> 
> 
>>
>> I realize this does not set good defaults for non-maven projects, so
>> there will be some friction there, but hopefully maven userbase is big
>> enough to create sufficient pressure for non-maven projects to provide
>> explicit module names.
>>
> 
> That's exactly my point in originally suggesting to leverage the g:a by
> default, but we can do exactly the same thing by injecting the Module-Name
> asap to build up the right practices before jigsaw takes off.
> 
> 
> 
>>
>> --
>> Regards,
>> Igor
>>
>> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
>> > I generally agree the concerns were mostly ignored. Specifically the
>> > dangers in not carefully approaching and setting best practices in the
>> > names, thereby willfully ignoring what happened with NPM.
>> >
>> > The inclusion of the Module-Name metadata is frankly, more than I
>> > expected
>> > we would get. I think this does give us something to work with, first by
>> > making that defaulted by the Maven plugins and later by enforcing in the
>> > repo as appropriate. Using this correctly could help solve some of my
>> > initial concerns that we weren't appropriately leveraging the
>> > default-effect.
>> >
>> > PS: those of you who aren'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
>> > <manf...@simpligility.com>
>> > 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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and
>> others
>> > > > [2].  I've collected my conclusions here rather than in separate
>> messages
>> > > > because there are several distinct yet intertwined issues.
>> > > >
>> > > > Summary:
>> > > >
>> > > >- Module names should not include Maven group identifiers, because
>> > > >  modules are more abstract than the artifacts that define them.
>> > > >
>> > > >- Module names should use the reverse-domain-name-prefix
>> convention
>> > > >  or, preferably, the project-name-prefix convention.
>> > > >
>> > > >- We should not abandon automatic modules, since they are a key
>> tool
>> > > >  for migration and adoption.
>> > >

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Brian Fox

On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko <i...@ifedorenko.com> 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 modularized. The bigger issue
is all the existing stuff that would be used as automodules...first they
are already out there and second, there's nothing to see and block.


>
> I realize this does not set good defaults for non-maven projects, so
> there will be some friction there, but hopefully maven userbase is big
> enough to create sufficient pressure for non-maven projects to provide
> explicit module names.
>

That's exactly my point in originally suggesting to leverage the g:a by
default, but we can do exactly the same thing by injecting the Module-Name
asap to build up the right practices before jigsaw takes off.



>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > I generally agree the concerns were mostly ignored. Specifically the
> > dangers in not carefully approaching and setting best practices in the
> > names, thereby willfully ignoring what happened with NPM.
> >
> > The inclusion of the Module-Name metadata is frankly, more than I
> > expected
> > we would get. I think this does give us something to work with, first by
> > making that defaulted by the Maven plugins and later by enforcing in the
> > repo as appropriate. Using this correctly could help solve some of my
> > initial concerns that we weren't appropriately leveraging the
> > default-effect.
> >
> > PS: those of you who aren'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
> > <manf...@simpligility.com>
> > 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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and
> others
> > > > [2].  I've collected my conclusions here rather than in separate
> messages
> > > > because there are several distinct yet intertwined issues.
> > > >
> > > > Summary:
> > > >
> > > >- Module names should not include Maven group identifiers, because
> > > >  modules are more abstract than the artifacts that define them.
> > > >
> > > >- Module names should use the reverse-domain-name-prefix
> convention
> > > >  or, preferably, the project-name-prefix convention.
> > > >
> > > >- We should not abandon automatic modules, since they are a key
> tool
> > > >  for migration and adoption.
> > > >
> > > >- We can address the problems of automatic modules with two fairly
> > > >  minor technical enhancements.
> > > >
> > > > If any of these points strikes you as controversial, please read on!
> > > >
> > > >* * *
> > > >
> > > > Module names should not include Maven group identifiers, as Robert
> > > > Scholte and Brian Fox suggest [1], even for modules declared
> explicitly
> > > > in `module-info.java` files.  Modules in JPMS are a construct of the
> Java
> > > > programming language, implemented in both the compiler and the
> virtual
> > > > machine.  As such, they are more abstract entities than the artifacts
> > > > that define them.  This distinction is useful, both conceptually and
> > > > practically, hence module names should remain more abstract.
> > > >
> > > > This distinction is useful conceptually because it makes it easier,
> as
> > > > we read source code, to think clearly about the nature of a module.
> We
> > > > can reason about a module's dependences, exports, ser

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Igor Fedorenko

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 userbase is big
enough to create sufficient pressure for non-maven projects to provide
explicit module names.

-- 
Regards,
Igor

On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> I generally agree the concerns were mostly ignored. Specifically the
> dangers in not carefully approaching and setting best practices in the
> names, thereby willfully ignoring what happened with NPM.
> 
> The inclusion of the Module-Name metadata is frankly, more than I
> expected
> we would get. I think this does give us something to work with, first by
> making that defaulted by the Maven plugins and later by enforcing in the
> repo as appropriate. Using this correctly could help solve some of my
> initial concerns that we weren't appropriately leveraging the
> default-effect.
> 
> PS: those of you who aren'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
> <manf...@simpligility.com>
> 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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and others
> > > [2].  I've collected my conclusions here rather than in separate messages
> > > because there are several distinct yet intertwined issues.
> > >
> > > Summary:
> > >
> > >- Module names should not include Maven group identifiers, because
> > >  modules are more abstract than the artifacts that define them.
> > >
> > >- Module names should use the reverse-domain-name-prefix convention
> > >  or, preferably, the project-name-prefix convention.
> > >
> > >- We should not abandon automatic modules, since they are a key tool
> > >  for migration and adoption.
> > >
> > >- We can address the problems of automatic modules with two fairly
> > >      minor technical enhancements.
> > >
> > > If any of these points strikes you as controversial, please read on!
> > >
> > >* * *
> > >
> > > Module names should not include Maven group identifiers, as Robert
> > > Scholte and Brian Fox suggest [1], even for modules declared explicitly
> > > in `module-info.java` files.  Modules in JPMS are a construct of the Java
> > > programming language, implemented in both the compiler and the virtual
> > > machine.  As such, they are more abstract entities than the artifacts
> > > that define them.  This distinction is useful, both conceptually and
> > > practically, hence module names should remain more abstract.
> > >
> > > This distinction is useful conceptually because it makes it easier, as
> > > we read source code, to think clearly about the nature of a module.  We
> > > can reason about a module's dependences, exports, services, and so forth
> > > without cluttering our minds with the details of group identifiers and
> > > version constraints.  Today, e.g., we can write, and read:
> > >
> > >  module foo.data {
> > >  exports com.bar.foo.data;
> > >  requires hibernate.core;
> > >  requires hibernate.jcache;
> > >  requires hibernate.validator;
> > >  }
> > >
> > > If we were to extend the syntax of module names to include group
> > > identifiers, and encourage people to use them, then we'd be faced with
> > > something much more verbose:
> > >
> > >  module com.bar:foo.data {
> > >  exports com.bar.foo.data;
> > >  requires org.hibernate:hibernate.core;
> > >  requires org.hibernate:hibernate.jcache;
> > >  requires org.hibernate:hibernate.validator;
> >

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Brian Fox

I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.

The inclusion of the Module-Name metadata is frankly, more than I expected
we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.

PS: those of you who aren'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 <manf...@simpligility.com>
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 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 Scholte and Brian Fox [1], and by Stephen Colebourne and others
> > [2].  I've collected my conclusions here rather than in separate messages
> > because there are several distinct yet intertwined issues.
> >
> > Summary:
> >
> >- Module names should not include Maven group identifiers, because
> >  modules are more abstract than the artifacts that define them.
> >
> >- Module names should use the reverse-domain-name-prefix convention
> >  or, preferably, the project-name-prefix convention.
> >
> >- We should not abandon automatic modules, since they are a key tool
> >  for migration and adoption.
> >
> >- We can address the problems of automatic modules with two fairly
> >  minor technical enhancements.
> >
> > If any of these points strikes you as controversial, please read on!
> >
> >    * * *
> >
> > Module names should not include Maven group identifiers, as Robert
> > Scholte and Brian Fox suggest [1], even for modules declared explicitly
> > in `module-info.java` files.  Modules in JPMS are a construct of the Java
> > programming language, implemented in both the compiler and the virtual
> > machine.  As such, they are more abstract entities than the artifacts
> > that define them.  This distinction is useful, both conceptually and
> > practically, hence module names should remain more abstract.
> >
> > This distinction is useful conceptually because it makes it easier, as
> > we read source code, to think clearly about the nature of a module.  We
> > can reason about a module's dependences, exports, services, and so forth
> > without cluttering our minds with the details of group identifiers and
> > version constraints.  Today, e.g., we can write, and read:
> >
> >  module foo.data {
> >  exports com.bar.foo.data;
> >  requires hibernate.core;
> >  requires hibernate.jcache;
> >  requires hibernate.validator;
> >  }
> >
> > If we were to extend the syntax of module names to include group
> > identifiers, and encourage people to use them, then we'd be faced with
> > something much more verbose:
> >
> >  module com.bar:foo.data {
> >  exports com.bar.foo.data;
> >  requires org.hibernate:hibernate.core;
> >  requires org.hibernate:hibernate.jcache;
> >  requires org.hibernate:hibernate.validator;
> >  }
> >
> > Group identifiers make perfect sense in the context of a build system
> > such as Maven, where they bring necessary structure to the names of the
> > millions of artifacts available across different repositories.  Such
> > structure is superfluous and distracting in the context of a module
> > system, where the number of relevant modules in any particular situation
> > is more likely to be in the tens, or hundreds, or (rarely) thousands.
> > All else being equal, simpler names are better.
> >
> > At a practical level, the distinction between modules and artifacts is
> > useful because it leaves the entire problem of artifact selection to the
> > build system.  This allows us to switch from one artifact to another
> > simply by editing a `pom.xml` file to adjust a version constraint or a
> > group identifi

Re: Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Manfred Moser

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:
> 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 Scholte and Brian Fox [1], and by Stephen Colebourne and others
> [2].  I've collected my conclusions here rather than in separate messages
> because there are several distinct yet intertwined issues.
> 
> Summary:
> 
>- Module names should not include Maven group identifiers, because
>  modules are more abstract than the artifacts that define them.
> 
>- Module names should use the reverse-domain-name-prefix convention
>  or, preferably, the project-name-prefix convention.
> 
>- We should not abandon automatic modules, since they are a key tool
>  for migration and adoption.
> 
>- We can address the problems of automatic modules with two fairly
>  minor technical enhancements.
> 
> If any of these points strikes you as controversial, please read on!
> 
>* * *
> 
> Module names should not include Maven group identifiers, as Robert
> Scholte and Brian Fox suggest [1], even for modules declared explicitly
> in `module-info.java` files.  Modules in JPMS are a construct of the Java
> programming language, implemented in both the compiler and the virtual
> machine.  As such, they are more abstract entities than the artifacts
> that define them.  This distinction is useful, both conceptually and
> practically, hence module names should remain more abstract.
> 
> This distinction is useful conceptually because it makes it easier, as
> we read source code, to think clearly about the nature of a module.  We
> can reason about a module's dependences, exports, services, and so forth
> without cluttering our minds with the details of group identifiers and
> version constraints.  Today, e.g., we can write, and read:
> 
>  module foo.data {
>  exports com.bar.foo.data;
>  requires hibernate.core;
>  requires hibernate.jcache;
>  requires hibernate.validator;
>  }
> 
> If we were to extend the syntax of module names to include group
> identifiers, and encourage people to use them, then we'd be faced with
> something much more verbose:
> 
>  module com.bar:foo.data {
>  exports com.bar.foo.data;
>  requires org.hibernate:hibernate.core;
>  requires org.hibernate:hibernate.jcache;
>  requires org.hibernate:hibernate.validator;
>  }
> 
> Group identifiers make perfect sense in the context of a build system
> such as Maven, where they bring necessary structure to the names of the
> millions of artifacts available across different repositories.  Such
> structure is superfluous and distracting in the context of a module
> system, where the number of relevant modules in any particular situation
> is more likely to be in the tens, or hundreds, or (rarely) thousands.
> All else being equal, simpler names are better.
> 
> At a practical level, the distinction between modules and artifacts is
> useful because it leaves the entire problem of artifact selection to the
> build system.  This allows us to switch from one artifact to another
> simply by editing a `pom.xml` file to adjust a version constraint or a
> group identifier; if module names included group identifiers then we'd
> also have to edit the `module-info.java` file.  This flexibility can be
> helpful if, e.g., a project is forked and a new module with the same name
> and artifact identifier is published under a different group identifier.
> We long ago decided not to do version selection in the module system,
> which surprised some people but has worked out fairly well.  We should
> treat group selection in the same manner.
> 
> Another practical benefit of the module/artifact distinction is that it
> keeps the module system independent of any particular build system, so
> that build systems can continue to improve and evolve independently over
> time.  Maven-style coordinates are the most popular way to name artifacts
> in repositories today, but that might not be true ten years from now.  It
> would be unwise to adopt Maven's naming convention for module names just
> because it's popular now, and doubly so to bake Maven's group-identifier
> concept into the Java programming language.
> 
>* * *
> 
> If module names don't include group identifiers, then how sho

Fwd: How to name modules, automatic and otherwise

2017-02-16 Thread Robert Scholte

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 Scholte and Brian Fox [1], and by Stephen Colebourne and others
[2].  I've collected my conclusions here rather than in separate messages
because there are several distinct yet intertwined issues.

Summary:

   - Module names should not include Maven group identifiers, because
 modules are more abstract than the artifacts that define them.

   - Module names should use the reverse-domain-name-prefix convention
 or, preferably, the project-name-prefix convention.

   - We should not abandon automatic modules, since they are a key tool
 for migration and adoption.

   - We can address the problems of automatic modules with two fairly
 minor technical enhancements.

If any of these points strikes you as controversial, please read on!

   * * *

Module names should not include Maven group identifiers, as Robert
Scholte and Brian Fox suggest [1], even for modules declared explicitly
in `module-info.java` files.  Modules in JPMS are a construct of the Java
programming language, implemented in both the compiler and the virtual
machine.  As such, they are more abstract entities than the artifacts
that define them.  This distinction is useful, both conceptually and
practically, hence module names should remain more abstract.

This distinction is useful conceptually because it makes it easier, as
we read source code, to think clearly about the nature of a module.  We
can reason about a module's dependences, exports, services, and so forth
without cluttering our minds with the details of group identifiers and
version constraints.  Today, e.g., we can write, and read:

 module foo.data {
 exports com.bar.foo.data;
 requires hibernate.core;
 requires hibernate.jcache;
 requires hibernate.validator;
 }

If we were to extend the syntax of module names to include group
identifiers, and encourage people to use them, then we'd be faced with
something much more verbose:

 module com.bar:foo.data {
 exports com.bar.foo.data;
 requires org.hibernate:hibernate.core;
 requires org.hibernate:hibernate.jcache;
 requires org.hibernate:hibernate.validator;
 }

Group identifiers make perfect sense in the context of a build system
such as Maven, where they bring necessary structure to the names of the
millions of artifacts available across different repositories.  Such
structure is superfluous and distracting in the context of a module
system, where the number of relevant modules in any particular situation
is more likely to be in the tens, or hundreds, or (rarely) thousands.
All else being equal, simpler names are better.

At a practical level, the distinction between modules and artifacts is
useful because it leaves the entire problem of artifact selection to the
build system.  This allows us to switch from one artifact to another
simply by editing a `pom.xml` file to adjust a version constraint or a
group identifier; if module names included group identifiers then we'd
also have to edit the `module-info.java` file.  This flexibility can be
helpful if, e.g., a project is forked and a new module with the same name
and artifact identifier is published under a different group identifier.
We long ago decided not to do version selection in the module system,
which surprised some people but has worked out fairly well.  We should
treat group selection in the same manner.

Another practical benefit of the module/artifact distinction is that it
keeps the module system independent of any particular build system, so
that build systems can continue to improve and evolve independently over
time.  Maven-style coordinates are the most popular way to name artifacts
in repositories today, but that might not be true ten years from now.  It
would be unwise to adopt Maven's naming convention for module names just
because it's popular now, and doubly so to bake Maven's group-identifier
concept into the Java programming language.

   * * *

If module names don't include group identifiers, then how should modules
be named?  What advice should we give to someone who's creating a new
module from scratch, or modularizing an existing component by writing a
`module-info.java` file for it?  (Continue to set aside, for the moment,
the problems of automatic modules.)

In structuring any particular space of names we must balance (at least)
three fundamental tensions: We want names that are long enough to be
descriptive, short enough to be memorable, and unique enough to avoid
needless conflicts.

If you control all of the modules upon which your module depends, and
all of the modules that depend upon it, then you can

Re: Jenkins: Modules changed, recalculating dependency graph

2016-12-14 Thread Robert Scholte


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 Dec 2016 05:19:25 +0100, Christian Schulte   
wrote:



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 do anything about it.



If I ever meet Mr. Jenkins in person, he'll wish he never would have met
me for the rest of his live 8-) .

Regards,


-
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

Re: Jenkins: Modules changed, recalculating dependency graph

2016-12-13 Thread Robert Scholte

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
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 do anything about it.



If I ever meet Mr. Jenkins in person, he'll wish he never would have met
me for the rest of his live 8-) .

Regards,


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

Jenkins: Modules changed, recalculating dependency graph

2016-12-12 Thread Christian Schulte

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 do anything about it.



If I ever meet Mr. Jenkins in person, he'll wish he never would have met
me for the rest of his live 8-) .

Regards,
-- 
Christian

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

[GitHub] maven-plugins pull request #93: [MPIR-349] Bad modules links in 'index/modul...

2016-10-02 Thread axel3rd

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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-plugins pull request #93: [MPIR-349] Bad modules links in 'index/modul...

2016-09-29 Thread axel3rd

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/browse/MPIR-349)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/axel3rd/maven-plugins MPIR-349

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/93.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #93


commit 99553a6d2053cd8448f807f218f81117baa3d3b5
Author: Alix Lourme <alix.lou...@gmail.com>
Date:   2016-09-29T21:40:05Z

[MPIR-349] Bad modules links in 'index/modules' reports when
'distributionManagement.site.url' comes from settings.xml




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: svn commit: r1726407 - in /maven/doxia/doxia/trunk: ./ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/ doxia

2016-01-27 Thread Hervé BOUTEMY

in short: if you prefer the parse method with ParseRequest, I'm ok

in more details:
IMHO, the Parser interface tell what we want it to tell: yes, currently it was 
done as there is no state, and while adding this emitComment property, I 
changed it to be stateful.
I'm not convinced that making the interface stateful is an issue: it's a 
choice (and I confess I didn't check that Plexus did create an instance on 
each independent use)
but if you prefer to change the API to make Parser interface back to 
stateless, and put the state in ParserRequest, I'm ok with that. The only 
drawback I see is that this state has to be passed on each API call. Notice 
that while thinking more at it, there is already a lot of state in Parser 
implementations: you can't use one Parser instance in multiple threads for 
treating multiple contents in parallel
then IMHO this question of "making Parser statefull" seems now more as "making 
clear that Parser implementations are stateful"

Regards,

Hervé

Le mercredi 27 janvier 2016 20:49:25 Robert Scholte a écrit :
> If it is a per-file setting, then I think this approach is wrong (even if
> it is a singleton or not).
> 
> The Parser interface only tells us what kind of parser it is ( text, xml
> or unknown ) and it has the parse-method (ignoring the LogEnabled
> interface :) ).
> 
> So only if you can say that for instance every AptParser must always
> emitComments, then it is fine here, but then there's no need for a setter.
> 
> I would say that it must be an argument of the parse-method. In fact, I
> already added the sourceName too.
> Looks like we need a ParseRequest to be able to support advanced parsing.
> 
> thanks,
> Robert
> 
> [1]
> http://maven.apache.org/doxia/doxia/doxia-core/apidocs/org/apache/maven/doxi
> a/parser/Parser.html
> 
> 
> Op Wed, 27 Jan 2016 04:05:01 +0100 schreef Hervé BOUTEMY
> 
> <herve.bout...@free.fr>:
> > Doxia being a generic lib, able to be used in any context and not just
> > maven-
> > site-plugin, we need to make our own choice on how flexible we want to be
> > 
> > regarding how this API is used in Doxia Sitetools for a site rendering,
> > the
> > value is set with static value (false) on each source file parsing
> > 
> > when used by doxia-converter, it is not expected to have non-default
> > value, ie
> > it is expected to render comments
> > 
> > and I don't know current case where we have a mixed run maven-site-
> > plugin+doxia-converter, but in theory, it is possible
> > 
> > 
> > then Parser implementation IMHO should not be a singleton, or we're at
> > risk
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 26 janvier 2016 21:26:18 Robert Scholte a écrit :
> >> Hi Hervé,
> >> 
> >> based on only the interface it is possible that the Parser
> >> implementation
> >> is a singleton.
> >> Is the emitComments meant to be a per-Parser setting or a per-file
> >> setting?
> >> 
> >> thanks,
> >> Robert
> >> 
> >> Op Sat, 23 Jan 2016 16:48:08 +0100 schreef <hbout...@apache.org>:
> >> > Author: hboutemy
> >> > Date: Sat Jan 23 15:48:07 2016
> >> > New Revision: 1726407
> >> > 
> >> > URL: http://svn.apache.org/viewvc?rev=1726407=rev
> >> > Log:
> >> > [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
> >> 
> >> > a/parser/AbstractParser.java
> >> 
> >> maven/doxia/doxia/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/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/doxia-modules/doxia-module-docbook-simple/src
> >> 
> >> /main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
> >> 
> >> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/src/main/java/
> >> 
> >> > org/apache/maven/doxia/module/fml/FmlParser

Re: svn commit: r1726407 - in /maven/doxia/doxia/trunk: ./ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/ doxia

2016-01-27 Thread Robert Scholte

If it is a per-file setting, then I think this approach is wrong (even if  
it is a singleton or not).


The Parser interface only tells us what kind of parser it is ( text, xml  
or unknown ) and it has the parse-method (ignoring the LogEnabled  
interface :) ).


So only if you can say that for instance every AptParser must always  
emitComments, then it is fine here, but then there's no need for a setter.


I would say that it must be an argument of the parse-method. In fact, I  
already added the sourceName too.

Looks like we need a ParseRequest to be able to support advanced parsing.

thanks,
Robert

[1]  
http://maven.apache.org/doxia/doxia/doxia-core/apidocs/org/apache/maven/doxia/parser/Parser.html



Op Wed, 27 Jan 2016 04:05:01 +0100 schreef Hervé BOUTEMY  
<herve.bout...@free.fr>:


Doxia being a generic lib, able to be used in any context and not just  
maven-

site-plugin, we need to make our own choice on how flexible we want to be

regarding how this API is used in Doxia Sitetools for a site rendering,  
the

value is set with static value (false) on each source file parsing

when used by doxia-converter, it is not expected to have non-default  
value, ie

it is expected to render comments

and I don't know current case where we have a mixed run maven-site-
plugin+doxia-converter, but in theory, it is possible


then Parser implementation IMHO should not be a singleton, or we're at  
risk


Regards,

Hervé

Le mardi 26 janvier 2016 21:26:18 Robert Scholte a écrit :

Hi Hervé,

based on only the interface it is possible that the Parser  
implementation

is a singleton.
Is the emitComments meant to be a per-Parser setting or a per-file  
setting?


thanks,
Robert

Op Sat, 23 Jan 2016 16:48:08 +0100 schreef <hbout...@apache.org>:
> Author: hboutemy
> Date: Sat Jan 23 15:48:07 2016
> New Revision: 1726407
>
> URL: http://svn.apache.org/viewvc?rev=1726407=rev
> Log:
> [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

> a/parser/AbstractParser.java
>  
maven/doxia/doxia/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/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/doxia-modules/doxia-module-docbook-simple/src
>  
/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
>  
maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/src/main/java/

> org/apache/maven/doxia/module/fml/FmlParser.java
> maven/doxia/doxia/trunk/pom.xml
>
> Modified:
>  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa

> rser/AbstractParser.java URL:
>  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/j
>  
ava/org/apache/maven/doxia/parser/AbstractParser.java?rev=1726407=17264

> 06=1726407=diff
>  
=

> = ---
>  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa

> rser/AbstractParser.java (original)
> +++
>  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa

> rser/AbstractParser.java Sat Jan 23 15:48:07 2016
> @@ -56,6 +56,11 @@ public abstract class AbstractParser
>
>  /** Log instance. */
>  private Log logger;
>
> +/**
> + * Emit Doxia comment events when parsing comments?
> + */
> +private boolean emitComments = true;
> +
>
>  private static final String DOXIA_VERSION;
>
> static
>
> @@ -99,6 +104,16 @@ public abstract class AbstractParser
>
>  return UNKNOWN_TYPE;
>
>  }
>
> +public void setEmitComments( boolean emitComments )
> +{
> +this.emitComments = emitComments;
> +}
> +
> +public boolean isEmitComments()
> +{
> +return emitComments;
> +}
> +
>
>  /**
>
>   * Execute a macro on the given sink.
>   *
>
> Modified:
>  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa

> rser/AbstractXmlParser.java URL:
>  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/j
>  
ava/org/apache/maven/doxia/parser/AbstractXmlParser.java?rev=1726407=17

> 26406=1726407=diff
>  
=

> = ---
>  
maven/doxia/doxia/tr

Re: svn commit: r1726407 - in /maven/doxia/doxia/trunk: ./ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/ doxia

2016-01-26 Thread Robert Scholte


Hi Hervé,

based on only the interface it is possible that the Parser implementation  
is a singleton.

Is the emitComments meant to be a per-Parser setting or a per-file setting?

thanks,
Robert

Op Sat, 23 Jan 2016 16:48:08 +0100 schreef <hbout...@apache.org>:


Author: hboutemy
Date: Sat Jan 23 15:48:07 2016
New Revision: 1726407

URL: http://svn.apache.org/viewvc?rev=1726407=rev
Log:
[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/doxia/parser/AbstractParser.java

maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java

maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java

maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/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/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java

maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/src/main/java/org/apache/maven/doxia/module/fml/FmlParser.java
maven/doxia/doxia/trunk/pom.xml

Modified:  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java
URL:  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java?rev=1726407=1726406=1726407=diff

==
---  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java  
(original)
+++  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java  
Sat Jan 23 15:48:07 2016

@@ -56,6 +56,11 @@ public abstract class AbstractParser
 /** Log instance. */
 private Log logger;
+/**
+ * Emit Doxia comment events when parsing comments?
+ */
+private boolean emitComments = true;
+
 private static final String DOXIA_VERSION;
static
@@ -99,6 +104,16 @@ public abstract class AbstractParser
 return UNKNOWN_TYPE;
 }
+public void setEmitComments( boolean emitComments )
+{
+this.emitComments = emitComments;
+}
+
+public boolean isEmitComments()
+{
+return emitComments;
+}
+
 /**
  * Execute a macro on the given sink.
  *

Modified:  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
URL:  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java?rev=1726407=1726406=1726407=diff

==
---  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java  
(original)
+++  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java  
Sat Jan 23 15:48:07 2016

@@ -371,7 +371,10 @@ public abstract class AbstractXmlParser
 protected void handleComment( XmlPullParser parser, Sink sink )
 throws XmlPullParserException
 {
-sink.comment( getText( parser ) );
+if ( isEmitComments() )
+{
+sink.comment( getText( parser ) );
+}
 }
/**

Modified:  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java
URL:  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java?rev=1726407=1726406=1726407=diff

==
---  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java  
(original)
+++  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java  
Sat Jan 23 15:48:07 2016

@@ -66,4 +66,18 @@ public interface Parser
  * @return the type of Parser
  */
 int getType();
+
+/**
+ * When comments are found in source markup, emit comment Doxia  
events or just ignore?

+ *
+ * @param emitComments true (default value) to emit  
comment Doxia events

+ */
+void setEmitComments( boolean emitComments );
+
+/**
+ * Does the parser emit Doxia comments event when comments found in  
source?

+ *
+ * @return true (default value) if comment Doxia  
events are emitted

+ */
+boolean isEmitComments();
 }

Modified:  
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/XhtmlBaseParser.java
URL:  
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/XhtmlBaseParser.java?rev=1726407=1726406=172640

Re: svn commit: r1726407 - in /maven/doxia/doxia/trunk: ./ doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/ doxia

2016-01-26 Thread Hervé BOUTEMY

Doxia being a generic lib, able to be used in any context and not just maven-
site-plugin, we need to make our own choice on how flexible we want to be

regarding how this API is used in Doxia Sitetools for a site rendering, the 
value is set with static value (false) on each source file parsing

when used by doxia-converter, it is not expected to have non-default value, ie 
it is expected to render comments

and I don't know current case where we have a mixed run maven-site-
plugin+doxia-converter, but in theory, it is possible


then Parser implementation IMHO should not be a singleton, or we're at risk

Regards,

Hervé

Le mardi 26 janvier 2016 21:26:18 Robert Scholte a écrit :
> Hi Hervé,
> 
> based on only the interface it is possible that the Parser implementation
> is a singleton.
> Is the emitComments meant to be a per-Parser setting or a per-file setting?
> 
> thanks,
> Robert
> 
> Op Sat, 23 Jan 2016 16:48:08 +0100 schreef <hbout...@apache.org>:
> > Author: hboutemy
> > Date: Sat Jan 23 15:48:07 2016
> > New Revision: 1726407
> > 
> > URL: http://svn.apache.org/viewvc?rev=1726407=rev
> > Log:
> > [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
> > a/parser/AbstractParser.java
> > maven/doxia/doxia/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/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/doxia-modules/doxia-module-docbook-simple/src
> > /main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
> > maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/src/main/java/
> > org/apache/maven/doxia/module/fml/FmlParser.java
> > maven/doxia/doxia/trunk/pom.xml
> > 
> > Modified:
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractParser.java URL:
> > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/j
> > ava/org/apache/maven/doxia/parser/AbstractParser.java?rev=1726407=17264
> > 06=1726407=diff
> > =
> > = ---
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractParser.java (original)
> > +++
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractParser.java Sat Jan 23 15:48:07 2016
> > @@ -56,6 +56,11 @@ public abstract class AbstractParser
> > 
> >  /** Log instance. */
> >  private Log logger;
> > 
> > +/**
> > + * Emit Doxia comment events when parsing comments?
> > + */
> > +private boolean emitComments = true;
> > +
> > 
> >  private static final String DOXIA_VERSION;
> > 
> > static
> > 
> > @@ -99,6 +104,16 @@ public abstract class AbstractParser
> > 
> >  return UNKNOWN_TYPE;
> >  
> >  }
> > 
> > +public void setEmitComments( boolean emitComments )
> > +{
> > +this.emitComments = emitComments;
> > +}
> > +
> > +public boolean isEmitComments()
> > +{
> > +return emitComments;
> > +}
> > +
> > 
> >  /**
> >  
> >   * Execute a macro on the given sink.
> >   *
> > 
> > Modified:
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractXmlParser.java URL:
> > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/j
> > ava/org/apache/maven/doxia/parser/AbstractXmlParser.java?rev=1726407=17
> > 26406=1726407=diff
> > =
> > = ---
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractXmlParser.java (original)
> > +++
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/pa
> > rser/AbstractXmlParser.java Sat Jan 23 15:48:07 2016
> > @@ -371,7 +371,10 @@ public abstract class AbstractXmlParser
> > 
> >  protected void

Re: Java 9 - Java Modules aka Jigsaw

2015-11-19 Thread Rory O'Donnell


Hi Robert,

JEP 261 helps explains -modulepath, otherwise jigsaw-dev should be able 
to help.


Rgds,Rory

On 18/11/2015 22:03, Robert Scholte wrote:

Hi,

I've started patching the plexus-compiler so we can start compiling 
projects with module-info


See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea

However, I can't find detailed info about the -modulepath argument.

Usage: javac  
where possible options include:
...
 -classpath   Specify where to find user class files and 
annotation processors

...
 -modulepath  Specify where to find user module class files

However, I can't simply add a range of jar files like I can with 
classpath, or could this be a Windows issue?


error: illegal argument for -modulepath: 
F:\java-workspace\apache-maven-maven\maven\maven-builder-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 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 sessions

Keynote by Mark Reinhold
https://www.youtube.com/watch?v=l1s7R85GF1A

Introduction to Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=qr4O4SbzihQ

Prepare for JDK 9! by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=KZfbRuvv5qc

Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=V6ycn1-QQV0

Advanced Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=SU1WFX8yeKM

Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=UKC0uC7QUkI

Ask the JDK Architects
https://www.youtube.com/watch?v=7vvx505mu3s

Form now all Devoxx sessions are freely available on Youtube at D+1

https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg

As Jason is in the expert group I imagine that he already started to 
think
about how to adapt maven to be able to easily consume/produce 
classical jar

files and J9+ Java Modules.

Cheers,


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


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

Re: Java 9 - Java Modules aka Jigsaw

2015-11-19 Thread Robert Scholte


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 of a more efficient way to handle modules.


thanks,
Robert

Op Thu, 19 Nov 2015 11:09:12 +0100 schreef Rory O'Donnell  
<rory.odonn...@oracle.com>:



Hi Robert,

JEP 261 helps explains -modulepath, otherwise jigsaw-dev should be able  
to help.


Rgds,Rory

On 18/11/2015 22:03, Robert Scholte wrote:

Hi,

I've started patching the plexus-compiler so we can start compiling  
projects with module-info


See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea

However, I can't find detailed info about the -modulepath argument.

Usage: javac  
where possible options include:
...
 -classpath   Specify where to find user class files and  
annotation processors

...
 -modulepath  Specify where to find user module class  
files


However, I can't simply add a range of jar files like I can with  
classpath, or could this be a Windows issue?


error: illegal argument for -modulepath:  
F:\java-workspace\apache-maven-maven\maven\maven-builder-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 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 sessions

Keynote by Mark Reinhold
https://www.youtube.com/watch?v=l1s7R85GF1A

Introduction to Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=qr4O4SbzihQ

Prepare for JDK 9! by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=KZfbRuvv5qc

Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=V6ycn1-QQV0

Advanced Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=SU1WFX8yeKM

Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=UKC0uC7QUkI

Ask the JDK Architects
https://www.youtube.com/watch?v=7vvx505mu3s

Form now all Devoxx sessions are freely available on Youtube at D+1

https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg

As Jason is in the expert group I imagine that he already started to  
think
about how to adapt maven to be able to easily consume/produce  
classical jar

files and J9+ Java Modules.

Cheers,


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

Re: Java 9 - Java Modules aka Jigsaw


Hi Tibor,

"Whatever critical or non-critical, the JDK dependency appears."

Just wondering how you collected these information. I don't recognize all  
packages as being marked as JDK Internal. The list is described as JEP  
260: Encapsulate Most Internal APIs[1]


thanks,
Robert

[1] http://openjdk.java.net/jeps/260

Op Mon, 16 Nov 2015 17:48:42 +0100 schreef Tibor Digana  
<tibordig...@apache.org>:



Our plugins are dependent on internal Sun JDK packages.
This is the list of plugins:Java classes and JDK classes.
Whatever critical or non-critical, the JDK dependency appears.

maven-jdeps-plugin:Base64Codec sun.misc.BASE64Decoder
maven-changes-plugin:ProjectJavamailMailSender
com.sun.net.ssl.internal.ssl.Provider, ?mail.smtp.socketFactory?
maven-changes-plugin:FeedGenerator com.sun.syndication.*
maven-javadoc-plugin:AbstractJavadocMojo   Javadoc:
com.sun.tools.javadoc.*, com.sun.tools.doclets.*,
com.sun.tools.doclets.ToDoTaglet
maven-javadoc-plugin:JavadocUtil   Javadoc:
com.sun.tools.doclets.Taglet,
maven-ant-plugin:AntBuildWriterUtilorg.w3c.*
maven-site-plugin:WebXmlTest   org.w3c.*
maven-pdm-plugin:CpdReportTest org.w3c.*


On 11/16/15, Tibor Digana <tibordig...@apache.org> 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éritier [via Maven] <
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

maven) I recommend you to watch the recording of the following sessions

Keynote by Mark Reinhold
https://www.youtube.com/watch?v=l1s7R85GF1A

Introduction to Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=qr4O4SbzihQ

Prepare for JDK 9! by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=KZfbRuvv5qc

Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=V6ycn1-QQV0

Advanced Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=SU1WFX8yeKM

Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=UKC0uC7QUkI

Ask the JDK Architects
https://www.youtube.com/watch?v=7vvx505mu3s

Form now all Devoxx sessions are freely available on Youtube at D+1

https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg

As Jason is in the expert group I imagine that he already started to
think
about how to adapt maven to be able to easily consume/produce classical
jar
files and J9+ Java Modules.

Cheers,

--
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier


--
If you reply to this email, your message will be added to the  
discussion

below:

http://maven.40175.n5.nabble.com/Java-9-Java-Modules-aka-Jigsaw-tp5851980.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
.
NAML
<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>







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

Re: Java 9 - Java Modules aka Jigsaw


Hi,

I've started patching the plexus-compiler so we can start compiling  
projects with module-info


See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea

However, I can't find detailed info about the -modulepath argument.

Usage: javac  
where possible options include:
...
 -classpath   Specify where to find user class files and  
annotation processors

...
 -modulepath  Specify where to find user module class files

However, I can't simply add a range of jar files like I can with  
classpath, or could this be a Windows issue?


error: illegal argument for -modulepath:  
F:\java-workspace\apache-maven-maven\maven\maven-builder-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 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 sessions

Keynote by Mark Reinhold
https://www.youtube.com/watch?v=l1s7R85GF1A

Introduction to Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=qr4O4SbzihQ

Prepare for JDK 9! by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=KZfbRuvv5qc

Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=V6ycn1-QQV0

Advanced Modular Development by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=SU1WFX8yeKM

Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
https://www.youtube.com/watch?v=UKC0uC7QUkI

Ask the JDK Architects
https://www.youtube.com/watch?v=7vvx505mu3s

Form now all Devoxx sessions are freely available on Youtube at D+1

https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg

As Jason is in the expert group I imagine that he already started to  
think
about how to adapt maven to be able to easily consume/produce classical  
jar

files and J9+ Java Modules.

Cheers,


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

Re: Java 9 - Java Modules aka Jigsaw

2015-11-18 Thread Paul Benedict

I believe the -modulepath option is for specifying a directory, not a jar.
Do something like this:
javac -modulepath mods YourClass.java


Cheers,
Paul

On Wed, Nov 18, 2015 at 4:03 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi,
>
> I've started patching the plexus-compiler so we can start compiling
> projects with module-info
>
> See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
>
> However, I can't find detailed info about the -modulepath argument.
>
> Usage: javac  
> where possible options include:
> ...
>  -classpath   Specify where to find user class files and
> annotation processors
> ...
>  -modulepath  Specify where to find user module class files
>
> However, I can't simply add a range of jar files like I can with
> classpath, or could this be a Windows issue?
>
> error: illegal argument for -modulepath:
> F:\java-workspace\apache-maven-maven\maven\maven-builder-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 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 sessions
>>
>> Keynote by Mark Reinhold
>> https://www.youtube.com/watch?v=l1s7R85GF1A
>>
>> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>
>> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>
>> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>
>> Advanced Modular Development by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>
>> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>
>> Ask the JDK Architects
>> https://www.youtube.com/watch?v=7vvx505mu3s
>>
>> Form now all Devoxx sessions are freely available on Youtube at D+1
>>
>> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>
>> As Jason is in the expert group I imagine that he already started to think
>> about how to adapt maven to be able to easily consume/produce classical
>> jar
>> files and J9+ Java Modules.
>>
>> Cheers,
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Java 9 - Java Modules aka Jigsaw

2015-11-18 Thread Tibor Digana

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 to replace with standard API.

On Wed, Nov 18, 2015 at 9:12 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi Tibor,
>
> "Whatever critical or non-critical, the JDK dependency appears."
>
> Just wondering how you collected these information. I don't recognize all
> packages as being marked as JDK Internal. The list is described as JEP 260:
> Encapsulate Most Internal APIs[1]
>
> thanks,
> Robert
>
> [1] http://openjdk.java.net/jeps/260
>
> Op Mon, 16 Nov 2015 17:48:42 +0100 schreef Tibor Digana <
> tibordig...@apache.org>:
>
>
> Our plugins are dependent on internal Sun JDK packages.
>> This is the list of plugins:Java classes and JDK classes.
>> Whatever critical or non-critical, the JDK dependency appears.
>>
>> maven-jdeps-plugin:Base64Codec sun.misc.BASE64Decoder
>> maven-changes-plugin:ProjectJavamailMailSender
>> com.sun.net.ssl.internal.ssl.Provider, ?mail.smtp.socketFactory?
>> maven-changes-plugin:FeedGenerator com.sun.syndication.*
>> maven-javadoc-plugin:AbstractJavadocMojo   Javadoc:
>> com.sun.tools.javadoc.*, com.sun.tools.doclets.*,
>> com.sun.tools.doclets.ToDoTaglet
>> maven-javadoc-plugin:JavadocUtil   Javadoc:
>> com.sun.tools.doclets.Taglet,
>> maven-ant-plugin:AntBuildWriterUtilorg.w3c.*
>> maven-site-plugin:WebXmlTest   org.w3c.*
>> maven-pdm-plugin:CpdReportTest org.w3c.*
>>
>>
>> On 11/16/15, Tibor Digana <tibordig...@apache.org> 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éritier [via Maven] <
>>> 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
>>>> maven) I recommend you to watch the recording of the following sessions
>>>>
>>>> Keynote by Mark Reinhold
>>>> https://www.youtube.com/watch?v=l1s7R85GF1A
>>>>
>>>> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>>>> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>>>
>>>> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>>>> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>>>
>>>> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>>>> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>>>
>>>> Advanced Modular Development by Mark Reinhold/Alan Bateman
>>>> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>>>
>>>> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>>>> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>>>
>>>> Ask the JDK Architects
>>>> https://www.youtube.com/watch?v=7vvx505mu3s
>>>>
>>>> Form now all Devoxx sessions are freely available on Youtube at D+1
>>>>
>>>> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>>>
>>>> As Jason is in the expert group I imagine that he already started to
>>>> think
>>>> about how to adapt maven to be able to easily consume/produce classical
>>>> jar
>>>> files and J9+ Java Modules.
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> -
>>>> Arnaud Héritier
>>>> http://aheritier.net
>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>> Twitter/Skype : aheritier
>>>>
>>>>
>>>> --
>>>> If you reply to this email, your message will be added to the discussion
>>>> below:
>>>>
>>>>
>>>> http://maven.40175.n5.nabble.com/Java-9-Java-Modules-aka-Jigsaw-tp5851980.html
>>>> To start a new topic under Maven Developers, email
>>>> ml-node+s40175n142166...@n5.nabble.com
>>>> To unsubscribe from Maven Developers, click here
>>>> <
>>>> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
>>>> >
>>>> .
>>>> NAML
>>>> <
>>>> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>>>> >
>>>>
>>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: Java 9 - Java Modules aka Jigsaw

Hi Paul, I know about the directory based example,but I really hope there are 
more options. Directory would mean copying jars per module. IO is slow and 
we're back to those days where you have dozens of copies of jars all over your 
system.

Thanks, Robert


Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Paul Benedict 
<pbened...@apache.org> Datum:18-11-2015  23:34  (GMT+01:00) 
Aan: Maven Developers List <dev@maven.apache.org> Cc: 
"Rory O'Donnell Oracle, Dublin Ireland" <rory.odonn...@oracle.com>, Dalibor 
Topic <dalibor.to...@oracle.com> Onderwerp: Re: Java 9 - Java 
Modules aka Jigsaw 
Robert, also see the "Greetings World" example here. The page has good
examples of how to use the command line options:
http://openjdk.java.net/projects/jigsaw/quick-start

And again from this presentation:
http://openjdk.java.net/projects/jigsaw/j1/intro-modular-dev-j1-2015.pdf



Cheers,
Paul

On Wed, Nov 18, 2015 at 4:23 PM, Paul Benedict <pbened...@apache.org> wrote:

> I believe the -modulepath option is for specifying a directory, not a jar.
> Do something like this:
> javac -modulepath mods YourClass.java
>
>
> Cheers,
> Paul
>
> On Wed, Nov 18, 2015 at 4:03 PM, Robert Scholte <rfscho...@apache.org>
> wrote:
>
>> Hi,
>>
>> I've started patching the plexus-compiler so we can start compiling
>> projects with module-info
>>
>> See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
>>
>> However, I can't find detailed info about the -modulepath argument.
>>
>> Usage: javac  
>> where possible options include:
>> ...
>>  -classpath   Specify where to find user class files and
>> annotation processors
>> ...
>>  -modulepath  Specify where to find user module class files
>>
>> However, I can't simply add a range of jar files like I can with
>> classpath, or could this be a Windows issue?
>>
>> error: illegal argument for -modulepath:
>> F:\java-workspace\apache-maven-maven\maven\maven-builder-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 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 sessions
>>>
>>> Keynote by Mark Reinhold
>>> https://www.youtube.com/watch?v=l1s7R85GF1A
>>>
>>> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>>
>>> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>>
>>> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>>
>>> Advanced Modular Development by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>>
>>> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>>
>>> Ask the JDK Architects
>>> https://www.youtube.com/watch?v=7vvx505mu3s
>>>
>>> Form now all Devoxx sessions are freely available on Youtube at D+1
>>>
>>> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>>
>>> As Jason is in the expert group I imagine that he already started to
>>> think
>>> about how to adapt maven to be able to easily consume/produce classical
>>> jar
>>> files and J9+ Java Modules.
>>>
>>> Cheers,
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: Java 9 - Java Modules aka Jigsaw