[jira] [Updated] (MSITE-802) Support more than one directory
[ https://issues.apache.org/jira/browse/MSITE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-802: Fix Version/s: 3.7 > Support more than one directory > --- > > Key: MSITE-802 > URL: https://issues.apache.org/jira/browse/MSITE-802 > Project: Maven Site Plugin > Issue Type: Task >Reporter: Allen Wittenauer >Assignee: Hervé Boutemy >Priority: Minor > Fix For: 3.7 > > > It would be great if maven-site-plugin could support more than one site > directory per module. Specifically, I'm looking for a way to process > generated content without copying all of src/site into target where my > generated content is sitting or using a separate module that only handles > generated content to get aggregated later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-802) Support more than one directory
[ https://issues.apache.org/jira/browse/MSITE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-802: Issue Type: Task (was: New Feature) > Support more than one directory > --- > > Key: MSITE-802 > URL: https://issues.apache.org/jira/browse/MSITE-802 > Project: Maven Site Plugin > Issue Type: Task >Reporter: Allen Wittenauer >Priority: Minor > Fix For: 3.7 > > > It would be great if maven-site-plugin could support more than one site > directory per module. Specifically, I'm looking for a way to process > generated content without copying all of src/site into target where my > generated content is sitting or using a separate module that only handles > generated content to get aggregated later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MSITE-802) Support more than one directory
[ https://issues.apache.org/jira/browse/MSITE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy reassigned MSITE-802: --- Assignee: Hervé Boutemy > Support more than one directory > --- > > Key: MSITE-802 > URL: https://issues.apache.org/jira/browse/MSITE-802 > Project: Maven Site Plugin > Issue Type: Task >Reporter: Allen Wittenauer >Assignee: Hervé Boutemy >Priority: Minor > Fix For: 3.7 > > > It would be great if maven-site-plugin could support more than one site > directory per module. Specifically, I'm looking for a way to process > generated content without copying all of src/site into target where my > generated content is sitting or using a separate module that only handles > generated content to get aggregated later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSITE-801) Expand features in site.xml for menus
[ https://issues.apache.org/jira/browse/MSITE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248389#comment-16248389 ] Hervé Boutemy commented on MSITE-801: - bq. t's kind of awful to have to effectively re-implement the built-in menu stuff just because we want to add a few custom characters to some of the menus did you know that when creating a skin, you're de-facto re-implementing the built in menu stuff? I suppose that most people just copy the file, completely ignoring that. But just look at the first macro in https://github.com/apache/maven-fluido-skin/blob/master/src/main/resources/META-INF/maven/site-macros.vm "menu stuff" is just not part of Doxia Site Rendering: it's part of each skin that's why in MSKINS-128 I split site.vm into site.vm+site-macros.vm: just to ease maintenance by differentiating the general html template part from the macros doing menus, breadcrumbs and so on what we can do is adding the feature to Fluido skin, using a convention on img content (specific form of url): this way, people copy/pasting Fluido site-macros.vm will have the feature, which will be kind of shared... > Expand features in site.xml for menus > - > > Key: MSITE-801 > URL: https://issues.apache.org/jira/browse/MSITE-801 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: Allen Wittenauer >Priority: Minor > > The short story is that I'm looking for a way to configure FontAwesome icons > in menu items. > (for an example, see https://yetus.apache.org/ 's Get Involved menu as built > with Middleman 3.) > Since that's rather specific :), there does seem to be a feature gap here. It > would be really useful if site.xml parsing could support either optional > fields to pass to skins, allow HTML elements in menu items, or some other way > that this could be accomplished. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248453#comment-16248453 ] Robert Scholte commented on MJAR-193: - A thought:the maven-jar-plugin has either an option to discover extensionpoints or that you can specify them in the configuration. While building up the manifist file, these extension points can help to enrich that data. > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248456#comment-16248456
]
Robert Scholte commented on SUREFIRE-1424:
--
You can disable it by adding another value for {{--add-modules}}.
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-489) Javadoc plugin needs to set module path
[
https://issues.apache.org/jira/browse/MJAVADOC-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248459#comment-16248459
]
Robert Scholte commented on MJAVADOC-489:
-
I think upgrading the WIKI is probably better.
> Javadoc plugin needs to set module path
> ---
>
> Key: MJAVADOC-489
> URL: https://issues.apache.org/jira/browse/MJAVADOC-489
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
> Environment: macOS 10.12.5 build 175
> $java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+175)
> Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)
>Reporter: Philippe Marschall
> Fix For: 3.0.0
>
>
> Javadoc generation fails for Jigsaw modules that depends on other Jigsaw
> modules:
> {code}
> module c {
> requires a;
> requires b;
> }
> {code}
> while javadoc generation succeeds for modules a and b which have no module
> dependencies javadoc generation fails for module c which has module
> dependencies
> {code}
> MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /Users/user/git/jigsaw/src/main/java/module-info.java:3: error: module not
> found: a
> [ERROR] requires a;
> [ERROR]^
> [ERROR] /Users/user/git/jigsaw/src/main/java/module-info.java:4: error:
> module not found: b
> [ERROR] requires b;
> [ERROR]^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/javadoc
> @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/user/git/jigsaw/target/apidocs' dir.
> {code}
> The issue seems to be that the javadoc plugin only ever sets {{-classpath}}.
> The javadoc plugin would have to set {{--module-path}} like the compiler
> plugin does.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MJAVADOC-489) Javadoc plugin needs to set module path
[
https://issues.apache.org/jira/browse/MJAVADOC-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-489:
Fix Version/s: 3.0.0
> Javadoc plugin needs to set module path
> ---
>
> Key: MJAVADOC-489
> URL: https://issues.apache.org/jira/browse/MJAVADOC-489
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
> Environment: macOS 10.12.5 build 175
> $java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+175)
> Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)
>Reporter: Philippe Marschall
> Fix For: 3.0.0
>
>
> Javadoc generation fails for Jigsaw modules that depends on other Jigsaw
> modules:
> {code}
> module c {
> requires a;
> requires b;
> }
> {code}
> while javadoc generation succeeds for modules a and b which have no module
> dependencies javadoc generation fails for module c which has module
> dependencies
> {code}
> MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /Users/user/git/jigsaw/src/main/java/module-info.java:3: error: module not
> found: a
> [ERROR] requires a;
> [ERROR]^
> [ERROR] /Users/user/git/jigsaw/src/main/java/module-info.java:4: error:
> module not found: b
> [ERROR] requires b;
> [ERROR]^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/javadoc
> @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/user/git/jigsaw/target/apidocs' dir.
> {code}
> The issue seems to be that the javadoc plugin only ever sets {{-classpath}}.
> The javadoc plugin would have to set {{--module-path}} like the compiler
> plugin does.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248469#comment-16248469
]
Julian Reschke commented on SUREFIRE-1424:
--
[~rfscholte] - as a workaround, yes. But this should really be fixed.
[~russgold] - this is what I did in Jackrabbit:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-parent/pom.xml?r1=1812543&r2=1812634&pathrev=1812634&diff_format=h
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-499) Ignore module-info.java on earlier Java versions
[
https://issues.apache.org/jira/browse/MJAVADOC-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248472#comment-16248472
]
Robert Scholte commented on MJAVADOC-499:
-
I don't understand the reason why one would add a {{module-info.java}} if
they're not going to use it. The introduction of this magic will do more harm.
People will assume that the module-info is being compiled if it is there. If
they accidentally are using an older Java version it should not be ignored.
Instead the build must fail to make them aware they're using the wrong Java
version.
> 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] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248474#comment-16248474
]
Robert Scholte commented on SUREFIRE-1424:
--
Of course this must be fixed, no question about that. It was a first attempt to
solve some Java9 related issues. It felt incorrect to me, which is now
confirmed.
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNGSITE-321) Replace "clean install" with "verify" as much as possible
Robert Scholte created MNGSITE-321:
--
Summary: Replace "clean install" with "verify" as much as possible
Key: MNGSITE-321
URL: https://issues.apache.org/jira/browse/MNGSITE-321
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
I'm trying to learn everybody that they should run {{mvn verify}} instead of
{{mvn clean install}} and why that is better. Kind of embarrassing I still see
it on our pages, e.g.
https://maven.apache.org/run-maven/index.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-286) requireProperty from active profiles are incorrectly mixed
Ralf created MENFORCER-286:
--
Summary: requireProperty from active profiles are incorrectly mixed
Key: MENFORCER-286
URL: https://issues.apache.org/jira/browse/MENFORCER-286
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0-M1
Environment: Apache Maven 3.3.9
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
20170722_357405 (JIT enabled, AOT enabled)
Reporter: Ralf
Attachments: pom.xml
I have two profiles that both use the enforcer plugin to check some properties.
* profile1 checks the property "test.user" for the value "tester"
* profile2 checks that the property "inttest.user" is set.
If either profile is enabled everything works fine.
If both profiles are enabled the property "intest.user" is tested for the value
"tester". That fails.
The problem depends on the ordering of the profiles in the pom. If I move
profile2 above profile1 everything works fine. Unfortunately I can't use this
workaround in my real live project.
Take the attached pom and run the following:
{code}
mvn validate# OK
mvn validate -Pprofile1 # OK
mvn validate -Pprofile2 # OK
mvn validate -Pprofile1 -Pprofile2 # FAILS
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNGSITE-322) Remove IDE goals
Robert Scholte created MNGSITE-322:
--
Summary: Remove IDE goals
Key: MNGSITE-322
URL: https://issues.apache.org/jira/browse/MNGSITE-322
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Robert Scholte
Nowadays there's close to no reason to execute specific IDE maven-plugins.
Especially {{eclipse:eclipse}} will do more harm than good.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-286) requireProperty from active profiles are incorrectly mixed
[
https://issues.apache.org/jira/browse/MENFORCER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf updated MENFORCER-286:
---
Priority: Minor (was: Major)
> requireProperty from active profiles are incorrectly mixed
> --
>
> Key: MENFORCER-286
> URL: https://issues.apache.org/jira/browse/MENFORCER-286
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
> Environment: Apache Maven 3.3.9
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20170722_357405 (JIT enabled, AOT enabled)
>Reporter: Ralf
>Priority: Minor
> Attachments: pom.xml
>
>
> I have two profiles that both use the enforcer plugin to check some
> properties.
> * profile1 checks the property "test.user" for the value "tester"
> * profile2 checks that the property "inttest.user" is set.
> If either profile is enabled everything works fine.
> If both profiles are enabled the property "intest.user" is tested for the
> value "tester". That fails.
> The problem depends on the ordering of the profiles in the pom. If I move
> profile2 above profile1 everything works fine. Unfortunately I can't use this
> workaround in my real live project.
> Take the attached pom and run the following:
> {code}
> mvn validate# OK
> mvn validate -Pprofile1 # OK
> mvn validate -Pprofile2 # OK
> mvn validate -Pprofile1 -Pprofile2 # FAILS
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-286) requireProperty from active profiles are incorrectly mixed
[
https://issues.apache.org/jira/browse/MENFORCER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf updated MENFORCER-286:
---
Priority: Major (was: Minor)
> requireProperty from active profiles are incorrectly mixed
> --
>
> Key: MENFORCER-286
> URL: https://issues.apache.org/jira/browse/MENFORCER-286
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
> Environment: Apache Maven 3.3.9
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20170722_357405 (JIT enabled, AOT enabled)
>Reporter: Ralf
> Attachments: pom.xml
>
>
> I have two profiles that both use the enforcer plugin to check some
> properties.
> * profile1 checks the property "test.user" for the value "tester"
> * profile2 checks that the property "inttest.user" is set.
> If either profile is enabled everything works fine.
> If both profiles are enabled the property "intest.user" is tested for the
> value "tester". That fails.
> The problem depends on the ordering of the profiles in the pom. If I move
> profile2 above profile1 everything works fine. Unfortunately I can't use this
> workaround in my real live project.
> Take the attached pom and run the following:
> {code}
> mvn validate# OK
> mvn validate -Pprofile1 # OK
> mvn validate -Pprofile2 # OK
> mvn validate -Pprofile1 -Pprofile2 # FAILS
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MENFORCER-286) requireProperty from active profiles are incorrectly mixed
[
https://issues.apache.org/jira/browse/MENFORCER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248549#comment-16248549
]
Ralf commented on MENFORCER-286:
Aaaargghh! Problem is that the executions in both profiles have the same id.
So this my fault. Please close as invalid (can't find how to do that myself).
Sorry.
> requireProperty from active profiles are incorrectly mixed
> --
>
> Key: MENFORCER-286
> URL: https://issues.apache.org/jira/browse/MENFORCER-286
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
> Environment: Apache Maven 3.3.9
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20170722_357405 (JIT enabled, AOT enabled)
>Reporter: Ralf
> Attachments: pom.xml
>
>
> I have two profiles that both use the enforcer plugin to check some
> properties.
> * profile1 checks the property "test.user" for the value "tester"
> * profile2 checks that the property "inttest.user" is set.
> If either profile is enabled everything works fine.
> If both profiles are enabled the property "intest.user" is tested for the
> value "tester". That fails.
> The problem depends on the ordering of the profiles in the pom. If I move
> profile2 above profile1 everything works fine. Unfortunately I can't use this
> workaround in my real live project.
> Take the attached pom and run the following:
> {code}
> mvn validate# OK
> mvn validate -Pprofile1 # OK
> mvn validate -Pprofile2 # OK
> mvn validate -Pprofile1 -Pprofile2 # FAILS
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MENFORCER-286) requireProperty from active profiles are incorrectly mixed
[
https://issues.apache.org/jira/browse/MENFORCER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MENFORCER-286.
---
Resolution: Invalid
thanks for your report (and work on evaluation, that lead to this self close :)
)
> requireProperty from active profiles are incorrectly mixed
> --
>
> Key: MENFORCER-286
> URL: https://issues.apache.org/jira/browse/MENFORCER-286
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
> Environment: Apache Maven 3.3.9
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
> 20170722_357405 (JIT enabled, AOT enabled)
>Reporter: Ralf
> Attachments: pom.xml
>
>
> I have two profiles that both use the enforcer plugin to check some
> properties.
> * profile1 checks the property "test.user" for the value "tester"
> * profile2 checks that the property "inttest.user" is set.
> If either profile is enabled everything works fine.
> If both profiles are enabled the property "intest.user" is tested for the
> value "tester". That fails.
> The problem depends on the ordering of the profiles in the pom. If I move
> profile2 above profile1 everything works fine. Unfortunately I can't use this
> workaround in my real live project.
> Take the attached pom and run the following:
> {code}
> mvn validate# OK
> mvn validate -Pprofile1 # OK
> mvn validate -Pprofile2 # OK
> mvn validate -Pprofile1 -Pprofile2 # FAILS
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MCOMPILER-308) Compiler failure but no compiler message on the console
[
https://issues.apache.org/jira/browse/MCOMPILER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-308:
-
Description:
Using:
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 9, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
Steps to reproduce:
* git clone https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
* git checkout tags/log4j-2.9.1-rc1
* mvn -e test-compile
Will give you:
{noformat}
[INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
log4j-core ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 530 source files to
C:\temp\rc\apache-log4j-2.9.1-src\log4j-core\target\test-classes
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [ 3.890 s]
[INFO] Apache Log4j API Java 9 support SUCCESS [ 8.330 s]
[INFO] Apache Log4j API ... SUCCESS [ 37.451 s]
[INFO] Apache Log4j Core .. FAILURE [ 55.364 s]
[INFO] Apache Log4j Core Integration Tests SKIPPED
[INFO] Apache Log4j 1.x Compatibility API . SKIPPED
[INFO] Apache Log4j SLF4J Binding . SKIPPED
[INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
[INFO] Apache Log4j Commons Logging Bridge SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j Samples: Configuration SKIPPED
[INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
[INFO] Apache Log4j OSGi .. SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO] Apache Log4j Liquibase Binding . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 01:47 min
[INFO] Finished at: 2017-09-18T10:00:51-06:00
[INFO] Final Memory: 41M/137M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project log4j-core: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project log4j-core: Compilation failure
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at
java.base/jdk.internal.refle
[jira] [Updated] (MCOMPILER-308) Compiler failure but no compiler message on the console
[
https://issues.apache.org/jira/browse/MCOMPILER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-308:
-
Description:
Using:
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 9, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
Steps to reproduce:
* git clone https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
* git checkout tags/log4j-2.9.1-rc1
* mvn -e verify
Will give you:
{noformat}
[INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
log4j-core ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 530 source files to
C:\temp\rc\apache-log4j-2.9.1-src\log4j-core\target\test-classes
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [ 3.890 s]
[INFO] Apache Log4j API Java 9 support SUCCESS [ 8.330 s]
[INFO] Apache Log4j API ... SUCCESS [ 37.451 s]
[INFO] Apache Log4j Core .. FAILURE [ 55.364 s]
[INFO] Apache Log4j Core Integration Tests SKIPPED
[INFO] Apache Log4j 1.x Compatibility API . SKIPPED
[INFO] Apache Log4j SLF4J Binding . SKIPPED
[INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
[INFO] Apache Log4j Commons Logging Bridge SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j Samples: Configuration SKIPPED
[INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
[INFO] Apache Log4j OSGi .. SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO] Apache Log4j Liquibase Binding . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 01:47 min
[INFO] Finished at: 2017-09-18T10:00:51-06:00
[INFO] Final Memory: 41M/137M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project log4j-core: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project log4j-core: Compilation failure
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at
java.base/jdk.internal.reflect.Nat
[jira] [Commented] (MCOMPILER-308) Compiler failure but no compiler message on the console
[
https://issues.apache.org/jira/browse/MCOMPILER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248567#comment-16248567
]
Robert Scholte commented on MCOMPILER-308:
--
Seems to be JDK9 related, I cannot reproduce it with JDK1.7 or JDK1.8
I'll try to get in contact with the JDK team.
> Compiler failure but no compiler message on the console
> ---
>
> Key: MCOMPILER-308
> URL: https://issues.apache.org/jira/browse/MCOMPILER-308
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Gary Gregory
>
> Using:
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> Steps to reproduce:
> * git clone https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> * git checkout tags/log4j-2.9.1-rc1
> * mvn -e verify
> Will give you:
> {noformat}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
> log4j-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 530 source files to
> C:\temp\rc\apache-log4j-2.9.1-src\log4j-core\target\test-classes
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [ 3.890
> s]
> [INFO] Apache Log4j API Java 9 support SUCCESS [ 8.330
> s]
> [INFO] Apache Log4j API ... SUCCESS [ 37.451
> s]
> [INFO] Apache Log4j Core .. FAILURE [ 55.364
> s]
> [INFO] Apache Log4j Core Integration Tests SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:47 min
> [INFO] Finished at: 2017-09-18T10:00:51-06:00
> [INFO] Final Memory: 41M/137M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>
[jira] [Closed] (MJAVADOC-489) Javadoc plugin needs to set module path
[
https://issues.apache.org/jira/browse/MJAVADOC-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-489.
---
Resolution: Fixed
Assignee: Robert Scholte
Fixed in [r1802722|http://svn.apache.org/viewvc/?view=rev&rev=1802722]
> Javadoc plugin needs to set module path
> ---
>
> Key: MJAVADOC-489
> URL: https://issues.apache.org/jira/browse/MJAVADOC-489
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
> Environment: macOS 10.12.5 build 175
> $java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+175)
> Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)
>Reporter: Philippe Marschall
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> Javadoc generation fails for Jigsaw modules that depends on other Jigsaw
> modules:
> {code}
> module c {
> requires a;
> requires b;
> }
> {code}
> while javadoc generation succeeds for modules a and b which have no module
> dependencies javadoc generation fails for module c which has module
> dependencies
> {code}
> MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /Users/user/git/jigsaw/src/main/java/module-info.java:3: error: module not
> found: a
> [ERROR] requires a;
> [ERROR]^
> [ERROR] /Users/user/git/jigsaw/src/main/java/module-info.java:4: error:
> module not found: b
> [ERROR] requires b;
> [ERROR]^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/javadoc
> @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/user/git/jigsaw/target/apidocs' dir.
> {code}
> The issue seems to be that the javadoc plugin only ever sets {{-classpath}}.
> The javadoc plugin would have to set {{--module-path}} like the compiler
> plugin does.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MSCMPUB-32) improve doc for GitHub gh-pages use in orphan Git branch
Hervé Boutemy created MSCMPUB-32: Summary: improve doc for GitHub gh-pages use in orphan Git branch Key: MSCMPUB-32 URL: https://issues.apache.org/jira/browse/MSCMPUB-32 Project: Maven SCM Publish Plugin Issue Type: Improvement Affects Versions: 1.1 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.2 import explanations on orphan branch init in http://www.mojohaus.org/development/performing-a-release.html#Staging_the_Release see Git commit https://github.com/mojohaus/mojohaus.github.io/commit/422ae4b6cfbb1320303cf8c03c8d9e8466c4facb -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSCMPUB-33) add color output to improve UX
Hervé Boutemy created MSCMPUB-33:
Summary: add color output to improve UX
Key: MSCMPUB-33
URL: https://issues.apache.org/jira/browse/MSCMPUB-33
Project: Maven SCM Publish Plugin
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
Fix For: 1.2
{noformat}[INFO] --- maven-scm-publish-plugin:1.1:publish-scm (scm-publish) @
mojo-site ---
[INFO] Checking out the pub tree from
scm:git:ssh://g...@github.com/mojohaus/mojohaus.github.io.git into
/mojohaus.github.io/target/scmpublish-checkout
...
[INFO] Updating checkout directory with actual content in
/mojohaus.github.io/target/site
[INFO] Content consists in 15 directories and 74 files = 1 MB
[INFO] Publishing content into SCM will result in 0 addition(s), 74 update(s),
0 delete(s)
[INFO] Checking in SCM, starting at Sat Nov 11 19:28:28 CET 2017...
...
[INFO] Checked in 21 file(s) to revision null in 0 h 0 m 3 s{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248675#comment-16248675 ] Robert Scholte commented on MPDF-81: Just a note: the maven-site-plugin should be released soon, since there are some Java9 issues in it. They've already been fixed, it's only waiting for a released version of Doxia. This issue seems to slow down the release, so maybe this issue should be moved to a next release. To me having plugins working with Java 9 is more important to me right now. Any problem pushing this to Doxia 1.8.1? > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > Fix For: 1.4 > > Attachments: maven-pdf-plugin2.pdf > > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSCMPUB-32) improve doc for GitHub gh-pages use in orphan Git branch
[ https://issues.apache.org/jira/browse/MSCMPUB-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248690#comment-16248690 ] Hudson commented on MSCMPUB-32: --- SUCCESS: Integrated in Jenkins build maven-plugins #9192 (See [https://builds.apache.org/job/maven-plugins/9192/]) [MSCMPUB-32] added instruction on Git orphan branch creation (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1814988]) * (edit) maven-scm-publish-plugin/src/site/apt/various-tips.apt.vm > improve doc for GitHub gh-pages use in orphan Git branch > > > Key: MSCMPUB-32 > URL: https://issues.apache.org/jira/browse/MSCMPUB-32 > Project: Maven SCM Publish Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.2 > > > import explanations on orphan branch init in > http://www.mojohaus.org/development/performing-a-release.html#Staging_the_Release > see Git commit > https://github.com/mojohaus/mojohaus.github.io/commit/422ae4b6cfbb1320303cf8c03c8d9e8466c4facb -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248693#comment-16248693 ] Alex O'Ree commented on MPDF-81: push it if you want, i'm tied up working on other things currently > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > Fix For: 1.4 > > Attachments: maven-pdf-plugin2.pdf > > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSCMPUB-32) improve doc for GitHub gh-pages use in orphan Git branch
[ https://issues.apache.org/jira/browse/MSCMPUB-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSCMPUB-32. Resolution: Fixed > improve doc for GitHub gh-pages use in orphan Git branch > > > Key: MSCMPUB-32 > URL: https://issues.apache.org/jira/browse/MSCMPUB-32 > Project: Maven SCM Publish Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.2 > > > import explanations on orphan branch init in > http://www.mojohaus.org/development/performing-a-release.html#Staging_the_Release > see Git commit > https://github.com/mojohaus/mojohaus.github.io/commit/422ae4b6cfbb1320303cf8c03c8d9e8466c4facb -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSCMPUB-33) add color output to improve UX
[
https://issues.apache.org/jira/browse/MSCMPUB-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248717#comment-16248717
]
Hudson commented on MSCMPUB-33:
---
SUCCESS: Integrated in Jenkins build maven-plugins #9193 (See
[https://builds.apache.org/job/maven-plugins/9193/])
[MSCMPUB-33] added color to key message parts to improve UX (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1814989])
* (edit) maven-scm-publish-plugin/pom.xml
* (edit)
maven-scm-publish-plugin/src/main/java/org/apache/maven/plugins/scmpublish/AbstractScmPublishMojo.java
* (edit)
maven-scm-publish-plugin/src/main/java/org/apache/maven/plugins/scmpublish/ScmPublishPublishScmMojo.java
> add color output to improve UX
> --
>
> Key: MSCMPUB-33
> URL: https://issues.apache.org/jira/browse/MSCMPUB-33
> Project: Maven SCM Publish Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 1.2
>
>
> {noformat}[INFO] --- maven-scm-publish-plugin:1.1:publish-scm (scm-publish) @
> mojo-site ---
> [INFO] Checking out the pub tree from
> scm:git:ssh://g...@github.com/mojohaus/mojohaus.github.io.git into
> /mojohaus.github.io/target/scmpublish-checkout
> ...
> [INFO] Updating checkout directory with actual content in
> /mojohaus.github.io/target/site
> [INFO] Content consists in 15 directories and 74 files = 1 MB
> [INFO] Publishing content into SCM will result in 0 addition(s), 74
> update(s), 0 delete(s)
> [INFO] Checking in SCM, starting at Sat Nov 11 19:28:28 CET 2017...
> ...
> [INFO] Checked in 21 file(s) to revision null in 0 h 0 m 3 s{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINVOKER-228) Fix documentation: "Using with other integration test frameworks" page
Alberto Scotto created MINVOKER-228:
---
Summary: Fix documentation: "Using with other integration test
frameworks" page
Key: MINVOKER-228
URL: https://issues.apache.org/jira/browse/MINVOKER-228
Project: Maven Invoker Plugin
Issue Type: Task
Reporter: Alberto Scotto
https://maven.apache.org/plugins/maven-invoker-plugin/examples/integration-test-verify.html
In the example the goal 'install' is missing from the list of goals under the
tag execution.
This causes the integration tests to either use an old version of the plugin
under test, or just fail if the plugin has never been installed in the local M2
repo before.
Please fix the example to be like this:
{{
maven-invoker-plugin
3.0.1
integration-test
install
integration-test
verify
}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MINVOKER-228) Fix documentation: "Using with other integration test frameworks" page
[
https://issues.apache.org/jira/browse/MINVOKER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Scotto updated MINVOKER-228:
Description:
https://maven.apache.org/plugins/maven-invoker-plugin/examples/integration-test-verify.html
In the example the goal 'install' is missing from the list of goals under the
tag execution.
This causes the integration tests to either use an old version of the plugin
under test, or just fail if the plugin has never been installed in the local M2
repo before.
Please fix the example to be like this:
{code:java}
maven-invoker-plugin
3.0.1
integration-test
install
integration-test
verify
{code}
was:
https://maven.apache.org/plugins/maven-invoker-plugin/examples/integration-test-verify.html
In the example the goal 'install' is missing from the list of goals under the
tag execution.
This causes the integration tests to either use an old version of the plugin
under test, or just fail if the plugin has never been installed in the local M2
repo before.
Please fix the example to be like this:
{{
maven-invoker-plugin
3.0.1
integration-test
install
integration-test
verify
}}
> Fix documentation: "Using with other integration test frameworks" page
> --
>
> Key: MINVOKER-228
> URL: https://issues.apache.org/jira/browse/MINVOKER-228
> Project: Maven Invoker Plugin
> Issue Type: Task
>Reporter: Alberto Scotto
>
> https://maven.apache.org/plugins/maven-invoker-plugin/examples/integration-test-verify.html
> In the example the goal 'install' is missing from the list of goals under the
> tag execution.
> This causes the integration tests to either use an old version of the plugin
> under test, or just fail if the plugin has never been installed in the local
> M2 repo before.
> Please fix the example to be like this:
> {code:java}
>
>
>
>
> maven-invoker-plugin
> 3.0.1
>
>
> integration-test
>
> install
> integration-test
> verify
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
