[jira] Closed: (MSITE-581) NullPointerException while site:deploy

[Lukas Theussl (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSITE-581.
---

Resolution: Duplicate
  Assignee: Lukas Theussl

> NullPointerException while site:deploy
> --
>
> Key: MSITE-581
> URL: http://jira.codehaus.org/browse/MSITE-581
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.0-beta-3
> Environment: java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
>Reporter: Graham Leggett
>Assignee: Lukas Theussl
>
> When attempting site-deploy to sourceforge.net via wagon-ssh, the following 
> NullPointerException is thrown:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy (default-deploy) 
> on project mailhttp: Execution default-deploy of goal 
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed. 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy 
> (default-deploy) on project mailhttp: Execution default-deploy of goal 
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3: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:534)
>   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-deploy of goal 
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:deploy failed.
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116)
>   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.SiteDeployMojo.execute(SiteDeployMojo.java:216)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>   ... 20 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] Created: (MSKINS-11) stylus skin incorrectly flags some URLs as external

[Lukas Theussl (JIRA)]

stylus skin incorrectly flags some URLs as external
---

 Key: MSKINS-11
 URL: http://jira.codehaus.org/browse/MSKINS-11
 Project: Maven Skins
  Issue Type: Bug
  Components: Stylus Skin
Affects Versions:  stylus-1.2
Reporter: Lukas Theussl


Same as DOXIASITETOOLS-52.

-- 
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] Updated: (MSKINS-11) stylus skin incorrectly flags some URLs as external

[Lukas Theussl (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSKINS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSKINS-11:


Affects Version/s: (was:  stylus-1.2)
   stylus-1.3
Fix Version/s: stylus-1.4

> stylus skin incorrectly flags some URLs as external
> ---
>
> Key: MSKINS-11
> URL: http://jira.codehaus.org/browse/MSKINS-11
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Stylus Skin
>Affects Versions: stylus-1.3
>Reporter: Lukas Theussl
> Fix For: stylus-1.4
>
>
> Same as DOXIASITETOOLS-52.

-- 
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: (MNG-5062) Dependency resolution in multimodule project with child having different groupId

[Samuli Saarinen (JIRA)]

Dependency resolution in multimodule project with child having different groupId


 Key: MNG-5062
 URL: http://jira.codehaus.org/browse/MNG-5062
 Project: Maven 2 & 3
  Issue Type: Bug
Affects Versions: 3.0.3
 Environment: java 1.6 maven 3.0.3 (3.0.2 also)
Reporter: Samuli Saarinen
Priority: Minor
 Attachments: maven-test.zip

I don't know if this is as user or maven error but I'll report it any way. 
Dependency resolution does not work correctly when child project references a 
dependency defined in parent's dependencyManagement if childs groupId is not 
same as parents.

parents depedencyManagement
{code:xml}

  

  ${project.groupId}
  child
  ${project.version}


{code}

childs pom.xml
{code:xml}
...

  com.example.test
  parent
  1.0-SNAPSHOT

com.example.other
child2


  
com.example.test
child
  
 
{code}

It works if hard coded groupId instead of ${project.groupId} is used in the 
parent.

Attached is a sample project that demonstrates the problem.



-- 
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] Closed: (MSKINS-11) stylus skin incorrectly flags some URLs as external

[Lukas Theussl (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSKINS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl closed MSKINS-11.
---

Resolution: Fixed
  Assignee: Lukas Theussl

Fixed in [r1091369|http://svn.apache.org/viewvc?rev=1091369&view=rev]

> stylus skin incorrectly flags some URLs as external
> ---
>
> Key: MSKINS-11
> URL: http://jira.codehaus.org/browse/MSKINS-11
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Stylus Skin
>Affects Versions: stylus-1.3
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: stylus-1.4
>
>
> Same as DOXIASITETOOLS-52.

-- 
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] Closed: (MNG-5062) Dependency resolution in multimodule project with child having different groupId

[Benjamin Bentmann (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-5062.
--

Resolution: Not A Bug
  Assignee: Benjamin Bentmann

Expressions referring to {{project.*}} are evaluated against the project that 
is to be built, not the POM that declared them originally. I.e. child2 inherits 
the dependency management from its parent but uses the groupId of child2 to 
evaluate the expressions, yielding effectively:
{code:xml}

  

  com.example.other
  child
  1.0-SNAPSHOT

{code}
.

> Dependency resolution in multimodule project with child having different 
> groupId
> 
>
> Key: MNG-5062
> URL: http://jira.codehaus.org/browse/MNG-5062
> Project: Maven 2 & 3
>  Issue Type: Bug
>Affects Versions: 3.0.3
> Environment: java 1.6 maven 3.0.3 (3.0.2 also)
>Reporter: Samuli Saarinen
>Assignee: Benjamin Bentmann
>Priority: Minor
> Attachments: maven-test.zip
>
>
> I don't know if this is as user or maven error but I'll report it any way. 
> Dependency resolution does not work correctly when child project references a 
> dependency defined in parent's dependencyManagement if childs groupId is not 
> same as parents.
> parents depedencyManagement
> {code:xml}
> 
>   
> 
>   ${project.groupId}
>   child
>   ${project.version}
> 
> 
> {code}
> childs pom.xml
> {code:xml}
> ...
> 
>   com.example.test
>   parent
>   1.0-SNAPSHOT
> 
> com.example.other
> child2
>   
> 
>   
> com.example.test
> child
>   
>
> {code}
> It works if hard coded groupId instead of ${project.groupId} is used in the 
> parent.
> Attached is a sample project that demonstrates the problem.

-- 
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] Updated: (MSITE-574) Update to Doxia 1.2

[Lukas Theussl (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Theussl updated MSITE-574:


Summary: Update to Doxia 1.2  (was: Update to Doxia 1.1.5)

> Update to Doxia 1.2
> ---
>
> Key: MSITE-574
> URL: http://jira.codehaus.org/browse/MSITE-574
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Task
>Affects Versions: 2.2, 3.0-beta-3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.3, 3.0-beta-4
>
>


-- 
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: (MWAR-142) custom manifest and war overlays

[Gabriela Chiribau (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=263281#action_263281
 ] 

Gabriela Chiribau commented on MWAR-142:


It is useful to have the ability to keep one's own manifest, especially when 
using maven to generate a war file for "other" application servers. E.g 
websphere doesn't accept the manifest generated by maven, it required \n 
instead of space as the separator the manifest. The ability to specify an 
existing manifest just to have it overriden is somewhat frustrating :)

Also, the classpath is overriden in the manifest with or _without_ 
addClasspath=false; this is plainly ignored.




WebContent/META-INF/MANIFEST.MF


false




This will still override the manifest _with_ the classpath generated by maven.

> custom manifest and war overlays
> 
>
> Key: MWAR-142
> URL: http://jira.codehaus.org/browse/MWAR-142
> Project: Maven 2.x WAR Plugin
>  Issue Type: Improvement
>  Components: manifest, overlay
>Affects Versions: 2.0.2, 2.1-alpha-1
> Environment: maven 2.0.7
>Reporter: Rémy Sanlaville
> Attachments: custom-manifest-war-overlays.zip
>
>
> Despite the fact that it is possible to generate a custom manifest as 
> described in 
> [war-manifest-guide|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html],
>  it's not good enough when using the overlays mechanism. The maven-war-plugin 
> can't take into account an existing manifest. It can just generate a new one 
> with the corresponding configuration in the pom.
> However, if you use the overlays mechanism, you rather want to keep the 
> manifest from your common war (see custom-manifest-war-overlays.zip in 
> attachment). 

-- 
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] Updated: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a defined in the build.xml

[Stephen Connolly (JIRA)]

 [ 
http://jira.codehaus.org/browse/MANTTASKS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly updated MANTTASKS-218:
---

Fix Version/s: 2.1.3

> cacheDependencyRefs is ignored when pulling dependencies from a  defined 
> in the build.xml
> --
>
> Key: MANTTASKS-218
> URL: http://jira.codehaus.org/browse/MANTTASKS-218
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: dependencies task
>Affects Versions: 2.1.2
>Reporter: Stephen Connolly
> Fix For: 2.1.3
>
> Attachments: MANTTASKS-218.patch
>
>
> When a  is defined in the ant build.xml and then the  task 
> uses that  then cacheDependencyRefs is ignored unless the  is 
> loaded from a file on disk.
> This is causing a regression in build time for the Apache Cassandra project 
> (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152)

-- 
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] Closed: (MANTTASKS-218) cacheDependencyRefs is ignored when pulling dependencies from a defined in the build.xml

[Stephen Connolly (JIRA)]

 [ 
http://jira.codehaus.org/browse/MANTTASKS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Connolly closed MANTTASKS-218.
--

Resolution: Fixed

r1091446

> cacheDependencyRefs is ignored when pulling dependencies from a  defined 
> in the build.xml
> --
>
> Key: MANTTASKS-218
> URL: http://jira.codehaus.org/browse/MANTTASKS-218
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: dependencies task
>Affects Versions: 2.1.2
>Reporter: Stephen Connolly
> Fix For: 2.1.3
>
> Attachments: MANTTASKS-218.patch
>
>
> When a  is defined in the ant build.xml and then the  task 
> uses that  then cacheDependencyRefs is ignored unless the  is 
> loaded from a file on disk.
> This is causing a regression in build time for the Apache Cassandra project 
> (https://issues.apache.org/jira/browse/CASSANDRA-1851?focusedCommentId=13017152&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13017152)

-- 
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: (MSITE-582) Make it possible to remove breadcrumbs in child projects again

[Andreas Sewe (JIRA)]

Make it possible to remove breadcrumbs in child projects again
--

 Key: MSITE-582
 URL: http://jira.codehaus.org/browse/MSITE-582
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: New Feature
  Components: inheritance
Affects Versions: 3.0-beta-4
Reporter: Andreas Sewe
 Attachments: example.tar.gz

Currently a child can only add more breadcrumbs. There are situations, however, 
where it is desirable to remove some or all of the breadcrumbs defined by the 
parent, in particular when the Maven project hierarchy doesn't match the 
_natural_ hierarchy of the site. See 
 for an 
example (also attached).

One way to do this, without requiring changes to the {{site.xml}} format and 
with only minimal breakage of compatibility, would be to simply use the child's 
breadcrumbs wholesale whenever they are a prefix to the parents.

-- 
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-724) Running individual test cases does not work under JUnit 3.8.2

[Jesse Glick (JIRA)]

Running individual test cases does not work under JUnit 3.8.2
-

 Key: SUREFIRE-724
 URL: http://jira.codehaus.org/browse/SUREFIRE-724
 Project: Maven Surefire
  Issue Type: Bug
  Components: JUnit 3.x support
Affects Versions: 2.8
 Environment: JDK 6u24, Ubuntu
Reporter: Jesse Glick


See SUREFIRE-577. After

{noformat}
diff --git a/maven-model/pom.xml b/maven-model/pom.xml
index bc66415..903648a 100644
--- a/maven-model/pom.xml
+++ b/maven-model/pom.xml
@@ -74,6 +74,11 @@ under the License.
   
 
   
+  
+org.apache.maven.plugins
+maven-surefire-plugin
+2.8
+  
 
   
 
{noformat}

if I run

{noformat}
mvn -f maven-model/pom.xml 
-Dtest=org.apache.maven.model.DependencyTest\#testEqualsIdentity surefire:test
{noformat}

I see

{noformat}
[INFO] --- maven-surefire-plugin:2.8:test (default-cli) @ maven-model ---
[INFO] Surefire report directory: .../maven-model/target/surefire-reports

---
 T E S T S
---
Running org.apache.maven.model.DependencyTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec

Results :

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
{noformat}

Similarly, in a new quickstart project if I create

{noformat}
package test.test196655;
import junit.framework.TestCase;
public class AppTest extends TestCase {
public void test1() {}
public void test2() {}
}
{noformat}

and run

{noformat}
mvn -Dtest=test.test196655.AppTest#test1 test-compile surefire:test
{noformat}

both tests are run until I upgrade the JUnit dep from 3.8.1 to 4.8.2.

By the way the corresponding function works as expected in Ant 1.8.2.

-- 
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: (MNG-5063) Unable to install file with existing pom with element set to 'dll'

[Alexandre de Paula (JIRA)]

Unable to install file with existing pom with  element set to 'dll'
--

 Key: MNG-5063
 URL: http://jira.codehaus.org/browse/MNG-5063
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Command Line
Affects Versions: 3.0.3
 Environment: Windows XP 32 bits
JRE 6 update 24
Reporter: Alexandre de Paula
Priority: Minor


Installing a dll file into local repository works fine when typing all required 
parameters like below:

mvn install:install-file -Dfile=myfile.dll -DgroupId=my.group.id 
-DartifactId=myartifact -Dversion=1.0 -Dpackaging=dll -DgeneratePo
m=true

Although, when I create a pom file with such descriptions and try to install it 
like:

mvn install:install-file -Dfile=myfile.dll -DpomFile=./pom.xml

an error message is displayed:

[ERROR] Unknown packaging: dll @ line 8, column 16

-- 
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