from:"Stephen Colebourne \(JIRA\)"

[jira] [Commented] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments

2020-02-26 Thread Stephen Colebourne (Jira)



[ 
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045358#comment-17045358
 ] 

Stephen Colebourne commented on MJAVADOC-481:
-

Yes

> Java 1.8.0_u121 allow-script-in-comments
> 
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In its infinite wisdom, Oracle added a new command line flag in the standard 
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
> script tags in headers and footers. An example use for these would be to add 
> Google Analytics to the footer of each page of Javadoc. For example [see 
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>  
> The rejection of scripts can be turned off using "--allow-script-in-comments" 
> (note the double hyphen). The new flag can only be added to javadoc in 
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on 
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Sadly, this does not work:
> {code}
> 
>   
> [1.8.0.121,]
>   
>   
>   --allow-script-in-comments
>   
> 
> {code}
> As such, this needs to be exposed as a flag in Maven to provide a way to 
> create a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes: 
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments

2020-02-26 Thread Stephen Colebourne (Jira)



[ 
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045339#comment-17045339
 ] 

Stephen Colebourne commented on MJAVADOC-481:
-

I'm quite sure there are developers out there still using Java 8 pre u121!

At this point I'd prefer to see a change to profiles, because there seem to be 
more flags getting added in update releases than previously, and Maven can't 
handle that in general (this is just one speific example).

> Java 1.8.0_u121 allow-script-in-comments
> 
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In its infinite wisdom, Oracle added a new command line flag in the standard 
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
> script tags in headers and footers. An example use for these would be to add 
> Google Analytics to the footer of each page of Javadoc. For example [see 
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>  
> The rejection of scripts can be turned off using "--allow-script-in-comments" 
> (note the double hyphen). The new flag can only be added to javadoc in 
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on 
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Sadly, this does not work:
> {code}
> 
>   
> [1.8.0.121,]
>   
>   
>   --allow-script-in-comments
>   
> 
> {code}
> As such, this needs to be exposed as a flag in Maven to provide a way to 
> create a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes: 
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments

2020-02-26 Thread Stephen Colebourne (Jira)



[ 
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045330#comment-17045330
 ] 

Stephen Colebourne commented on MJAVADOC-481:
-

Java 8 is still in widespread use. And an open source project cannot guarantee 
what Java 8 version its users will use.

[https://github.com/OpenGamma/Strata/blob/master/modules/pom.xml#L108]

Fixing the more general issue of profiles with update versions of Java might be 
a more useful fix as it would provide a solution or other similar issues 
introduced in update releases.

> Java 1.8.0_u121 allow-script-in-comments
> 
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In its infinite wisdom, Oracle added a new command line flag in the standard 
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
> script tags in headers and footers. An example use for these would be to add 
> Google Analytics to the footer of each page of Javadoc. For example [see 
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>  
> The rejection of scripts can be turned off using "--allow-script-in-comments" 
> (note the double hyphen). The new flag can only be added to javadoc in 
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on 
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Sadly, this does not work:
> {code}
> 
>   
> [1.8.0.121,]
>   
>   
>   --allow-script-in-comments
>   
> 
> {code}
> As such, this needs to be exposed as a flag in Maven to provide a way to 
> create a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes: 
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"

2019-12-30 Thread Stephen Colebourne (Jira)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005851#comment-17005851
 ] 

Stephen Colebourne commented on SUREFIRE-1563:
--

I've read this thread and others a number of times, and I'm still not sure why 
this wasn't a relatively easy fix for surefire to automatically add 
`--add-modules=` whenever `required static` is seen. 

In the absence of that, the `module-info.test` file is a practical solution to 
this and many other issues. A format is [in use 
elsewhere|[https://github.com/java9-modularity/gradle-modules-plugin#how-does-it-work]],
 and as a simple text file it would not need any special processing by IDEs or 
maven if it was located in `src/test/module` for example.

The last comment suggests using a configuration block with 
`` which would also work I guess.

Really, the key problem is that users are forced to learn the low level 
`add-modules` and `add-opens` commands for what should be straightforward 
testing tasks once a `module-info.java` is added. If this can't be solved, 
maybe Maven/Surefire should default to testing in classpath mode even when a 
`module-info.java` is present. Getting the default configuration to "just work" 
should be the first priority IMO.

 

> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires 
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for 
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the 
> tests run fine.
> Attached a reproducible project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

2019-11-24 Thread Stephen Colebourne (Jira)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981192#comment-16981192
 ] 

Stephen Colebourne commented on SUREFIRE-1497:
--

[~tibordigana]True, the flag does work. However, 
https://issues.apache.org/jira/browse/SUREFIRE-1563 is still not tackled AFAIK, 
so its still a pain to use Maven to test most of my projects. 

Should this issue be closed then?

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>  Labels: jigsaw
> Attachments: maven-issue4.zip
>
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MCHANGES-393) Default for teamlist is wrong

2018-08-20 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/MCHANGES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16586039#comment-16586039
 ] 

Stephen Colebourne commented on MCHANGES-393:
-

The title of this issue could be clearer. Maybe "Broken links for team members 
on changes report".

> Default for teamlist is wrong
> -
>
> Key: MCHANGES-393
> URL: https://issues.apache.org/jira/browse/MCHANGES-393
> Project: Maven Changes Plugin
>  Issue Type: Bug
>  Components: changes.xml
>Reporter: Joerg Schaible
>Priority: Major
>
> It seems at some stage the PIR changed the name for the page generated for 
> the team list. At least with current PIR 3.0.0 generates a page _team.html_ 
> and the current changes report has broken links for the devs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSITE-827) Site builds rely on HTTP 404

2018-08-18 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-827:


 Summary: Site builds rely on HTTP 404
 Key: MSITE-827
 URL: https://issues.apache.org/jira/browse/MSITE-827
 Project: Maven Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 3.7.1
Reporter: Stephen Colebourne


If the _pom.xml_ that is being built has a parent that is stored in a remote 
repository, then the site plugin (or some other part of the site-building 
process) will try to find two files alongside the parent pom - _site_en.xml_ 
and _site.xml_.

Since these files are being fetched from a remote repository, there is the 
potential for network issues, and I've seen cases where builds fail 
semi-randomly as well as consistently. The key problem seems to be that the 
child build relies on getting *404 for both files* from the remote repository 
before it can continue. This can be a bigger problem if there are multiple 
remote repositories, as *all repositories must return 404 for both files* 
before the child build can continue.

The Maven recommendation is to use _site:attach-descriptor_ in the parent build 
to publish _site.xml_ in cases like this. However, *this is insufficient*, as 
_site:attach-descriptor_ only publishes _site.xml_ and not _site_en.xml_, so 
the client build still relies on getting 404 on _site_en.xml_ in order to be 
able to continue.

As per this [answer|https://stackoverflow.com/a/51912311/38896], there is a 
hacky workaround to allow both _site_en.xml_ and _site.xml_ to be published 
from the parent project by mis-using the locales configuration. Once *both* 
files are published, the client build no longer needs to rely on HTTP 404 as it 
finds both files it is looking for.

Given how everything works today, I suspect that the client build is going to 
have to continue to use HTTP 404, as making it more tolerant could mask errors. 
Unless there is some way to provide a config flag in the site plugin of the 
child build.

I suspect that the only way to tackle this issue will be to make 
_site:attach-descriptor_ publish both _site_en.xml_ and _site.xml_ by default 
(without the need for hacky locales config).

See also MSITE-639 which provides more info.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSITE-639) sub-project tries to fetch a site_en.xml even though no locales are configured

2018-08-18 Thread Stephen Colebourne (JIRA)

[
https://issues.apache.org/jira/browse/MSITE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584858#comment-16584858
]

Stephen Colebourne edited comment on MSITE-639 at 8/18/18 6:22 PM:
---

I can't reopen this (as I don't have permission), but I believe it is still a
problem with the latest plugins. However it is transient - it does not happen
every time. I haven't tried the projects above, but can point you at Joda-Money
for example. [https://github.com/JodaOrg/joda-money] as of the 18th August.

I suspect that it does not always fail the first time as the failure is due to
network issues of some kind, such as Maven Central being flaky. This is
particularly a problem if multiple repos are being queried. Without
investigating further, my gut feeling is that the code only determines that the
file is missing if _all_ the remote repos say its not there. Thus if one repo
is slow, or returns something other than 404 (eg. a security access failure)

I've seen the problem on Java 8, 9 and 10 builds on Travis. For example, I
pushed three separate Joda projects in the last hour which performed 9 builds
on Travis - with two Java 9 failures and one Java 10. ie. the same commit in
the same Travis build failing on 10 but working on 9 and vice versa). My next
set of 9 builds saw 4 fail and 5 succeed.

This is the section of the build in my case when it succeeds, as can be seen it
queries multiple repos:
{noformat}
[INFO] Done SpotBugs Analysis [INFO] Rendering site with default locale
English (en) [INFO] Downloading from sonatype:
https://oss.sonatype.org/content/repositories/releases/org/joda/joda-parent/1.3/joda-parent-1.3-site_en.xml
[INFO] Downloading from sonatype-apache:
https://repository.apache.org/releases/org/joda/joda-parent/1.3/joda-parent-1.3-site_en.xml
[INFO] Downloading from central:
http://repo.maven.apache.org/maven2/org/joda/joda-parent/1.3/joda-parent-1.3-site.xml
[INFO] Downloaded from central:
http://repo.maven.apache.org/maven2/org/joda/joda-parent/1.3/joda-parent-1.3-site.xml
(87 B at 4.1 kB/s) [INFO] Relativizing decoration links with respect to
localized project URL: http://www.joda.org/joda-beans/{noformat}
Note that until these most recent builds, my parent project had no `site.xml`.
The purpose of my change today was to publish site.xml using
site:attach-descriptor to avoid this problem. However, since it is still
looking for site_en.xml which is not published, I still get the error, which is
a pain.

For the logs produced when it fails, see here:
[https://travis-ci.org/JodaOrg/joda-convert/jobs/417679434] As can be seen, the
"connection timed out", but the real question is why is it trying to query the
_en file in the first place?

PS. When both site_en.xml and site.xml are present, mvn site:attach-descriptor
only attaches the _en variant! But there is a workaround - declare
configuration in site:attach-descriptor of en,de (de chosen
at random). This causes both files to get uploaded, which avoids the need for
Maven to rely on HTTP 404.

was (Author: scolebou...@joda.org):
I can't reopen this (as I don't have permission), but I believe it is still a
problem with the latest plugins. However it is transient - it does not happen
every time. I haven't tried the projects above, but can point you at Joda-Money
for example. [https://github.com/JodaOrg/joda-money] as of the 18th August.

[jira] [Comment Edited] (MSITE-639) sub-project tries to fetch a site_en.xml even though no locales are configured

2018-08-18 Thread Stephen Colebourne (JIRA)

[
https://issues.apache.org/jira/browse/MSITE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584858#comment-16584858
]

Stephen Colebourne edited comment on MSITE-639 at 8/18/18 5:55 PM:
---

PS. When both site_en.xml and site.xml are present, mvn site:attach-descriptor
only attaches the _en variant!

[jira] [Commented] (MSITE-639) sub-project tries to fetch a site_en.xml even though no locales are configured

2018-08-18 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/MSITE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584858#comment-16584858
 ] 

Stephen Colebourne commented on MSITE-639:
--

I can't reopen this (as I don't have permission), but I believe it is still a 
problem with the latest plugins. However it is transient - it does not happen 
every time. I haven't tried the projects above, but can point you at Joda-Money 
for example. [https://github.com/JodaOrg/joda-money] as of the 18th August.

I suspect that it does not always fail the first time as the failure is due to 
network issues of some kind, such as Maven Central being flaky. This is 
particularly a problem if multiple repos are being queried. Without 
investigating further, my gut feeling is that the code only determines that the 
file is missing if  _all_ the remote repos say its not there. Thus if one repo 
is slow, or returns something other than 404 (eg. a security access failure)

I've seen the problem on Java 8, 9 and 10 builds on Travis. For example, I 
pushed three separate Joda projects in the last hour which performed 9 builds 
on Travis - with two Java 9 failures and one Java 10. ie. the same commit in 
the same Travis build failing on 10 but working on 9 and vice versa). My next 
set of 9 builds saw 4 fail and 5 succeed.

This is the section of the build in my case when it succeeds, as can be seen it 
queries multiple repos:
 
{noformat}
[INFO] Done SpotBugs Analysis [INFO] Rendering site with default locale 
English (en) [INFO] Downloading from sonatype: 
https://oss.sonatype.org/content/repositories/releases/org/joda/joda-parent/1.3/joda-parent-1.3-site_en.xml
 [INFO] Downloading from sonatype-apache: 
https://repository.apache.org/releases/org/joda/joda-parent/1.3/joda-parent-1.3-site_en.xml
 [INFO] Downloading from central: 
http://repo.maven.apache.org/maven2/org/joda/joda-parent/1.3/joda-parent-1.3-site.xml
 [INFO] Downloaded from central: 
http://repo.maven.apache.org/maven2/org/joda/joda-parent/1.3/joda-parent-1.3-site.xml
 (87 B at 4.1 kB/s) [INFO] Relativizing decoration links with respect to 
localized project URL: http://www.joda.org/joda-beans/{noformat}
 
Note that until these most recent builds, my parent project had no `site.xml`. 
The purpose of my change today was to publish site.xml using 
site:attach-descriptor to avoid this problem. However, since it is still 
looking for site_en.xml which is not published, I still get the error, which is 
a pain.

For the logs produced when it fails, see here: 
[https://travis-ci.org/JodaOrg/joda-convert/jobs/417679434] As can be seen, the 
"connection timed out", but the real question is why is it trying to query the 
_en file in the first place?

 

> sub-project tries to fetch a site_en.xml even though no locales are configured
> --
>
> Key: MSITE-639
> URL: https://issues.apache.org/jira/browse/MSITE-639
> Project: Maven Site Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7 64bit,  Sun JDK 1.6.0_27
>Reporter: Martin Goldhahn
>Priority: Major
> Attachments: parent-project.zip, sub-project.zip
>
>
> I have a parent project that has a site descriptor and a pom project that has 
> the parent project as parent. Neither of them defines the locales parameter 
> of the site plugin.
> When I try to build the sub-project, I get an error that Maven cannot find 
> the site_en.xml descriptor of the parent project. Why doesn't it just use the 
> site.xml?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1531) Option to switch-off Java 9 modules

2018-08-17 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583862#comment-16583862
 ] 

Stephen Colebourne commented on SUREFIRE-1531:
--

The PR is basically what I want. Note sure that "disableModules" is clear 
enough as a property name though.

The existing plugin also contains the same bug as MJAVADOC-506, namely that 
excluding the module-info.java file using configuration does not cause the 
plugin to ignore it when determining how to test. ( existsModuleDescriptor() 
does not take into account file excludes).

> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules. 
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if 
> it detects module-info.java While it may make sense in some cases, in my case 
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a 
> Spring interface. Mockito has to create an implementation of this interface 
> (proxy or subclass) and for this it needs to have access to the Spring 
> interfaces. If Java 9 modules are enabled for the tests I have to manually 
> add each such dependencies to Surefire configuration, which does not make 
> much sense. To makes things worse, the interface actually extends two Spring 
> interfaces form two different Spring modules so the configuration is almost 
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module 
> altogether (same behavior as pre 2.21.0)
>  
> The test is here 
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>  
> If you want, I can send a pull request.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-08-17 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583853#comment-16583853
 ] 

Stephen Colebourne commented on SUREFIRE-1497:
--

Not sure about that. Failsafe is all about setup and teardown of expensive 
(server-based) envionments. Whereas all that is needed here is to run the same 
unit tests in two ways. A bit like this:

https://github.com/JodaOrg/joda-convert/blob/4a91619ea3762e9be960fd8e63991a1d7e205f30/pom.xml#L55-L85

ie. I don't think this is an integration testing problem. To me its a unit 
testing one.

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>  Labels: jigsaw
> Attachments: maven-issue4.zip
>
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1531) Option to switch-off Java 9 modules

2018-08-14 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16580418#comment-16580418
 ] 

Stephen Colebourne commented on SUREFIRE-1531:
--

This is the same fundamental request as SUREFIRE-1497. We really do need a way 
to switch between using the modulepath and ignoring it at runtime for testing 
purposes.

> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules. 
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if 
> it detects module-info.java While it may make sense in some cases, in my case 
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a 
> Spring interface. Mockito has to create an implementation of this interface 
> (proxy or subclass) and for this it needs to have access to the Spring 
> interfaces. If Java 9 modules are enabled for the tests I have to manually 
> add each such dependencies to Surefire configuration, which does not make 
> much sense. To makes things worse, the interface actually extends two Spring 
> interfaces form two different Spring modules so the configuration is almost 
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module 
> altogether (same behavior as pre 2.21.0)
>  
> The test is here 
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>  
> If you want, I can send a pull request.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-330) Add java.* JPMS modules for testing only is hard

2018-06-02 Thread Stephen Colebourne (JIRA)



[ 
https://issues.apache.org/jira/browse/MCOMPILER-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499209#comment-16499209
 ] 

Stephen Colebourne commented on MCOMPILER-330:
--

 Thanks for merging MCOMPILER-341 which should provide a solution to this 
issue. I'd prefer to see a module-patch.java file to avoid duplicating the 
whole module-info, but what 341 has should be enough to get projects moving.

> Add java.* JPMS modules for testing only is hard
> 
>
> Key: MCOMPILER-330
> URL: https://issues.apache.org/jira/browse/MCOMPILER-330
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
> Environment: Windows 10, Maven v3.5.2
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue3.zip
>
>
> Attached is a project demonstrating this issue (which affects both compiler 
> and surefire). The basic problem here is where the project depends on a 
> java.* module for testing but not at compile time. For example, the test code 
> depends on `java.desktop` module, but the main code does not.
> While this has similarities with MCOMPILER-320 it is different because there 
> is no way to refer to the `java.*` JPMS modules as dependencies.
> Right now the workaround is to add both --add-modules and --add-reads, as 
> shown in the attachment. This is painful low-level stuff that Maven should be 
> hiding the user from.
> NOTE: the attachment will succeed when run. Delete the compiler/surefire 
> plugin config to see the issue.
> Rather than tackle this problem directly, my preference would be to have a 
> module-patch.java file that allows users to declare additional 
> dependencies/exports/services that only apply at testing time. This would be 
> interpreted whenever --patch-module is being used. (As well as the example 
> explained here, I've also run into the need to export packages that only 
> exist in tests, and this currently also requires low-level argLine 
> manipulation).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-341) Compile module-info.java files located in test sources

2018-05-13 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473634#comment-16473634
 ] 

Stephen Colebourne commented on MCOMPILER-341:
--

This looks like a good approach to the problem - we need module-info for 
testing (although ideally it could be merged with that from the src/main/java 
folder)

> Compile module-info.java files located in test sources
> --
>
> Key: MCOMPILER-341
> URL: https://issues.apache.org/jira/browse/MCOMPILER-341
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: Christian Stein
>Priority: Minor
>  Labels: pull-request-available
>
> Support compilation of projects with test sources containing modules – along 
> with explicit module descriptors ({{module-info.java}} files).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-329) Compile fails with optional and scope test sections with JPMS modules

2018-03-16 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401733#comment-16401733
 ] 

Stephen Colebourne commented on MCOMPILER-329:
--

Perhaps its time for Maven's warning to become an error?

I'm happy for the focus to be on SUREFIRE-1501

> Compile fails with optional and scope test sections with JPMS modules
> -
>
> Key: MCOMPILER-329
> URL: https://issues.apache.org/jira/browse/MCOMPILER-329
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Windows 10, Maven v3.5.2
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue2.zip
>
>
> Attached is a simple project that demonstrates this bug. The pom.xml has one 
> significant dependency - Guava, an automatic module.
> The same dependency is added twice - once declared optional and once declared 
> as scope=test. In addition, the module-info declares the dependency using 
> `requires static`.
> The duplicate dependency causes the plugin problems determining the 
> modulepath, as the result is the error "module not found". It isn't clear 
> whether the module isn't being added to the modulepath or whether it is there 
> and not being seen.
> While this may be an odd setup, it greatly complicated finding SUREFIRE-1501



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1501) Optional dependencies not correctly handled with JPMS modules

2018-03-16 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401732#comment-16401732
 ] 

Stephen Colebourne commented on SUREFIRE-1501:
--

Yes, but only if the Maven dependency tree contains the relevant jar.

> Optional dependencies not correctly handled with JPMS modules
> -
>
> Key: SUREFIRE-1501
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1501
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.21.0
> Environment: Windows 10, Maven v3.5.2
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue1.zip
>
>
> Attached is a pointlessly simple project for Java 9. The module-info declares 
> an _optional_ dependency on Google Guava (an automatic module) using 
> _requires static_. This optionality is reflected in the pom.xml, where the 
> dependency is marked as optional.
> It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that 
> although the Guava jar file is added to the modulepath, it is not referenced 
> using --add-modules. As such, the module graph builder never pulls it in, 
> despite it being on the modulepath. (Optional dependencies need to be 
> directly added using --add-modules if in Maven's dependency graph)
> Adding the --add-modules to the `argLine` parameter solves the problem, but 
> this is a bug because the surefire plugin should handle the situation without 
> manually adding it.
> NOTE! The attachment has the --add-modules manually added to the pom.xml. 
> Remove it to see the bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-03-15 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400685#comment-16400685
 ] 

Stephen Colebourne commented on SUREFIRE-1497:
--

The attachment shows the problem.

When surefire is set to v2.21.0 it tests in "module mode", using the service 
list in module-info.java.

When surefire is set to v2.20.1 it tests in "classpath mode", using the service 
list in META-INF/services.

The attached project is setup such that "module mode" is correct but "classpath 
mode" has a bug. As a library author, I cannot control or know whether the 
project will be used in "module mode" or "classpath mode". As such, what is 
needed is a way to test in both "module mode" and "classpath mode" - at present 
surefire provides no mechanism to test both modes.

NOTE: The attached project uses surefire v2.21.0 so will pass. Change the 
pom.xml version of surefire to v2.20.1 to see it fail (because the 
META-INF/services file is incorrect).

 

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue4.zip
>
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-03-15 Thread Stephen Colebourne (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated SUREFIRE-1497:
-
Attachment: maven-issue4.zip

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue4.zip
>
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MCOMPILER-330) Add java.* JPMS modules for testing only is hard

2018-03-15 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MCOMPILER-330:


 Summary: Add java.* JPMS modules for testing only is hard
 Key: MCOMPILER-330
 URL: https://issues.apache.org/jira/browse/MCOMPILER-330
 Project: Maven Compiler Plugin
  Issue Type: Improvement
Affects Versions: 3.7.0
 Environment: Windows 10, Maven v3.5.2
Reporter: Stephen Colebourne
 Attachments: maven-issue3.zip

Attached is a project demonstrating this issue (which affects both compiler and 
surefire). The basic problem here is where the project depends on a java.* 
module for testing but not at compile time. For example, the test code depends 
on `java.desktop` module, but the main code does not.

While this has similarities with MCOMPILER-320 it is different because there is 
no way to refer to the `java.*` JPMS modules as dependencies.

Right now the workaround is to add both --add-modules and --add-reads, as shown 
in the attachment. This is painful low-level stuff that Maven should be hiding 
the user from.

NOTE: the attachment will succeed when run. Delete the compiler/surefire plugin 
config to see the issue.

Rather than tackle this problem directly, my preference would be to have a 
module-patch.java file that allows users to declare additional 
dependencies/exports/services that only apply at testing time. This would be 
interpreted whenever --patch-module is being used. (As well as the example 
explained here, I've also run into the need to export packages that only exist 
in tests, and this currently also requires low-level argLine manipulation).

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MCOMPILER-329) Compile fails with optional and scope test sections with JPMS modules

2018-03-15 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MCOMPILER-329:


 Summary: Compile fails with optional and scope test sections with 
JPMS modules
 Key: MCOMPILER-329
 URL: https://issues.apache.org/jira/browse/MCOMPILER-329
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.7.0
 Environment: Windows 10, Maven v3.5.2
Reporter: Stephen Colebourne
 Attachments: maven-issue2.zip

Attached is a simple project that demonstrates this bug. The pom.xml has one 
significant dependency - Guava, an automatic module.

The same dependency is added twice - once declared optional and once declared 
as scope=test. In addition, the module-info declares the dependency using 
`requires static`.

The duplicate dependency causes the plugin problems determining the modulepath, 
as the result is the error "module not found". It isn't clear whether the 
module isn't being added to the modulepath or whether it is there and not being 
seen.

While this may be an odd setup, it greatly complicated finding SUREFIRE-1501



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1501) Optional dependencies not correctly handled with JPMS modules

2018-03-15 Thread Stephen Colebourne (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated SUREFIRE-1501:
-
Description: 
Attached is a pointlessly simple project for Java 9. The module-info declares 
an _optional_ dependency on Google Guava (an automatic module) using _requires 
static_. This optionality is reflected in the pom.xml, where the dependency is 
marked as optional.

It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although 
the Guava jar file is added to the modulepath, it is not referenced using 
--add-modules. As such, the module graph builder never pulls it in, despite it 
being on the modulepath. (Optional dependencies need to be directly added using 
--add-modules if in Maven's dependency graph)

Adding the --add-modules to the `argLine` parameter solves the problem, but 
this is a bug because the surefire plugin should handle the situation without 
manually adding it.

NOTE! The attachment has the --add-modules manually added to the pom.xml. 
Remove it to see the bug.

  was:
Attached is a pointlessly simple project for Java 9. The module-info declares 
an _optional_ dependency on Google Guava (an automatic module) using _requires 
static_. This optionality is reflected in the pom.xml, where the dependency is 
marked as optional.

It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although 
the Guava jar file is added to the modulepath, it is not referenced using 
--add-modules. As such, the module graph builder never pulls it in, despite it 
being on the modulepath. (Optional dependencies need to be directly added using 
--add-modules if in Maven's dependency graph)

Adding the --add-modules to the `argLine` parameter solves the problem, but 
this is a bug because the surefire plugin should handle the situation without 
manually adding it.


> Optional dependencies not correctly handled with JPMS modules
> -
>
> Key: SUREFIRE-1501
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1501
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.21.0
> Environment: Windows 10, Maven v3.5.2
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue1.zip
>
>
> Attached is a pointlessly simple project for Java 9. The module-info declares 
> an _optional_ dependency on Google Guava (an automatic module) using 
> _requires static_. This optionality is reflected in the pom.xml, where the 
> dependency is marked as optional.
> It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that 
> although the Guava jar file is added to the modulepath, it is not referenced 
> using --add-modules. As such, the module graph builder never pulls it in, 
> despite it being on the modulepath. (Optional dependencies need to be 
> directly added using --add-modules if in Maven's dependency graph)
> Adding the --add-modules to the `argLine` parameter solves the problem, but 
> this is a bug because the surefire plugin should handle the situation without 
> manually adding it.
> NOTE! The attachment has the --add-modules manually added to the pom.xml. 
> Remove it to see the bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1501) Optional dependencies not correctly handled with JPMS modules

2018-03-15 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created SUREFIRE-1501:


 Summary: Optional dependencies not correctly handled with JPMS 
modules
 Key: SUREFIRE-1501
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1501
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.21.0
 Environment: Windows 10, Maven v3.5.2
Reporter: Stephen Colebourne
 Attachments: maven-issue1.zip

Attached is a pointlessly simple project for Java 9. The module-info declares 
an _optional_ dependency on Google Guava (an automatic module) using _requires 
static_. This optionality is reflected in the pom.xml, where the dependency is 
marked as optional.

It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although 
the Guava jar file is added to the modulepath, it is not referenced using 
--add-modules. As such, the module graph builder never pulls it in, despite it 
being on the modulepath. (Optional dependencies need to be directly added using 
--add-modules if in Maven's dependency graph)

Adding the --add-modules to the `argLine` parameter solves the problem, but 
this is a bug because the surefire plugin should handle the situation without 
manually adding it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException

2018-03-13 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396840#comment-16396840
 ] 

Stephen Colebourne commented on SUREFIRE-1496:
--

Another example of the same basic problem, where the format of "--add-exports" 
is wrong. I suspect this one would be harder to fix as it involves argLine:

 
{noformat}
# Created on 2018-03-13T11:14:38.132
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'Error occurred during initialization of boot layer'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma 
after third character in command 'Error occurred during initialization of boot 
layer'.
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
 at java.base/java.lang.Thread.run(Thread.java:844)

# Created on 2018-03-13T11:14:38.132
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'java.lang.RuntimeException: Unable to parse --add-exports =: 
org.joda.beans.sample'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma 
after third character in command 'java.lang.RuntimeException: Unable to parse 
--add-exports =: org.joda.beans.sample'.
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
 at java.base/java.lang.Thread.run(Thread.java:844)
{noformat}
 

> Dump file error for java.lang.module.ResolutionException
> 
>
> Key: SUREFIRE-1496
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> Scenario:
>  * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
>  * `org.foo.a` requires `org.foo.b`
>  * `org.foo.b` exports package `org.foo.b.c`
>  * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
>  * when surefire is run on module `org.foo.a` a dump file error occurs:
>  
> {noformat}
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
> 'Error occurred during initialization of boot layer'.
> java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma 
> after third character in command 'Error occurred during initialization of 
> boot layer'.
>  at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
>  at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
>  at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
>  at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
>  at java.base/java.lang.Thread.run(Thread.java:844)
> Created on 2018-03-07T11:32:36.053
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
> 'java.lang.module.ResolutionException: Module org.foo.a contains package 
> org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'. 
> {noformat}
>  
> While the scenario is one that JPMS rejects, surefire should handle it 
> better. The compiler compiles the code just fine because it doesn't see the 
> resources as a package. Surefire is thus the first part of Maven that sees it 
> as a "package" that clashes with the module org.foo.b.
> Clearly, some part of surefire needs to be taught to about 
> java.lang.module.ResolutionException, as the error is tricky to find/see 
> because it is a dump file.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-03-07 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390300#comment-16390300
 ] 

Stephen Colebourne commented on SUREFIRE-1497:
--

 The goal of the issue is to match how the library will be used. It might be 
used on the modulepath or it might be used on the classpath. There is no way 
that I as library author can control which approach the end-user will use. As 
such, I need a way to test the library in both ways.

Today, I changed the surefire version from v2.20.1 to v2.21.0. This found two 
separate cases where the module I had setup was incorrect. Now that it is setup 
correctly, surefire v2.21.0 tests this. However, in order to know whether the 
code still works on the classpath, the only option surefire has at present is 
to temporarily downgrade the version and re-run the tests.

This is not theoretical either. To use ServiceLoader in Java 9 you have to 
duplicate the configuration. Once in META-INF/services and once in 
module-info.java. As it stands, there is no way in v2.21.0 to test the 
META-INF/services config, as that config is only used when the module is on the 
classpath.

A test case exposing this would be a module where META-INF/services is missing 
or wrong, but the module-info.java provides clause is correct.

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-03-07 Thread Stephen Colebourne (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated SUREFIRE-1497:
-
Affects Version/s: 2.21.0

> Flag to select modulepath or classpath
> --
>
> Key: SUREFIRE-1497
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
> Project: Maven Surefire
>  Issue Type: Improvement
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1497) Flag to select modulepath or classpath

2018-03-07 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created SUREFIRE-1497:


 Summary: Flag to select modulepath or classpath
 Key: SUREFIRE-1497
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
 Project: Maven Surefire
  Issue Type: Improvement
Reporter: Stephen Colebourne


SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
great. However, as a library developer I cannot guarantee that the code will be 
run on the modulepath, it might well be run on the classpath.

As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on and 
off? This would allow a single pom.xml to run surefire twice, once with the 
code on the modulepath and once with the code on the classpath, to ensure that 
the behaviour always works however the code is run. (Other solutions to achieve 
the same goal may be possible, but this seems the most obvious).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException

2018-03-07 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created SUREFIRE-1496:


 Summary: Dump file error for java.lang.module.ResolutionException
 Key: SUREFIRE-1496
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.21.0
Reporter: Stephen Colebourne


Scenario:
 * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
 * `org.foo.a` requires `org.foo.b`
 * `org.foo.b` exports package `org.foo.b.c`
 * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
 * when surefire is run on module `org.foo.a` a dump file error occurs:

 
{noformat}
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'Error occurred during initialization of boot layer'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma 
after third character in command 'Error occurred during initialization of boot 
layer'.
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
 at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
 at java.base/java.lang.Thread.run(Thread.java:844)
Created on 2018-03-07T11:32:36.053
Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 
'java.lang.module.ResolutionException: Module org.foo.a contains package 
org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'. 
{noformat}
 

While the scenario is one that JPMS rejects, surefire should handle it better. 
The compiler compiles the code just fine because it doesn't see the resources 
as a package. Surefire is thus the first part of Maven that sees it as a 
"package" that clashes with the module org.foo.b.

Clearly, some part of surefire needs to be taught to about 
java.lang.module.ResolutionException, as the error is tricky to find/see 
because it is a dump file.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MJAVADOC-506) Javadoc plugin broken on Java 8 when module-info.java present

2017-12-14 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MJAVADOC-506:
---

 Summary: Javadoc plugin broken on Java 8 when module-info.java 
present
 Key: MJAVADOC-506
 URL: https://issues.apache.org/jira/browse/MJAVADOC-506
 Project: Maven Javadoc Plugin
  Issue Type: Bug
  Components: javadoc
Affects Versions: 3.0.0
Reporter: Stephen Colebourne


The fix to MJAVADOC-498 causes the command line flag `--class-path` to be used 
on Java 8, a flag that is not recognised. This happens when the project 
contains `module-info.java`, but the module-info file is excluded by the 
configuration of the plugin.

The problem is here:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java?r1=1802722&r2=1813672&pathrev=1813672
where the code checks whether `src/main/java/module-info.java` exists without 
considering whether the file has been excluded by configuration. (I am simply 
trying to setup a build that uses Java 9 tooling on Java 9 and Java 8 tooling 
when running on Java 8)

There is no workaround to this in v3.0.0 that I can see, so I have to rollback 
to v3.0.0-M1. The solution is to check the includes/excludes when trying to 
obtain the module-info file. Or to check what version of the Javadoc tool is 
being used (as per MJAVADOC-499).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MJAVADOC-499) Ignore module-info.java on earlier Java versions

2017-11-17 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257052#comment-16257052
 ] 

Stephen Colebourne commented on MJAVADOC-499:
-

I don't have anything to add. Right now, every single pom.xml I'm updating for 
Java 9 compatibility (20+ pom.xml files) will need a profile matching Java 8 to 
exclude `module-info.java`. Java 8 is the LTS, so the projects have to compile 
there, which means ignoring the module file. The plugin knows all the facts, 
but doesn't process them. If you are unwilling to do it automatically, how 
about a flag? `ignoreFilesByJdkVersion` - it could apply to the compiler plugin 
and javadoc plugin at a minimum.

> Ignore module-info.java on earlier Java versions
> 
>
> Key: MJAVADOC-499
> URL: https://issues.apache.org/jira/browse/MJAVADOC-499
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Stephen Colebourne
>Assignee: Robert Scholte
>
> Versions of the javadoc tool prior to Java 9 cannot process 
> `module-info.java`. The plugin should automatically detect and exclude 
> `module-info.java` if the javadoc tool is Java 8 or earlier. The alternative 
> (Java version specific profiles) does work, but is very verbose for something 
> that can never work (thus the plugin should deal with it)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MJAVADOC-499) Ignore module-info.java on earlier Java versions

2017-11-13 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249529#comment-16249529
 ] 

Stephen Colebourne commented on MJAVADOC-499:
-

Java 9 is not an LTS version, so many projects are going to need to have their 
projects still compile and build on Java 8. The linked pom.xml ensures that 
releases are done on Java 9, but there is no requirement for anyone other than 
the person doing the release to use Java 9.

ie. a pom.xml is never just for a single maintainer in an OSS project - anyone 
might come along and want to build it for their own needs. And since Java 9 
isn't a long-lived LTS release, it won't be unusual for people to have Java 8, 
but not Java 9. I'd expect many OSS projects to want to compile on both the 
last LTS and the most current release, making use of additional features like 
module-info where possible.

This request is very similar to cases when flags get added. For example, 
doclint flag only exists in Javadoc from v8, but the plugin knows this and 
doesn't try to use the flag when running older versions of Javadoc. Here, the 
Javadoc plugin knows that older versions of Javadoc can't cope with 
module-info, so it would exclude it.

> Ignore module-info.java on earlier Java versions
> 
>
> Key: MJAVADOC-499
> URL: https://issues.apache.org/jira/browse/MJAVADOC-499
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Stephen Colebourne
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> Versions of the javadoc tool prior to Java 9 cannot process 
> `module-info.java`. The plugin should automatically detect and exclude 
> `module-info.java` if the javadoc tool is Java 8 or earlier. The alternative 
> (Java version specific profiles) does work, but is very verbose for something 
> that can never work (thus the plugin should deal with it)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MJAVADOC-499) Ignore module-info.java on earlier Java versions

2017-11-05 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239735#comment-16239735
 ] 

Stephen Colebourne commented on MJAVADOC-499:
-

No. The use case is a project with code locked to Java 6 where the build needs 
to work on Java 6, 7, 8 and 9. I don't think this is an uneasonable use case - 
its not fair or right to force people to install and run Java 9, particularly 
as it is not a long-term support release.

If the user builds on Java 6, use the Javadoc tool from Java 6. If they build 
on Java 8, use the Javadoc tool from Java 8. And if they build on Java 9, use 
the Javadoc tool from Java 9. A simple and straightforward goal.

The change that is needed is to make the plugin automatically exclude 
module-info.java when the version of Javadoc doesn't understand it. The Javadoc 
tool from Java 8 will never understand module-info.java, so it should be 
excluded. The alternative is pretty horrible and pretty tricky, because the 
profile has to exclude the file twice, once in the build and once in reporting: 
https://github.com/JodaOrg/joda-convert/blob/module-info/pom.xml#L603 

Note that Java 8 is going to last a long time as it is the last "normal" 
release. So, there will be lots of projects wanting to have a Java 8 baseline, 
but also be able to add a module-info for Java 9 and later. IMO, the compile 
plugin should also do the same - automatically exclude module-info.java on 
versions prior to Java 9. Its too common a use case for just documentation.


> Ignore module-info.java on earlier Java versions
> 
>
> Key: MJAVADOC-499
> URL: https://issues.apache.org/jira/browse/MJAVADOC-499
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Stephen Colebourne
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> Versions of the javadoc tool prior to Java 9 cannot process 
> `module-info.java`. The plugin should automatically detect and exclude 
> `module-info.java` if the javadoc tool is Java 8 or earlier. The alternative 
> (Java version specific profiles) does work, but is very verbose for something 
> that can never work (thus the plugin should deal with it)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRELEASE-980) Provide the ability to control commit messages

2017-11-01 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MRELEASE-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16233759#comment-16233759
 ] 

Stephen Colebourne commented on MRELEASE-980:
-

Does this mean the PR was rejected? Would be nice to get a reason if so.

> Provide the ability to control commit messages
> --
>
> Key: MRELEASE-980
> URL: https://issues.apache.org/jira/browse/MRELEASE-980
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.5.3
>Reporter: Stephen Colebourne
>Priority: Major
> Fix For: 3.0.0
>
>
> The commit messages used by maven-release-plugin are rather ugly to my eyes. 
> While the comment prefix provides some control, what is really needed is to 
> be able to change the whole message from xml configuration.
> I've implemented this here: 
> https://github.com/jodastephen/maven-release/commit/35b2a50900cfc8e8fca88a94e46985a09e538e86
>  (all rights granted to Apache - I'm still a committer at Apache Commons.
> It adds four new properties that allow the commit message to be controlled at 
> various points. The commit message can be configured using `@{}` style 
> inserts. There are more messages that could be controlled, but these were all 
> I needed.
> Note that issue MRELEASE-706 originally requested this feature, but it was 
> closed due to inactivity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MJAVADOC-499) Ignore module-info.java on earlier Java versions

2017-10-31 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MJAVADOC-499:
---

 Summary: Ignore module-info.java on earlier Java versions
 Key: MJAVADOC-499
 URL: https://issues.apache.org/jira/browse/MJAVADOC-499
 Project: Maven Javadoc Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0-M1
Reporter: Stephen Colebourne


Versions of the javadoc tool prior to Java 9 cannot process `module-info.java`. 
The plugin should automatically detect and exclude `module-info.java` if the 
javadoc tool is Java 8 or earlier. The alternative (Java version specific 
profiles) does work, but is very verbose for something that can never work 
(thus the plugin should deal with it)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments

2017-05-08 Thread Stephen Colebourne (JIRA)


 [ 
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated MJAVADOC-481:

Description: 
In its infinite wisdom, Oracle added a new command line flag in the standard 
doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
script tags in headers and footers. An example use for these would be to add 
Google Analytics to the footer of each page of Javadoc. For example [see 
here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
 

The rejection of scripts can be turned off using "--allow-script-in-comments" 
(note the double dash). The new flag can only be added to javadoc in 1.8.0u121 
or later. If the flag is added to "additionalparam" and used on earlier 
releases of JDK 8, it will complain that it is an unrecognised flag.

Sadly, this does not work:


  
[1.8.0.121,]
  
  
  --allow-script-in-comments
  


As such, this needs to be exposed as a flag in Maven to provide a way to create 
a Maven pom.xml that is valid for all JDK 8 releases.

Thread complaining about the lack of release notes: 
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
Issue in Gradle: https://github.com/gradle/gradle/issues/1393

  was:
In its infinite wisdom, Oracle added a new command line flag in the standard 
doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
script tags in headers and footers. An example use for these would be to add 
Google Analytics to the footer of each page of Javadoc. For example [see 
here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
 

The rejection of scripts can be turned off using "--allow-script-in-comments" 
(note the double dash). The new flag can only be added to javadoc in 1.8.0u121 
or later. If the flag is added to "additionalparam" and used on earlier 
releases of JDK 8, it will complain that it is an unrecognised flag.

Fortunately, it does seem that this works:


  
[1.8.0.121,]
  
  
  --allow-script-in-comments
  


This needs to be exposed as a flag in Maven to provide an easy way to create a 
Maven pom.xml that is valid for all JDK 8 releases.

Thread complaining about the lack of release notes: 
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
Issue in Gradle: https://github.com/gradle/gradle/issues/1393


> Java 1.8.0_u121 allow-script-in-comments
> 
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>
> In its infinite wisdom, Oracle added a new command line flag in the standard 
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
> script tags in headers and footers. An example use for these would be to add 
> Google Analytics to the footer of each page of Javadoc. For example [see 
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>  
> The rejection of scripts can be turned off using "--allow-script-in-comments" 
> (note the double dash). The new flag can only be added to javadoc in 
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on 
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Sadly, this does not work:
> 
>   
> [1.8.0.121,]
>   
>   
>   --allow-script-in-comments
>   
> 
> As such, this needs to be exposed as a flag in Maven to provide a way to 
> create a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes: 
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MJAVADOC-481) Java 1.8.0_u121 allow-script-in-comments

2017-05-08 Thread Stephen Colebourne (JIRA)


 [ 
https://issues.apache.org/jira/browse/MJAVADOC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated MJAVADOC-481:

Summary: Java 1.8.0_u121 allow-script-in-comments  (was: Java Update 121 
allow-script-in-comments)

> Java 1.8.0_u121 allow-script-in-comments
> 
>
> Key: MJAVADOC-481
> URL: https://issues.apache.org/jira/browse/MJAVADOC-481
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Stephen Colebourne
>
> In its infinite wisdom, Oracle added a new command line flag in the standard 
> doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
> script tags in headers and footers. An example use for these would be to add 
> Google Analytics to the footer of each page of Javadoc. For example [see 
> here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
>  
> The rejection of scripts can be turned off using "--allow-script-in-comments" 
> (note the double dash). The new flag can only be added to javadoc in 
> 1.8.0u121 or later. If the flag is added to "additionalparam" and used on 
> earlier releases of JDK 8, it will complain that it is an unrecognised flag.
> Fortunately, it does seem that this works:
> 
>   
> [1.8.0.121,]
>   
>   
>   --allow-script-in-comments
>   
> 
> This needs to be exposed as a flag in Maven to provide an easy way to create 
> a Maven pom.xml that is valid for all JDK 8 releases.
> Thread complaining about the lack of release notes: 
> http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
> Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MJAVADOC-481) Java Update 121 allow-script-in-comments

2017-05-08 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MJAVADOC-481:
---

 Summary: Java Update 121 allow-script-in-comments
 Key: MJAVADOC-481
 URL: https://issues.apache.org/jira/browse/MJAVADOC-481
 Project: Maven Javadoc Plugin
  Issue Type: Improvement
  Components: javadoc
Affects Versions: 2.10.4
Reporter: Stephen Colebourne


In its infinite wisdom, Oracle added a new command line flag in the standard 
doclet in JDK 8 update release 1.8.0_u121. By default, they now reject any 
script tags in headers and footers. An example use for these would be to add 
Google Analytics to the footer of each page of Javadoc. For example [see 
here|https://github.com/OpenGamma/Strata/blob/9712d78bec9f441024c30e9216e9b243fe679e2b/modules/pom.xml#L645]
 

The rejection of scripts can be turned off using "--allow-script-in-comments" 
(note the double dash). The new flag can only be added to javadoc in 1.8.0u121 
or later. If the flag is added to "additionalparam" and used on earlier 
releases of JDK 8, it will complain that it is an unrecognised flag.

Fortunately, it does seem that this works:


  
[1.8.0.121,]
  
  
  --allow-script-in-comments
  


This needs to be exposed as a flag in Maven to provide an easy way to create a 
Maven pom.xml that is valid for all JDK 8 releases.

Thread complaining about the lack of release notes: 
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/thread.html
Issue in Gradle: https://github.com/gradle/gradle/issues/1393



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRELEASE-706) Add "scmTagComment" and "scmPostTagComment" parameters

2017-02-17 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MRELEASE-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871809#comment-15871809
 ] 

Stephen Colebourne commented on MRELEASE-706:
-

See MRELEASE-980

> Add "scmTagComment" and "scmPostTagComment" parameters
> --
>
> Key: MRELEASE-706
> URL: https://issues.apache.org/jira/browse/MRELEASE-706
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Reporter: Jackie Noi
>
> Could you add two parameters that control what get written in the SCM comment 
> when {{mvn release:prepare}} is run?
> I suggest:
> * {{scmTagComment}}: what should be written in the commit message of the tag;
> * {{scmPostTagComment}}: what should be written in commit message for the 
> commit with the new version.
> For example, in my project ProjectFOO I would set {{scmTagComment}} to 
> "Released ProjectFOO (v@{project.version})" and {{scmPostTagComment}} to 
> "Prepare for ProjectFOO next development iteration (v@{project.version})". (I 
> suppose @{project.version} will change after the tag has been put.)
> Changing commit message of already tagged commits is an uncomfortable process 
> in SVN and Git, I'd love having {{mvn release:prepare}} get it right instead 
> of having to fix it manually.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MRELEASE-980) Provide the ability to control commit messages

2017-02-17 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MRELEASE-980:
---

 Summary: Provide the ability to control commit messages
 Key: MRELEASE-980
 URL: https://issues.apache.org/jira/browse/MRELEASE-980
 Project: Maven Release Plugin
  Issue Type: Improvement
  Components: prepare
Affects Versions: 2.5.3
Reporter: Stephen Colebourne
 Fix For: 3.0.0


The commit messages used by maven-release-plugin are rather ugly to my eyes. 
While the comment prefix provides some control, what is really needed is to be 
able to change the whole message from xml configuration.

I've implemented this here: 
https://github.com/jodastephen/maven-release/commit/35b2a50900cfc8e8fca88a94e46985a09e538e86
 (all rights granted to Apache - I'm still a committer at Apache Commons.

It adds four new properties that allow the commit message to be controlled at 
various points. The commit message can be configured using `@{}` style inserts. 
There are more messages that could be controlled, but these were all I needed.

Note that issue MRELEASE-706 originally requested this feature, but it was 
closed due to inactivity.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MASSEMBLY-817) Make finalName readonly parameter

2017-01-27 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843063#comment-15843063
 ] 

Stephen Colebourne edited comment on MASSEMBLY-817 at 1/27/17 5:35 PM:
---

This has just bitten me too. This is a very annoying and nasty change. Changing 
the finalName of the whole project is very definitely not what is wanted, as it 
does not allow a project to produce multiple distributions via the assembly 
plugin, each with distinct names, or to produce jar files with a different zip 
file name. Please reconsider this, as it was a widely used feature and will be 
painful for many users that want to produce output zip files (ie. it will break 
a lot of builds).

Could the name be settable when attach=false. That would be a step forward, 
although restoring the full feature would be better.


was (Author: scolebourne):
This has just bitten me too. This is a very annoying and nasty change. Changing 
the finalName of the whole project is very definitely not what is wanted, as it 
does not allow a project to produce multiple distributions via the assembly 
plugin, each with distinct names, or to produce jar files with a different zip 
file name. Please reconsider this, as it was a widely used feature and will be 
painful for many users that want to produce output zip files (ie. it will break 
a lot of builds).

> Make finalName readonly parameter
> -
>
> Key: MASSEMBLY-817
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-817
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Reporter: Anders Hammar
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> The name of the created artifact (in the target folder) should always follow 
> the convention. It shouldn't be configurable.
> As this is a breaking change it is appropriate for v3.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-817) Make finalName readonly parameter

2017-01-27 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843063#comment-15843063
 ] 

Stephen Colebourne commented on MASSEMBLY-817:
--

This has just bitten me too. This is a very annoying and nasty change. Changing 
the finalName of the whole project is very definitely not what is wanted, as it 
does not allow a project to produce multiple distributions via the assembly 
plugin, each with distinct names, or to produce jar files with a different zip 
file name. Please reconsider this, as it was a widely used feature and will be 
painful for many users that want to produce output zip files (ie. it will break 
a lot of builds).

> Make finalName readonly parameter
> -
>
> Key: MASSEMBLY-817
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-817
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Reporter: Anders Hammar
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> The name of the created artifact (in the target folder) should always follow 
> the convention. It shouldn't be configurable.
> As this is a breaking change it is appropriate for v3.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEPLOY-160) Deploy all installed artifacts

2016-03-11 Thread Stephen Colebourne (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190811#comment-15190811
 ] 

Stephen Colebourne commented on MDEPLOY-160:


As the OP, I no longer have need of this feature as that particular project has 
ended. However, I believe it is still of importance, as it allows maven to be 
used in build pipelines.

Specifically, it should be possible to build and install a project in one 
command, and then in a separate command, take what was installed and deploy it. 
The benefit of being able to run multiple installs followed by one deploy of a 
combined set of artifacts drops out naturally from this.

> Deploy all installed artifacts
> --
>
> Key: MDEPLOY-160
> URL: https://issues.apache.org/jira/browse/MDEPLOY-160
> Project: Maven Deploy Plugin
>  Issue Type: New Feature
>Affects Versions: 2.7
>Reporter: scolebourne2
> Fix For: waiting-for-feedback
>
>
> This is related to MDEPLOY-124, however it is sufficiently different to the 
> discussion there to warrant a separate issue.
> I'm proposing a single new goal in the plugin, "{{deploy:installed}}". This 
> new goal would deploy all the artifacts currently in the local repo as per 
> the GAV in the pom. A filter set could be used to filter the list.
> This mojo should in theory be relatively simple to write. Read the list of 
> files in the local repo, work out the classifiers and deploy them. Unless I'm 
> missing something...
> The solution propsed in MDEPLOY-124 would not work in my use case. We have a 
> build where there is a native element that is built on two (or more) 
> different machines. We would like to end up with a combined deploy folder. 
> ie. Linux machine produces pom, jar and linux artifacts, whereas the Windows 
> machine produces pom, jar and windows artifacts. The only time there is a 
> complete set of artifacts to deploy is when both machines have run and pushed 
> to a shared local repo. The goal would be more generally useful than this, as 
> it would allow install, test/review, deploy, workflows, which seems to be a 
> pretty common desire not supported by maven.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint

2014-04-21 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345159#comment-345159
 ] 

Stephen Colebourne commented on MJAVADOC-387:
-

Based on observation, the real issue seems to be trying to get a build to work 
in both JDK 8 and earlier JDKs. IIUC, the -X flag is not accepted by earlier 
javadocs, so the only approach is the tedious and non-helpful fixing of Javadoc 
to Oracle's artificial standards.

> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://jira.codehaus.org/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Reporter: Stephen Colebourne
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates 
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default 
> settings, it rejects many HTML elements that are perfectly acceptable to 
> browsers, and all invalid Javadoc references (@links). This is likely to 
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can 
> control the doclint tool (currently this requires using additionalparam 
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in, 
> not opt-out (ie. fix Oracle's messed up default). This will also make it much 
> easier for developers to handle migration to JDK 8.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint

2014-02-08 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MJAVADOC-387:
---

 Summary: Handle JDK8 -Xdoclint
 Key: MJAVADOC-387
 URL: https://jira.codehaus.org/browse/MJAVADOC-387
 Project: Maven Javadoc Plugin
  Issue Type: Improvement
Reporter: Stephen Colebourne


The Oracle team have added the doclint tool to JDK 8. The tool validates 
Javadoc as part of a standard Javadoc run. Unfortunately, with the default 
settings, it rejects many HTML elements that are perfectly acceptable to 
browsers, and all invalid Javadoc references (@links). This is likely to prove 
very unpopular with developers.

Action needed:
1) Provide a maven-javadoc-plugin configuration item and property that can 
control the doclint tool (currently this requires using additionalparam AFAICT).

2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in, 
not opt-out (ie. fix Oracle's messed up default). This will also make it much 
easier for developers to handle migration to JDK 8.




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCHECKSTYLE-205) NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression

2013-12-06 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336888#comment-336888
 ] 

Stephen Colebourne commented on MCHECKSTYLE-205:


I can confirm this affected us to (trace below).

This commit fixed it by downgrading to v2.10
https://github.com/OpenGamma/OG-Platform/commit/cc98210696e36c9b79ecec99fa168846d8b1f3f4

To reproduce
- checkout OpenGamma: https://github.com/OpenGamma/OG-Platform.git
- checkout commit 8730fd93b3cc520098c7f08ea47a326817c98132 (on the develop 
branch)
- change to the 'projects' directory
- run 'mvn site'


build   05-Dec-2013 23:02:42[INFO] Generating "Checkstyle" report--- 
maven-checkstyle-plugin:2.11
build   05-Dec-2013 23:03:10[INFO] 
build   05-Dec-2013 23:03:10[INFO] 

build   05-Dec-2013 23:03:10[INFO] Reactor Summary:
build   05-Dec-2013 23:03:10[INFO] 
build   05-Dec-2013 23:03:10[INFO] OG-Platform-Public 
 FAILURE [2:37.697s]
build   05-Dec-2013 23:03:10[INFO] OG-TimeSeries 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Util 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Analytics 
.. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Core 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Master 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-FinancialTypes 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Security 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-LiveData 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Provider 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Engine 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Financial 
.. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Web 
 SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-UtilDB 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-MasterDB 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-EngineDB 
... SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Component 
.. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Bloomberg 
.. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Integration 
 SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Client 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] OG-Server 
. SKIPPED
build   05-Dec-2013 23:03:10[INFO] 

build   05-Dec-2013 23:03:10[INFO] BUILD FAILURE
build   05-Dec-2013 23:03:10[INFO] 

build   05-Dec-2013 23:03:10[INFO] Total time: 2:40.267s
build   05-Dec-2013 23:03:10[INFO] Finished at: Thu Dec 05 23:03:10 GMT 2013
build   05-Dec-2013 23:03:10[INFO] Final Memory: 58M/769M
build   05-Dec-2013 23:03:10[INFO] 

build   05-Dec-2013 23:03:10[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
og-platform-public: Execution default-site of goal 
org.apache.maven.plugins:maven-site-plugin:3.3:site failed. 
NullPointerException -> [Help 1]
build   05-Dec-2013 23:03:10
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
og-platform-public: Execution default-site of goal 
org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
build   05-Dec-2013 23:03:10at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
build   05-Dec-2013 23:03:10at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
build   05-Dec-2013 23:03:10at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
build   05-Dec-2013 23:03:10at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
build   05-Dec-2013 23:03:10at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

[jira] (MCHECKSTYLE-197) Documentation: Check goal is incorrectly described

2013-07-26 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MCHECKSTYLE-197:
--

 Summary: Documentation: Check goal is incorrectly described
 Key: MCHECKSTYLE-197
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-197
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.10
Reporter: Stephen Colebourne


The website describes the check goal as

{panel}
checkstyle:check performs a violation check against the last Checkstyle run to 
see if there are any violations. It reads the Checkstyle output file, counts 
the number of violations found and displays it on the console.{panel}

This is incorrect. The check goal will, by default, run the actual checkstyle 
analysis before printing the messages.

The following text would be better on the home page:
http://maven.apache.org/plugins/maven-checkstyle-plugin/index.html

{panel}
* checkstyle:checkstyle - a reporting task that performs Checkstyle analysis 
and generates an HTML report on violations.
* checkstyle:checkstyle-aggregate - a reporting task that performs Checkstyle 
analysis and generates an aggregate HTML report on violations in a multi-module 
reactor build.
* checkstyle:check - performs Checkstyle analysis and outputs violations to the 
console, potentially failing the build. It can also be configured to re-use an 
earlier analysis.
{panel}

The description on the check-mojo page should also be fixed similarly:
http://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html

An example or FAQ should be added to emphasise the difference between the 
checkstyle and check goals.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MASSEMBLY-637) fileSet unix strips last newline of file

2013-07-24 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/MASSEMBLY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329396#comment-329396
 ] 

Stephen Colebourne commented on MASSEMBLY-637:
--

Thanks!

> fileSet unix strips last newline of file
> -
>
> Key: MASSEMBLY-637
> URL: https://jira.codehaus.org/browse/MASSEMBLY-637
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Linux ws117v6226517 2.6.32-5-686 #1 SMP Sun Sep 23 
> 09:49:36 UTC 2012 i686 GNU/Linux
> Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Maven home: /usr/local/lib/apache-maven-3.0.4
> Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
> Java home: /usr/local/lib/jdk1.6.0_33/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-5-686", arch: "i386", family: "unix"
>Reporter: deckrider
>Assignee: Olivier Lamy
> Fix For: 2.5
>
> Attachments: MASSEMBLY-637.patch
>
>
> using unix strips last newline of file when 
> building on Linux platform (not sure about other platforms)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MASSEMBLY-637) fileSet unix strips last newline of file

2013-07-22 Thread Stephen Colebourne (JIRA)


 [ 
https://jira.codehaus.org/browse/MASSEMBLY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Colebourne updated MASSEMBLY-637:
-

Attachment: MASSEMBLY-637.patch

Please find attached the patch to fix this issue. I am an ASF committer.

The patch moves the encoding logic from {{FileFormatter}} to 
{{AssemblyFileUtils}}. This is necessary to get access to the {{File}} object 
so that the existing end-of-file line ending can be queried. That is then used 
to fix the bug without breaking MASSEMBLY-96.

I have added a {{Boolean}} parameter {{atEndOfFile}} to the 
{{AssemblyFileUtils}} method so that a future enhancement can add a new 
configuration item to the assembly desriptor file - "newLineAtEndOfFile" - 
which would have values "retain" (the default), "ensure" and "remove" (where 
"ensure" is the interesting value, adding a new line at the end of the file if 
it is missing). I haven't change the assembly descriptor to keep this patch 
simple.

Please apply this patch, as this is a pretty serious bug IMO.

> fileSet unix strips last newline of file
> -
>
> Key: MASSEMBLY-637
> URL: https://jira.codehaus.org/browse/MASSEMBLY-637
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Linux ws117v6226517 2.6.32-5-686 #1 SMP Sun Sep 23 
> 09:49:36 UTC 2012 i686 GNU/Linux
> Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Maven home: /usr/local/lib/apache-maven-3.0.4
> Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
> Java home: /usr/local/lib/jdk1.6.0_33/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-5-686", arch: "i386", family: "unix"
>Reporter: deckrider
> Attachments: MASSEMBLY-637.patch
>
>
> using unix strips last newline of file when 
> building on Linux platform (not sure about other platforms)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEPLOY-118) Enable deployment of attached release artifacts if POM is identical

2013-07-05 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328055#comment-328055
 ] 

Stephen Colebourne commented on MDEPLOY-118:


Fixing this would definitely be helpful to me, as outlined in the similar use 
case motivating MDEPLOY-160.

> Enable deployment of attached release artifacts if POM is identical
> ---
>
> Key: MDEPLOY-118
> URL: https://jira.codehaus.org/browse/MDEPLOY-118
> Project: Maven 2.x and 3.x Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 2.4
> Environment: Windows XP SP3
>Reporter: Bruno F
>  Labels: contributers-welcome
>
> In the context of the build of a native application, one might have 
> zip-artifacts containing several DLL or so files like:
> boost:boost_regex:1.34.1:zip
> In order to distinguish between platforms, it seems to be recommended to use 
> the classifier:
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8
> or:
> boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3
> If a Maven repository manager is configured to prevent from re-deploying 
> release artifacts (and I believe it should be), it is not possible to deploy 
> attached artifacts when the POM is the same because the POM is deployed 
> twice. The deploy plugin could check that the POM is already deployed and is 
> the same than the local one (modulo platform-dependent line-break concerns, 
> and that's important!), then choose not to deploy it but only the attached 
> artifact.
> In the example above, it could enable to deploy the 
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 artifact from a Windows 
> machine(coming along with a boost:boost_regex:1.34.1:pom artifact), then to 
> deploy the boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 artifact from 
> a Linux machine (coming along with the same boost:boost_regex:1.34.1:pom 
> artifact, that will not be deployed since it is identical to the first one 
> deployed).
> Maybe this could be generalized to any kind of artifact? If the artifact to 
> deploy is the same, the plugin should not fail and simply skip the deployment 
> of that artifact?
> I post that bug here on a suggestion of Brett Porter (see the MRM-1357 bug) 
> since it is quite unclear to me whether it is a MRM or deploy plugin concern.
> That bug might also be related to:
> - MDEPLOY-117
> - MDEPLOY-114

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEPLOY-160) Deploy all installed artifacts

2013-07-05 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MDEPLOY-160:
--

 Summary: Deploy all installed artifacts
 Key: MDEPLOY-160
 URL: https://jira.codehaus.org/browse/MDEPLOY-160
 Project: Maven 2.x and 3.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Stephen Colebourne


This is related to MDEPLOY-124, however it is sufficiently different to the 
discussion there to warrant a separate issue.

I'm proposing a single new goal in the plugin, "{{deploy:installed}}". This new 
goal would deploy all the artifacts currently in the local repo as per the GAV 
in the pom. A filter set could be used to filter the list.

This mojo should in theory be relatively simple to write. Read the list of 
files in the local repo, work out the classifiers and deploy them. Unless I'm 
missing something...

The solution propsed in MDEPLOY-124 would not work in my use case. We have a 
build where there is a native element that is built on two (or more) different 
machines. We would like to end up with a combined deploy folder. ie. Linux 
machine produces pom, jar and linux artifacts, whereas the Windows machine 
produces pom, jar and windows artifacts. The only time there is a complete set 
of artifacts to deploy is when both machines have run and pushed to a shared 
local repo. The goal would be more generally useful than this, as it would 
allow install, test/review, deploy, workflows, which seems to be a pretty 
common desire not supported by maven.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAR-167) skipIfEmpty outputs incorrect logging nessage

2013-06-14 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MJAR-167:
---

 Summary: skipIfEmpty outputs incorrect logging nessage
 Key: MJAR-167
 URL: https://jira.codehaus.org/browse/MJAR-167
 Project: Maven 2.x JAR Plugin
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Stephen Colebourne
Priority: Trivial


The 'skipIfEmpty' flag added in MJAR-139 has the wrong debugging message 
(refers to test-jar, not jar):

{code}
[INFO] --- maven-jar-plugin:2.4:jar (jar) @ og-server ---
[INFO] Skipping packaging of the test-jar
[INFO]
[INFO] --- maven-jar-plugin:2.4:test-jar (test-jar) @ og-server ---
[INFO] Skipping packaging of the test-jar
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MANTTASKS-239) Requires ant 1.9.1

2013-06-12 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MANTTASKS-239:


 Summary: Requires ant 1.9.1
 Key: MANTTASKS-239
 URL: https://jira.codehaus.org/browse/MANTTASKS-239
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
  Components: documentation
Reporter: Stephen Colebourne


When using ant v1.8 the ant tasks do not work for me. Upgrading to ant v1.9.1 
made them work.

With v1.8, the pom task failed to resolve the pom. The build continued, but 
expressions such as pom.version did not resolve.

In addition, the dependencies task failed to read maven-metadata-local.xml:

{code}


Finding dependencies of ${pom.artifactId}-${version}

 



 [echo] POM ${pom.version}
 [echo] Finding dependencies of ${pom.artifactId}-${pom.version}
[artifact:dependencies] An error has occurred while processing the Maven artifac
t tasks.
[artifact:dependencies]  Diagnosis:
[artifact:dependencies]
[artifact:dependencies] Unable to resolve artifact: Unable to get dependency inf
ormation: Unable to read the metadata file for artifact 'com.opengamma.platform:
og-util:jar': Error getting POM for 'com.opengamma.platform:og-util' from the re
pository: Unable to read local copy of metadata: Cannot read metadata from 'E:\m
aven\repository\com\opengamma\platform\og-util\2.0.0-SNAPSHOT\maven-metadata-loc
al.xml': expected START_TAG or END_TAG not TEXT (position: TEXT seen ...sourceshttp://maven.opengamma.com/nexus/content/gr
oups/public),
[artifact:dependencies]   central (http://repo1.maven.org/maven2)
[artifact:dependencies] Path to dependency:
[artifact:dependencies] 1) com.opengamma.platform:og-language:jar:2.0.0-
SNAPSHOT
{code}

Moving to ant v1.9.1 fixed both issues.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MINSTALL-95) Enhance documentation of install-file

2013-06-11 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MINSTALL-95:
--

 Summary: Enhance documentation of install-file
 Key: MINSTALL-95
 URL: https://jira.codehaus.org/browse/MINSTALL-95
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Stephen Colebourne
Priority: Minor


When you want to install a pre-built third party jar file into a local repo 
google will [point 
you|https://www.google.co.uk/search?q=maven+install+artifact&ie=utf-8] at these 
pages:
* http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
* 
http://maven.apache.org/plugins/maven-install-plugin/examples/specific-local-repo.html

Neither of these pages explains what to do if you have a pom that you want to 
deploy as well as the jar file. The right answer is already documented here:
* 
http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html

Please enhance the documentation in two ways:
* enhance the 
[mini-guide|http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html]
 to include an example with a pom
* enhance the [plugin 
guides|http://maven.apache.org/plugins/maven-install-plugin/examples/specific-local-repo.html]
 to provide cross-links between the individual pages. ie, after the example at 
links along the lines of "if you want to install a pom as well click here" etc.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-569) There should be a way to run unit tests from a dependency jar.

2013-06-11 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326532#comment-326532
 ] 

Stephen Colebourne commented on SUREFIRE-569:
-

This worked perfectly for me in the 2.15 release. As the config isn't fully 
documented I looked at the patch and used that:

{code}

  com.group.id:my-artifact
  com.group.id:my-other-artifact

{code}

> There should be a way to run unit tests from a dependency jar.
> --
>
> Key: SUREFIRE-569
> URL: https://jira.codehaus.org/browse/SUREFIRE-569
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: Maven Surefire Plugin
>Reporter: Paul Gier
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
> Attachments: SUREFIRE-569.patch
>
>
> In some cases it would be useful to have a set of tests that run with various 
> dependency configurations.  One way to accomplish this would be to have a 
> single project that contains the unit tests and generates a test jar.  
> Several test configuration projects could then consume the unit tests and run 
> them with different dependency sets.  The problem is that there is no easy 
> way to run tests in a dependency jar.  The surefire plugin should have a 
> configuration to allow me to run all or a set of unit tests contained in a 
> dependency jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-691) Aggregator pom with child parent not handled

2013-06-03 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-691:


 Summary: Aggregator pom with child parent not handled
 Key: MSITE-691
 URL: https://jira.codehaus.org/browse/MSITE-691
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: multi module
Affects Versions: 3.3
Reporter: Stephen Colebourne
 Attachments: OG-Platform.zip

The attached zip demonstrates a project where the parent is an aggregator only 
pom and the children include the parent:

{code}
platform
- pom.xml  (aggregator only)
- projects
  - parent
- pom.xml  (parent for the child project)
  - child
- pom.xml
{code}

Running the zip file with "mvn clean test site" will build incorrect hyperlinks.

The top left hyperlinks, added by the site plugin, are defined as 
"parent/index.html" and "child/child/index.html". I consider the former to be 
correct, but not the latter.

In addition, the navigation links produce both a link to the parent (under the 
"Parent Project" heading), and a second link to the parent under the "Modules" 
heading. This seems unnecessary, and in fact does not work in design terms, see 
below. (It appears that separate aggregator and parent pom projects are not 
really supported in design terms)

The child projects also contain the wrong link to the parent (under "Parent 
Projects" in the navigation area). They create a link as 
"../../parent/index.html". This will be one ".." too far, as the 
"distributionManagement.site.url" definition removes the extra level.

Finally, the site of the parent pom does not contain a "Parent projects" link 
in the navigation area. That would make sense if there was no aggregator 
project, but does not make sense here from a website pint of view.

What I would expect is the following staged website:
{code}
target
- staging
  - index.html  (links to child projects, including parent)
  - parent 
- index.html  (link back to aggregator)
  - child
- index.html  (link back to aggregator, link to parent: 
"../parent/index.html")
{code}



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MPIR-279) Wrong hyperlinks on index and modules page

2013-06-03 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MPIR-279:
---

 Summary: Wrong hyperlinks on index and modules page
 Key: MPIR-279
 URL: https://jira.codehaus.org/browse/MPIR-279
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: modules
Affects Versions: 2.7
Reporter: Stephen Colebourne
 Attachments: OG-Platform2.zip

The attached zip is a complete multi-module build with the bug exposed. Run 
using "mvn clean site site:stage" to reproduce.

What is observed is that the navigation hyperlinks in the top left (added by 
the site plugin) are correctly defined as 
"target/staging/og-timeseries/index.html", whereas the hyperlinks in the middle 
of index.html and modules.html are incorrectly defined as 
"target/staging/projects/og-timeseries/index.html" - note the incorrect extra 
"projects".

The problem will occur because the child projects in the multi-module build are 
not immediate children of the parent/aggregator. Instead the structure is:

{code}
platform
 - pom.xml
 - projects
   - og-timeseries
 - pom.xml
{code}

The extra layer is being handled by the site plugin (by referring to the 
"distributionManagement.site.url"). It is not handled by this plugin.

As a side note, if "distributionManagement.site.url" is NOT set in the child 
projects, then the site will build consistently using 
"target/staging/projects/og-timeseries/index.html" everywhere.

This is no doubt related to MPIR-273.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-690) Add new "process-reports" goal

2013-06-01 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-690:


 Summary: Add new "process-reports" goal
 Key: MSITE-690
 URL: https://jira.codehaus.org/browse/MSITE-690
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Improvement
Affects Versions: 3.3
Reporter: Stephen Colebourne


AFAICT, maven builds a site by relying on other plugins to generate files in a 
specific HTML format. For example, the PMD and Checkstyle plugins generate 
reports that include references to "@import url("./css/maven-base.css");" and 
"${project.version}". The site plugin then post-processes these files to do 
three things:
(a) add the css files,
(b) convert references like ${project.version}
(c) add in a generated menu structure with relative links

Propose adding a new goal "process-reports" that performs steps (a) and (b) 
only. Instead of generating the index structure in step (c), it would simply 
remove the index and header parts of the HTML file to create a simple 
*standalone* HTML file.

The aim of this improvement is to allow valid complete HTML files to be created 
without the rest of the generated site (with the complications of relative 
links). This goal would simply run in each project of the multi-module build 
independently, processing the resources it finds locally.

Users wanting a checkstyle report could then run "mvn clean 
checkstyle:checkstyle-aggregator site:process-reports". Today, "mvn clean 
checkstyle:checkstyle-aggregator" works OK but produces half-complete HTML 
files.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-690) Sanity check for site:stage

2013-06-01 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-690:


 Summary: Sanity check for site:stage
 Key: MSITE-690
 URL: https://jira.codehaus.org/browse/MSITE-690
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Improvement
  Components: site:stage(-deploy)
Affects Versions: 3.3
Reporter: Stephen Colebourne


The site:stage goal is intended to copy and combine the sites from all 
sub-modules into a single target/staging folder. On occasion, this goal can 
mis-calculate the relative folder structure, copying the sites into the target 
folder rather than target/staging. This creates a big mess (and it would be 
worse if it copied things above target!)

Propose to add a sanity check that prevents anything being copied outside the 
target/staging folder.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-689) Enhance "configuring reports" documentation

2013-05-31 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-689:


 Summary: Enhance "configuring reports" documentation
 Key: MSITE-689
 URL: https://jira.codehaus.org/browse/MSITE-689
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.3
Reporter: Stephen Colebourne
Priority: Minor


Since maven 3 changed and then reverted the way that reports should be 
customized, it is very hard to find a complete and accurate example of what is 
now the correct customization of reports and what can be defined where. This 
page, 
http://maven.apache.org/plugins/maven-site-plugin/examples/configuring-reports.html,
 is a start, but needs enhancing.

1) If you want to run javadoc/checkstyle/etc in both the main build and the 
site plugin, where should the config be? Build or reporting or both?

2) Do the reporting plugins choose aggregating reports automatically if running 
in a reactor, or do they have to be configured? The current example suggests 
extra config is needed.

3) If a parent pom defines a reporting block and the same plugin is overridden 
in a child of that parent pom, what happens? What if the child is an aggregator?

4) Examples, or links, to common reporting plugins (checkstyle/pmd/javadoc) are 
also needed as they all appear to vary subtly.

Ultimately, it should be possible to go to the page, decide what example 
matches your project structure, and copy/amend from that specific example.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-688) Enhance site:stage documentation

2013-05-31 Thread Stephen Colebourne (JIRA)

Stephen Colebourne created MSITE-688:


 Summary: Enhance site:stage documentation
 Key: MSITE-688
 URL: https://jira.codehaus.org/browse/MSITE-688
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Improvement
  Components: site:stage(-deploy)
Affects Versions: 3.3
Reporter: Stephen Colebourne
Priority: Minor


The site:stage goal would benefit from enhanced documentation.

Firstly, the summary, 
http://maven.apache.org/plugins/maven-site-plugin/plugin-info.html, is not 
clear about the need to run "mvn site" before "mvn site:stage". Add the 
sentence "This goal requires the site to already have been generated using the 
site goal, such as by calling "mvn site".

Secondly, there needs to be an expansion of the documentation for 
multi-module/reactor builds to give examples of the complete set of values 
needed to make it work 
http://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html .

Since there are multiple different multi-module project layouts (separate 
aggregator/parent vs same aggregator/parent, aggregator contains parent etc), 
this is likely to need multiple examples. The examples should focus on the 
right settings to use for fields such as distribution.site.url (and the fact 
that distribution.site.id is also mandatory).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"

2013-05-31 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326017#comment-326017
 ] 

Stephen Colebourne commented on MSITE-669:
--

Just noting that issues I experienced are similar
http://www.mail-archive.com/users@maven.apache.org/msg130057.html

In my case, the reactor is run from an aggregator pom, with the parent and 
other modules as subdirectories. The aggregator also extends the parent.

I would recommend adding a sanity check that ensures that the stage goal never 
writes files outside the target/staging directory.

What the site project really needs is a page with a fuller example of what 
needs to be in the distribution.url and other settings given a particular type 
of project structure.


> site:stage creates incorrect structure when module paths contains sets of 
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jorelid
>Assignee: Lukas Theussl
> Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch, 
> msite_669_v4.patch, nazgul_tools_project_dependencies.png, 
> nazgul_tools_reactor_structure.png, sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets 
> of maps relative to the staging directory - i.e. outside of the target 
> directory.
> {code:xml} 
> 
>   ../../validation/validation-api
>   ../../validation/validation-aspect
>   ../parent
> 
> {code}
> The staged site should be fully included within the staging directory. It 
> would appear that relativization of links for site:stage should take special 
> links into consideration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-569) There should be a way to run unit tests from a dependency jar.

2013-05-03 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324658#comment-324658
 ] 

Stephen Colebourne commented on SUREFIRE-569:
-

Thank you very much for applying the patch. And yes, that extra "standardised" 
filtering would be very nice!

> There should be a way to run unit tests from a dependency jar.
> --
>
> Key: SUREFIRE-569
> URL: https://jira.codehaus.org/browse/SUREFIRE-569
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: Maven Surefire Plugin
>Reporter: Paul Gier
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
> Attachments: SUREFIRE-569.patch
>
>
> In some cases it would be useful to have a set of tests that run with various 
> dependency configurations.  One way to accomplish this would be to have a 
> single project that contains the unit tests and generates a test jar.  
> Several test configuration projects could then consume the unit tests and run 
> them with different dependency sets.  The problem is that there is no easy 
> way to run tests in a dependency jar.  The surefire plugin should have a 
> configuration to allow me to run all or a set of unit tests contained in a 
> dependency jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-569) There should be a way to run unit tests from a dependency jar.

2013-05-01 Thread Stephen Colebourne (JIRA)


[ 
https://jira.codehaus.org/browse/SUREFIRE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324500#comment-324500
 ] 

Stephen Colebourne commented on SUREFIRE-569:
-

Having spent the best part of a day trying to workaround this, I can't 
emphasise enough how much this is needed. Being able to produce a jar of test 
classes without being able to run them in a separate project is basically just 
a bug.

The patch could do with an enhancement, which is to pickup all jar files of 
type "test-jar", rather than having to name each individually, but I'd take the 
basic patch right now.

If you search the web, you'll see lots of people want to be able to test 
outside the original project.
http://softwaremavens.blogspot.co.uk/2009/09/running-tests-from-maven-test-jar-in.html
http://dharshanaw.blogspot.co.uk/2012/10/how-to-execute-testng-tests-in-side.html
http://stackoverflow.com/questions/3543473/run-maven-tests-from-classpath
http://stackoverflow.com/questions/13859737/run-testng-on-a-maven-test-dependency
http://stackoverflow.com/questions/11331518/testng-execute-compiled-tests-in-jar-file

> There should be a way to run unit tests from a dependency jar.
> --
>
> Key: SUREFIRE-569
> URL: https://jira.codehaus.org/browse/SUREFIRE-569
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: Maven Surefire Plugin
>Reporter: Paul Gier
> Attachments: SUREFIRE-569.patch
>
>
> In some cases it would be useful to have a set of tests that run with various 
> dependency configurations.  One way to accomplish this would be to have a 
> single project that contains the unit tests and generates a test jar.  
> Several test configuration projects could then consume the unit tests and run 
> them with different dependency sets.  The problem is that there is no easy 
> way to run tests in a dependency jar.  The surefire plugin should have a 
> configuration to allow me to run all or a set of unit tests contained in a 
> dependency jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-2253) Upload Joda-Time 1.6

2008-10-29 Thread Stephen Colebourne (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152280#action_152280
 ] 

Stephen Colebourne commented on MAVENUPLOAD-2253:
-

Not really. I would need a pom.xml rather than a project.xml. Plus, I would 
have to generate the two signature files for every file I place there.

The bundle is created by ant - I don't have to think about it.

> Upload Joda-Time 1.6
> 
>
> Key: MAVENUPLOAD-2253
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2253
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Stephen Colebourne
>
> http://joda-time.sourceforge.net/joda-time-1.6-bundle.jar
>   
> http://joda-time.sourceforge.net
> http://joda-time.sourceforge.net/team-list.html
>   
> Please upload joda-time 1.6

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-2253) Upload Joda-Time 1.6

2008-10-27 Thread Stephen Colebourne (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152093#action_152093
 ] 

Stephen Colebourne commented on MAVENUPLOAD-2253:
-

The reason why I am not using automatic sync as that would require me to 
upgrade to maven 2, which is a lot of hassle.

The bundle http://joda-time.sourceforge.net/joda-time-hibernate-1.1-bundle.jar 
also needs uploading please.


> Upload Joda-Time 1.6
> 
>
> Key: MAVENUPLOAD-2253
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2253
> Project: Maven Upload Requests
>  Issue Type: Wish
>Reporter: Stephen Colebourne
>
> http://joda-time.sourceforge.net/joda-time-1.6-bundle.jar
>   
> http://joda-time.sourceforge.net
> http://joda-time.sourceforge.net/team-list.html
>   
> Please upload joda-time 1.6

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-2253) Upload Joda-Time 1.6

2008-10-27 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.6


 Key: MAVENUPLOAD-2253
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2253
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.6-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.6

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1964) Upload Joda-Time jsptags 1.0.2

2008-03-15 Thread Stephen Colebourne (JIRA)

Upload Joda-Time jsptags 1.0.2
--

 Key: MAVENUPLOAD-1964
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1964
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-jsptags-1.0.2-bundle.jar

http://joda-time.sourceforge.net/contrib/jsptags
http://joda-time.sourceforge.net/contrib/jsptags/team-list.html
  
Bundle includes source and javadoc files for maven 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1910) Upload Joda-Time 1.5.2 (with -sources and -javadoc jars)

2008-01-27 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.5.2 (with -sources and -javadoc jars)


 Key: MAVENUPLOAD-1910
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1910
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.5.2-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html

Please upload Joda-Time 1.5.2 including the sources and javadoc jars

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1835) Upload Joda-Time 1.5.1 (with -sources and -javadoc jars)

2007-12-04 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.5.1 (with -sources and -javadoc jars)


 Key: MAVENUPLOAD-1835
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1835
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.5.1-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.5.1
*** This bundle also contains joda-time-1.5.1-sources.jar & 
joda-time-1.5.1-javadoc.jar ***

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1816) Upload Joda-Time jsptags 1.0.1

2007-11-14 Thread Stephen Colebourne (JIRA)

Upload Joda-Time jsptags 1.0.1
--

 Key: MAVENUPLOAD-1816
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1816
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-jsptags-1.0.1-bundle.jar
  
http://joda-time.sourceforge.net/contrib/jsptags/
http://joda-time.sourceforge.net/contrib/jsptags/team-list.html
  
Please upload joda-time-jsptags-1.0.1, thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1785) Upload Joda-Time 1.5 (with -sources and -javadoc jars)

2007-10-29 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.5 (with -sources and -javadoc jars)
--

 Key: MAVENUPLOAD-1785
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1785
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.5-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.5
*** This bundle also contains joda-time-1.5-sources.jar & 
joda-time-1.5-javadoc.jar ***

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1753) Upload Joda-Time hibernate 1.0

2007-10-07 Thread Stephen Colebourne (JIRA)

Upload Joda-Time hibernate 1.0
--

 Key: MAVENUPLOAD-1753
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1753
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/contrib/hibernate/joda-time-hibernate-1.0-bundle.jar

http://joda-time.sourceforge.net/contrib/hibernate/index.html
http://joda-time.sourceforge.net/contrib/hibernate/team-list.html

Please upload the new joda-time-hibernate release. Thanks. Stephen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1230) Upload Joda-Time 1.4

2006-11-12 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.4


 Key: MAVENUPLOAD-1230
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1230
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.4-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.4


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1028) Upload Joda-Time 1.3

2006-08-02 Thread Stephen Colebourne (JIRA)

Upload Joda-Time 1.3


 Key: MAVENUPLOAD-1028
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1028
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stephen Colebourne


http://joda-time.sourceforge.net/joda-time-1.3-bundle.jar
  
http://joda-time.sourceforge.net
http://joda-time.sourceforge.net/team-list.html
  
Please upload joda-time 1.3


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPJDIFF-9) Jdiff fails with svn

2006-07-31 Thread Stephen Colebourne (JIRA)

Jdiff fails with svn


 Key: MPJDIFF-9
 URL: http://jira.codehaus.org/browse/MPJDIFF-9
 Project: maven-jdiff-plugin
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Stephen Colebourne


The module part of the connection is ignored (JodaTime) when using jdiff. ie. 
there is an addtional level in the connection that should be used but isn't.

Error:
xdoc:init:
[echo] Generates the directory structure required for xdocs
[INFO] Working directory: C:\joda\time\target\jdiff\v1_2_000
[INFO] Command line: svn --non-interactive checkout https://svn.sourceforge.net/
svnroot/joda-time/tags/v1_2_000 v1_2_000

BUILD FAILED
File.. C:\Documents and Settings\Stephen\.maven\cache\maven-jdiff-plugin-1.5
\plugin.jelly
Element... ant:javadoc
Line.. 150
Column 39
C:\joda\time\target\jdiff\v1_2_000\src\java not found.

Properties:
maven.scm.svn.tag.base=https://svn.sourceforge.net/svnroot/joda-time/tags

POM:
  

scm:svn:https://svn.sourceforge.net/svnroot/joda-time/trunk/JodaTime/
http://svn.sourceforge.net/viewcvs.cgi/joda-time/trunk/JodaTime/
  


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

75 matches

Mail list logo