[jira] [Commented] (MENFORCER-282) Add RequireProfileIdsExist to ensure al mentioned cmdline profiles exist
[ https://issues.apache.org/jira/browse/MENFORCER-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179911#comment-16179911 ] Hudson commented on MENFORCER-282: -- SUCCESS: Integrated in Jenkins build maven-enforcer #273 (See [https://builds.apache.org/job/maven-enforcer/273/]) [MENFORCER-282] Add RequireProfileIdsExist to ensure al mentioned cmdline profiles exist (rfscholte: [http://svn.apache.org/viewvc/?view=rev=1809668]) * (add) enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireProfileIdsExist.java * (edit) enforcer-rules/src/site/apt/index.apt * (add) enforcer-rules/src/site/apt/requireProfileIdsExist.apt.vm * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_failure * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_failure/invoker.properties * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_failure/pom.xml * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_failure/verify.groovy * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_success * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_success/invoker.properties * (add) maven-enforcer-plugin/src/it/projects/require-profile-ids-exist_success/pom.xml > Add RequireProfileIdsExist to ensure al mentioned cmdline profiles exist > > > Key: MENFORCER-282 > URL: https://issues.apache.org/jira/browse/MENFORCER-282 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Robert Scholte >Assignee: Robert Scholte > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-291) No possible use compilerArgs arg "-J--add-opens" multiple times
[
https://issues.apache.org/jira/browse/MCOMPILER-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179857#comment-16179857
]
Roel Spilker commented on MCOMPILER-291:
It is a big problem that it is not possible to repeat the
{noformat}-J--add-opens{noformat} argument. they are there for a reason.
The only good thing is that, at least for now, it is possible to use lombok
without specifying the {noformat}-J--add-opens{noformat} clauses. The following
worked for me:
{code:xml}
org.projectlombok
lombok
1.16.18
provided
org.apache.maven.plugins
maven-compiler-plugin
3.7.0
1.9
1.9
utf-8
true
d:/jdk9/bin/javac.exe
1.9
{code}
Sorry for the extra line-breaks. I couldn't convince JIRA not to strike my J's
:(
> No possible use compilerArgs arg "-J--add-opens" multiple times
> ---
>
> Key: MCOMPILER-291
> URL: https://issues.apache.org/jira/browse/MCOMPILER-291
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Pascal Schumacher
>
> I'm trying to a project with uses lombok to work with java 9.
> {code}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.6.1
>
> 1.8
> 1.8
> true
>
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
>
> -J--add-opens-Jjdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
>
>
>
> {code}
> {code}mvn -X compile{code} shows me that the {code}-J--add-opens{code}
> arguments are collapsed:
> {code}
> cmd.exe /X /C ""C:\Program Files\Java\jdk-9\bin\javac.exe"
> @C:/Users/User/random-beans/random-beans/target/classes/org.codehaus.plexus.compiler.javac.JavacCompiler9403484282707867963arguments
> -J--add-opens -Jjdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
> -Jjdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED"
> {code}
> which results in:
> {code}Error: Main Class jdk.compiler.com.sun.tools.javac.util=ALL-UNNAMED
> could not be found or load{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1423) empty excludes list in profile does not override excludes
Mark Lehky created SUREFIRE-1423:
Summary: empty excludes list in profile does not override excludes
Key: SUREFIRE-1423
URL: https://issues.apache.org/jira/browse/SUREFIRE-1423
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 2.20
Reporter: Mark Lehky
I have a set of tests that I want to run by themselves and only sometime. I
defined my failsafe plugin as follows:
{noformat}
org.apache.maven.plugins
maven-failsafe-plugin
2.20
**/tests/dataload/**
integration-test
verify
{noformat}
I then defined a profile as follows:
{noformat}
run.dataload.tests
maven-failsafe-plugin
**/tests/dataload/**
{noformat}
Please note the empty {{}} tag in the profile. I was hoping this
would "remove" my excludes definition from the plugin definition. However, when
I run {{mvn -Prun.dataload.tests verify}} none of my tests are run.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-282) Add RequireProfileIdsExist to ensure al mentioned cmdline profiles exist
Robert Scholte created MENFORCER-282: Summary: Add RequireProfileIdsExist to ensure al mentioned cmdline profiles exist Key: MENFORCER-282 URL: https://issues.apache.org/jira/browse/MENFORCER-282 Project: Maven Enforcer Plugin Issue Type: New Feature Components: Standard Rules Reporter: Robert Scholte Assignee: Robert Scholte -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-257) Project enforcer-rules Class RequireActiveProfile - Modification proposal for active profile inheritance
[
https://issues.apache.org/jira/browse/MENFORCER-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-257:
-
Description:
Active profiles are not inherited from a parent pom, following a proposal to
handle this issue:
From:
{code}
protected boolean isProfileActive( MavenProject project, String profileName )
{
@SuppressWarnings( "unchecked" )
List activeProfiles = project.getActiveProfiles();
if ( activeProfiles != null && !activeProfiles.isEmpty() )
{
for ( Profile profile : activeProfiles )
{
if ( profile.getId().equals( profileName ) )
{
return true;
}
}
}
return false;
}
{code}
To:
{code}
@SuppressWarnings("unchecked")
protected boolean isProfileActive(MavenProject project, String profileName)
{
boolean active = false;
while(!active && project != null) {
active = isProfileActive(project.getActiveProfiles(), profileName);
project = project.getParent();
}
return active;
}
protected boolean isProfileActive(List activeProfiles, String
profileName) {
if (activeProfiles != null && !activeProfiles.isEmpty()) {
for (Profile profile : activeProfiles) {
if (profile.getId().equals(profileName)) {
return true;
}
}
}
return false;
}
{code}
was:
Active profiles are not inherited from a parent pom, following a proposal to
handle this issue:
From:
protected boolean isProfileActive( MavenProject project, String profileName )
{
@SuppressWarnings( "unchecked" )
List activeProfiles = project.getActiveProfiles();
if ( activeProfiles != null && !activeProfiles.isEmpty() )
{
for ( Profile profile : activeProfiles )
{
if ( profile.getId().equals( profileName ) )
{
return true;
}
}
}
return false;
}
To:
@SuppressWarnings("unchecked")
protected boolean isProfileActive(MavenProject project, String profileName)
{
boolean active = false;
while(!active && project != null) {
active = isProfileActive(project.getActiveProfiles(), profileName);
project = project.getParent();
}
return active;
}
protected boolean isProfileActive(List activeProfiles, String
profileName) {
if (activeProfiles != null && !activeProfiles.isEmpty()) {
for (Profile profile : activeProfiles) {
if (profile.getId().equals(profileName)) {
return true;
}
}
}
return false;
}
> Project enforcer-rules Class RequireActiveProfile - Modification proposal for
> active profile inheritance
>
>
> Key: MENFORCER-257
> URL: https://issues.apache.org/jira/browse/MENFORCER-257
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.4.1
>Reporter: Stefano Asperti
>Priority: Minor
>
> Active profiles are not inherited from a parent pom, following a proposal to
> handle this issue:
> From:
> {code}
> protected boolean isProfileActive( MavenProject project, String profileName )
> {
> @SuppressWarnings( "unchecked" )
> List activeProfiles = project.getActiveProfiles();
> if ( activeProfiles != null && !activeProfiles.isEmpty() )
> {
> for ( Profile profile : activeProfiles )
> {
> if ( profile.getId().equals( profileName ) )
> {
> return true;
> }
> }
> }
> return false;
> }
> {code}
> To:
> {code}
> @SuppressWarnings("unchecked")
> protected boolean isProfileActive(MavenProject project, String
> profileName) {
> boolean active = false;
> while(!active && project != null) {
> active = isProfileActive(project.getActiveProfiles(),
> profileName);
> project = project.getParent();
> }
> return active;
> }
> protected boolean isProfileActive(List activeProfiles, String
> profileName) {
> if (activeProfiles != null && !activeProfiles.isEmpty()) {
> for (Profile profile : activeProfiles) {
> if (profile.getId().equals(profileName)) {
> return true;
> }
> }
> }
> return false;
> }
> {code}
--
This message was sent by Atlassian JIRA
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179705#comment-16179705 ] Robert Scholte commented on MNG-6012: - No, my idea is an argumentless enforcer rule. It just verifies if the profile specified on the commandline exists in one the the projects. > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb > Fix For: needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SCM-851) "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
[
https://issues.apache.org/jira/browse/SCM-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179693#comment-16179693
]
Robert Scholte commented on SCM-851:
Looks like the {{TfsScmProvider}} is missing unittests to cover all the scm
urls, can you help with those verifications?
> "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
> -
>
> Key: SCM-851
> URL: https://issues.apache.org/jira/browse/SCM-851
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.9.5
> Environment: All
>Reporter: Jason
>
> If you have a scm definition like:
> {{scm:tfs:https//server_name:workspace:$/TeamProject/Path/To/Project}}
> Then you will receive the following error: {{TFS Url "https" is not a valid
> URL. The TFS Url syntax is
> [[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
> This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
> rather than optional as stated in the error message.
> Workaround: Add "{{:false}}" to the URL declaration, just before the
> workspace.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179692#comment-16179692 ] Oliver Gierke commented on MNG-6012: That's a pity, as I then have to duplicate all profile names into that rule's configuration and it's easy to just forget to add to do so when a new one is added. > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb > Fix For: needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MRELEASE-989) prepare-with-pom - Cannot add release POM to SCM - API regression
[ https://issues.apache.org/jira/browse/MRELEASE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179690#comment-16179690 ] Robert Scholte commented on MRELEASE-989: - I'd prefer to upgrade the java requirement to Java 7 and solve this properly with Path instances > prepare-with-pom - Cannot add release POM to SCM - API regression > - > > Key: MRELEASE-989 > URL: https://issues.apache.org/jira/browse/MRELEASE-989 > Project: Maven Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.5.3 > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) > Maven home: D:\maven\apache-maven-3.5.0\bin\.. > Java version: 1.8.0_60, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_60\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > Included: org.apache.maven.plugins:maven-release-plugin:jar:2.5.3 > Included: > com.google.code.maven-scm-provider-svnjava:maven-scm-provider-svnjava:jar:2.1.1 > Included: org.apache.maven.scm:maven-scm-provider-svn-commons:jar:1.8 > Included: net.java.dev.jna:jna:jar:3.5.2 > Included: commons-lang:commons-lang:jar:2.6 > Included: commons-io:commons-io:jar:2.1 > Included: org.tmatesoft.svnkit:svnkit:jar:1.8.7 > Included: com.jcraft:jsch.agentproxy.svnkit-trilead-ssh2:jar:0.0.7 > Included: com.jcraft:jsch.agentproxy.core:jar:0.0.7 >Reporter: Georg Tsakumagos >Priority: Critical > Attachments: maven-console.log > > > Preparing a prepare-with-pom fails due to the changed SCM API. > The ScmFileSet constructor needs a base path and a list of relative file > paths. The release plugin provides a full qualified path. The SCM concat the > full qualified path to the basepath and is not able to locate the file. The > path should be relative as described in JavaDoc. > May the problem arise to some svn scm implementation which interprets the > JavaDoc to precise. But hey thats the reason someone writes javadoc. The > constructor org.apache.maven.scm.ScmFileSet.ScmFileSet(File, List) > should check the restriction and fail fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179671#comment-16179671 ] Robert Scholte commented on MNG-6012: - For now I'd suggest to resolve this with an enforcer rule, also much easier to release. > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb > Fix For: needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPLUGIN-325) Documentation incorrectly claims plugin:updateRegistry is bound to install phase
[
https://issues.apache.org/jira/browse/MPLUGIN-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179609#comment-16179609
]
Robert Scholte commented on MPLUGIN-325:
The wording could be improved. See
https://maven.apache.org/plugin-tools/maven-plugin-plugin/updateRegistry-mojo.html
What's actually happening if that if you specify this goal within the
execution-block, it binds itself to the install-phase if you don't specify a
phase yourself.
> Documentation incorrectly claims plugin:updateRegistry is bound to install
> phase
>
>
> Key: MPLUGIN-325
> URL: https://issues.apache.org/jira/browse/MPLUGIN-325
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
>Reporter: Andreas Sewe
>Priority: Minor
>
> The documentation
> [claims|https://maven.apache.org/components/plugin-tools/maven-plugin-plugin/usage.html#The_plugin:updateRegistry_Goal]
> that
> {quote}
> The plugin:updateRegistry goal is bound to the install phase of the build
> life cycle.
> {quote}
> But this seems not be be the case, as a {{mvn install}} does not execute it.
> It is not listed [here as a default plugin
> binding|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]
> either.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINVOKER-226) run goal failing on Windows + OracleJDK 8-144
[
https://issues.apache.org/jira/browse/MINVOKER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179602#comment-16179602
]
Robert Scholte commented on MINVOKER-226:
-
It's not not really the run that fails, but the verification.
{noformat}
[DEBUG] Error evaluating post-build script
I:\babun\.babun\cygwin\home\abelsr\github\asciidoctor-maven-plugin\target\it\resource-filtering\validate.groovy,
java.lang.Exception: Missing file
I:\babun\.babun\cygwin\home\abelsr\github\asciidoctor-maven-plugin\target\it\resource-filtering\target\docs\sample.html
java.lang.Exception: Missing file
I:\babun\.babun\cygwin\home\abelsr\github\asciidoctor-maven-plugin\target\it\resource-filtering\target\docs\sample.html
{noformat}
The message is quite clear: could this be a cygwin issue?
> run goal failing on Windows + OracleJDK 8-144
> -
>
> Key: MINVOKER-226
> URL: https://issues.apache.org/jira/browse/MINVOKER-226
> Project: Maven Invoker Plugin
> Issue Type: Bug
> Environment: Windows 7 and Windows 8.1 (2 different machines)
> Oracle JDK 8-144
> Maven 3.5.0
> maven-invoker-plugin: from 2.0.0 to 3.0.1
>Reporter: Abel Salgado Romero
>Priority: Minor
> Attachments: logs.txt
>
>
> maven-invoker-plugin (version 2.0.0) run goal started failing on Windows 8.1
> and Windows 7 with OracleJDK 8.144. It worked fine previously.
> Runs OK on MacOS (JDK 8-133 and 8-144), and Ubuntu TraviCI and Windows
> AppVeyor.
> Though the issue started with invoker 2.0.0, I am fine to focus on 3.0.1
> since it's the current version. Also 2.0.0 and 3.0.0 show a different error.
> With 3.0.1 everything seems to run fine but the validation scripts fail
> because they cannot find the generated files of the plugin being tested (see
> this branch
> https://github.com/abelsromero/asciidoctor-maven-plugin/tree/it_test_fail_on_Windows_jdk8_144).
> That's true, the target directory does not hold the generated files but
> running with -X shows that the goals are apparently executed as seen by the
> line
> {{[DEBUG] Executing: cmd.exe /X /C
> "I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven\3.5.0\bin\mvn.cmd
> -B -X -D maven.repo.local=C:\Users\abelsr\.m2\repository -s
> C:\Users\abelsr\AppData\Local\Temp\invoker-settings4165519454880719356.xml
> clean asciidoctor:process-asciidoc"}}
> Running the same command without the custom settings file in the it-tests
> directory works fine and generates the files.
> NOTE: even if you see in the paths of the attached log that files are in a
> Babun home, I run the command {{mvn clean verify -Prun-its -X}} from a
> standard cmd shell.
> Could it be, that the plugin runs the tests on another directory?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5981.
---
Resolution: Fixed
Assignee: Christian Schulte
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
>Assignee: Christian Schulte
> Fix For: 3.5.0
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MPLUGIN-325) Documentation incorrectly claims plugin:updateRegistry is bound to install phase
Andreas Sewe created MPLUGIN-325:
Summary: Documentation incorrectly claims plugin:updateRegistry is
bound to install phase
Key: MPLUGIN-325
URL: https://issues.apache.org/jira/browse/MPLUGIN-325
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.5
Environment: Apache Maven 3.5.0
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
Reporter: Andreas Sewe
Priority: Minor
The documentation
[claims|https://maven.apache.org/components/plugin-tools/maven-plugin-plugin/usage.html#The_plugin:updateRegistry_Goal]
that
{quote}
The plugin:updateRegistry goal is bound to the install phase of the build life
cycle.
{quote}
But this seems not be be the case, as a {{mvn install}} does not execute it. It
is not listed [here as a default plugin
binding|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]
either.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MRELEASE-989) prepare-with-pom - Cannot add release POM to SCM - API regression
Georg Tsakumagos created MRELEASE-989: - Summary: prepare-with-pom - Cannot add release POM to SCM - API regression Key: MRELEASE-989 URL: https://issues.apache.org/jira/browse/MRELEASE-989 Project: Maven Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.5.3 Environment: Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) Maven home: D:\maven\apache-maven-3.5.0\bin\.. Java version: 1.8.0_60, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_60\jre Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Included: org.apache.maven.plugins:maven-release-plugin:jar:2.5.3 Included: com.google.code.maven-scm-provider-svnjava:maven-scm-provider-svnjava:jar:2.1.1 Included: org.apache.maven.scm:maven-scm-provider-svn-commons:jar:1.8 Included: net.java.dev.jna:jna:jar:3.5.2 Included: commons-lang:commons-lang:jar:2.6 Included: commons-io:commons-io:jar:2.1 Included: org.tmatesoft.svnkit:svnkit:jar:1.8.7 Included: com.jcraft:jsch.agentproxy.svnkit-trilead-ssh2:jar:0.0.7 Included: com.jcraft:jsch.agentproxy.core:jar:0.0.7 Reporter: Georg Tsakumagos Priority: Critical Attachments: maven-console.log Preparing a prepare-with-pom fails due to the changed SCM API. The ScmFileSet constructor needs a base path and a list of relative file paths. The release plugin provides a full qualified path. The SCM concat the full qualified path to the basepath and is not able to locate the file. The path should be relative as described in JavaDoc. May the problem arise to some svn scm implementation which interprets the JavaDoc to precise. But hey thats the reason someone writes javadoc. The constructor org.apache.maven.scm.ScmFileSet.ScmFileSet(File, List) should check the restriction and fail fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SCM-851) "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
Jason created SCM-851:
-
Summary: "isCheckinPoliciesEnabled" is treated as mandatory in TFS
URL
Key: SCM-851
URL: https://issues.apache.org/jira/browse/SCM-851
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-tfs
Affects Versions: 1.9.5
Environment: All
Reporter: Jason
If you have a scm definition like:
{{scm:tfs:https//server_name[:port]:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
Then you will receive the following error: {{ TFS Url "https" is not a valid
URL. The TFS Url syntax is
[[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
rather than optional as stated in the error message.
Workaround: Add "{{:false}}" to the URL delcaration, just before the workspace.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SCM-851) "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
[
https://issues.apache.org/jira/browse/SCM-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated SCM-851:
--
Description:
If you have a scm definition like:
{{scm:tfs:https//server_name:workspace:$/TeamProject/Path/To/Project}}
Then you will receive the following error: {{TFS Url "https" is not a valid
URL. The TFS Url syntax is
[[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
rather than optional as stated in the error message.
Workaround: Add "{{:false}}" to the URL declaration, just before the workspace.
was:
If you have a scm definition like:
{{scm:tfs:https//server_name[:port]:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
Then you will receive the following error: {{ TFS Url "https" is not a valid
URL. The TFS Url syntax is
[[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
rather than optional as stated in the error message.
Workaround: Add "{{:false}}" to the URL delcaration, just before the workspace.
> "isCheckinPoliciesEnabled" is treated as mandatory in TFS URL
> -
>
> Key: SCM-851
> URL: https://issues.apache.org/jira/browse/SCM-851
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.9.5
> Environment: All
>Reporter: Jason
>
> If you have a scm definition like:
> {{scm:tfs:https//server_name:workspace:$/TeamProject/Path/To/Project}}
> Then you will receive the following error: {{TFS Url "https" is not a valid
> URL. The TFS Url syntax is
> [[domain\]username[;password]@]http[s]://server_name[:port][:isCheckinPoliciesEnabled]:workspace:$/TeamProject/Path/To/Project}}
> This is because the code treats "{{isCheckinPoliciesEnabled}}" as mandatory,
> rather than optional as stated in the error message.
> Workaround: Add "{{:false}}" to the URL declaration, just before the
> workspace.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINVOKER-226) run goal failing on Windows + OracleJDK 8-144
Abel Salgado Romero created MINVOKER-226:
Summary: run goal failing on Windows + OracleJDK 8-144
Key: MINVOKER-226
URL: https://issues.apache.org/jira/browse/MINVOKER-226
Project: Maven Invoker Plugin
Issue Type: Bug
Environment: Windows 7 and Windows 8.1 (2 different machines)
Oracle JDK 8-144
Maven 3.5.0
maven-invoker-plugin: from 2.0.0 to 3.0.1
Reporter: Abel Salgado Romero
Priority: Minor
Attachments: logs.txt
maven-invoker-plugin (version 2.0.0) run goal started failing on Windows 8.1
and Windows 7 with OracleJDK 8.144. It worked fine previously.
Runs OK on MacOS (JDK 8-133 and 8-144), and Ubuntu TraviCI and Windows AppVeyor.
Though the issue started with invoker 2.0.0, I am fine to focus on 3.0.1 since
it's the current version. Also 2.0.0 and 3.0.0 show a different error.
With 3.0.1 everything seems to run fine but the validation scripts fail because
they cannot find the generated files of the plugin being tested (see this
branch
https://github.com/abelsromero/asciidoctor-maven-plugin/tree/it_test_fail_on_Windows_jdk8_144).
That's true, the target directory does not hold the generated files but running
with -X shows that the goals are apparently executed as seen by the line
{{[DEBUG] Executing: cmd.exe /X /C
"I:\babun\.babun\cygwin\home\abelsr\.sdkman\candidates\maven\3.5.0\bin\mvn.cmd
-B -X -D maven.repo.local=C:\Users\abelsr\.m2\repository -s
C:\Users\abelsr\AppData\Local\Temp\invoker-settings4165519454880719356.xml
clean asciidoctor:process-asciidoc"}}
Running the same command without the custom settings file in the it-tests
directory works fine and generates the files.
NOTE: even if you see in the paths of the attached log that files are in a
Babun home, I run the command {{mvn clean verify -Prun-its -X}} from a standard
cmd shell.
Could it be, that the plugin runs the tests on another directory?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178845#comment-16178845 ] Oliver Gierke commented on MNG-6012: That's been moved to 3.5 but 3.5 has been around for a while now. What are the current plans for this? > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb > Fix For: needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178793#comment-16178793
]
Sami Jaatinen commented on MNG-5981:
Awesome, thanks for the quick response [~mcculls]!
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178780#comment-16178780
]
Stuart McCulloch commented on MNG-5981:
---
This was fixed in Maven 3.5.0 by the commit mentioned in the previous
comment (after it was reopened) so upgrade to at least 3.5.0 to pick up the
fix.
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178771#comment-16178771
]
Sami Jaatinen commented on MNG-5981:
Hi folks!
This would be a really really nice fix to have, any idea when we could get this
merged and released?
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
