Re: main-class + module-version

2017-08-28 Thread Plamen Totev
Hi Robert,

Thank you for you comments.

>> Also I took a look at the changes in the JDK jar tool and I notice a
>> couple of things that it does:
>>
>> 1. The structure of the jar produced is such that the module info
>> entries are placed after the manifest and before the rest of the
>> files. Plexus Archiver does not handle  the module info entries
>> differently and they are placed in random order among the rest of the
>> files.
>
>
> IIRC Plexus Archiver is already capable to put the manifest file up front.
> The same should be possible with the module descriptor.

I double checked the changes in the Jar File Specifications [1] and
there are no requirements specifying where the module-info.class entry
should be located in regard to the rest of the entries(I mean
physically in the file). So I consider this behavior implementation
specific.

> I think we need to focus on version and mainClass first, that's probably the
> first things users will ask and which is really visible to them. If the
> extra checks are not required I consider them as nice to have checks and
> pick them up later.

Makes sense. I created issues for them as well so we don't forget them.[2][3][4]

Regarding the implementation. Unfortunately as you mention it will
require adjusting the byte code of the module-info.class. And I don't
have knowledge in the matter so I'll need help with that. Also I was
thinking that maybe such functionality(adding/replacing  information
to the ModuleDescriptor) is good fit for the newly introduced
plexus-languages project?

Regards,
Plamen Totev

[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/jar.html
[2] https://github.com/codehaus-plexus/plexus-archiver/issues/67
[3] https://github.com/codehaus-plexus/plexus-archiver/issues/68
[4] https://github.com/codehaus-plexus/plexus-archiver/issues/69

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



[GitHub] maven-surefire issue #161: SUREFIRE-1396: Provider class path is incorrect f...

2017-08-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/161
  
@jon-bell 
Thx for contributing.


---
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-surefire pull request #161: SUREFIRE-1396: Provider class path is inco...

2017-08-28 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/maven-surefire/pull/161


---
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-surefire issue #161: SUREFIRE-1396: Provider class path is incorrect f...

2017-08-28 Thread jon-bell
Github user jon-bell commented on the issue:

https://github.com/apache/maven-surefire/pull/161
  
@Tibor17 I have rebased master on top of my branch, it is again up to date.


---
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-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

2017-08-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/157
  
@JoelNGeorge 
@owenfarrell 
Pls let me run the build and next steps.


---
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-surefire issue #159: SUREFIRE-1391: Eliminate redundant call in calcul...

2017-08-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/159
  
@andrew-j-cohen 
Please close this PR. It was already merged in Surefire project.


---
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: [GitHub] maven-surefire issue #161: SUREFIRE-1396: Provider class path is incorrect f...

2017-08-28 Thread Tibor Digana
Check your branch if it is up to date with master.

On Mon, Aug 28, 2017 at 11:51 PM, Tibor17  wrote:

> Github user Tibor17 commented on the issue:
>
> https://github.com/apache/maven-surefire/pull/161
>
> @jon-bell
> Ok, now your IT passed. I will run whole test set now.
>
>
> ---
> 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
>
>


-- 
Cheers
Tibor


[GitHub] maven-surefire issue #161: SUREFIRE-1396: Provider class path is incorrect f...

2017-08-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/161
  
@jon-bell 
Ok, now your IT passed. I will run whole test set now.


---
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-surefire issue #162: SUREFIRE-1384: ProviderInfo for JUnit Plattform (...

2017-08-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/162
  
@britter 
Done. I added enforcer configuration. I hope it will be fine.
Let me know if you have something to do for me.
Sometimes I am without internet connection for several days or I am 
connected a half day or so.


---
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-surefire pull request #162: SUREFIRE-1384: ProviderInfo for JUnit Plat...

2017-08-28 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/maven-surefire/pull/162


---
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 #113: [MNG-6127] Fix plugin execution configuration interference

2017-08-28 Thread mkrizmanic
Github user mkrizmanic commented on the issue:

https://github.com/apache/maven/pull/113
  
Merged to master: 
https://github.com/apache/maven/commit/f1ed6592b1c701834d1377fade6cdb382a63bbf4


---
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 #113: [MNG-6127] Fix plugin execution configuration inter...

2017-08-28 Thread mkrizmanic
Github user mkrizmanic closed the pull request at:

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


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



Code review on SUREFIRE-1264_2

2017-08-28 Thread Tibor Digana
Hi All,

I have pushed branch SUREFIRE-1264_2 which is bug fix for
Jira SUREFIRE-1264.
I have announced our user on Jira and asked him to test this fix in his
project.

-- 
Cheers
Tibor


Re: [GitHub] maven-surefire issue #162: SUREFIRE-1384: ProviderInfo for JUnit Plattform (...

2017-08-28 Thread Tibor Digana
I will have a look.

On Mon, Aug 28, 2017 at 8:49 PM, britter  wrote:

> Github user britter commented on the issue:
>
> https://github.com/apache/maven-surefire/pull/162
>
> @Tibor17 any news on this?
>
>
> ---
> 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
>
>


-- 
Cheers
Tibor


[GitHub] maven-surefire issue #162: SUREFIRE-1384: ProviderInfo for JUnit Plattform (...

2017-08-28 Thread britter
Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/162
  
@Tibor17 any news on this?


---
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: maven-jdeps-plugin and JDK9 - no love :(

2017-08-28 Thread Robert Scholte

My bad, I thought it was was the 23rd plugin to update.
This is an easy fix.
Should be able to do a release this week.

Robert

On Mon, 28 Aug 2017 13:13:03 +0200, Mark Derricutt  wrote:



On 28 Aug 2017, at 22:07, Robert Scholte wrote:


Can you share these 23? Maybe worth sharing at  
https://s.apache.org/maven-j9


Ack - I was meaning to write 23 DAYS on the countdown ( at  
http://www.java9countdown.xyz/ )


Mark

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


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

Re: maven-jdeps-plugin and JDK9 - no love :(

2017-08-28 Thread Mark Derricutt
On 28 Aug 2017, at 22:07, Robert Scholte wrote:

> Can you share these 23? Maybe worth sharing at 

Ack - I was meaning to write 23 DAYS on the countdown ( at 
http://www.java9countdown.xyz/ )

Mark


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

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


signature.asc
Description: OpenPGP digital signature


Re: maven-jdeps-plugin and JDK9 - no love :(

2017-08-28 Thread Robert Scholte

On Mon, 28 Aug 2017 09:03:40 +0200, Mark Derricutt  wrote:



On 28 Aug 2017, at 18:11, Enrico Olivelli wrote:


Mark,
IMHO It seems just a 'well known' problem of commons lang. Maybe just
updating the dependency for the plugin in your pom may help.


Sweet that worked - will go raise a ticket about it so we can get a PR  
made and another release...


23 on the countdown to Java 9 :)


Can you share these 23? Maybe worth sharing at  
https://s.apache.org/maven-j9


Robert


Mark

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


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

Re: main-class + module-version

2017-08-28 Thread Robert Scholte
On Mon, 28 Aug 2017 07:32:36 +0200, Plamen Totev  
 wrote:



Hi,

On Fri, Aug 25, 2017 at 6:57 PM, Robert Scholte   
wrote:
I'm having a look at the JarArchiver of the plexus-archiver project as  
used

by maven-jar-plugin.
This archiver does some MANIFEST and index stuff already, so it kind of
makes sense to add the module-descriptor logic here as well.


I think it is a good idea to make Plexus Archiver module aware. I can
help you with it if you want.


All help is appreciated, Java 9 came with quite some extra work for us.



Also I took a look at the changes in the JDK jar tool and I notice a
couple of things that it does:

1. The structure of the jar produced is such that the module info
entries are placed after the manifest and before the rest of the
files. Plexus Archiver does not handle  the module info entries
differently and they are placed in random order among the rest of the
files.


IIRC Plexus Archiver is already capable to put the manifest file up front.  
The same should be possible with the module descriptor.



2. It adds/replaces some additional information to the module
description such as the list of packages it contains, the hashes of
the modules, module version, main class.


seems like an Archive needs to get a module(descriptor?) next to the  
manifest when there are so much extra options



3. There is verification that the module descriptor is consistent -
exported/opened/provided  packages/classes are actually presented in
the jar file.


 See #2


I have to double check which of those are part of the specification
and which are OpenJdk specific. In any case it sounds like a good idea
to have some verification (3.) and to update the packages field with
the packages that are actually packaged. The module hashes seem to be
OpenJdk specific but they do sound like a nice feature. Maybe we
should do some(or all) of the above thing as well, what do you think?



I think we need to focus on version and mainClass first, that's probably  
the first things users will ask and which is really visible to them. If  
the extra checks are not required I consider them as nice to have checks  
and pick them up later.



The points above convince we even more that the Plexus Archiver should
be module aware and the component to verify/modify the module
descriptors.

BTW what do you think - should we have a new class ModuleJarArchiver
that extends JarArchiver or just to modify JarArchiver. There is no
new packaging type and from this POV it does sounds logical to just
modify the JarArchiver. But on other hand it is extended by
WarArchiver & co so they'll become module aware as well. Not
completely sure if that is ok. I guess they should be ok as they do
not contain any code(modules or not) in their root folder, right? Or I
am wrong?


I think so. Otherwise we'll have to add an abstraction layer.



Regards,
Plamen Totev

-
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: maven-jdeps-plugin and JDK9 - no love :(

2017-08-28 Thread Mark Derricutt
On 28 Aug 2017, at 18:11, Enrico Olivelli wrote:

> Mark,
> IMHO It seems just a 'well known' problem of commons lang. Maybe just
> updating the dependency for the plugin in your pom may help.

Sweet that worked - will go raise a ticket about it so we can get a PR made and 
another release...

23 on the countdown to Java 9 :)

Mark


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

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


signature.asc
Description: OpenPGP digital signature


Re: maven-jdeps-plugin and JDK9 - no love :(

2017-08-28 Thread Enrico Olivelli
On lun 28 ago 2017, 07:49 Mark Derricutt  wrote:

> Hey all,
>
> Now that there's versions of enforcer/javadoc and co that work with java
> 9, and error-prone now seems to work with java 9 - my builds have gotten as
> far as running jdeps, which appears to not like java 9 at all :(
>
> .smxemail.tiles.enforcements:3.0.70::default of goal 
> org.apache.maven.plugins:maven-jdeps-plugin:3.0.0:jdkinternals failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-jdeps-plugin:3.0.0:jdkinternals: 
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/amrk/.m2/repository/org/apache/maven/plugins/maven-jdeps-plugin/3.0.0/maven-jdeps-plugin-3.0.0.jar
> [ERROR] urls[1] = 
> file:/Users/amrk/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> [ERROR] urls[2] = 
> file:/Users/amrk/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> [ERROR] urls[3] = 
> file:/Users/amrk/.m2/repository/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar
> [ERROR] urls[4] = 
> file:/Users/amrk/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[5] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> [ERROR] urls[6] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[7] = 
> file:/Users/amrk/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[8] = 
> file:/Users/amrk/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[9] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.21/plexus-utils-3.0.21.jar
> [ERROR] urls[10] = 
> file:/Users/amrk/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import  from realm 
> ClassRealm[project>com.smxemail:com.smxemail.api:21.0.4-SNAPSHOT, parent: 
> ClassRealm[maven.api, parent: null]]]
> [ERROR]
> [ERROR] -
> [ERROR] : begin 0, end 3, length 1
>
> Running with -e yields:
>
> Caused by: org.apache.maven.plugin.PluginContainerException: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-jdeps-plugin:3.0.0:jdkinternals: 
> java.lang.ExceptionInInitializerError: null
> -
> realm =plugin>org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] = 
> file:/Users/amrk/.m2/repository/org/apache/maven/plugins/maven-jdeps-plugin/3.0.0/maven-jdeps-plugin-3.0.0.jar
> urls[1] = 
> file:/Users/amrk/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> urls[2] = 
> file:/Users/amrk/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> urls[3] = 
> file:/Users/amrk/.m2/repository/org/apache/maven/maven-aether-provider/3.0/maven-aether-provider-3.0.jar
> urls[4] = 
> file:/Users/amrk/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> urls[5] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> urls[6] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> urls[7] = 
> file:/Users/amrk/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> urls[8] = 
> file:/Users/amrk/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> urls[9] = 
> file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.21/plexus-utils-3.0.21.jar
> urls[10] = 
> file:/Users/amrk/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> Number of foreign imports: 1
> import: Entry[import  from realm 
> ClassRealm[project>com.smxemail:com.smxemail.api:21.0.4-SNAPSHOT, parent: 
> ClassRealm[maven.api, parent: null]]]
>
> -
>
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:181)
> ... 21 more
> Caused by: java.lang.ExceptionInInitializerError
> at 
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.getJDepsExecutable(AbstractJDepsMojo.java:359)
> at 
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.execute(AbstractJDepsMojo.java:196)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
>