Re: Building a Java9 project just using JDK9

[Tibor Digana]

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

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 ALL-SYSTEM
> > >> instead
> > >> > of providing all modules installed in JRE. For instance, small JRE
> > >> having
> > >> > {{java.base}} has advantage on embedded systems and the only should
> be
> > >> > propagated. Big scope JRE should propagate all installed modules.
> > >> > But for me it does not make security sense and common sense to
> force
> > >> JRE to
> > >> > provide modules. It should be opposite and the admin/Jenkins should
> > >> > configure big scope JRE with selected modules propagated to Java
> > runtime
> > >> > applications.
> > >> > If this admin does not do that then all modules should be available
> by
> > >> > default which is backwards compatibility for me and we do not have
> to
> > to
> > >> > implement these stupid tricks."
> > >> >
> > >> > As far as we remember Java Security, the policies can be
> configured.
> > >> > I can imaging same paradigm in Jigsaw/Java 9 and then the admin who
> > has
> > >> > installed JDK or JRE would "switch off" some modules. But opposite,
> > that
> > >> > means the script which starts Java app currently enables "all"
> modules
> > >> is
> > >> > against security and against the principle of modular system
> because
> > the
> > >> > modules do not make sense then.
> > >> >
> > >> > What makes sense to me is to enable "all java/javax" modules except
> > for
> > >> the
> > >> > "com.sun" proprietary ones by default.
> > >> > So yes enable them by default and please release specific JRE
> > >> installations
> > >> > with specific bunch of Java modules for 

Re: ASF Jenkins fails on Pipeline build saying that javac has no permissions

[Tibor Digana]

No I updated Jenkinsfile [1] and the result is better but still strange
with this error:

/bin/sh: 1: /bin/java: not found

[1]: 
https://github.com/apache/maven-surefire/commit/5f70c371c6be09d5599b713490d9d1a77b3f809f


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

> Hi dev,
>
> In ASF/Maven we have this build [1] which uses Jenkinsfile and Pipeline.
> Compiling the project fails with error [2].
> Do you know what we are doing wrong and how to fix it?
>
>
> [1]: https://builds.apache.org/view/M-R/view/Maven/job/maven-
> surefire-pipeline/job/master/57/console
>
> [2]:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile 
> (default-compile) on project surefire-logger-api: Fatal error compiling: 
> Error creating file with javac arguments: Permission denied -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile 
> (default-compile) on project surefire-logger-api: Fatal error compiling
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>
>

ASF Jenkins fails on Pipeline build saying that javac has no permissions

[Tibor Digana]

Hi dev,

In ASF/Maven we have this build [1] which uses Jenkinsfile and Pipeline.
Compiling the project fails with error [2].
Do you know what we are doing wrong and how to fix it?


[1]:
https://builds.apache.org/view/M-R/view/Maven/job/maven-surefire-pipeline/job/master/57/console

[2]:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
(default-compile) on project surefire-logger-api: Fatal error
compiling: Error creating file with javac arguments: Permission denied
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
(default-compile) on project surefire-logger-api: Fatal error
compiling
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)

How to use Invoker in Jenkinsfile

[Tibor Digana]

Can you give me pls an example with "invoker" in Jenkinsfile showing test
reports in "Test result" screen from maven-invoker-plugin.
This should be something similar to "junit"

success {
junit healthScaleFactor: 0.0, allowEmptyResults: true,
keepLongStdio: true, testResults:
'**/target/surefire-reports/**/*.xml,**/target/failsafe-reports/**/*.xml'
}


-- 
Cheers
Tibor

Re: maven-compiler-plugin release

[Robert Scholte]

I need to work an the plexus-java performance issue and also think of a  
way to preserve the extra JPMS arguments used during compilation so they  
can be available at runtime as well (= MCOMPILER-296).
As far as I know these are the final open issues required to have a  
complete Java 9 supported plugin.


I will pick these up probably next week.

thanks,
Robert


On Tue, 15 Aug 2017 22:34:19 +0200, Karl Heinz Marbaise  
 wrote:



Hi Robert,

would you think we should do another release for maven-compiler-plugin ?

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: Building a Java9 project just using JDK9

[Karl Heinz Marbaise]

Hi Gary,

as Robert already pointed out Maven can run fine on JDK 9...for a very 
long time..


I'm working on support for jlink, jmod to support creation of run time 
images with Maven simple (currently in its alpha states if this is 
appropriate) ...which can be looked at the currenty example project[1] 
also in my blog[2] etc.


Furthermore we have at the moment only left few problems (see 
maven-ear-plugin)...The maven-ejb-plugin where currently the VOTE is 
running for which fixes issues related to JDK 9...


Robert is making many efforts on getting things done in 
maven-compiler-plugin and many other plugins/components as well...


The current state can be looked at the wiki[4]

It would be great to see people trying to use JDK 9 and see how it works 
with Maven...in particular issues related to migration to JDK 9 and 
modularization? What are the pain points ?


I've taken an example project which does some usage of JDK 9 and modules 
in a way I don't like (changind maven default directory layout) so I'm 
trying to fix in the way I like to see how it should work...and if it 
works...And currently there is an issue in maven-compiler-plugin which 
will be fixed with the next released which will come very soon...


Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/jdk9-jlink-jmod-example
[2]: 
http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/
[3]: 
https://dzone.com/articles/jdk9-howto-create-a-java-run-time-image-with-maven

[4]: https://s.apache.org/maven-j9



On 15/08/17 20:10, Robert Scholte wrote:
On Tue, 15 Aug 2017 19:57:37 +0200, Gary Gregory 
 wrote:


I'm guessing that all the pain of doing this will not be fully known 
until

Maven is Java 9-ified.


Not sure what you mean by this. Maven itself can run on Java 9, most 
plugins work with Java 9, most Java 9 features are supported.


Don't expect Maven to become a modularized project. We have split 
packages, which we cannot remove.
Based on the 2 pillars of Jigsaw, i.e strong encapsulation and reliable 
configuration, I think Maven would like to benefit from the first one, 
but I don't see the reliable configuration as an issue.
Modularizing would mean a complete rewrite with new packages, which 
would make all current maven-plugins probably useless.

To sum it all up: modularizing is probably not worth it for this project.

Robert



Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:


Il mar 15 ago 2017, 17:51 Gary Gregory  ha
scritto:

> You will need the same tricks at runtime for the command line that 
Maven

> might hide at build time... :-( I guess hacks like --add-modules
ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be 
hacked

in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully 
migrate to

the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven 
goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now 
we are

going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana 
ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of 
modules is

> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however 
JEE8

has
> > not
> > > yet been released even if the ambition was to develop JEE9 in
parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from 
jigsaw.
> > I think that the strong encapsulation work will make development 
of the

> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from 
java8

to
> > java9 ad far as we can. Maybe most of developers which are using 
maven

> will
> > not see all the tricks under the hood
> >
> > 

maven-compiler-plugin release

[Karl Heinz Marbaise]

Hi Robert,

would you think we should do another release for maven-compiler-plugin ?

Kind regards
Karl Heinz Marbaise

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

[GitHub] maven-integration-testing issue #21: [MNG-6127] Add plugin execution configu...

[mkrizmanic]

Github user mkrizmanic commented on the issue:

https://github.com/apache/maven-integration-testing/pull/21
  
already merged


---
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-integration-testing pull request #21: [MNG-6127] Add plugin execution ...

[mkrizmanic]

Github user mkrizmanic closed the pull request at:

https://github.com/apache/maven-integration-testing/pull/21


---
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: JDK9: Maven-JLink-Plugin, Maven-JMod-Plugin

[Karl Heinz Marbaise]

Hi Robert,

I've taken a the liberaty to create INFRA[1] ticket which seemed be 
already working on...


Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/INFRA-14878

On 15/08/17 22:10, Robert Scholte wrote:

Hi Karl Heinz,

I think it makes sense to have these packaging plugins.
Haven't looked at the code yet, but you can start with the preparations.
I hope Brian is available to make this Jira projects.

thanks,
Robert

On Sun, 13 Aug 2017 21:19:55 +0200, Karl Heinz Marbaise 
 wrote:



Hi,
I would like to start a first alpha release of those two plugins to 
have something in the wild to be used and see how the feedback would 
be



What do you think?

I would request JIRA projects for them

Kind regards
Karl Heinz Marbaise

-
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





Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

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

Re: JDK9: Maven-JLink-Plugin, Maven-JMod-Plugin

[Robert Scholte]

Hi Karl Heinz,

I think it makes sense to have these packaging plugins.
Haven't looked at the code yet, but you can start with the preparations.
I hope Brian is available to make this Jira projects.

thanks,
Robert

On Sun, 13 Aug 2017 21:19:55 +0200, Karl Heinz Marbaise  
 wrote:



Hi,
I would like to start a first alpha release of those two plugins to have  
something in the wild to be used and see how the feedback would be



What do you think?

I would request JIRA projects for them

Kind regards
Karl Heinz Marbaise

-
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: Building a Java9 project just using JDK9

[Robert Scholte]

On Tue, 15 Aug 2017 19:57:37 +0200, Gary Gregory   
wrote:


I'm guessing that all the pain of doing this will not be fully known  
until

Maven is Java 9-ified.


Not sure what you mean by this. Maven itself can run on Java 9, most  
plugins work with Java 9, most Java 9 features are supported.


Don't expect Maven to become a modularized project. We have split  
packages, which we cannot remove.
Based on the 2 pillars of Jigsaw, i.e strong encapsulation and reliable  
configuration, I think Maven would like to benefit from the first one, but  
I don't see the reliable configuration as an issue.
Modularizing would mean a complete rewrite with new packages, which would  
make all current maven-plugins probably useless.

To sum it all up: modularizing is probably not worth it for this project.

Robert



Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:


Il mar 15 ago 2017, 17:51 Gary Gregory  ha
scritto:

> You will need the same tricks at runtime for the command line that  
Maven

> might hide at build time... :-( I guess hacks like --add-modules
ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be  
hacked

in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully migrate  
to

the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven  
goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now we  
are

going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana 
ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of  
modules is

> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however  
JEE8

has
> > not
> > > yet been released even if the ambition was to develop JEE9 in
parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from  
jigsaw.
> > I think that the strong encapsulation work will make development of  
the

> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from  
java8

to
> > java9 ad far as we can. Maybe most of developers which are using  
maven

> will
> > not see all the tricks under the hood
> >
> > Thank you
> >
> >
> > Enrico
> >
> >
> > > I understand that development parties of application servers and
> > libraries
> > > suppliers are slow but this still would not guarantee that there  
is

no
> > risk
> > > that Jigsaw project made some mistake which (if happens) cannot be
> taken
> > > back after the final release of JSE9.
> > >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <
eolive...@gmail.com
> >
> > > wrote:
> > >
> > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
tibor.dig...@googlemail.com>
> > ha
> > > > scritto:
> > > >
> > > > > Hello Enrico,
> > > > >
> > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > I need an approval for the Jira SUREFIRE-1403 for you and  
Robert.

> Thx
> > > in
> > > > > advance.
> > > > >
> > > >
> > > > I will check as soon as I wil be back from vacation. Thank you  
very

> > much.
> > > > For me it is very important
> > > >
> > > > >
> > > > > I have added integration tests for Failsafe plugin, added
> > > documentation "
> > > > > java9.md" and removed JAXB which is located in module
> > > > *javax.xml.binding*.
> > > > >
> > > > > *Here is a clarification on why I was unhappy with Java status
and
> > why
> > > > > Surefire project could not run with Java 9 and how it was  
fixed:*

> > > > >
> > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not
run
> in
> > > > > Java9.
> > > > > Reason is that module *javax.xml.binding* is however in Java  
API

> but
> > > not
> > > > > propagated on classpath when running Maven process (different

Re: Building a Java9 project just using JDK9

[Gary Gregory]

I'm guessing that all the pain of doing this will not be fully known until
Maven is Java 9-ified.

Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:

> Il mar 15 ago 2017, 17:51 Gary Gregory  ha
> scritto:
>
> > You will need the same tricks at runtime for the command line that Maven
> > might hide at build time... :-( I guess hacks like --add-modules
> ALL-SYSTEM
> > will become part of our daily grind...
> >
>
> Gary, I think you are right, scripts to launch applications will be hacked
> in the same way, at least during the transition.
> New j9 applications which do not use the classpath will not suffer from
> this problem. Anyway in order to launch a jigsaw enabled application you
> have to change the arguments passed to the jvm and so to fully migrate to
> the new j9 style a lot of work is to be done.
>
> For many developers most of the work life is bound to running maven goals.
> When I just wanted to try j9 I got into a lot of blocker issues. Now we are
> going to make the life easier to develop and test java8 applications and
> gradually switch to java9
>
> Cheers
> Enrico
>
>
> > Gary
> >
> > On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> > wrote:
> >
> > > Il mar 15 ago 2017, 00:03 Tibor Digana 
> ha
> > > scritto:
> > >
> > > > I do not want to be too pessimistic but the inheritance of modules is
> > > > crucial for all the world.
> > > >
> > > > The common sense tells me that I should not release Java 9 on
> > September,
> > > > 2017 unless Java EE application servers work properly.
> > > >
> > > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
> and
> > > > maybe we will find out new issues which regarding for module
> > java.se.ee.
> > > >
> > > > Without waiting for JEE9 this release would be too fast.
> > > > Oracle had an ambition to align JSE9 release with JEE9 however JEE8
> has
> > > not
> > > > yet been released even if the ambition was to develop JEE9 in
> parallel
> > > with
> > > > JEE8.
> > > >
> > > > Isn't this too fast for the release of JSE9?
> > > >
> > >
> > > We are all waiting java9 and all the new features, apart from jigsaw.
> > > I think that the strong encapsulation work will make development of the
> > jdk
> > > more simple and new java releases will follow a faster pace.
> > > I am really worried about the lack of interest in defining exacly at
> > least
> > > the behaviour of most used frameworks, first of all the wrb
> > > applications/servlet world
> > >
> > > I am happy that the maven world will make it easy to switch from java8
> to
> > > java9 ad far as we can. Maybe most of developers which are using maven
> > will
> > > not see all the tricks under the hood
> > >
> > > Thank you
> > >
> > >
> > > Enrico
> > >
> > >
> > > > I understand that development parties of application servers and
> > > libraries
> > > > suppliers are slow but this still would not guarantee that there is
> no
> > > risk
> > > > that Jigsaw project made some mistake which (if happens) cannot be
> > taken
> > > > back after the final release of JSE9.
> > > >
> > > >
> > > >
> > > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
> tibor.dig...@googlemail.com>
> > > ha
> > > > > scritto:
> > > > >
> > > > > > Hello Enrico,
> > > > > >
> > > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert.
> > Thx
> > > > in
> > > > > > advance.
> > > > > >
> > > > >
> > > > > I will check as soon as I wil be back from vacation. Thank you very
> > > much.
> > > > > For me it is very important
> > > > >
> > > > > >
> > > > > > I have added integration tests for Failsafe plugin, added
> > > > documentation "
> > > > > > java9.md" and removed JAXB which is located in module
> > > > > *javax.xml.binding*.
> > > > > >
> > > > > > *Here is a clarification on why I was unhappy with Java status
> and
> > > why
> > > > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > > > >
> > > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not
> run
> > in
> > > > > > Java9.
> > > > > > Reason is that module *javax.xml.binding* is however in Java API
> > but
> > > > not
> > > > > > propagated on classpath when running Maven process (different
> > > situation
> > > > > in
> > > > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > > > This is strange and will be strange for most people, for instance
> > in
> > > > our
> > > > > > *Java
> > > > > > EE project using REST* the WildFly server has to use
> > *"--add-modules
> > > > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working
> again.
> > > > > > As a solution in Surefire project I removed JAXB which was simple
> > XML
> > > > in
> > > > > my
> > > > > > case but not simple in 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il mar 15 ago 2017, 17:51 Gary Gregory  ha scritto:

> You will need the same tricks at runtime for the command line that Maven
> might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be hacked
in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully migrate to
the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now we are
going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana  ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of modules is
> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has
> > not
> > > yet been released even if the ambition was to develop JEE9 in parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from jigsaw.
> > I think that the strong encapsulation work will make development of the
> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from java8 to
> > java9 ad far as we can. Maybe most of developers which are using maven
> will
> > not see all the tricks under the hood
> >
> > Thank you
> >
> >
> > Enrico
> >
> >
> > > I understand that development parties of application servers and
> > libraries
> > > suppliers are slow but this still would not guarantee that there is no
> > risk
> > > that Jigsaw project made some mistake which (if happens) cannot be
> taken
> > > back after the final release of JSE9.
> > >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli  >
> > > wrote:
> > >
> > > > Il lun 14 ago 2017, 11:46 Tibor Digana 
> > ha
> > > > scritto:
> > > >
> > > > > Hello Enrico,
> > > > >
> > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert.
> Thx
> > > in
> > > > > advance.
> > > > >
> > > >
> > > > I will check as soon as I wil be back from vacation. Thank you very
> > much.
> > > > For me it is very important
> > > >
> > > > >
> > > > > I have added integration tests for Failsafe plugin, added
> > > documentation "
> > > > > java9.md" and removed JAXB which is located in module
> > > > *javax.xml.binding*.
> > > > >
> > > > > *Here is a clarification on why I was unhappy with Java status and
> > why
> > > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > > >
> > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not run
> in
> > > > > Java9.
> > > > > Reason is that module *javax.xml.binding* is however in Java API
> but
> > > not
> > > > > propagated on classpath when running Maven process (different
> > situation
> > > > in
> > > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > > This is strange and will be strange for most people, for instance
> in
> > > our
> > > > > *Java
> > > > > EE project using REST* the WildFly server has to use
> *"--add-modules
> > > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > > > As a solution in Surefire project I removed JAXB which was simple
> XML
> > > in
> > > > my
> > > > > case but not simple in general.
> > > > >
> > > >
> > > > I will have to do it for several projects, or at leastleast to add
> > > > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > > > default, that is weird to me
> > > >
> > > > >
> > > > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > > > modularity".
> > > > > But there are reasons where you will use it.
> > > > > For instance new API in Java or Java EE 9 in the future.
> > > > >
> > > >
> > > 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il dom 13 ago 2017, 17:31 Tibor Digana  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  >
> 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 
> > 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"  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 ALL-SYSTEM
> >> instead
> >> > of providing all modules installed in JRE. For instance, small JRE
> >> having
> >> > {{java.base}} has advantage on embedded systems and the only should be
> >> > propagated. Big scope JRE should propagate all installed modules.
> >> > But for me it does not make security sense and common sense to force
> >> JRE to
> >> > provide modules. It should be opposite and the admin/Jenkins should
> >> > configure big scope JRE with selected modules propagated to Java
> runtime
> >> > applications.
> >> > If this admin does not do that then all modules should be available by
> >> > default which is backwards compatibility for me and we do not have to
> to
> >> > implement these stupid tricks."
> >> >
> >> > As far as we remember Java Security, the policies can be configured.
> >> > I can imaging same paradigm in Jigsaw/Java 9 and then the admin who
> has
> >> > installed JDK or JRE would "switch off" some modules. But opposite,
> that
> >> > means the script which starts Java app currently enables "all" modules
> >> is
> >> > against security and against the principle of modular system because
> the
> >> > modules do not make sense then.
> >> >
> >> > What makes sense to me is to enable "all java/javax" modules except
> for
> >> the
> >> > "com.sun" proprietary ones by default.
> >> > So yes enable them by default and please release specific JRE
> >> installations
> >> > with specific bunch of Java modules for specific use cases.
> >> > This means those modules in that particular release are all enabled by
> >> > default if not configured otherwise by admin, e.g. Jenkins, operation
> >> > staff, etc. (do NOT mean Sun packages - never visible).
> >> >
> >> > Here it comes. The idea that we can install small 5MB/JRE on small
> Linux
> >> > device would be possible because Oracle would release such tiny JRE
> >> using
> >> > only "java.lang" and then another JRE installation using java.lang and
> >> > java.utils, and later NIO and later "java.desktop", etc.
> >> >
> >> > Then vendors of web browsers and Linux dist would be happy to
> integrate
> >> > small JRE into and use JavaFX.

Re: Building a Java9 project just using JDK9

[Gary Gregory]

You will need the same tricks at runtime for the command line that Maven
might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
will become part of our daily grind...

Gary

On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
wrote:

> Il mar 15 ago 2017, 00:03 Tibor Digana  ha
> scritto:
>
> > I do not want to be too pessimistic but the inheritance of modules is
> > crucial for all the world.
> >
> > The common sense tells me that I should not release Java 9 on September,
> > 2017 unless Java EE application servers work properly.
> >
> > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> > maybe we will find out new issues which regarding for module java.se.ee.
> >
> > Without waiting for JEE9 this release would be too fast.
> > Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has
> not
> > yet been released even if the ambition was to develop JEE9 in parallel
> with
> > JEE8.
> >
> > Isn't this too fast for the release of JSE9?
> >
>
> We are all waiting java9 and all the new features, apart from jigsaw.
> I think that the strong encapsulation work will make development of the jdk
> more simple and new java releases will follow a faster pace.
> I am really worried about the lack of interest in defining exacly at least
> the behaviour of most used frameworks, first of all the wrb
> applications/servlet world
>
> I am happy that the maven world will make it easy to switch from java8 to
> java9 ad far as we can. Maybe most of developers which are using maven will
> not see all the tricks under the hood
>
> Thank you
>
>
> Enrico
>
>
> > I understand that development parties of application servers and
> libraries
> > suppliers are slow but this still would not guarantee that there is no
> risk
> > that Jigsaw project made some mistake which (if happens) cannot be taken
> > back after the final release of JSE9.
> >
> >
> >
> > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli 
> > wrote:
> >
> > > Il lun 14 ago 2017, 11:46 Tibor Digana 
> ha
> > > scritto:
> > >
> > > > Hello Enrico,
> > > >
> > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx
> > in
> > > > advance.
> > > >
> > >
> > > I will check as soon as I wil be back from vacation. Thank you very
> much.
> > > For me it is very important
> > >
> > > >
> > > > I have added integration tests for Failsafe plugin, added
> > documentation "
> > > > java9.md" and removed JAXB which is located in module
> > > *javax.xml.binding*.
> > > >
> > > > *Here is a clarification on why I was unhappy with Java status and
> why
> > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > >
> > > > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > > > Java9.
> > > > Reason is that module *javax.xml.binding* is however in Java API but
> > not
> > > > propagated on classpath when running Maven process (different
> situation
> > > in
> > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > This is strange and will be strange for most people, for instance in
> > our
> > > > *Java
> > > > EE project using REST* the WildFly server has to use *"--add-modules
> > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > > As a solution in Surefire project I removed JAXB which was simple XML
> > in
> > > my
> > > > case but not simple in general.
> > > >
> > >
> > > I will have to do it for several projects, or at leastleast to add
> > > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > > default, that is weird to me
> > >
> > > >
> > > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > > modularity".
> > > > But there are reasons where you will use it.
> > > > For instance new API in Java or Java EE 9 in the future.
> > > >
> > >
> > > The main reason for migration is to keep up to date, java8 will soon
> > reach
> > > EOL.
> > > Java9 comes with many improvements that just upgrading will speed up
> most
> > > applications, just think about nee compat strings. New API are great
> and
> > > were expected from long time ago, like the new Process API
> > >
> > >
> > > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> > principle.
> > > >
> > >
> > > Yep, new applications will be more fine tuned, the problem here is only
> > for
> > > the migration
> > >
> > > As a workaround to this in Maven would be to develop *smart
> > > > maven-compiler-plugin* which automatically generates
> > *module-info.class*
> > > > upon import sections in Java classes and Maven dependencies.
> > > > Not easy I guess.
> > > >
> > >
> > > I think this will be not feasible in general and very dangerous and
> > maybe I
> > > hope maven will never do such things
> > >
> > > Cheers
> > > Enrico
> > >
> > > >
> > > >
> 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il mar 15 ago 2017, 00:03 Tibor Digana  ha
scritto:

> I do not want to be too pessimistic but the inheritance of modules is
> crucial for all the world.
>
> The common sense tells me that I should not release Java 9 on September,
> 2017 unless Java EE application servers work properly.
>
> This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> maybe we will find out new issues which regarding for module java.se.ee.
>
> Without waiting for JEE9 this release would be too fast.
> Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has not
> yet been released even if the ambition was to develop JEE9 in parallel with
> JEE8.
>
> Isn't this too fast for the release of JSE9?
>

We are all waiting java9 and all the new features, apart from jigsaw.
I think that the strong encapsulation work will make development of the jdk
more simple and new java releases will follow a faster pace.
I am really worried about the lack of interest in defining exacly at least
the behaviour of most used frameworks, first of all the wrb
applications/servlet world

I am happy that the maven world will make it easy to switch from java8 to
java9 ad far as we can. Maybe most of developers which are using maven will
not see all the tricks under the hood

Thank you


Enrico


> I understand that development parties of application servers and libraries
> suppliers are slow but this still would not guarantee that there is no risk
> that Jigsaw project made some mistake which (if happens) cannot be taken
> back after the final release of JSE9.
>
>
>
> On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli 
> wrote:
>
> > Il lun 14 ago 2017, 11:46 Tibor Digana  ha
> > scritto:
> >
> > > Hello Enrico,
> > >
> > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx
> in
> > > advance.
> > >
> >
> > I will check as soon as I wil be back from vacation. Thank you very much.
> > For me it is very important
> >
> > >
> > > I have added integration tests for Failsafe plugin, added
> documentation "
> > > java9.md" and removed JAXB which is located in module
> > *javax.xml.binding*.
> > >
> > > *Here is a clarification on why I was unhappy with Java status and why
> > > Surefire project could not run with Java 9 and how it was fixed:*
> > >
> > > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > > Java9.
> > > Reason is that module *javax.xml.binding* is however in Java API but
> not
> > > propagated on classpath when running Maven process (different situation
> > in
> > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > This is strange and will be strange for most people, for instance in
> our
> > > *Java
> > > EE project using REST* the WildFly server has to use *"--add-modules
> > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > As a solution in Surefire project I removed JAXB which was simple XML
> in
> > my
> > > case but not simple in general.
> > >
> >
> > I will have to do it for several projects, or at leastleast to add
> > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > default, that is weird to me
> >
> > >
> > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > modularity".
> > > But there are reasons where you will use it.
> > > For instance new API in Java or Java EE 9 in the future.
> > >
> >
> > The main reason for migration is to keep up to date, java8 will soon
> reach
> > EOL.
> > Java9 comes with many improvements that just upgrading will speed up most
> > applications, just think about nee compat strings. New API are great and
> > were expected from long time ago, like the new Process API
> >
> >
> > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> principle.
> > >
> >
> > Yep, new applications will be more fine tuned, the problem here is only
> for
> > the migration
> >
> > As a workaround to this in Maven would be to develop *smart
> > > maven-compiler-plugin* which automatically generates
> *module-info.class*
> > > upon import sections in Java classes and Maven dependencies.
> > > Not easy I guess.
> > >
> >
> > I think this will be not feasible in general and very dangerous and
> maybe I
> > hope maven will never do such things
> >
> > Cheers
> > Enrico
> >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli  >
> > > wrote:
> > >
> > > > Il dom 13 ago 2017, 17:31 Tibor Digana 
> > ha
> > > > scritto:
> > > >
> > > > > I found an issue. JDK printed this on std/out:
> > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > >
> > > > > It hapens after my test:
> > > > >
> > > > > import org.junit.Test;
> > > > >
> > > > > public class J9Test
> > > > > {
> > > > > @Test
> > > > > public void testMiscellaneousAPI() 

Re: [JAVA 9] Need for review of branch SUREFIRE-1403

[Enrico Olivelli]

Il mar 15 ago 2017, 14:25 Tibor Digana  ha
scritto:

> Ok guys, I am glad too that you are satisfied, so I will push the branch to
> master, and thank you very much for working with me.
> Enrico, I know that you are on vacation right now but I would like to
> kindly ask you to join us on IRC channel, maybe after your vacation.
>
Can you give me the address? I can use my phone. Today I am at home and I
had the opportunity to use my laptop

Enrico

Thx.
>
> On Tue, Aug 15, 2017 at 2:07 PM, Enrico Olivelli 
> wrote:
>
> > +1 for me
> > I have checked out branch SUREFIRE-1403 and I was able to run tests of an
> > application which uses java.sql.Timestamp without changes in code, just
> but
> > upgrading surefire to 21.1-SNAPSHOT
> >
> > Unfortunately I do not use the failsafe plugin so I have to real world
> > project to test
> >
> > I did a brief review on code and it looks good to me
> >
> >
> > Thank you very much Tibor
> >
> > -- Enrico
> >
> >
> > 2017-08-15 0:12 GMT+02:00 Robert Scholte :
> >
> > > +1
> > >
> > > This is looking good.
> > >
> > > Robert
> > >
> > > On Mon, 14 Aug 2017 20:34:11 +0200, Tibor Digana <
> > > tibor.dig...@googlemail.com> wrote:
> > >
> > > Hi devs,
> > >>
> > >> I would like to push the branch and Jira ticket *SUREFIRE-1403* which
> > >> enables Surefire and Failsafe on Java 9.
> > >>
> > >> If you have a little spare time pls start review.
> > >>
> > >> Thx.
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>
-- 


-- Enrico Olivelli

Re: [JAVA 9] Need for review of branch SUREFIRE-1403

[Tibor Digana]

Ok guys, I am glad too that you are satisfied, so I will push the branch to
master, and thank you very much for working with me.
Enrico, I know that you are on vacation right now but I would like to
kindly ask you to join us on IRC channel, maybe after your vacation.
Thx.

On Tue, Aug 15, 2017 at 2:07 PM, Enrico Olivelli 
wrote:

> +1 for me
> I have checked out branch SUREFIRE-1403 and I was able to run tests of an
> application which uses java.sql.Timestamp without changes in code, just but
> upgrading surefire to 21.1-SNAPSHOT
>
> Unfortunately I do not use the failsafe plugin so I have to real world
> project to test
>
> I did a brief review on code and it looks good to me
>
>
> Thank you very much Tibor
>
> -- Enrico
>
>
> 2017-08-15 0:12 GMT+02:00 Robert Scholte :
>
> > +1
> >
> > This is looking good.
> >
> > Robert
> >
> > On Mon, 14 Aug 2017 20:34:11 +0200, Tibor Digana <
> > tibor.dig...@googlemail.com> wrote:
> >
> > Hi devs,
> >>
> >> I would like to push the branch and Jira ticket *SUREFIRE-1403* which
> >> enables Surefire and Failsafe on Java 9.
> >>
> >> If you have a little spare time pls start review.
> >>
> >> Thx.
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
Cheers
Tibor

Re: [JAVA 9] Need for review of branch SUREFIRE-1403

[Enrico Olivelli]

+1 for me
I have checked out branch SUREFIRE-1403 and I was able to run tests of an
application which uses java.sql.Timestamp without changes in code, just but
upgrading surefire to 21.1-SNAPSHOT

Unfortunately I do not use the failsafe plugin so I have to real world
project to test

I did a brief review on code and it looks good to me


Thank you very much Tibor

-- Enrico


2017-08-15 0:12 GMT+02:00 Robert Scholte :

> +1
>
> This is looking good.
>
> Robert
>
> On Mon, 14 Aug 2017 20:34:11 +0200, Tibor Digana <
> tibor.dig...@googlemail.com> wrote:
>
> Hi devs,
>>
>> I would like to push the branch and Jira ticket *SUREFIRE-1403* which
>> enables Surefire and Failsafe on Java 9.
>>
>> If you have a little spare time pls start review.
>>
>> Thx.
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>