[jira] Created: (MWAR-73) war overlay mechanism does not work for classes
war overlay mechanism does not work for classes --- Key: MWAR-73 URL: http://jira.codehaus.org/browse/MWAR-73 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.0.1, 2.0, 2.0.2, 2.1 Environment: all OS, all JDK, currently using jdk1.4.2_10 and jdk1.5.0_06 under linux fedora core 5/x86_64 and sunOS5.10/Sparc64 Reporter: mark struberg Attachments: maven-war-plugin-patch.tar.gz PROBLEM DESCRIPTION: When building a WAR (e.g. war2.war) which depends on another WAR (e.g. war1.war), the web-resources from the dependant war are beeing used as base for overlaying. This mechanism doesn't currently work for the classes within the dependant war, altough it is specified by the plugin documentation See the SampleActionDependency.class in http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html APPLIED PATCH: I have written two simple war examples war1 and war2 and extended the maven-war-plugin by an own WarClasspathMojo which is bound to the phase generate-resources to fix this issue. Since i found no way to add non-artifact parts to the classpath, i simply unpack all dependant war files (reusing the functions already there in AbstractWarMojo) and add a resource-path to the $explodedWarDir/WEB-INF/classes for each of them. The The implementation fits all my needs, but if you provide me with a hint how it may be improved, then let me know. KNOWN ISSUES: This mechanism currently doesn't work if you have specified to generate an archive for the dependant war's classes. -- 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: (MECLIPSE-76) Projects containing war's as dependency will not include war-reference
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73408 ]
mark struberg commented on MECLIPSE-76:
---
Hi Tom!
I've possibly fixed my issue.
You may take a look at http://jira.codehaus.org/browse/MWAR-73 if this may be
modified to also fit your use-case.
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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: (MCOMPILER-43) Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse'
Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse' Key: MCOMPILER-43 URL: http://jira.codehaus.org/browse/MCOMPILER-43 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.1 Environment: Windows XP, java 5 and java 1.4 with maven 2.0.4 Reporter: Binyan Priority: Critical Attachments: compiler-test.zip The maven-compiler-plugin, along with the plexus-eclipse-compiler component, is generating ghost classes (i.e. java source files that compile, but don't generate a .class file). If I put a deliberate error into the Logger.java file then the compilers, javac and eclipse, both catch it. However, only javac when invoked through maven will create a .class files for the 2 java files in the example project. I'm using the following pom definition: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.abc.logging abc-logging 1.0-SNAPSHOT jar ABC Logging junit junit 3.8.1 org.apache.maven.plugins maven-compiler-plugin 1.4 1.4 true false eclipse org.codehaus.plexus plexus-compiler-eclipse 1.5.1 If you execute "mvn clean compile" then there will only be 1 class file, Foo.class, in the target/classes/com/abc/logging directory. However if you change the pom's element to be javac then 3 classes are now in the target folder. This would indicate an eclipse compiler bug, but wait there's more. The plexus-eclipse-compiler component uses the org.eclipse.jdt.core:core:3.1.0 repo artifact for compiling. So if you run the batch compiler in the core-3.1.0 jar like java -jar /org/eclipse/jdt/core/3.1.0/core-3.1.0.jar -verbose -d target/classes src/main/java then you will get the following output indicating all 3 classes were created. E:\dev\workspace-eclipse\compiler-test>java -jar "C:\Documents and Settings\wbeckwit\.m2\repository\org\eclipse\jdt\core\3.1.0\core-3.1.0.jar" -verbose -d target/classes -verbose src/main/java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\resources [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/lang/Object.class] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [writingcom\abc\logging\Foo.class - #1] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/util/Map.class] [readingjava/util/HashMap.class] [readingjava/lang/Class.class] [readingjava/lang/String.class] [readingjava/lang/Throwable.class] [readingjava/io/Serializable.class] [readingjava/lang/Cloneable.class] [readingjava/util/AbstractMap.class] [writingcom\abc\logging\Logger$Bar.class - #2] [writingcom\abc\logging\Logger.class - #3] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [2 units compiled] [3 .class files generated] -- 1. WARNING in E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java (at line 8) private boolean debug; // *** comment this invocation out and the class file will be generated ^ The field Logger.debug is never read locally -- 1 problem (1 warning) E:\dev\workspace-eclipse\compiler-test> Also if you use the lastest 3.2 eclipse compiler available here, http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/download.php?dropFile=ecj.jar, then you still get 3 classes compiled. Therefore this indicates a maven bug, but wait there's even more. The Logger.java file has 2 "// ***" comments in it. If you comment out the boolean declaration then the eclipse compiler, when invoked through maven, will create the 3 class files. Howeve if you also comment out the marked method invocation then the we're back to getting only 1 class file generated. WTF!? Again javac invoked via maven and the eclipse core-3.1.0 compiler always generates 3 class files. Can someone help the universe make sense again? Setting the element to true has no affect on the results seen. -- This m
[jira] Commented: (CONTINUUM-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=comments#action_73420 ] David Blevins commented on CONTINUUM-418: - Adam, I'd say definitely submit it as a patch if you still have the code. Can't hurt. > RSS feed for build status > - > > Key: CONTINUUM-418 > URL: http://jira.codehaus.org/browse/CONTINUUM-418 > Project: Continuum > Issue Type: Wish > Components: Web interface >Affects Versions: 1.0 >Reporter: David Blevins >Priority: Minor > Fix For: 1.1 > > Attachments: rss.patch > > > Lyndon Samson suggested on the Geronimo dev list that an rss feed for > reporting build status would be a really great way to report build status. > A neat application of that feature would be the ability to include continuum > data on a confluence page. -- 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: (WAGONSSH-44) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGONSSH-44?page=comments#action_73422 ] Eric Bernstein commented on WAGONSSH-44: Since the above comments seem to question to wagon ssh problem with file permissions, I figured I'd report one more instance of it. I've experianced the file permission problem with scp:// on both redhat and apple (In fact, I've never gotten scp:// to set permissions completely correctly). One interesting note: the filePermission issue appears somewhat unique to write permissions. Here's the results of a number of tests I ran. settings.xml config = results on server 400 = u+r 666 = u+rw,g+r,o+r 664 = u+rw,g+r,o+r (this is the one I want, obviously not the right results) 777 = u+rwx,g+rx,o+rx Wasn't sure if this was worth opening a different issue for. It seems different than the description, but the fix appears to be in Trustin's patch. > directoryPermissions is not repected when I deploy a POM > > > Key: WAGONSSH-44 > URL: http://jira.codehaus.org/browse/WAGONSSH-44 > Project: wagon-ssh > Issue Type: Bug > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee > Assigned To: Brett Porter > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- 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: (MPIR-54) Team list table improvement
[ http://jira.codehaus.org/browse/MPIR-54?page=comments#action_73423 ] Vincent Siveton commented on MPIR-54: - Hi Dmitry, It is better for us to work with svn patch [1]. Could you provide us one? Thanks! [1] http://maven.apache.org/guides/development/guide-m2-development.html#Creating%20and%20submitting%20a%20patch > Team list table improvement > --- > > Key: MPIR-54 > URL: http://jira.codehaus.org/browse/MPIR-54 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0, 2.0.1 >Reporter: Dmitry Kobyleha > Attachments: TeamListReport.java > > > When fo all developers in pom.xml we some property not defined, it is good to > not include it to html output. > Fow example: > ... > > developer1 > Developer 1 > [EMAIL PROTECTED] > > Project Manager > Architect > Java Developer > > +2 > > > developer2 > Developer 2 > [EMAIL PROTECTED] > > Java Developer > > +2 > > ... > For both developers properties like URL, Organization,Organization > URL and Properties not specified. In result html we have cells with "-". > As for me it is good not not include columns where only "-" present at all. -- 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: (MPIR-26) Could the Dependencies report show the size of the jars/etc...
[ http://jira.codehaus.org/browse/MPIR-26?page=all ] Vincent Siveton updated MPIR-26: Attachment: dependencies.html Already done in svn (due to MPIR-11) and after. Here is a rendering. > Could the Dependencies report show the size of the jars/etc... > -- > > Key: MPIR-26 > URL: http://jira.codehaus.org/browse/MPIR-26 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Benoit Xhenseval >Priority: Minor > Attachments: dependencies.html > > > Hi > Not sure if this is on the agenda but I'd like to see the size of the > dependencies on the report. This would help developers to sometimes think a > bit more before throwing the kitchen sink in a build... > Thanks for considering this. > Benoit -- 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: (MAVENUPLOAD-1096) Upload ASM 3.0rc1
Upload ASM 3.0rc1 - Key: MAVENUPLOAD-1096 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1096 Project: maven-upload-requests Issue Type: Task Reporter: Eugene Kuleshov http://www.md.pp.ru/~eu/11/asm-3.0_RC1-bundle.zip http://asm.objectweb.org/ http://asm.objectweb.org/team.html ASM is a Java bytecode manipulation framework. Please note that this bundle actually contains 8 artifacts (including parent pom) -- 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: (MPIR-26) Could the Dependencies report show the size of the jars/etc...
[ http://jira.codehaus.org/browse/MPIR-26?page=all ] Vincent Siveton closed MPIR-26. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Already fixed > Could the Dependencies report show the size of the jars/etc... > -- > > Key: MPIR-26 > URL: http://jira.codehaus.org/browse/MPIR-26 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Benoit Xhenseval > Assigned To: Vincent Siveton >Priority: Minor > Fix For: 2.1 > > Attachments: dependencies.html > > > Hi > Not sure if this is on the agenda but I'd like to see the size of the > dependencies on the report. This would help developers to sometimes think a > bit more before throwing the kitchen sink in a build... > Thanks for considering this. > Benoit -- 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: (MAVENUPLOAD-1097) Upload ASM 2.2.3
Upload ASM 2.2.3 Key: MAVENUPLOAD-1097 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1097 Project: maven-upload-requests Issue Type: Task Reporter: Eugene Kuleshov http://www.md.pp.ru/~eu/11/asm-2.2.3-bundle.zip http://asm.objectweb.org/ http://asm.objectweb.org/team.html ASM is a Java bytecode manipulation framework. Please note that this bundle actually contains 9 artifacts (including parent pom) -- 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-2530) mojo-sandbox documentation contains errors
mojo-sandbox documentation contains errors -- Key: MNG-2530 URL: http://jira.codehaus.org/browse/MNG-2530 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Jimisola Laursen 1) http://mojo.codehaus.org/development/guidelines.html states that org.codehaus.mojo mojo-sandbox 2-SNAPSHOT but https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/pom.xml shows that current version is 3-SNAPSHOT. 2) Using Sandbox Plugins / Snapshot Repository (http://mojo.codehaus.org/using-sandbox-plugins.html) has an incorrent link to the snapshot repository since it links to http://snapshots.maven.codehaus.org when it should be http://snapshots.repository.codehaus.org for more info see discussion with Kaare in comments MOJO-475) -- 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: (MAVENUPLOAD-1098) Upload Stripes 1.4 to IBiblio repository
Upload Stripes 1.4 to IBiblio repository Key: MAVENUPLOAD-1098 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1098 Project: maven-upload-requests Issue Type: Task Reporter: Tim Fennell -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: CONTINUUM-755-continuum-webapp.patch Attached patch that validates the Project, Schedule, User, User Group and Project/Group Build Definition forms. Please disregard the other two attachments. This patch already incorporates the changes in the other two patches. Thanks :) > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-continuum-webapp-userValidation.patch, > CONTINUUM-755-continuum-webapp.patch, CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 0 minutes > -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: (was: CONTINUUM-755-continuum-webapp.patch) > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-continuum-webapp-userValidation.patch, > CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 0 minutes > -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Comment: was deleted > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-continuum-webapp-userValidation.patch, > CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 0 minutes > -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: CONTINUUM-755-complete-continuum-webapp.patch Attached patch that validates the Project, User, UserGroup, Schedule and Project/Group Build Definition forms. Please disregard the other two patches I've attached previously. This patch (CONTINUUM-755-complete-continuum-webapp.patch) already incorporates the changes in the other 2 patches. Thanks :) > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-complete-continuum-webapp.patch, > CONTINUUM-755-continuum-webapp-userValidation.patch, > CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 0 minutes > -- 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: (MRELEASE-152) Can't release a POM using the -N option when there are local changes in sub directories
Can't release a POM using the -N option when there are local changes in sub directories --- Key: MRELEASE-152 URL: http://jira.codehaus.org/browse/MRELEASE-152 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Jason van Zyl If you are only releasing a pom.xml i.e. using the -N option then local changes shouldn't matter and be ignored. I can't release a pom.xml without checking everything which I don't want to do. -- 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-176) AbstractSiteRenderingMojo causes a NPE if url of current project is not set
[ http://jira.codehaus.org/browse/MSITE-176?page=comments#action_73441 ] Martin Zeltner commented on MSITE-176: -- Sorry. We moving now definitfly to Maven2. The correct Url is now https://svn.sourceforge.net/svnroot/el4j/trunk/el4j Cheers, Martin > AbstractSiteRenderingMojo causes a NPE if url of current project is not set > --- > > Key: MSITE-176 > URL: http://jira.codehaus.org/browse/MSITE-176 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: WinXP, Java5 >Reporter: Martin Zeltner >Priority: Blocker > Attachments: patch_maven-site-plugin.txt > > > AbstractSiteRenderingMojo causes a NullPointerException in > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler > if url of current project is not set. > $ mvn site:site > ... > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.getParentPrefix > (DefaultDecorationModelInheritanceAssembler.java:340) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelIn > heritance(DefaultDecorationModelInheritanceAssembler.java:46) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:225 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:217 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:492 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo. > java:431) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:108) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:690) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) > 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:585) > 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) > This url is mostly not set, anyway not for each child module. To solve this > issue I did the following in method *getDecorationModel* of > *org.apache.maven.plugins.site.AbstractSiteRenderingMojo*: > If the parent model descriptor exists, the current and the parent model will > be assembled by using following url parameters: > If parent's url is null but child's not child's url will be used for parent. > If both urls are null the "url" "./" will be used for current and parent. > See appended patch. > Cheers, > Martin -- 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://w
[jira] Created: (MNG-2531) Source jar + POM changes
Source jar + POM changes Key: MNG-2531 URL: http://jira.codehaus.org/browse/MNG-2531 Project: Maven 2 Issue Type: Improvement Components: POM Reporter: Brian Topping Priority: Minor [This idea is kind of half-baked, but please think it through. I think it could save a lot of time if it worked.] Would it be reasonable to automatically create some kind of source jar for projects when they are built? All the data is there to create the source tree, and if it was, the POM could be extended such that the IDE plugins such as IDEA could make use of knowing where the sources are for a dependency, download and unjar them automagically as a part of the build, then configure the IDE project so the sources were linked to the JAR. I'm thinking about this because the IDE plugins are really one of the best integrations with the IDEs, but when one rebuilds the IDE project file, the source links are typically destroyed. If you have several dependencies in your IDE that you have to re-establish the source link with every time you rebuild the project, the expense of using the IDE plugin goes way up. When that happens, the IDE becomes an easier place to make the changes, and sometimes these changes get forgotten about, breaking the Maven build. If that's the de-facto build for an organization (because the IDEs can generate from it), then it's a problem. Another (probably easier) option would be to upgrade all the IDE plugins to cache the existing source locations for JARs across runs of the project generation, but it does require an implementation for each IDE plugin. Storing sources in the Maven repos are probably not the ideal situation, but putting hardcoded source addresses in the POM would not work either because developers typically have different locations for things. It might be possible to set it up so the local source addresses are stored in the user properties, but that sounds like a very difficult thing to do in a clean manner. Thanks for reading this rather long winded brainstorm. -- 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
