[ANN] Apache Maven Assembly Plugin Version 3.2.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Assembly Plugin Version 3.1.0

The Assembly Plugin for Maven is primarily intended to allow users to aggregate
the project output along with its dependencies, modules, site documentation,
and other files into a single distributable archive.
 
https://maven.apache.org/plugins/maven-assembly-plugin/

Important Note since 3.1.0:

 * Maven 3.X only
 * JDK 7 minimum requirement

You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-assembly-plugin
  3.1.0


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-assembly-plugin/download.cgi
 
Release Notes Maven Assembly Plugin 3.1.0

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12338667

Bugs:

 * [MASSEMBLY-643] - descriptorSourceDirectory: parameter isn't used
 * [MASSEMBLY-841] - Maven Assembly Plugin throws IllegalStateException when 
looking for project modules
 * [MASSEMBLY-842] - Incorrect entries created in MANIFEST/maven
 * [MASSEMBLY-855] - Remote repositories ignored in a multi-module project

Dependency upgrades:

 * [MASSEMBLY-854] - Upgrade to Plexus Archiver 3.5
 * [MASSEMBLY-859] - Upgrade to Plexus IO 3.0.0
 * [MASSEMBLY-867] - Upgrade maven-archiver to 3.2.0
 * [MASSEMBLY-868] - Upgrade plexus-utils to version 3.1.0

Improvements:

 * [MASSEMBLY-711] - Add support for generating XZ compressed tarballs (.tar.xz)
 * [MASSEMBLY-858] - don't read assembly descriptor from thread classloader but 
plugin classloader
 * [MASSEMBLY-860] - Upgrade to Java 7

Thanks to the volunteer(s) who helped to check this release.

 o Grzegorz Grzybek

Enjoy,
 
-The Apache Maven team

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

[GitHub] maven-shared pull request #22: Add color support auto detection in MessageUt...

[mryan43]

Github user mryan43 closed the pull request at:

https://github.com/apache/maven-shared/pull/22


---
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 pull request #114: MNG-6220 add color CLI option

[mryan43]

Github user mryan43 closed the pull request at:

https://github.com/apache/maven/pull/114


---
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 issue #114: MNG-6220 add color CLI option

[mryan43]

Github user mryan43 commented on the issue:

https://github.com/apache/maven/pull/114
  
Great thanks @rfscholte ! 


---
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 issue #114: MNG-6220 add color CLI option

[agudian]

Github user agudian commented on the issue:

https://github.com/apache/maven/pull/114
  
@rfscholte: looks good! 👍


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

[RESULT] [VOTE] Release Apache Maven Assembly Plugin version 3.1.0

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Grzegorz Grzybek, Stephane Nicoll, Tibor Digana, 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 Assembly Plugin version 3.1.0

[Karl Heinz Marbaise]

Hi,

here is my +1.

Kind regards
Karl Heinz Marbaise
On 13/08/17 14:18, Karl Heinz Marbaise wrote:

Hi,

We solved 10 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=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-1354/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


-
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

[Karl Heinz Marbaise]

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

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

[Tibor Digana]

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

Re: Building a Java9 project just using JDK9

[Tibor Digana]

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

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

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