Re: [all] Java 9 module names

On 22 April 2017 at 05:18, Matt Sicker wrote: > Despite all the shit the Java champions talk about OSGi, Jigsaw is still a > simplified version of OSGi basically, so anything already supported via > OSGi will generally port extremely easily to Java 9 modules. JPMS (Jigsaw) is not a simplified OSG

Re: [all] Java 9 module names

See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction Basically, you need "requires static" for optional dependencies. The exception if for a module where the dependency is an annotation where you don't ne

Re: [all] Java 9 module names

Despite all the shit the Java champions talk about OSGi, Jigsaw is still a simplified version of OSGi basically, so anything already supported via OSGi will generally port extremely easily to Java 9 modules. As for the optional modules, it sounds like static module imports are the way to declare o

Re: [all] Java 9 module names

On to the next question - which I apologize for asking as it may not apply to Commons. Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires

Re: [all] Java 9 module names

Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2. Ralph > On Apr 21, 2017, at 3:01 PM, Stephen Colebourne wrote: > > Some rules: > - Each module contains a set of packages, each of which must be > specified expli

[GitHub] commons-compress issue #20: COMPRESS-382

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/20 [](https://coveralls.io/builds/11191052) Coverage increased (+0.2%) to 84.437% when pulling **7d73baf10e435fcaa4

[GitHub] commons-compress issue #20: COMPRESS-382

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/20 [](https://coveralls.io/builds/11191052) Coverage increased (+0.2%) to 84.437% when pulling **7d73baf10e435fcaa4

Re: [all] Java 9 module names

I've started a page here: https://github.com/jodastephen/jpms-module-names/blob/master/README.md Feel free to raise a PR with more projects at commons or elsewhere in Apache - I'm just checking the Javadoc and releases to ensure there are no problems. Stephen On 21 April 2017 at 13:49, Stephen

Re: [all] Java 9 module names

Some rules: - Each module contains a set of packages, each of which must be specified explicitly. - Modules depend on other modules, but must not form a cycle of dependencies. - No package can be in two modules Looking at the Javadoc here - https://logging.apache.org/log4j/2.x/javadoc.html - it se

Re: [all] Java 9 module names

No packages are not hierarchical. There is for example a java.sql and java.sql.rowset module. (The first contains java.sql and javax.sql the later javax.sql.rowset and javax.sql.rowset.{serial,spi}. Or module java.desktop contains Java.awt and Java.datatransfer contains java.awt.datatransfer.

Re: [all] Java 9 module names

I think I finally found it at http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html . Ralph > On Apr 21, 2017, at 1:58 PM, Ralph Goers wrote: > > Ok - it seems I missed that every package has to be individually specified. > Where is

Re: [all] Java 9 module names

Ok - it seems I missed that every package has to be individually specified. Where is the link to the spec for the module-info file. All I seem to be able to find with google are examples and descriptions. Ralph > On Apr 21, 2017, at 1:40 PM, Ralph Goers wrote: > > How do I export org.apache.l

Re: [all] Java 9 module names

How do I export org.apache.logging.log4j from the log4j-api module and then be able to export org.apache.logging.log4j.core from the log4j-core module? My understanding is that exporting a package exports that package and those beneath it. Is that incorrect? Ralph > On Apr 21, 2017, at 1:37 P

Re: [all] Java 9 module names

Around what? there is no problem to have multiple packages in multiple modules depending on each other (if you decide to ship modules at all). Only split packages is a problem (but this is also a problem for OSGi or code signing so nobody should really use that anyway) Gruss Bernd -- http://ber

Re: [all] Java 9 module names

I am having a hard time figuring out how Log4j is going to be able to support this. The API itself is in org.apache.logging.log4j and some packages under that. All the main implementation is under org.apache.logging.log4j.core. These obviously overlap. Most of our other jars have packages th

Re: [ALL] explicit Maven groupId in component POMs

Am 21.04.2017 um 15:21 schrieb Emmanuel Bourg: I don't mind, but IntelliJ will highlight the groupId and suggest to remove it :) Eclipse also warns that the groupId duplicates the parent groupId. I prefer not to duplicate the parent groupId. Cheers, Pascal

Re: [ALL] explicit Maven groupId in component POMs

Le 21/04/2017 à 18:39, sebb a écrit : > But the problem is that it would be very easy to change the parent gid > and assume that everything is still OK. But why would we change the parent groupId? It hasn't changed since its first release 10 years ago and I don't see the need for a new name. Emm

Re: [ALL] explicit Maven groupId in component POMs

On 21 April 2017 at 16:54, Benedikt Ritter wrote: > >> Am 21.04.2017 um 15:12 schrieb sebb : >> >> Commons components use two different styles of groupId: >> >> commons- - used by some original components (e.g. IO, NET) >> org.apache.commons - newer style, used by most components >> >> Since Commo

Re: [ALL] explicit Maven groupId in component POMs

> Am 21.04.2017 um 15:12 schrieb sebb : > > Commons components use two different styles of groupId: > > commons- - used by some original components (e.g. IO, NET) > org.apache.commons - newer style, used by most components > > Since Commons Parent uses the latter, and the groupId is inherited,

Re: [ALL] explicit Maven groupId in component POMs

Le 21/04/2017 à 15:12, sebb a écrit : > Agreed? I don't mind, but IntelliJ will highlight the groupId and suggest to remove it :) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional comma

Re: [all] Java 9 module names

On 21 April 2017 at 13:59, sebb wrote: > What happens when there is a API break which necessitates a package name > change? > I assume that the module name will also need to change to the new > super-package. > e.g. > > Commons-Lang4 > -> super-package org.apache.commons.lang4 > -> module org.ap

Re: [all] Java 9 module names

On 21 April 2017 at 13:49, Stephen Colebourne wrote: > Right now, I don't recommend adding a module-info.java file. Java 9 is > not released, the tools are still under development, and the binary > format may yet change. All we are agreeing is that the module name > will be `org.apache.commons.lan

[Commons Wiki] Update of "CommonsGroupids" by sebbapache

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "CommonsGroupids" page has been changed by sebbapache: https://wiki.apache.org/commons/CommonsGroupids?action=diff&rev1=2&rev2=3 Comment: Typo Many Commons components have mi

[ALL] explicit Maven groupId in component POMs

Commons components use two different styles of groupId: commons- - used by some original components (e.g. IO, NET) org.apache.commons - newer style, used by most components Since Commons Parent uses the latter, and the groupId is inherited, in theory a component using the new groupId does not nee

Re: [all] Java 9 module names

On 21 April 2017 at 13:00, Stephen Colebourne wrote: > Hi All, > Java 9 is coming soon (unless it is delayed again, but that seems > unlikely). The major feature is JPMS, the Java Platform Module System. > While JPMS is far from ideal, projects like Apache Commons and mine > Joda-* are going to be

Re: [all] Java 9 module names

Right now, I don't recommend adding a module-info.java file. Java 9 is not released, the tools are still under development, and the binary format may yet change. All we are agreeing is that the module name will be `org.apache.commons.lang3`, which doesn't change the release :-) What we need is a p

Re: [all] Java 9 module names

Le 21/04/2017 à 14:00, Stephen Colebourne a écrit : > Comments? Questions? Hi Stephen, Thank you for stopping by and enlightening us about JPMS. The new module system looks like a huge mess. I understand the need for modularization at the JRE level, but I haven't figured out yet how this extra c

Re: [all] Java 9 module names

I support this. Also good to know is that recently we managed to make the Jigsaw team reintroduce the NumberAtEnd[1] in the module name, which makes it again possible that commons-lang, commons-lang2 and commons-lang3 can live next to each other on the modulepath. Robert [1] http://mai

[all] Java 9 module names

Hi All, Java 9 is coming soon (unless it is delayed again, but that seems unlikely). The major feature is JPMS, the Java Platform Module System. While JPMS is far from ideal, projects like Apache Commons and mine Joda-* are going to be key to getting some adoption. This is particularly true as Comm

Jenkins build is back to stable : commons-lang #175

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

Jenkins build is back to stable : commons-lang » Apache Commons Lang #175

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

Jenkins build became unstable: commons-lang » Apache Commons Lang #174

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

Jenkins build became unstable: commons-lang #174

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