date:20170817

Re: Using "annotationProcessorPaths" together with version ranges

2017-08-17 Thread Mark Derricutt

On 17 Aug 2017, at 19:33, Cristian Spiescu wrote:

> When using maven-compiler-plugin with "annotationProcessorPaths", and I 
> specify a dependency with a version range: it doesn't seem to work. I have 
> done some debugging, and I see that the general dependency solving mechanism 
> (that does

I really wish we could have a new 'annotation' scope and NOT use 
'annotationProcessorPaths', it makes things really ik to work with when using 
parents/tiles and common compiler plugin settings.

Interestingly, the DTD doesn't actually specify a strict set of scopes, and 
neither does the documentation it seems.

Mark

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

signature.asc
Description: OpenPGP digital signature

Re: Building a Java9 project just using JDK9

2017-08-17 Thread Tibor Digana

I am going to run the build with
--add-modules java.se.ee

If this will work for me then pls confirm that I can commit it to master.

On Thu, Aug 17, 2017 at 11:18 PM, Enrico Olivelli 
wrote:

> On mer 16 ago 2017, 08:19 Tibor Digana 
> wrote:
>
> > Still I do not understand what is the difference between *all_system*
> > and *java.se.ee
> > *.
> > Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> > warning? It looks like it wants to be exposed out of the jdk to our
> > application which is not legal but then why jdk allows.
> >
>
> I see your headache with this.
> Maybe we could add only java.se.ee and document how to change to
> all_system.
> I will check the actual difference for normal applications
>
>
> Cheers
> Enrico
>
>
> > On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli 
> > wrote:
> >
> > > Il mer 16 ago 2017, 02:44 Tibor Digana  ha
> > > scritto:
> > >
> > > > Hi Enrico,
> > > >
> > > > It does not appear on console output however it is stored as native
> > > std/out
> > > > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
> > > >
> > >
> > > Yep, it is as I suspected. If we want ro get rid of it we have to only
> > add
> > > java.se.ee module
> > >
> > >
> > > > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
> > > > ml+s40175n5912520...@n5.nabble.com> wrote:
> > > >
> > > > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
> > > > > > ha
> > > > > scritto:
> > > > >
> > > > > > I found an issue. JDK printed this on std/out:
> > > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > > >
> > > > >
> > > > > IMHO This is because we are importing all system modules. Maybe
> > > importing
> > > > > only java.se.ee would cover most of the cases.
> > > > > I did not notice the warning on test I have run today
> > > > >
> > > > > Enrico
> > > > >
> > > > >
> > > > > > It hapens after my test:
> > > > > >
> > > > > > import org.junit.Test;
> > > > > >
> > > > > > public class J9Test
> > > > > > {
> > > > > > @Test
> > > > > > public void testMiscellaneousAPI() throws
> java.sql.SQLException
> > > > > > {
> > > > > > System.out.println( "loaded class " +
> > > > > > java.sql.SQLException.class.getName() );
> > > > > > System.out.println( "loaded class " +
> > > > > > javax.xml.ws.Holder.class.getName() );
> > > > > > System.out.println( "loaded class " +
> > > > > > javax.xml.bind.JAXBException.class.getName() );
> > > > > > System.out.println( "loaded class " +
> > > > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > > > > > System.out.println( "loaded class " +
> > > > > > javax.xml.xpath.XPath.class.getName() );
> > > > > > System.out.println( "java.specification.version=" +
> > > > > > System.getProperty( "java.specification.version" ) );
> > > > > > }
> > > > > >
> > > > > > @Test
> > > > > > public void test_corba_mod() throws
> org.omg.CORBA.BAD_INV_ORDER
> > > > > > {
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
> > > > > 
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > But why to add it? It's a hack. I do not use module-info.java
> and
> > > so
> > > > > > there
> > > > > > > is no reason to break the backwards compatibility.
> > > > > > >
> > > > > > > This is no more about Maven. It is about entire Java world.
> > > > > > > If we in Maven do it then everybody has to.
> > > > > > > And I am sure that the voices says that Kotlin is better and
> > Scala
> > > is
> > > > > > > better would make sense. Why to help these attempts to happen?
> No
> > > > > reason!
> > > > > > >
> > > > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email]
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using
> > plugin
> > > > > > >> specific
> > > > > > >> tags like below is going to be painful.
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email]
> > > > > > wrote:
> > > > > > >>
> > > > > > >> > Hi @Enrico,
> > > > > > >> >
> > > > > > >> > I am very unhappy with Java 9 status and very afraid.
> > > > > > >> > I do not like the style how Oracle has changed Java to Java
> 9
> > > and
> > > > > > forced
> > > > > > >> > all the world to use additional effort to adapt to Oracle
> > > > > activities.
> > > > > > >> >
> > > > > > >> > I am facing more unhappy Java development teams with Java 9
> in
> > > the
> > > > > > >> future.
> > > > > > >> > For instance as I have tried to implement users wish in
> Maven
> > >

Re: Building a Java9 project just using JDK9

2017-08-17 Thread Bernd Eckenfels

You recreate a limited modules JRE with jlink. Haven't tried it but maybe you 
can generate an image with Java.se.ee as root that way, too.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Tibor Digana 
Sent: Wednesday, August 16, 2017 8:28:02 AM
To: Maven Developers List
Subject: Re: Building a Java9 project just using JDK9

Btw. Can be JRE/JDK configures after installation in terms not doing these
things and so that non-modular application would have access to java.se.ee
by default?

And second question, which would be cool feature to have, is some script
which allows me to recreate a new JRE from installed one but much smaller
with the only *java.base* module and all binaries like *bin/modules, src,
jmods* sudenly become much smaller.

On Wed, Aug 16, 2017 at 8:19 AM, Tibor Digana 
wrote:

> Still I do not understand what is the difference between *all_system* and 
> *java.se.ee
> *.
> Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> warning? It looks like it wants to be exposed out of the jdk to our
> application which is not legal but then why jdk allows.
>
> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli 
> wrote:
>
>> Il mer 16 ago 2017, 02:44 Tibor Digana  ha
>> scritto:
>>
>> > Hi Enrico,
>> >
>> > It does not appear on console output however it is stored as native
>> std/out
>> > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
>> >
>>
>> Yep, it is as I suspected. If we want ro get rid of it we have to only add
>> java.se.ee module
>>
>>
>> > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
>> > ml+s40175n5912520...@n5.nabble.com> wrote:
>> >
>> > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
>> > > > ha
>> > > scritto:
>> > >
>> > > > I found an issue. JDK printed this on std/out:
>> > > > WARNING: Using incubator modules: jdk.incubator.httpclient
>> > > >
>> > >
>> > > IMHO This is because we are importing all system modules. Maybe
>> importing
>> > > only java.se.ee would cover most of the cases.
>> > > I did not notice the warning on test I have run today
>> > >
>> > > Enrico
>> > >
>> > >
>> > > > It hapens after my test:
>> > > >
>> > > > import org.junit.Test;
>> > > >
>> > > > public class J9Test
>> > > > {
>> > > > @Test
>> > > > public void testMiscellaneousAPI() throws java.sql.SQLException
>> > > > {
>> > > > System.out.println( "loaded class " +
>> > > > java.sql.SQLException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.ws.Holder.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.bind.JAXBException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.xpath.XPath.class.getName() );
>> > > > System.out.println( "java.specification.version=" +
>> > > > System.getProperty( "java.specification.version" ) );
>> > > > }
>> > > >
>> > > > @Test
>> > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
>> > > > {
>> > > > }
>> > > > }
>> > > >
>> > > >
>> > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
>> > > 
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > But why to add it? It's a hack. I do not use module-info.java and
>> so
>> > > > there
>> > > > > is no reason to break the backwards compatibility.
>> > > > >
>> > > > > This is no more about Maven. It is about entire Java world.
>> > > > > If we in Maven do it then everybody has to.
>> > > > > And I am sure that the voices says that Kotlin is better and
>> Scala is
>> > > > > better would make sense. Why to help these attempts to happen? No
>> > > reason!
>> > > > >
>> > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email]
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using
>> plugin
>> > > > >> specific
>> > > > >> tags like below is going to be painful.
>> > > > >>
>> > > > >> Gary
>> > > > >>
>> > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email]
>> > > > wrote:
>> > > > >>
>> > > > >> > Hi @Enrico,
>> > > > >> >
>> > > > >> > I am very unhappy with Java 9 status and very afraid.
>> > > > >> > I do not like the style how Oracle has changed Java to Java 9
>> and
>> > > > forced
>> > > > >> > all the world to use additional effort to adapt to Oracle
>> > > activities.
>> > > > >> >
>> > > > >> > I am facing more unhappy Java development teams with Java 9 in
>> the
>> > > > >> future.
>> > > > >> > For instance as I have tried to

Re: Building a Java9 project just using JDK9

2017-08-17 Thread Enrico Olivelli

On mer 16 ago 2017, 08:19 Tibor Digana  wrote:

> Still I do not understand what is the difference between *all_system*
> and *java.se.ee
> *.
> Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> warning? It looks like it wants to be exposed out of the jdk to our
> application which is not legal but then why jdk allows.
>

I see your headache with this.
Maybe we could add only java.se.ee and document how to change to
all_system.
I will check the actual difference for normal applications


Cheers
Enrico


> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli 
> wrote:
>
> > Il mer 16 ago 2017, 02:44 Tibor Digana  ha
> > scritto:
> >
> > > Hi Enrico,
> > >
> > > It does not appear on console output however it is stored as native
> > std/out
> > > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
> > >
> >
> > Yep, it is as I suspected. If we want ro get rid of it we have to only
> add
> > java.se.ee module
> >
> >
> > > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
> > > ml+s40175n5912520...@n5.nabble.com> wrote:
> > >
> > > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
> > > > > ha
> > > > scritto:
> > > >
> > > > > I found an issue. JDK printed this on std/out:
> > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > >
> > > >
> > > > IMHO This is because we are importing all system modules. Maybe
> > importing
> > > > only java.se.ee would cover most of the cases.
> > > > I did not notice the warning on test I have run today
> > > >
> > > > Enrico
> > > >
> > > >
> > > > > It hapens after my test:
> > > > >
> > > > > import org.junit.Test;
> > > > >
> > > > > public class J9Test
> > > > > {
> > > > > @Test
> > > > > public void testMiscellaneousAPI() throws java.sql.SQLException
> > > > > {
> > > > > System.out.println( "loaded class " +
> > > > > java.sql.SQLException.class.getName() );
> > > > > System.out.println( "loaded class " +
> > > > > javax.xml.ws.Holder.class.getName() );
> > > > > System.out.println( "loaded class " +
> > > > > javax.xml.bind.JAXBException.class.getName() );
> > > > > System.out.println( "loaded class " +
> > > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > > > > System.out.println( "loaded class " +
> > > > > javax.xml.xpath.XPath.class.getName() );
> > > > > System.out.println( "java.specification.version=" +
> > > > > System.getProperty( "java.specification.version" ) );
> > > > > }
> > > > >
> > > > > @Test
> > > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> > > > > {
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
> > > > 
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > But why to add it? It's a hack. I do not use module-info.java and
> > so
> > > > > there
> > > > > > is no reason to break the backwards compatibility.
> > > > > >
> > > > > > This is no more about Maven. It is about entire Java world.
> > > > > > If we in Maven do it then everybody has to.
> > > > > > And I am sure that the voices says that Kotlin is better and
> Scala
> > is
> > > > > > better would make sense. Why to help these attempts to happen? No
> > > > reason!
> > > > > >
> > > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email]
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using
> plugin
> > > > > >> specific
> > > > > >> tags like below is going to be painful.
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email]
> > > > > wrote:
> > > > > >>
> > > > > >> > Hi @Enrico,
> > > > > >> >
> > > > > >> > I am very unhappy with Java 9 status and very afraid.
> > > > > >> > I do not like the style how Oracle has changed Java to Java 9
> > and
> > > > > forced
> > > > > >> > all the world to use additional effort to adapt to Oracle
> > > > activities.
> > > > > >> >
> > > > > >> > I am facing more unhappy Java development teams with Java 9 in
> > the
> > > > > >> future.
> > > > > >> > For instance as I have tried to implement users wish in Maven
> > > > Surefire
> > > > > >> > project and invested my personal time and effort to adapt to
> > > Oracle
> > > > > >> > requirements, this still does not convince me to say that
> Java 9
> > > is
> > > > > >> ready
> > > > > >> > to go.
> > > > > >> >
> > > > > >> > This is my comment from Jira:
> > > > > >> >
> > > > > >> > "This is not nice on Java 9 that they broke backwards
> > > compatibility
> > > > > and
> > > > > >> > force the world to use the switch to use --add-modules
> >

[RESULT] [VOTE] Release Apache Maven EJB Plugin version 3.0.0

2017-08-17 Thread Karl Heinz Marbaise


i,

The vote has passed with the following result:

+1 : Tibor Digana, Anders Hammar, Karl Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

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

Re: [VOTE] Release Apache Maven EJB Plugin version 3.0.0

2017-08-17 Thread Karl Heinz Marbaise


Hi,

+1 from me...

Kind regards
Karl Heinz Marbaise

On 13/08/17 17:02, Karl Heinz Marbaise wrote:

Hi,

We solved 29 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317421=12330676 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MEJB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC 



Staging repo:
https://repository.apache.org/content/repositories/maven-1355

https://repository.apache.org/content/repositories/maven-1355/org/apache/maven/plugins/maven-ejb-plugin/3.0.0/maven-ejb-plugin-3.0.0-source-release.zip 



Source release checksum(s):
maven-ejb-plugin-3.0.0-source-release.zip sha1: 
306abe38824177836c0b3253180ab9f3110a5ddb


Staging site:
http://maven.apache.org/plugins-archives/maven-ejb-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] Release Apache Maven EJB Plugin version 3.0.0

2017-08-17 Thread Anders Hammar

+1 (binding)

Tested with Maven 3.3.3 and IBM JDK 7.1.

I did find some minor text bugs on the site which I filed tickets for [1]
[2] [3].

[1] https://issues.apache.org/jira/browse/MEJB-115
[2] https://issues.apache.org/jira/browse/MEJB-116
[3] https://issues.apache.org/jira/browse/MEJB-117

/Anders

On Wed, Aug 16, 2017 at 5:54 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> we need at least one more PMC VOTE ...
>
> Kind regards
> Karl Heinz Marbaise
> On 13/08/17 17:02, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> We solved 29 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12317421=12330676
>>
>> There are still a couple of issues left in JIRA:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MEJB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1355
>>
>> https://repository.apache.org/content/repositories/maven-135
>> 5/org/apache/maven/plugins/maven-ejb-plugin/3.0.0/maven-ejb-
>> plugin-3.0.0-source-release.zip
>>
>> Source release checksum(s):
>> maven-ejb-plugin-3.0.0-source-release.zip sha1:
>> 306abe38824177836c0b3253180ab9f3110a5ddb
>>
>> Staging site:
>> http://maven.apache.org/plugins-archives/maven-ejb-plugin-LATEST/
>>
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for at least 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Using "annotationProcessorPaths" together with version ranges

2017-08-17 Thread Cristian Spiescu


Hello,

I think I have spotted a bug, but I'm not 100% sure.

When using maven-compiler-plugin with "annotationProcessorPaths", and I 
specify a dependency with a version range: it doesn't seem to work. I 
have done some debugging, and I see that the general dependency solving 
mechanism (that does support version ranges) doesn't seem to be used 
when trying to resolve the dependencies from "annotationProcessorPaths". 
So if I specify [1.0.0, ), then maven actually tryies 
to use the version as-is, actually creating a directory "[1.0.0,)" in 
the local maven repo.


Does anyone has any pointers on this?

Thanks a lot in advance!

Cristian.


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

Re: Using "annotationProcessorPaths" together with version ranges

Re: Building a Java9 project just using JDK9

Re: Building a Java9 project just using JDK9

Re: Building a Java9 project just using JDK9

[RESULT] [VOTE] Release Apache Maven EJB Plugin version 3.0.0

Re: [VOTE] Release Apache Maven EJB Plugin version 3.0.0

Re: [VOTE] Release Apache Maven EJB Plugin version 3.0.0

Using "annotationProcessorPaths" together with version ranges

8 matches

Site Navigation

Mail list logo

Footer information