date:20170814

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

2017-08-14 Thread Tibor Digana

+1

On Sun, Aug 13, 2017 at 5:02 PM, 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
>
>


-- 
Cheers
Tibor

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

2017-08-14 Thread Robert Scholte


+1

This is looking good.

Robert

On Mon, 14 Aug 2017 20:34:11 +0200, Tibor Digana  
 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

Re: Building a Java9 project just using JDK9

2017-08-14 Thread Tibor Digana

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?

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() 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

Re: Building a Java9 project just using JDK9

2017-08-14 Thread Enrico Olivelli

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() 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 <
> > tibor.dig...@googlemail.com
> > > >
> > > 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 <
> garydgreg...@gmail.com>
> > > > 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.
> > >
> >
> > Tibor, thank you very much for your time and your effort.
> > I think that we should have chimed in long time before the approval of
> > those decisions on the jre. Now the game is over, we can only

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

2017-08-14 Thread Tibor Digana

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.

-- 
Cheers
Tibor

Re: Building a Java9 project just using JDK9

2017-08-14 Thread Tibor Digana

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

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.

I do not think that using *"--add-modules ALL-SYSTEM"* is good principle.
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.


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() 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 <
> tibor.dig...@googlemail.com
> > >
> > 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.
> >
>
> Tibor, thank you very much for your time and your effort.
> I think that we should have chimed in long time before the approval of
> those decisions on the jre. Now the game is over, we can only decide how
> maven users will deal with running classpath based applications on java9.
> I see two approaches:
> 1) add a lot of tricks in every base maven plugin and make it very easy to
> transition
> 2) leave the complexity to developers who will add a lot of profiles and
> hacks to detect java9
>
> My personal feeling is that I am very disappointed by the fact the few
> developers diffs not report this issues to the maven community long time
> ago. I think that the java9 adoption has not been taken into account by
> most developers and this will be an huge pain for the java community.
> I hope that Maven will help the java world to go on and to step over this
> painful transition
>
> I will test your patch as soon as I can
> Cheers
> Enrico
>
> >> > 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

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

2017-08-14 Thread Tibor Digana

+1

On Sun, Aug 13, 2017 at 2:18 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12317220=12338667
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 20MASSEMBLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1354
>
> https://repository.apache.org/content/repositories/maven-135
> 4/org/apache/maven/plugins/maven-assembly-plugin/3.1.0/maven
> -assembly-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-assembly-plugin-3.1.0-source-release.zip sha1:
> 9d42c075686b216590c438f329f86e2833c0ff6c
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-assembly-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
>
>

Re: Building a Java9 project just using JDK9

2017-08-14 Thread 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
>
> 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.
>

Tibor, thank you very much for your time and your effort.
I think that we should have chimed in long time before the approval of
those decisions on the jre. Now the game is over, we can only decide how
maven users will deal with running classpath based applications on java9.
I see two approaches:
1) add a lot of tricks in every base maven plugin and make it very easy to
transition
2) leave the complexity to developers who will add a lot of profiles and
hacks to detect java9

My personal feeling is that I am very disappointed by the fact the few
developers diffs not report this issues to the maven community long time
ago. I think that the java9 adoption has not been taken into account by
most developers and this will be an huge pain for the java community.
I hope that Maven will help the java world to go on and to step over this
painful transition

I will test your patch as soon as I can
Cheers
Enrico

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

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

2017-08-14 Thread Stephane Nicoll

+1 tested with various projects (including the regression that was
affecting Spring Boot).

Thanks!

On Sun, Aug 13, 2017 at 2:18 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12317220=12338667
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 20MASSEMBLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1354
>
> https://repository.apache.org/content/repositories/maven-135
> 4/org/apache/maven/plugins/maven-assembly-plugin/3.1.0/maven
> -assembly-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-assembly-plugin-3.1.0-source-release.zip sha1:
> 9d42c075686b216590c438f329f86e2833c0ff6c
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-assembly-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
>
>

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

2017-08-14 Thread Grzegorz Grzybek

Hello

I checked with JBoss Fuse and Fabric8 v1.
+1 (non-binding)

regards
Grzegorz Grzybek

2017-08-13 14:18 GMT+02:00 Karl Heinz Marbaise :

> Hi,
>
> We solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12317220=12338667
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 20MASSEMBLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1354
>
> https://repository.apache.org/content/repositories/maven-135
> 4/org/apache/maven/plugins/maven-assembly-plugin/3.1.0/maven
> -assembly-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-assembly-plugin-3.1.0-source-release.zip sha1:
> 9d42c075686b216590c438f329f86e2833c0ff6c
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-assembly-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
>
>

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

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

Re: Building a Java9 project just using JDK9

Re: Building a Java9 project just using JDK9

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

Re: Building a Java9 project just using JDK9

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

Re: Building a Java9 project just using JDK9

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

10 matches

Site Navigation

Mail list logo

Footer information