[jira] [Comment Edited] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786484#comment-16786484
]
Thomas Mortagne edited comment on MJAVADOC-584 at 3/7/19 7:51 AM:
--
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of numpackages ? Like
excluding everything under {{com.mycompany.myapp.package3}} in the example.
was (Author: tmortagne):
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of numpackages ?
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786484#comment-16786484
]
Thomas Mortagne edited comment on MJAVADOC-584 at 3/7/19 7:51 AM:
--
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of sumpackages ? Like
excluding everything under {{com.mycompany.myapp.package3}} in the example.
was (Author: tmortagne):
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of numpackages ? Like
excluding everything under {{com.mycompany.myapp.package3}} in the example.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786484#comment-16786484
]
Thomas Mortagne edited comment on MJAVADOC-584 at 3/7/19 7:51 AM:
--
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of subpackages ? Like
excluding everything under {{com.mycompany.myapp.package3}} in the example.
was (Author: tmortagne):
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of sumpackages ? Like
excluding everything under {{com.mycompany.myapp.package3}} in the example.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786484#comment-16786484
]
Thomas Mortagne commented on MJAVADOC-584:
--
{quote}
a wildcard at the beginning should match 1 or more folders
any other wildcard must match exactly one folder
{quote}
Does it means it not possible anymore to match any number of numpackages ?
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786483#comment-16786483
]
Thomas Mortagne edited comment on MJAVADOC-584 at 3/7/19 7:44 AM:
--
bq. In your case your package ends with internal, so it doesn't match
{{\*.internal.*}} anymore
OK thanks for the hint, I did not noticed it was only for final internal
packages.
was (Author: tmortagne):
bq. In your case your package ends with internal, so it doesn't match
*.internal.* anymore
OK thanks for the hint, I did not noticed it was only for final internal
packages.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786483#comment-16786483
]
Thomas Mortagne commented on MJAVADOC-584:
--
bq. In your case your package ends with internal, so it doesn't match
*.internal.* anymore
OK thanks for the hint, I did not noticed it was only for final internal
packages.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-67) The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11
[
https://issues.apache.org/jira/browse/MRESOLVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786166#comment-16786166
]
Michael Osipov commented on MRESOLVER-67:
-
https://github.com/apache/felix/pull/114
https://jira.mongodb.org/plugins/servlet/mobile#issue/JAVA-2559
> The Maven resolver API 1.3.2 JAR deployed on Maven central has been built
> with Java 11
> --
>
> Key: MRESOLVER-67
> URL: https://issues.apache.org/jira/browse/MRESOLVER-67
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.3.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Fix For: 1.3.3
>
>
> bq. Build-Jdk: 11.0.1
> Makes it unusable in Java 8. Example of problem:
> {quote}
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy(AbstractTransporter.java:254)
> {quote}
> See
> https://mail-archives.apache.org/mod_mbox/maven-dev/201903.mbox/%3c64fbf6c9-0868-5da9-b42a-77500458b...@apache.org%3e
> for more details.
> I see 1.3.2 is not marked as released on Jira. Maybe it was not even supposed
> to be on Maven central in the first place ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-scripting-plugin] eolivelli commented on issue #3: [MSCRIPTING-1] Squashed all commits from MSCRIPTING-1 branch
eolivelli commented on issue #3: [MSCRIPTING-1] Squashed all commits from MSCRIPTING-1 branch URL: https://github.com/apache/maven-scripting-plugin/pull/3#issuecomment-470265579 Sorry. I did have time to commit. I will try to be back on this as soon as possible. I will also try to prepare for a first release of the plugin This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-1388) Transitive Dependencies in a profile are not used
[
https://issues.apache.org/jira/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786038#comment-16786038
]
Robert Scholte commented on MNG-1388:
-
[~divStar] download attached pom-file (optionally rename it)
{{mvn -f mng1388.pom verify}} succeeds building only A
{{mvn -f mng1388.pom verify -Psome-profile}} fails due to missing directories B
and C (which makes sense).
Profiled modules are recognized, so I don't the issue.
> Transitive Dependencies in a profile are not used
> -
>
> Key: MNG-1388
> URL: https://issues.apache.org/jira/browse/MNG-1388
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0
> Environment: Windows XP using Maven 2.0.
>Reporter: dbradicich
>Priority: Major
> Attachments: mng1388.pom
>
>
> I have a jar project file that defines a dependency inside a certain profile.
> If I then include that project inside of another war project, the
> dependencies defined in the jar project's profile isn't getting transferred
> over to the war.
> Ie we have this:
> A depends on SQL or Oracle depending on profile
> B depends on A.
> If sql profile is active, I would expect that when I build B, it pulls
> the transitive dependancy on sql from A.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://issues.apache.org/jira/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-1388: Attachment: mng1388.pom > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://issues.apache.org/jira/browse/MNG-1388 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: dbradicich >Priority: Major > Attachments: mng1388.pom > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-67) The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11
[
https://issues.apache.org/jira/browse/MRESOLVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRESOLVER-67:
Fix Version/s: 1.3.3
> The Maven resolver API 1.3.2 JAR deployed on Maven central has been built
> with Java 11
> --
>
> Key: MRESOLVER-67
> URL: https://issues.apache.org/jira/browse/MRESOLVER-67
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.3.2
>Reporter: Thomas Mortagne
>Priority: Blocker
> Fix For: 1.3.3
>
>
> bq. Build-Jdk: 11.0.1
> Makes it unusable in Java 8. Example of problem:
> {quote}
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy(AbstractTransporter.java:254)
> {quote}
> See
> https://mail-archives.apache.org/mod_mbox/maven-dev/201903.mbox/%3c64fbf6c9-0868-5da9-b42a-77500458b...@apache.org%3e
> for more details.
> I see 1.3.2 is not marked as released on Jira. Maybe it was not even supposed
> to be on Maven central in the first place ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-67) The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11
[
https://issues.apache.org/jira/browse/MRESOLVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786022#comment-16786022
]
Robert Scholte commented on MRESOLVER-67:
-
We need to add the
[requireJavaVersion|https://maven.apache.org/enforcer/enforcer-rules/requireJavaVersion.html]
enforcer rule with version (,9) to the {{apache-release}} profile to prevent
this in the future.
> The Maven resolver API 1.3.2 JAR deployed on Maven central has been built
> with Java 11
> --
>
> Key: MRESOLVER-67
> URL: https://issues.apache.org/jira/browse/MRESOLVER-67
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.3.2
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> bq. Build-Jdk: 11.0.1
> Makes it unusable in Java 8. Example of problem:
> {quote}
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy(AbstractTransporter.java:254)
> {quote}
> See
> https://mail-archives.apache.org/mod_mbox/maven-dev/201903.mbox/%3c64fbf6c9-0868-5da9-b42a-77500458b...@apache.org%3e
> for more details.
> I see 1.3.2 is not marked as released on Jira. Maybe it was not even supposed
> to be on Maven central in the first place ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785995#comment-16785995
]
Robert Scholte commented on MJAVADOC-584:
-
The documentation of the parameter was updates (see
https://github.com/apache/maven-javadoc-plugin/commit/936cf7d5c91f5f3fa0fc54c1326601432374b112
) but the example-pages were missed.
In your case your package ends with {{internal}}, so it doesn't match
{{\*.internal.\*}} anymore because there's no subpackages. A dot is now always
a package-separator (which kept the regular expression clean).
A PR to update the documentation is appreciated.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Blocker
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-584:
Priority: Minor (was: Blocker)
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-738) SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems more correct
[
https://issues.apache.org/jira/browse/MSITE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785813#comment-16785813
]
Steve Brown commented on MSITE-738:
---
This is broken in version 3.7.1 of the site plugin and an example of the impact
is that the site for a child pom cannot be deployed to Artifactory because
Artifactory does not allow relative paths (although they are addressing the
issue for downloads from remote sites
([RTFACT-16457|https://www.jfrog.com/jira/browse/RTFACT-16457]). Artifactory
returns this error:
{{"status" : 500,"}}
{{"Path element cannot end with a dot: sites/ ... redacted ... */../*"}}
> SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems
> more correct
>
>
> Key: MSITE-738
> URL: https://issues.apache.org/jira/browse/MSITE-738
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.4
>Reporter: Grégory Joseph
>Priority: Major
>
> The javadoc of this method seems to be the desired behavior:
> {code}
> /**
> * Deploy directly to the current project's distribution management site.
> */
> @Override
> protected Site determineDeploySite()
> throws MojoExecutionException
> {
> return getSite( getTopLevelProject( project ) );
> }
> {code}
> However, the code indicates it goes all the way in the parent pom hierarchy ?
> Why ?
> * The outcome is inconsistent with the effective-pom
> * I'd assume if my pom declares a {{distributionManagement/site}} section, it
> should be used, rather than the site plugin trying to be smarter and use the
> parent pom's info then somewhat relativize ? This leads to the same issues I
> bumped into a couple years ago (when I didn't bother plugging my debugger in)
> :
> http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html
> This can cause at least two problems:
> * One can't deploy a site to a host that's different than that of the parent
> pom
> * Permissions on the server-side might not be applied correctly (perhaps the
> project's deployer doesn't have permissions to deploy into the path
> configured in the parent, but does in the path of his project.. however we
> try to deploy to {{...parent/../../project/...}}.
> Additionally, this just get confusing, because {{mvn help:effective-pom}}
> gives me the {{distributionManagement/site}} section I expect, but the site
> plugin ends up doing something else.
> Reverting to {code}
> protected Site determineDeploySite()
> throws MojoExecutionException
> {
> return getSite( project );
> }
> {code}
> Fixes the problem as far as I can tell, since project is already
> resolved/effective model, isn't it ? I'm not sure what sure what commit
> #1480820 was fixing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
Ivica Mikic created MDEPLOY-252: --- Summary: Deploy current archive without creating new archive (jar, war, ear) Key: MDEPLOY-252 URL: https://issues.apache.org/jira/browse/MDEPLOY-252 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy Affects Versions: 2.8.2 Reporter: Ivica Mikic It would be great to be able to deploy current archive file (jar, war, ear) without creating a new one, to preserve timestamp from previous package or install run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-584) excludePackageNames is not working as documented anymore
Thomas Mortagne created MJAVADOC-584:
Summary: excludePackageNames is not working as documented anymore
Key: MJAVADOC-584
URL: https://issues.apache.org/jira/browse/MJAVADOC-584
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Thomas Mortagne
We have the following configuration at XWiki:
https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
We don't want to produce javadoc for internal packages. This is very similar to
the example given on
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
error related to classes located in internal packages). For example:
{noformat}
/home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
error: reference not found
* @see org.sonatype.aether.util.version.GenericVersionConstraint
{noformat}
I noticed MJAVADOC-548 but since the documentation did not changed I assumed my
use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785662#comment-16785662
]
Michael Osipov commented on MNG-6605:
-
You cannot suppress them unless you go in batch mode. if you want to retain
colors, you have to force them because stdout is not attached to a tty.
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 2019-03-06_14-06-09.png
>
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785616#comment-16785616
]
Gunnar Wagenknecht commented on MNG-6605:
-
>From looking at the output it seems that {{ConsoleMavenTransferListener}} is
>used in addition to {{Slf4jMavenTransferListener}} or some other listener that
>prints "Downloading/Downloaded" messages to stdout. At least, that's how Maven
>output looks like in the Travis CI build logs. Please have a look the attached
>screenshot.
!2019-03-06_14-06-09.png!
I run the Maven command without {{--batch-mode}} and I do get those
"Downloading/Downloaded" messages. However, I'd like a way to suppress them
without having to specify {{--batch-mode}}.
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 2019-03-06_14-06-09.png
>
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunnar Wagenknecht updated MNG-6605:
Attachment: 2019-03-06_14-06-09.png
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 2019-03-06_14-06-09.png
>
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunnar Wagenknecht updated MNG-6605:
Description:
When running Maven in batch mode (with option {{-B}}) it's possible to suppress
download messages using
"{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
Example:
{{mvn clean install -B
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
When leaving out the {{-B}} option this no longer works.
*Example:*
{noformat}
export MAVEN_OPTS='-Xmx1g
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
-Dorg.slf4j.simpleLogger.showDateTime=true
-Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
mvn clean install
{noformat}
Prints out time stamps as configured but does not suppress download progress
messages.
*Expected:*
Suppressing "Downloaded" messages from the console output should be possible
without requiring the "{{--batch-mode}}" command line argument.
*Motivation:*
Because Travis CI supports colorized output in build logs I'd like to avoid
batch mode.
was:
When running Maven in batch mode (with option {{-B}}) it's possible to suppress
download messages using
"{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
Example:
{{mvn clean install -B
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
This does not work in non-batch mode.
*Example:*
{noformat}
export MAVEN_OPTS='-Xmx1g
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
-Dorg.slf4j.simpleLogger.showDateTime=true
-Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
mvn clean install
{noformat}
Prints out time stamps as configured but does not suppress download progress
messages.
*Motivation:*
Because Travis CI supports colorized output in build logs I'd like to avoid
batch mode.
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6605:
Fix Version/s: waiting-for-feedback
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> This does not work in non-batch mode.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785578#comment-16785578
]
Michael Osipov commented on MNG-6605:
-
{{Slf4jMavenTransferListener}} is not used in interactive mode. It writes to
[{{stdout}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/transfer/ConsoleMavenTransferListener.java].
It is not clear what you really request.
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> This does not work in non-batch mode.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-583) javadoc: error - The code being documented uses modules but the packages defined in {URL} are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785521#comment-16785521
]
Sjoerd Talsma commented on MJAVADOC-583:
{quote}Could it be as simple as a Set having been replaced by a non-unique
collection somewhere in the plugin?
{quote}
Unfortunately, with the {{packages}} files equal, I still get the _class Timing
clashes with package of same name_ in the new plugin.
* Packages should be fixed regardless, but turns out not to be the cause for
this problem. Should I create a new issue for the duplicate packages?
The difference must be in the {{options}} then.
I'll look further..
> javadoc: error - The code being documented uses modules but the packages
> defined in {URL} are in the unnamed module
> ---
>
> Key: MJAVADOC-583
> URL: https://issues.apache.org/jira/browse/MJAVADOC-583
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
> Environment: Travis CI, toolchain with openjdk 11.0.2
>Reporter: Sjoerd Talsma
>Priority: Major
> Attachments:
> context-propagation-dependabot-maven-org.apache.maven.plugins-maven-javadoc-plugin-3.1.0.zip,
> packages-3.0.1, packages-3.1.0
>
>
> My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
> generating both 'jar' and 'aggregate-jar' documentation.
> This seems to inversely relate to MJAVADOC-555 somehow.
> The following error occurs:
> {quote}Exit code: 1 - javadoc: error - The code being documented uses modules
> but the packages defined in
> [https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
> are in the unnamed module
> {quote}
> _source:
> [https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
> github:
> [https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> pull-request: https://github.com/talsma-ict/context-propagation/pull/108
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-583) javadoc: error - The code being documented uses modules but the packages defined in {URL} are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sjoerd Talsma updated MJAVADOC-583:
---
Description:
My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
generating both 'jar' and 'aggregate-jar' documentation.
This seems to inversely relate to MJAVADOC-555 somehow.
The following error occurs:
{quote}Exit code: 1 - javadoc: error - The code being documented uses modules
but the packages defined in
[https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
are in the unnamed module
{quote}
_source:
[https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
github:
[https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
pull-request: https://github.com/talsma-ict/context-propagation/pull/108
was:
My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
generating both 'jar' and 'aggregate-jar' documentation.
This seems to inversely relate to MJAVADOC-555 somehow.
The following error occurs:
{quote}Exit code: 1 - javadoc: error - The code being documented uses modules
but the packages defined in
[https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
are in the unnamed module
{quote}
_source:
[https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
github:
[https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> javadoc: error - The code being documented uses modules but the packages
> defined in {URL} are in the unnamed module
> ---
>
> Key: MJAVADOC-583
> URL: https://issues.apache.org/jira/browse/MJAVADOC-583
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
> Environment: Travis CI, toolchain with openjdk 11.0.2
>Reporter: Sjoerd Talsma
>Priority: Major
> Attachments:
> context-propagation-dependabot-maven-org.apache.maven.plugins-maven-javadoc-plugin-3.1.0.zip,
> packages-3.0.1, packages-3.1.0
>
>
> My project build with toolchains, using both oracle JDK 8 and openjdk 11.0.2
> generating both 'jar' and 'aggregate-jar' documentation.
> This seems to inversely relate to MJAVADOC-555 somehow.
> The following error occurs:
> {quote}Exit code: 1 - javadoc: error - The code being documented uses modules
> but the packages defined in
> [https://javadoc.io/page/nl.talsmasoftware.context/context-propagation-root/1.0.6-SNAPSHOT/]
> are in the unnamed module
> {quote}
> _source:
> [https://travis-ci.org/talsma-ict/context-propagation/builds/501900168]_
> github:
> [https://github.com/talsma-ict/context-propagation/tree/dependabot/maven/org.apache.maven.plugins-maven-javadoc-plugin-3.1.0]
> pull-request: https://github.com/talsma-ict/context-propagation/pull/108
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1020) Cannot run release:prepare-with-pom
[ https://issues.apache.org/jira/browse/MRELEASE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] komlan updated MRELEASE-1020: - Component/s: prepare-with-pom prepare Git > Cannot run release:prepare-with-pom > --- > > Key: MRELEASE-1020 > URL: https://issues.apache.org/jira/browse/MRELEASE-1020 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git, prepare, prepare-with-pom >Affects Versions: 2.5.3 >Reporter: komlan >Priority: Major > Attachments: maven.JPG > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-enforcer] Mazorius commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
Mazorius commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-470062266 > Do you know when the release is expected? I know as much as you do. :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-enforcer] destebanm commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
destebanm commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-470038326 Thanks @Mazorius! Do you know when the release is expected? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (SUREFIRE-1645) Surefire excludedGroups not overriding groups
Ulf Lilleengen created SUREFIRE-1645:
Summary: Surefire excludedGroups not overriding groups
Key: SUREFIRE-1645
URL: https://issues.apache.org/jira/browse/SUREFIRE-1645
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.22.1
Reporter: Ulf Lilleengen
With maven-surefire-plugin 2.22.1 and junit platform 1.4.0, junit 5 tests that
have tags both in the included and excluded groups will always include the
tests. This behavior is different when adding the dependency on
junit-platform-surefire-provider 1.3.2, which will cause the exclusion to take
precedence over the inclusion.
Assuming a test is tagged with both tag1 and tag2, the following will run the
test:
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
2.22.1
tag1
tag2
{code}
Whereas the following will not run the test
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
tag1
tag2
org.junit.platform
junit-platform-surefire-provider
1.3.2
{code}
I think the appropriate thing to do is to have exclusion take precedence over
inclusion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
