[jira] [Comment Edited] (MCOMPILER-567) Fail to compile if the "generated-sources/annotations" does not exist
[
https://issues.apache.org/jira/browse/MCOMPILER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798896#comment-17798896
]
Stefan Cordes edited comment on MCOMPILER-567 at 12/20/23 10:01 AM:
I faced the similar error
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.12.0:testCompile
(default-testCompile)
Fatal error compiling: basedir
...\target\generated-test-sources\test-annotations does not exist -> [Help 1]
{code}
and investigating I see it is not on all projects but only on these where the
message
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @ ...
---
[INFO] Recompiling the module because of changed dependency.
{code}
above is printed.
*Workaround* for me was to add
{code:java}
false{code}
to the maven-compiler-plugin-configuration. (even it is not recommended, but we
are running mvn +clean+ deploy on our build anyway ).
Now same build prints
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @
... --
[INFO] Nothing to compile - all classes are up to date.{code}
and no error comes up.
was (Author: JIRAUSER303578):
I faced the similar error
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.12.0:testCompile
(default-testCompile)
Fatal error compiling: basedir
...\target\generated-test-sources\test-annotations does not exist -> [Help 1]
{code}
and investigating I see it is not on all projects but only on these where the
message
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @ ...
---
[INFO] Recompiling the module because of changed dependency.
{code}
above is printed.
*Workaround* for me was to add
{code:java}
false{code}
to the maven-compiler-plugin-configuration. (even it is not recommended, but we
are running mvn +clean+ deploy on our build anyway ).
Now same build prints
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @
... --- [INFO] Nothing to compile - all classes are up to date.{code}
and no error comes up.
> Fail to compile if the "generated-sources/annotations" does not exist
> -
>
> Key: MCOMPILER-567
> URL: https://issues.apache.org/jira/browse/MCOMPILER-567
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Jorge Solórzano
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.12.1
>
>
> On some configurations (like a Kotlin project), the cleanup of the
> generated-soruces/annotations directory returns an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: basedir
> /maven-compiler-plugin/target/it/MCOMPILER-XX/target/generated-sources/annotations
> does not exist
> at org.codehaus.plexus.util.DirectoryScanner.scan
> (DirectoryScanner.java:268)
> at
> org.codehaus.plexus.compiler.AbstractCompiler.getSourceFilesForSourceRoot
> (AbstractCompiler.java:168)
> at org.codehaus.plexus.compiler.AbstractCompiler.getSourceFiles
> (AbstractCompiler.java:194)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:138)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1187)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:212)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>
[jira] [Commented] (MCOMPILER-567) Fail to compile if the "generated-sources/annotations" does not exist
[
https://issues.apache.org/jira/browse/MCOMPILER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798896#comment-17798896
]
Stefan Cordes commented on MCOMPILER-567:
-
I faced the similar error
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.12.0:testCompile
(default-testCompile)
Fatal error compiling: basedir
...\target\generated-test-sources\test-annotations does not exist -> [Help 1]
{code}
and investigating I see it is not on all projects but only on these where the
message
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @ ...
---
[INFO] Recompiling the module because of changed dependency.
{code}
above is printed.
*Workaround* for me was to add
{code:java}
false{code}
to the maven-compiler-plugin-configuration. (even it is not recommended, but we
are running mvn +clean+ deploy on our build anyway ).
Now same build prints
{code:java}
[INFO] --- maven-compiler-plugin:3.12.0:testCompile (default-testCompile) @
... --- [INFO] Nothing to compile - all classes are up to date.{code}
and no error comes up.
> Fail to compile if the "generated-sources/annotations" does not exist
> -
>
> Key: MCOMPILER-567
> URL: https://issues.apache.org/jira/browse/MCOMPILER-567
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Jorge Solórzano
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.12.1
>
>
> On some configurations (like a Kotlin project), the cleanup of the
> generated-soruces/annotations directory returns an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: basedir
> /maven-compiler-plugin/target/it/MCOMPILER-XX/target/generated-sources/annotations
> does not exist
> at org.codehaus.plexus.util.DirectoryScanner.scan
> (DirectoryScanner.java:268)
> at
> org.codehaus.plexus.compiler.AbstractCompiler.getSourceFilesForSourceRoot
> (AbstractCompiler.java:168)
> at org.codehaus.plexus.compiler.AbstractCompiler.getSourceFiles
> (AbstractCompiler.java:194)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:138)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1187)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:212)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
>
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683336#comment-17683336
]
Stefan Cordes commented on MENFORCER-407:
-
Thanks. Good to know.
I created a {{RequireUpperBoundDeps}} bug :
https://issues.apache.org/jira/browse/MENFORCER-466
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.2.0, 3.2.1
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-466) RequireUpperBoundDeps fails on provided dependencies since 3.2.1
Stefan Cordes created MENFORCER-466:
---
Summary: RequireUpperBoundDeps fails on provided dependencies
since 3.2.1
Key: MENFORCER-466
URL: https://issues.apache.org/jira/browse/MENFORCER-466
Project: Maven Enforcer Plugin
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Apache Maven 3.8.4
(9b656c72d54e5bacbed989b64718c159fe39b537)
Java version: 1.8.0_352, vendor: Temurin
Reporter: Stefan Cordes
Attachments: console-3.1.0.txt, console-3.2.1.txt, pom.xml
The attached pom.xml works fine for
{code:java}
mvn enforcer:enforce -Dversion.maven-enforcer-plugin=3.1.0 {code}
but
{code:java}
mvn enforcer:enforce -Dversion.maven-enforcer-plugin=3.2.1 {code}
fails with
{code:java}
Rule 0: org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps failed
with message:
Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.apache.maven:maven-model:3.8.5
[provided] paths to dependency are:
+-com.canda.maven:mvnbase-maven-plugin:1.0.0-local-SNAPSHOT
+-org.apache.maven:maven-plugin-api:3.8.5 [provided]
+-org.apache.maven:maven-model:3.8.5 [provided]
and
+-com.canda.maven:mvnbase-maven-plugin:1.0.0-local-SNAPSHOT
+-org.apache.maven:maven-core:3.8.7 [provided]
+-org.apache.maven:maven-model:3.8.7 [provided]
and
+-com.canda.maven:mvnbase-maven-plugin:1.0.0-local-SNAPSHOT
+-org.apache.maven:maven-core:3.8.7 [provided]
+-org.apache.maven:maven-model-builder:3.8.7 [provided]
+-org.apache.maven:maven-model:3.8.7 [provided]
and
+-com.canda.maven:mvnbase-maven-plugin:1.0.0-local-SNAPSHOT
+-org.apache.maven:maven-core:3.8.7 [provided]
+-org.apache.maven:maven-resolver-provider:3.8.7 [provided]
+-org.apache.maven:maven-model:3.8.7 [provided] {code}
Similar to dependencyConvergence (
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17683326#comment-17683326
) the updated plugin
seems to check "provided" dependencies for upperBounds.
All provided dependencies (at least the transitive ones?) needs to be ignored
by RequireUpperBoundDeps.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683317#comment-17683317
]
Stefan Cordes commented on MENFORCER-407:
-
Looks like "provided-check" is back since
[3.2.1|https://github.com/apache/maven-enforcer/releases/tag/enforcer-3.2.1] as
after switching from 3.1.0 some provided dependencies are newly "violated":
Here 3.2.1:
{code:java}
04:21:03 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
(ci-snapshot-execution) on project mvnbase-maven-plugin:
04:21:03 [ERROR] Rule 0:
org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps failed with
message:
04:21:03 [ERROR] Failed while enforcing RequireUpperBoundDeps. The error(s)
are [
04:21:03 [ERROR] Require upper bound dependencies error for
org.apache.maven:maven-model:3.8.5 [provided] paths to dependency are:
04:21:03 [ERROR]
+-com.canda.maven:mvnbase-maven-plugin:2020.9.1-19-beta-newest-properties-SNAPSHOT
04:21:03 [ERROR] +-org.apache.maven:maven-plugin-api:3.8.5 [provided]
04:21:03 [ERROR] +-org.apache.maven:maven-model:3.8.5 [provided]
04:21:03 [ERROR] and
04:21:03 [ERROR]
+-com.canda.maven:mvnbase-maven-plugin:2020.9.1-19-beta-newest-properties-SNAPSHOT
04:21:03 [ERROR] +-org.apache.maven:maven-core:3.8.7 [provided]
04:21:03 [ERROR] +-org.apache.maven:maven-model:3.8.7 [provided]
04:21:03 [ERROR] and
04:21:03 [ERROR]
+-com.canda.maven:mvnbase-maven-plugin:2020.9.1-19-beta-newest-properties-SNAPSHOT
04:21:03 [ERROR] +-org.apache.maven:maven-core:3.8.7 [provided]
04:21:03 [ERROR] +-org.apache.maven:maven-model-builder:3.8.7 [provided]
04:21:03 [ERROR] +-org.apache.maven:maven-model:3.8.7 [provided]
04:21:03 [ERROR] and
04:21:03 [ERROR]
+-com.canda.maven:mvnbase-maven-plugin:2020.9.1-19-beta-newest-properties-SNAPSHOT
04:21:03 [ERROR] +-org.apache.maven:maven-core:3.8.7 [provided]
04:21:03 [ERROR] +-org.apache.maven:maven-resolver-provider:3.8.7
[provided]
04:21:03 [ERROR] +-org.apache.maven:maven-model:3.8.7 [provided] {code}
With 3.1.0 same pom.xml is fine:
{code:java}
12:44:31 [INFO] --- maven-enforcer-plugin:3.1.0:enforce
(ci-snapshot-execution) @ mvnbase-maven-plugin ---
12:44:31 [INFO]
12:44:31 [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
mvnbase-maven-plugin --- {code}
My understanding was that provided dependency-tree should not be checked,
correct?
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.2.0, 3.2.1
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6697) Add a fast interpolator not using reflection
[
https://issues.apache.org/jira/browse/MNG-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010670#comment-17010670
]
Stefan Cordes commented on MNG-6697:
With
{code:java}
execution.setPhase( val ){code}
in StringVisitorModelInterpolator.ModelVisitor.visit(PluginExecution)
the command
{code:java}
mvn flatten:flatten{code}
with resolveCiFriendliesOnly
the properties in ${listProfilesPhase} are replaced by the
concrete value
which lets depending projects (using above pom as parent) fail no longer be
able to change phase via -DlistProfilesPhase=...
> Add a fast interpolator not using reflection
>
>
> Key: MNG-6697
> URL: https://issues.apache.org/jira/browse/MNG-6697
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Guillaume Nodet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.6.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5612) effective pom should not contain file-based profile activation fully interpolated but with limited interpolation like seen during profile activation
[
https://issues.apache.org/jira/browse/MNG-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973262#comment-16973262
]
Stefan Cordes commented on MNG-5612:
Hi Hervé,
{{this change lets}}
{noformat}
mvn flatten:flatten{noformat}
{{fail creating an "unchanged" pom with
resolveCiFriendliesOnly, see
https://issues.apache.org/jira/browse/MNG-6802}}
(which must replace ${revision}, ${sha1} and/or ${changelist} in the pom.xml
only, see [https://maven.apache.org/maven-ci-friendly.html] )
Please find another solution for this problem. (maybe another field
getResolvedExists() in org.apache.maven.model.ActivationFile or resolve each
time the getExists() is called. (But do not change the field).
> effective pom should not contain file-based profile activation fully
> interpolated but with limited interpolation like seen during profile
> activation
>
>
> Key: MNG-5612
> URL: https://issues.apache.org/jira/browse/MNG-5612
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: issues to be reviewed for 3.0.6, 3.2.2
>
>
> mvn help:effective-pom on a pom.xml containing
> {code:xml}
>
>
> ${project.basedir}/pom.xml
>
> {code}
> shows interpolated value, which points to an existing file then is misleading
> but the profile isn't activated since $\{project.basedir} isn't interpreted
> during profile activation
> we added a warning in MNG-5608, but showing the value interpolated exactly as
> done during profile interpolation would be more logic
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6802) FileProfileActivator changes FileProfileActivator.exists which lets flattened resolveCiFriendliesOnly depending fail activating profile
[
https://issues.apache.org/jira/browse/MNG-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973255#comment-16973255
]
Stefan Cordes commented on MNG-6802:
{noformat}
// replace activation value with interpolated value{noformat}
came in with https://issues.apache.org/jira/browse/MNG-5612
(commit c17578974716822ad04e72a0ed5c8b9e5e121dab )
> FileProfileActivator changes FileProfileActivator.exists which lets flattened
> resolveCiFriendliesOnly depending fail activating profile
> ---
>
> Key: MNG-6802
> URL: https://issues.apache.org/jira/browse/MNG-6802
> Project: Maven
> Issue Type: Bug
>Reporter: Stefan Cordes
>Priority: Major
>
> In my pom.xml I have
>
> {noformat}
> ...
>
>
>cas-mule4-app
>
>
> mule-artifact.json
>
>
> ...{noformat}
>
> which worked fine.
> After switching to ci-friendly pom.xml with revision and flatten the
> published .flattened-pom.xml contains absolute path:
>
> {noformat}
>
> cas-mule4-app
>
>
>
> D:\jenkins\workspace\mulestac-multibranch_mule4-DWHLMU7ZMPDNCYK6LVMSYLB6GODEIQS7CUNRQQVSISU47ME72PRQ\mule-artifact.json
>
>
> {noformat}
>
> (which is the temporary path of our jenkins container)
> and so other projects using that pom.xml as parent will fail to activate the
> profile.
>
> This came in with MNG-1775 or a related issue via adding
> {noformat}
> // replace activation value with interpolated value
> if ( missing )
> {
> file.setMissing( path );
> }
> else
> {
> file.setExists( path );
> }
> {noformat}
> in org.apache.maven.model.profile.activation.FileProfileActivator.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6802) FileProfileActivator changes FileProfileActivator.exists which lets flattened resolveCiFriendliesOnly depending fail activating profile
[
https://issues.apache.org/jira/browse/MNG-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973234#comment-16973234
]
Stefan Cordes edited comment on MNG-6802 at 11/13/19 10:54 AM:
---
See example pom.xml here:
[https://bitbucket.org/capublic/flatten-file-expands-path/src/master/pom.xml]
and the generated .flattened-pom.xml after performing
{noformat}
mvn clean package -Drevision=local-SNAPSHOT{noformat}
[https://bitbucket.org/capublic/flatten-file-expands-path/src/1a0de49d81a292451c4d7b635383c311841fb03f/.flattened-pom.xml#lines-62]
was (Author: ca-stefan-cordes):
See example pom.xml here:
[https://bitbucket.org/capublic/flatten-file-expands-path/src/master/pom.xml]
and the generated .flattened-pom.xml after performing
{noformat}
mvn clean package -Drevision=local-SNAPSHOT{noformat}
[https://bitbucket.org/capublic/flatten-file-expands-path/src/master/.flattened-pom.xml]
> FileProfileActivator changes FileProfileActivator.exists which lets flattened
> resolveCiFriendliesOnly depending fail activating profile
> ---
>
> Key: MNG-6802
> URL: https://issues.apache.org/jira/browse/MNG-6802
> Project: Maven
> Issue Type: Bug
>Reporter: Stefan Cordes
>Priority: Major
>
> In my pom.xml I have
>
> {noformat}
> ...
>
>
>cas-mule4-app
>
>
> mule-artifact.json
>
>
> ...{noformat}
>
> which worked fine.
> After switching to ci-friendly pom.xml with revision and flatten the
> published .flattened-pom.xml contains absolute path:
>
> {noformat}
>
> cas-mule4-app
>
>
>
> D:\jenkins\workspace\mulestac-multibranch_mule4-DWHLMU7ZMPDNCYK6LVMSYLB6GODEIQS7CUNRQQVSISU47ME72PRQ\mule-artifact.json
>
>
> {noformat}
>
> (which is the temporary path of our jenkins container)
> and so other projects using that pom.xml as parent will fail to activate the
> profile.
>
> This came in with MNG-1775 or a related issue via adding
> {noformat}
> // replace activation value with interpolated value
> if ( missing )
> {
> file.setMissing( path );
> }
> else
> {
> file.setExists( path );
> }
> {noformat}
> in org.apache.maven.model.profile.activation.FileProfileActivator.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6802) FileProfileActivator changes FileProfileActivator.exists which lets flattened resolveCiFriendliesOnly depending fail activating profile
[
https://issues.apache.org/jira/browse/MNG-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973234#comment-16973234
]
Stefan Cordes commented on MNG-6802:
See example pom.xml here:
[https://bitbucket.org/capublic/flatten-file-expands-path/src/master/pom.xml]
and the generated .flattened-pom.xml after performing
{noformat}
mvn clean package -Drevision=local-SNAPSHOT{noformat}
[https://bitbucket.org/capublic/flatten-file-expands-path/src/master/.flattened-pom.xml]
> FileProfileActivator changes FileProfileActivator.exists which lets flattened
> resolveCiFriendliesOnly depending fail activating profile
> ---
>
> Key: MNG-6802
> URL: https://issues.apache.org/jira/browse/MNG-6802
> Project: Maven
> Issue Type: Bug
>Reporter: Stefan Cordes
>Priority: Major
>
> In my pom.xml I have
>
> {noformat}
> ...
>
>
>cas-mule4-app
>
>
> mule-artifact.json
>
>
> ...{noformat}
>
> which worked fine.
> After switching to ci-friendly pom.xml with revision and flatten the
> published .flattened-pom.xml contains absolute path:
>
> {noformat}
>
> cas-mule4-app
>
>
>
> D:\jenkins\workspace\mulestac-multibranch_mule4-DWHLMU7ZMPDNCYK6LVMSYLB6GODEIQS7CUNRQQVSISU47ME72PRQ\mule-artifact.json
>
>
> {noformat}
>
> (which is the temporary path of our jenkins container)
> and so other projects using that pom.xml as parent will fail to activate the
> profile.
>
> This came in with MNG-1775 or a related issue via adding
> {noformat}
> // replace activation value with interpolated value
> if ( missing )
> {
> file.setMissing( path );
> }
> else
> {
> file.setExists( path );
> }
> {noformat}
> in org.apache.maven.model.profile.activation.FileProfileActivator.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6802) FileProfileActivator changes FileProfileActivator.exists which lets flattened resolveCiFriendliesOnly depending fail activating profile
Stefan Cordes created MNG-6802:
--
Summary: FileProfileActivator changes FileProfileActivator.exists
which lets flattened resolveCiFriendliesOnly depending fail activating profile
Key: MNG-6802
URL: https://issues.apache.org/jira/browse/MNG-6802
Project: Maven
Issue Type: Bug
Reporter: Stefan Cordes
In my pom.xml I have
{noformat}
...
cas-mule4-app
mule-artifact.json
...{noformat}
which worked fine.
After switching to ci-friendly pom.xml with revision and flatten the published
.flattened-pom.xml contains absolute path:
{noformat}
cas-mule4-app
D:\jenkins\workspace\mulestac-multibranch_mule4-DWHLMU7ZMPDNCYK6LVMSYLB6GODEIQS7CUNRQQVSISU47ME72PRQ\mule-artifact.json
{noformat}
(which is the temporary path of our jenkins container)
and so other projects using that pom.xml as parent will fail to activate the
profile.
This came in with MNG-1775 or a related issue via adding
{noformat}
// replace activation value with interpolated value
if ( missing )
{
file.setMissing( path );
}
else
{
file.setExists( path );
}
{noformat}
in org.apache.maven.model.profile.activation.FileProfileActivator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Cordes updated MNG-6240:
---
Attachment: partly-jenkins-log.txt
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.5.2
>
> Attachments: Nexus-Storage.png, jenkins-log.png, maven-metadata.png,
> partly-jenkins-log.txt
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966602#comment-16966602
]
Stefan Cordes commented on MNG-6240:
Hi,
unfortunately with maven-3.6.2 I faced the wrong metadata:
created metadata.xml:
!maven-metadata.png!
But storage has
[https://nexus.canda.com/repository/SnapshotsPurgedDaily/com/canda/mule4/dt0b35/dt0b35-mule-template-test-m4/2019.9.1-4-SNAPSHOT/dt0b35-mule-template-test-m4-2019.9.1-4-20191104.101314-4.pom]
in our nexus:
!Nexus-Storage.png!
as it was logged in the jenkins job:
!jenkins-log.png!
The word "20191104.101315-4" is not appearing anywhere in the maven output.
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.5.2
>
> Attachments: Nexus-Storage.png, jenkins-log.png, maven-metadata.png
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Cordes updated MNG-6240:
---
Attachment: Nexus-Storage.png
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.5.2
>
> Attachments: Nexus-Storage.png, jenkins-log.png, maven-metadata.png
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Cordes updated MNG-6240:
---
Attachment: jenkins-log.png
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.5.2
>
> Attachments: Nexus-Storage.png, jenkins-log.png, maven-metadata.png
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Cordes updated MNG-6240:
---
Attachment: maven-metadata.png
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.5.2
>
> Attachments: maven-metadata.png
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361888#comment-361888 ] Stefan Cordes commented on MSITE-640: - ...and it is Unresolved ;-) Maven searches only central repository for imported dependencies Key: MSITE-640 URL: https://jira.codehaus.org/browse/MSITE-640 Project: Maven Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0 Environment: Windows 7 Reporter: Markus Tippmann Attachments: stacktrace.txt We are using dependencyManagement with import scope like described here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies Problem occurs only at site generation, not at build time, where it works perfectly. The site plugin tries to find the imported artifacts, but searches only the central repository and ignores the repositories in settings.xml configuration. Mirror settings work, if central is mirrored, but dependencies need to be resolved from two repositories, so one mirror does not help here. I try to attach the relevant parts of the stacktrace. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338978#comment-338978 ] Stefan Cordes commented on MSITE-640: - With Maven 3.1.1 the import dependencies are still not resolved always. (depending on local repository content ?) Please use same dependency-resolution as other plugins do (like compile). Maven searches only central repository for imported dependencies Key: MSITE-640 URL: https://jira.codehaus.org/browse/MSITE-640 Project: Maven Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0 Environment: Windows 7 Reporter: Markus Tippmann Attachments: stacktrace.txt We are using dependencyManagement with import scope like described here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies Problem occurs only at site generation, not at build time, where it works perfectly. The site plugin tries to find the imported artifacts, but searches only the central repository and ignores the repositories in settings.xml configuration. Mirror settings work, if central is mirrored, but dependencies need to be resolved from two repositories, so one mirror does not help here. I try to attach the relevant parts of the stacktrace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-643) java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
[
https://jira.codehaus.org/browse/MECLIPSE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=334287#comment-334287
]
Stefan Cordes commented on MECLIPSE-643:
{{mvn eclipse:eclipse -X | find found workspace artefact | find null}}
finds the invalid project on windows.
Please fix anyway.
java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
-
Key: MECLIPSE-643
URL: https://jira.codehaus.org/browse/MECLIPSE-643
Project: Maven Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.7
Environment: C:\Documents and
Settings\catalrc\WorkspaceXYZ\FlexGNmvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_16
Java home: C:\Program Files\Java\jdk1.6.0_16\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Ricardo Catalfo
Priority: Minor
I found an issue when executing mvn eclipse:eclipse on my workspace. Below is
the stack trace and the reason of it:
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'eclipse'.
[INFO]
[INFO] Building FlexGN
[INFO]task-segment: [eclipse:eclipse]
[INFO]
[INFO] Preparing eclipse:eclipse
[INFO] No goals needed for project - skipping
[INFO] [eclipse:eclipse {execution: default-cli}]
[INFO] Using Eclipse Workspace: C:\Documents and Settings\catalrc\WorkspaceXYZ
[INFO] Adding default classpath container:
org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.eclipse.EclipsePlugin.isAvailableAsAWorkspaceProject(EclipsePlugin.java:1889)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.useProjectReference(EclipsePlugin.java:1932)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:683)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:507)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Mar 04 12:54:48 EST 2010
[INFO] Final Memory: 7M/15M
[INFO]
---
The pom.xml for this project (FlexGN) was fine. However, I detected that
another project in the same workspace had the following pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
[jira] (MECLIPSE-643) java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
[
https://jira.codehaus.org/browse/MECLIPSE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313109#comment-313109
]
Stefan Cordes commented on MECLIPSE-643:
You can find the invalid pom.xml by executing
{{mvn -X eclipse:eclipse}}
and searching for null in lines with found workspace artefact.
The line above (starting with read workpsace project) shows you the location
of the pom.xml without groupId/artifactId.
java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
-
Key: MECLIPSE-643
URL: https://jira.codehaus.org/browse/MECLIPSE-643
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Workspace settings
Affects Versions: 2.7
Environment: C:\Documents and
Settings\catalrc\WorkspaceXYZ\FlexGNmvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_16
Java home: C:\Program Files\Java\jdk1.6.0_16\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Ricardo Catalfo
Priority: Minor
I found an issue when executing mvn eclipse:eclipse on my workspace. Below is
the stack trace and the reason of it:
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'eclipse'.
[INFO]
[INFO] Building FlexGN
[INFO]task-segment: [eclipse:eclipse]
[INFO]
[INFO] Preparing eclipse:eclipse
[INFO] No goals needed for project - skipping
[INFO] [eclipse:eclipse {execution: default-cli}]
[INFO] Using Eclipse Workspace: C:\Documents and Settings\catalrc\WorkspaceXYZ
[INFO] Adding default classpath container:
org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.eclipse.EclipsePlugin.isAvailableAsAWorkspaceProject(EclipsePlugin.java:1889)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.useProjectReference(EclipsePlugin.java:1932)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:683)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:507)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Mar 04 12:54:48 EST 2010
[INFO] Final Memory: 7M/15M
[INFO]
---
The pom.xml for this project (FlexGN) was fine. However, I
[jira] (MPH-86) Hide passwords for effective-pom
Stefan Cordes created MPH-86: Summary: Hide passwords for effective-pom Key: MPH-86 URL: https://jira.codehaus.org/browse/MPH-86 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\.. Java version: 1.6.0, vendor: IBM Corporation Java home: C:\programs\ejbdeploy_base_v7\java\jre Default locale: de_DE, platform encoding: Cp1252 OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86, family: windows Reporter: Stefan Cordes Executing mvn help:effective-pom -Doutput=pom-effective.txt with profiles profile iddefault/id activation activeByDefaulttrue/activeByDefault /activation properties maven.scm.usernameMyUserId/maven.scm.username maven.scm.passwordMyVerySecretPassword/maven.scm.password /properties /profile /profiles /settings in %userprofile%\.m2\settings.xml results in an pom-effective.txt which contains properties maven.scm.usernameMyUserId/maven.scm.username maven.scm.passwordMyVerySecretPassword/maven.scm.password /properties As (in our case) the pom-effective.txt should be checked in version control system for later debug support we strongly need to hide the password analog to MPH-44 Hide passwords for effective-settings: properties maven.scm.usernameMyUserId/maven.scm.username maven.scm.password***/maven.scm.password /properties -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
CLONE -NPE while performing a scm:prepare-release goal -- Key: MPSCM-87 URL: http://jira.codehaus.org/browse/MPSCM-87 Project: maven-scm-plugin Issue Type: Bug Environment: Mac OS X, JSDK 1.4.2 Reporter: Stefan Cordes Assigned To: Brett Porter Fix For: 1.2 NPE while performing a scm:prepare-release goal From the trace it appears that the NPE is taking place in the release.VersionTransformer.transformRequired(VersionTransformer.java:136) Here is the trace from running the scm:prepare-release goal: [...] What is the new tag name? release_from_maven_0_2 What is the new version? [release_from_maven_0_2] 2.5.2 Verifying valid tag name [cvs] Using cvs passfile: /Users/sebastiensahuc/.cvspass [cvs] T project.xml ASTIdentifier : java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:165) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:572) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:304) at org.apache.maven.cli.App.doMain(App.java:505) at org.apache.maven.cli.App.main(App.java:1156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.lang.NullPointerException at org.apache.maven.release.VersionTransformer.transformRequired(VersionTransformer.java:136) ... 44 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
[ http://jira.codehaus.org/browse/MPSCM-87?page=comments#action_75886 ] Stefan Cordes commented on MPSCM-87: The Nullpointer happens again with scm plugin 1.5 when adding project xmlns=http://maven.apache.org/POM/3.0.0; as described in http://maven.apache.org/maven-1.x/plugins/pom/validation.html -- STACKTRACE scm:prepare-release: [echo] Verifying no modifications are present [INFO] Executing: cvs -f -n -q update -d [INFO] Working directory: c:\workspaces\trend51-maven\o4-upload ASTIdentifier : java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java(Compiled Code)) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java(Inlined Compiled Code)) at java.util.ArrayList.get(ArrayList.java(Compiled Code)) at org.apache.maven.release.VersionTransformer.transformRequired(VersionTransformer.java:112) ... 41 more -- STACKTRACE CLONE -NPE while performing a scm:prepare-release goal -- Key: MPSCM-87 URL: http://jira.codehaus.org/browse/MPSCM-87 Project: maven-scm-plugin Issue Type: Bug Environment: Mac OS X, JSDK 1.4.2 Reporter: Stefan Cordes Assigned To: Brett Porter Fix For: 1.2 NPE while performing a scm:prepare-release goal From the trace it appears that the NPE is taking place in the
[jira] Commented: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
[ http://jira.codehaus.org/browse/MPSCM-87?page=comments#action_75888 ] Stefan Cordes commented on MPSCM-87: Correction: Not a Nullpointer happens, but an IndexOutOfBoundsException on a similar line mentioned in the previous issue. CLONE -NPE while performing a scm:prepare-release goal -- Key: MPSCM-87 URL: http://jira.codehaus.org/browse/MPSCM-87 Project: maven-scm-plugin Issue Type: Bug Environment: Mac OS X, JSDK 1.4.2 Reporter: Stefan Cordes Assigned To: Brett Porter Fix For: 1.2 NPE while performing a scm:prepare-release goal From the trace it appears that the NPE is taking place in the release.VersionTransformer.transformRequired(VersionTransformer.java:136) Here is the trace from running the scm:prepare-release goal: [...] What is the new tag name? release_from_maven_0_2 What is the new version? [release_from_maven_0_2] 2.5.2 Verifying valid tag name [cvs] Using cvs passfile: /Users/sebastiensahuc/.cvspass [cvs] T project.xml ASTIdentifier : java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:165) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:572) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:304) at org.apache.maven.cli.App.doMain(App.java:505) at org.apache.maven.cli.App.main(App.java:1156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.lang.NullPointerException at
