[jira] Created: (MNG-5064) mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds)
mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local
builds)
---
Key: MNG-5064
URL: http://jira.codehaus.org/browse/MNG-5064
Project: Maven 2 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.0.3
Reporter: Geoffrey De Smet
Priority: Critical
Here's the command I ran (on a fresh morning, because our update policy is
daily and our SNAPSHOTs are deployed by Hudson at night, with maven 3.0.3):
{code}
$ mvn -nsu clean install -DskipTests
[INFO] Scanning for projects...
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/droolsjbpm-parent/5.2.0-SNAPSHOT/maven-metadata.xml
...
[INFO]
[INFO] Building Drools Planner core 5.2.0-SNAPSHOT
[INFO]
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
Downloaded:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/maven-metadata.xml
(2 KB at 1.8 KB/sec)
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
Downloaded:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.pom
(6 KB at 6.0 KB/sec)
...
Downloading:
http://repository.jboss.org/nexus/content/groups/public/org/drools/knowledge-api/5.2.0-SNAPSHOT/knowledge-api-5.2.0-20110413.010206-9.jar
...
{code}
Despite that I added -nsu (also known as --no-snapshot-updates), it
downloaded snapshots.
This is a pretty bad thing, because if I hadn't pulled in days (and just wanted
to test my local changes before merging in remote changes),
this would have broke my build, for example:
- because the parent pom in downloaded SNAPSHOT had a dependency removed which
my local pom was still using (because I hadn't pulled the changes yet)
- because the downloaded knowledge-api changed a non-released method signature
(and I hadn't pulled the changes to deal with that yet).
- ...
--
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: (MSITE-546) container field of SiteDeployMojo not populated correctly - NPE with servers containing configuration
[
http://jira.codehaus.org/browse/MSITE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263420#action_263420
]
Marcin Kuthan commented on MSITE-546:
-
Hi Olivier
I've verified the 3.0-beta-4-SNAPSHOT and the NPE is still thrown:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:stage-deploy
(default-cli) on project corporate-pom: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:stage-deploy
failed. NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:stage-deploy
(default-cli) on project corporate-pom: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:stage-deploy
failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:stage-deploy
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugins.site.SiteDeployMojo.configureWagon(SiteDeployMojo.java:474)
at
org.apache.maven.plugins.site.SiteStageDeployMojo.deployStagingSite(SiteStageDeployMojo.java:185)
at
org.apache.maven.plugins.site.SiteStageDeployMojo.execute(SiteStageDeployMojo.java:145)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{code}
For reference settings.xml fragment:
{code}
server
idhostname/id
usernameusername/username
passwordpassword/password
configuration
!-- Disable host checking --
knownHostsProvider
implementation=org.apache.maven.wagon.providers.ssh.knownhost.NullKnownHostProvider
hostKeyCheckingno/hostKeyChecking
/knownHostsProvider
/configuration
/server
{code}
Should I open the new issue?
Thanks,
Marcin
container field of SiteDeployMojo not populated correctly - NPE with
servers containing configuration
Key: MSITE-546
URL: http://jira.codehaus.org/browse/MSITE-546
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: Maven 3, site:deploy
Affects Versions: 3.0-beta-3
Reporter: Carl Wilund
Assignee: Olivier Lamy
Fix For: 3.0-beta-4
In SiteDeployMojo, the field container is not populated correctly (version
skew with @Requirement?). When configureWagon is subsequently called, IFF the
site deploy server has an entry in settings.xml AND contains a
configuration subelement, there will be a NullPointerException thrown (line
474) when container.lookup is called.
Simple repro:
settings.xml:
...
server
[jira] Commented: (MNG-4702) MavenProject.getActiveProfiles() does not merge active profiles from parent POMs
[
http://jira.codehaus.org/browse/MNG-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263429#action_263429
]
Tiggy Ziggy commented on MNG-4702:
--
I consider also this as an issue because during the build of the children we
can clearly see that it uses the profile from the parent It clearly
demonstrates that Maven considers the profile defined in the parent as
activated.
It means that the maven-help-plugin does not reflect the way Maven will behave
:(
MavenProject.getActiveProfiles() does not merge active profiles from parent
POMs
Key: MNG-4702
URL: http://jira.codehaus.org/browse/MNG-4702
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1, 3.0-beta-1
Reporter: Lars Corneliussen
Attachments: buggy-profiles.zip
Profiles from parent pom's are internally merged, but getActiveProfiles()
doesn't return them as long as they aren't redefined in the module.
The zip contains two poms with some profiles:
buggy-profiles (activate-me, active-by-default, shared-profile)
+ buggy-module (module-activate-me, module-active-by-default, shared-profile)
Each of the profiles adds a echo ... to the validate-phase.
{code:title=mvn validate help:active-profiles}
Building buggy-pom 1.0-SNAPSHOT
--- exec-maven-plugin:1.1:exec (active-by-default) @ buggy-pom ---
### running 'active-by-default'
Building buggy-module 1.0-SNAPSHOT
--- exec-maven-plugin:1.1:exec (active-by-default) @ buggy-module ---
### running 'active-by-default'
--- exec-maven-plugin:1.1:exec (module-active-by-default) @ buggy-module ---
### running 'module-active-by-default'
..
..
Active Profiles for Project 'test:buggy-pom:pom:1.0-SNAPSHOT':
The following profiles are active:
- active-by-default (source: pom)
- netcologne.default (source: settings.xml)
Active Profiles for Project 'test:buggy-module:pom:1.0-SNAPSHOT':
The following profiles are active:
- module-active-by-default (source: pom)
- netcologne.default (source: settings.xml)
{code}
The module should also list 'active-by-default'. Even more since it is also
run correctly.
Explicitely activated profiles behave the same:
{code}mvn validate help:active-profiles -P activate-me,
module-activate-me{code}
When the a profile is redefined in the module (without any changes) the
active-profiles list is correct:
{code}
{code}mvn validate help:active-profiles -P activate-me,
module-activate-me{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-370) Archetype generation profile for multi-module project
Archetype generation profile for multi-module project - Key: ARCHETYPE-370 URL: http://jira.codehaus.org/browse/ARCHETYPE-370 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Environment: All Reporter: Charlie Mordant Priority: Minor Can you provide a sort of maven profile for Maven archetype? For example, I have one multi module archetype embedding 6 modules: parent, web, ws-client, ws-server, core and jpa, I would like to have two generation profiles: one complete with all modules and one short for parent, web, core and jpa. I think it would be a nice thing ;). Best regards, thank you for this wonderful tool. Tcharl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-163) Folder antrun with build-main.xml is left under ${project.build.directory} of the module
Folder antrun with build-main.xml is left under ${project.build.directory} of
the module
-
Key: MANTRUN-163
URL: http://jira.codehaus.org/browse/MANTRUN-163
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.6, 1.5
Reporter: Liya Katz
Since 1.5 the folder antrun with build-main.xml is left under
${project.build.directory} of the module, which sometimes cause this folder to
appear inside module's artifact (zip, tar and etc.) and forces to change
configuration to explicitly exclude this folder during archiving - very
annoying!
--
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: (MSITE-546) container field of SiteDeployMojo not populated correctly - NPE with servers containing configuration
[ http://jira.codehaus.org/browse/MSITE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263433#action_263433 ] Lukas Theussl commented on MSITE-546: - I don't think you are actually running 3.0-beta-4-SNAPSHOT, in the current dev version there is no line number 474 in SiteDeployMojo: http://svn.apache.org/viewvc/maven/plugins/branches/maven-site-plugin-3.x/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java?view=markup container field of SiteDeployMojo not populated correctly - NPE with servers containing configuration Key: MSITE-546 URL: http://jira.codehaus.org/browse/MSITE-546 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3, site:deploy Affects Versions: 3.0-beta-3 Reporter: Carl Wilund Assignee: Olivier Lamy Fix For: 3.0-beta-4 In SiteDeployMojo, the field container is not populated correctly (version skew with @Requirement?). When configureWagon is subsequently called, IFF the site deploy server has an entry in settings.xml AND contains a configuration subelement, there will be a NullPointerException thrown (line 474) when container.lookup is called. Simple repro: settings.xml: ... server idbogus/id usernamebogus/username passwordbogus/password configuration /configuration /server ... pom.xml: ... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.0-beta-3/version /plugin /plugins /build distributionManagement site idbogus/id nameBogus/name urlsftp://bogus.bogus.org/bogus/url /site /distributionManagement ... While this should obviously not work, it should not NPE at line 474. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-725) Test result output ist sent to System.out instead of using logger
Test result output ist sent to System.out instead of using logger
-
Key: SUREFIRE-725
URL: http://jira.codehaus.org/browse/SUREFIRE-725
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.8
Reporter: Michael Osipov
If I run mvn -q I still see this:
{noformat}
[debug] execute contextualize
[debug] execute contextualize
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[debug] execute contextualize
[debug] execute contextualize
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[debug] execute contextualize
[debug] execute contextualize
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[debug] execute contextualize
{noformat}
It seems like the output is not sent through a logger.
--
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: (MRESOURCES-140) Plugin shows always '[debug] execute contextualize' despite the logging level
[
http://jira.codehaus.org/browse/MRESOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263445#action_263445
]
Michael Osipov commented on MRESOURCES-140:
---
This one is really annoying with mvn -q
Plugin shows always '[debug] execute contextualize' despite the logging level
-
Key: MRESOURCES-140
URL: http://jira.codehaus.org/browse/MRESOURCES-140
Project: Maven 2.x Resources Plugin
Issue Type: Improvement
Affects Versions: 2.5
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_23\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: x86, family: windows
Reporter: Robert Scholte
Priority: Minor
While running Maven with the default logging level, it shows the following
text in my console.
{noformat}
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ project
---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
{noformat}
Reason seems to be, that the {{contextualize()}} is called before the plugin
is fully setup, so there's no proper logger yet.
Please remove this debug-line.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-316) Grammar error: has not be previously called
Grammar error: has not be previously called
-
Key: MJAVADOC-316
URL: http://jira.codehaus.org/browse/MJAVADOC-316
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Jesse Glick
Priority: Trivial
{{maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java}}
has
{noformat}
+ ' has not be previously called for the project: ' + p.getId()
{noformat}
{{be}} should be {{been}}.
--
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: (MNG-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263463#action_263463 ] Bram commented on MNG-3139: --- I'm also experiencing the same bug on our Jenkins server (v 1.405) with Maven 2.2.1. Removing LOCAL-REPO/org/apache/maven/skins/* does help for a few days, but not for long The skin does not exist: Unable to determine the release version Key: MNG-3139 URL: http://jira.codehaus.org/browse/MNG-3139 Project: Maven 2 3 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0.7 Reporter: eyal david Assignee: John Casey Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 Attachments: cached-metadata.patch, mvn_site_debug.zip hi I have problem generating site when im using the command mvn site it performs all stagegs and when it came to site generation the message is shown : The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven -default-skin \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file org.apache.maven.skins:maven-default-skin:jar:RELEASE do u have an idea what is the problem ? p.s the jar is registered in my local repository and in the remote repository thank u -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-685) PDE projects not importing non-provided OSGI bundles
PDE projects not importing non-provided OSGI bundles Key: MECLIPSE-685 URL: http://jira.codehaus.org/browse/MECLIPSE-685 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: PDE support Affects Versions: 2.8 Environment: Eclipse 3.6.1, Windows XP, Java 6 Reporter: Jeff Torson Attachments: pom.xml When setting up a project as a PDE project and including OSGI artifacts which the project requires at compile time and runtime, the artifact is explicitly ignored even though it's marked as provided (default scope of compile). I can see the reason to ignore Eclipse JARs but if I specify that I need an artifact for my PDE project, I would think it would include it, unless I specify a scope of provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-686) Allow project references for PDE projects
Allow project references for PDE projects - Key: MECLIPSE-686 URL: http://jira.codehaus.org/browse/MECLIPSE-686 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: PDE support Affects Versions: 2.8 Environment: Windows XP, Eclipse 3.6.1, Java 6 Reporter: Jeff Torson Attachments: pom.xml When creating a PDE project, it would be since if project references were still used when the useProjectReferences is set to true. I know that PDE projects need JARs to run correctly but for development it's must nicer to be able to edit other dependent projects files and to be able to use those changes right away. Currently setting this to true for a multi-module project will not include any projects in the classpath. Setting this to false will add classpath entries but to the copied project JARs. If I set this to false, or if useProjectReferences was set to true and did still allow projects in the classpath, I would need to regenerate the JARs in order to run my application, so it seems like the developer friendly way would be the better way to go. -- 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
