[jira] Commented: (MJAVADOC-283) isValidJavadocLink should be more strict
[
http://jira.codehaus.org/browse/MJAVADOC-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219669#action_219669
]
Christian Schulte commented on MJAVADOC-283:
Attached patch would break 'http://junit.org/apidocs/package-list' with content
type 'text/html; charset=UTF-8' although a valid package-list file. Maybe
better add parameters for excluding/including the dependencies to use with
'detectLinks'.
> isValidJavadocLink should be more strict
>
>
> Key: MJAVADOC-283
> URL: http://jira.codehaus.org/browse/MJAVADOC-283
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.6.1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_16-p9
> Java home: /usr/local/jdk-1.5.0/jre
> Default locale: de_DE, platform encoding: ISO8859-15
> OS name: "openbsd" version: "4.6" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MJAVADOC-283.patch
>
>
> When setting 'detectLinks' to 'true', the plugin checks that access to the
> constructed package-list files is possible by checking the HTTP status code
> to match 200. This check should be more strict and additionally check that
> the accessed package-list file is of correct type. For example, if setting
> detect links to 'true' and having a dependency on
> 'javax.annotation:jsr250-api' the plugin will add a link like
> 'http://jcp.org/aboutJava/communityprocess/final/jsr250/index.html/apidocs'
> so that javadoc will then try to access the package-list file located at
> 'http://jcp.org/aboutJava/communityprocess/final/jsr250/index.html/apidocs/package-list'.
> That link returns a HTTP status code 200 but no valid package-list file.
> Using the following javadoc plugin configuration
> {xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.7
>
> true
> true
> true
> true
> 1.5
> ${project.name} ${project.version}
> ${project.name} ${project.version}
> true
> false
> true
> org.umlgraph.doclet.UmlGraphDoc
>
> org.umlgraph
> doclet
> 5.1
>
>
>
> org.apache.maven.plugin-tools
> maven-plugin-tools-javadoc
> 2.5
>
>
> org.codehaus.plexus
> plexus-javadoc
> 1.0
>
>
>
> -inferrel -inferdep -hide java.* -collpackages java.util.*
> -qualify -postfixpackage -nodefontsize 9
> -nodefontpackagesize 7
>
>
> true
> false
> true
>
>
>
> {xml}
>
> the configured umlgraph doclet will fail when trying to parse the retrieved
> HTML document as a package-list file.
--
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-159) ZipException during "mvn clean compile site"
[
http://jira.codehaus.org/browse/MPIR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPIR-159:
---
Description:
When running "mvn clean compile site" I get the exception below during
generation of JAR dependency report. This is in a multi module project with
parent A and child modules B and C. Also B depends on C. Exception occurs when
generating site for module B.
{noformat}
[INFO] Generating "Dependencies" report.
[WARNING] The parameter 'dependencyLocationsEnabled' is ignored in offline mode.
[ERROR] IOException: Is a directory
java.util.zip.ZipException: Is a directory
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:203)
at java.util.jar.JarFile.(JarFile.java:132)
at java.util.jar.JarFile.(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:102)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
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)
{noformat}
was:
When running "mvn clean compile site" I get the exception below during
generation of JAR dependency report. This is in a multi module project with
parent A and child modules B and C. Also B depends on C. Exception occurs when
generating site for module B.
[INFO] Generating "Dependencies" report.
[WARNING] The parameter 'dependencyLocationsEnabled' is ignored in offline mode.
[ERROR] IOException: Is a directory
java.util.zip.ZipException: Is a directory
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:203)
at java.util.jar.JarFile.(JarFile.java:132)
at java.util.jar.JarFile.(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:102)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at
org.apache.maven.report.projectin
[jira] Updated: (MSHARED-87) ZipException throw by SDK's JarFile constructor may lack file name
[
http://jira.codehaus.org/browse/MSHARED-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-87:
-
Description:
We get the following (non fatal) error. The attached patch helps us.
{noformat}
[INFO] Generating "Dependencies" report.
[ERROR] IOException: error in opening zip file
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:203)
at java.util.jar.JarFile.(JarFile.java:132)
at java.util.jar.JarFile.(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:102)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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)
[INFO] Generating "changelog" report.
[INFO] Generating "dev-activity" report.
[INFO] Generating "file-activity" report.
{noformat}
was:
We get the following (non fatal) error. The attached patch helps us.
[INFO] Generating "Dependencies" report.
[ERROR] IOException: error in opening zip file
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:203)
at java.util.jar.JarFile.(JarFile.java:132)
at java.util.jar.JarFile.(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:102)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java
[jira] Updated: (MSHARED-134) Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid MANIFEST files
[
http://jira.codehaus.org/browse/MSHARED-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-134:
--
Description:
If you have a maven dependency on an something with an artifactId that contains
a '.' in it, it creates an illegal manifest file when trying to create an
executable jar file (java -jar foo.jar).
{noformat}
Exception in thread "main" java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
at java.util.jar.Attributes.read(Attributes.java:409)
at java.util.jar.Manifest.read(Manifest.java:167)
at java.util.jar.Manifest.(Manifest.java:52)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
at java.util.jar.JarFile.getManifest(JarFile.java:145)
{noformat}
Here's my configuration:
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
my.class.Test
true
true
./lib/
{code}
I added the following dependency:
{code:xml}
org.apache.geronimo.specs
geronimo-jms_1.1_spec
{code}
When the maven-archiver tries to create a manifest file with the JARs
dependencies it adds the following to the META-INF/MANIFEST.MF file:
{noformat}
geronimo-jms_1.1_spec-Extension-Name: geronimo-jms_1.1_spec
geronimo-jms_1.1_spec-Implementation-Version: 1.0
{noformat}
After digging around a bit it turns out that '.' is an illegal character in the
"Extension-Name" and "Implementaion-Version" header fields, which leads to the
following exception when I try to run "java -jar Test.jar"
java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
was:
If you have a maven dependency on an something with an artifactId that contains
a '.' in it, it creates an illegal manifest file when trying to create an
executable jar file (java -jar foo.jar).
Exception in thread "main" java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
at java.util.jar.Attributes.read(Attributes.java:409)
at java.util.jar.Manifest.read(Manifest.java:167)
at java.util.jar.Manifest.(Manifest.java:52)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
at java.util.jar.JarFile.getManifest(JarFile.java:145)
Here's my configuration:
org.apache.maven.plugins
maven-jar-plugin
my.class.Test
true
true
./lib/
I added the following dependency:
org.apache.geronimo.specs
geronimo-jms_1.1_spec
When the maven-archiver tries to create a manifest file with the JARs
dependencies it adds the following to the META-INF/MANIFEST.MF file:
geronimo-jms_1.1_spec-Extension-Name: geronimo-jms_1.1_spec
geronimo-jms_1.1_spec-Implementation-Version: 1.0
After digging around a bit it turns out that '.' is an illegal character in the
"Extension-Name" and "Implementaion-Version" header fields, which leads to the
following exception when I try to run "java -jar Test.jar"
java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
> Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid
> MANIFEST files
> --
>
> Key: MSHARED-134
> URL: http://jira.codehaus.org/browse/MSHARED-134
> Project: Maven Shared Components
> Issue Type: Bug
>Affects Versions: maven-archiver-2.4
> Environment: Java HotSpot(TM) Client VM (build 1.5.0_13-121)
>Reporter: Todd Caine
> Attachments: MavenArchiver.java-Patch.txt, nautilus-debug-log.txt
>
>
> If you have a maven dependency on an something with an artifactId that
> contains a '.' in it, it creates an illegal manifest file when trying to
> create an executable jar file (java -jar foo.jar).
> {noformat}
> Exception in thread "main" java.io.IOException: invalid header field name:
> geronimo-jms_1.1_spec-Extension-Name
> at java.util.jar.Attributes.read(Attributes.java:409)
> at java.util.jar.Manifest.read(Manifest.java:167)
> at java.util.jar.Manifest.(Manifest.java:52)
> at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
> at java.util.jar.JarFile.getManifest(JarFile.java:145)
> {noformat}
> Here's my configuration:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> my.class.Test
> true
> true
> ./lib/
>
>
>
>
> {code}
> I added the following dependency:
> {code:xml}
>
>
[jira] Commented: (MSITE-369) remove copy of reporting-api MavenMultiPageReport class
[ http://jira.codehaus.org/browse/MSITE-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219676#action_219676 ] Herve Boutemy commented on MSITE-369: - now that reporting-api is decoupled from Maven Core, we can use reporting-api version 3.0 (when released) without having Maven 3 as a prerequisite > remove copy of reporting-api MavenMultiPageReport class > --- > > Key: MSITE-369 > URL: http://jira.codehaus.org/browse/MSITE-369 > Project: Maven 2.x Site Plugin > Issue Type: Task >Affects Versions: 2.0-beta-7 >Reporter: Herve Boutemy >Priority: Minor > > this will force the plugin to have Maven 3.0 as a prerequisite, since this > interface was added in reporting-api 3.0 -- 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: (MECLIPSE-636) MECLIPSE-156 wasn't resolved
[ http://jira.codehaus.org/browse/MECLIPSE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramiro Pereira de Magalhães updated MECLIPSE-636: - Attachment: MECLIPSE-636-withTests.patch I upload a new patch that fixes some small problems with the previous patch. This patch also includes a test case that ensures the correct preference file contains the needed configuration for a Eclipse's project source code and resource file encoding works properly. > MECLIPSE-156 wasn't resolved > > > Key: MECLIPSE-636 > URL: http://jira.codehaus.org/browse/MECLIPSE-636 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.7 >Reporter: Ramiro Pereira de Magalhães > Attachments: MECLIPSE-636-withTests.patch, patch-MECLIPSE-636.patch > > > Task MECLIPSE-156 wasn't correctly implemented and the proposed feature > (namely, that the plugin should support setting file encoding) does not work. > I think that only one of the proposed patches there were implemented (on > IdeUtils.java) while the other (on EclipseUtils.java) one wasn't. -- 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: (MJAR-128) Add support for updating jar
[ http://jira.codehaus.org/browse/MJAR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219680#action_219680 ] Pierre-Yves Ricau commented on MJAR-128: Thanks all, and special thanks to Dennis : the Maven Shade Plugin is exactly what I needed, with almost no configuration (to anyone reading this later on, here is what I've done => http://code.google.com/p/cas-client-appengine/source/browse/tags/3.1.10-1.0/cas-client-core-appengine/pom.xml ) > Add support for updating jar > > > Key: MJAR-128 > URL: http://jira.codehaus.org/browse/MJAR-128 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: David Hoffer > > As a user of the maven jar plugin I want to be able to modify/update existing > jars. For example, I want to replace a few class files in a jar and i want > to replace a few sources files in a sources jar artifact. Adding/removing > should also be supported. > This is a needed feature because for large jars, it takes to long to unpack > and re-jar. -- 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: (MSHARED-120) No single report generated with latest maven-reporting-impl
[
http://jira.codehaus.org/browse/MSHARED-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHARED-120.
-
Resolution: Fixed
done in r940300
> No single report generated with latest maven-reporting-impl
> ---
>
> Key: MSHARED-120
> URL: http://jira.codehaus.org/browse/MSHARED-120
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl 2.0.4.1, maven-reporting-impl
> 2.0.4.2
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
>Priority: Blocker
> Fix For: maven-reporting-impl 2.0.4.3
>
> Attachments: MSHARED-120.patch, reporting.patch
>
>
> Recently, I fixed several report plugins (changelog, changes etc.) to use
> Doxia 1.0 and latest maven-reporting-impl.
> The main goal was to make reporting plugins available in PDF (see MPDF-26 and
> doc [1])
> I notified that running a single report doesn't work but works when coupling
> with maven-site-plugin 2.0.x.
> For instance, run:
> {noformat}
> mvn org.apache.maven.plugins:maven-changelog-plugin:2.2-SNAPSHOT:changelog
> {noformat}
> In Doxia 1.0, the SiteRenderSink [2] uses a StringWriter by default to use
> getBody() in the renderer [3]. So running a single report doesn't write a
> file with reporting-impl:2.0.4.2
> In MPIR 2.1.2, we overrided the mojo.execute() to handle a default renderer
> [4] so we are able to run a single report. I propose to move this logic in
> AbstractMavenReport.
> [1]
> http://maven.apache.org/plugins/maven-pdf-plugin-1.1-SNAPSHOT/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues
> [2]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/sink/SiteRendererSink.html#47
> [3]
> http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#433
> [4]
> http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/AbstractProjectInfoReport.html#137
--
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-301) rootArtifactId is interpreted incorrectly in maven-archetype-plugin:2.0-alpha-5 (was okay in 2.0-alpha-4)
rootArtifactId is interpreted incorrectly in maven-archetype-plugin:2.0-alpha-5
(was okay in 2.0-alpha-4)
-
Key: ARCHETYPE-301
URL: http://jira.codehaus.org/browse/ARCHETYPE-301
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0-alpha-5
Environment: Mac OS X 10.6.3, Java 1.6.0_17, Maven 3.0-beta-1
Reporter: Pat Podenski
Priority: Critical
Attachments: demo-archetype.zip
Apparently a modification was made to the maven-archetype-plugin in 2.0-alpha-5
that has changed the way that rootArtifactId is interpreted. A similar issue
has been reported, but with somewhat different symptoms (ARCHETYPE-298).
If you install the attached demo-archetype (multimodule) and then create a
project from it, rootArtifactId will be interpreted differently between
2.0-alpha-4 and 2.0-alpha-5. This demo-archetype uses the supplied artifactId
(when creating a project) to 'derive' the desired parent and sub-module
artifactIds with the following expressions in the respective archetype poms:
parent artifactId ${artifactId}-parent
module artifactId ${rootArtifactId}-module
Steps to reproduce this problem using demo-archetype:
1] unzip demo-archetype.zip and build it (mvn install) to install in
~/.m2/repository.
2] Create a project from the demo-archetype using 2.0-alpha-4:
mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate
3] Note that in the sub-module the parent artifactId is correct for the
associated parent.
4] Then create a project from the demo-archetype using 2.0-alpha-5:
mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-5:generate
5] Note that in this project sub-module the parent artifactId is NOT correct
for the associated parent.
For example, for a project whose input artifactId = purchase-order, the
following results are obtained for the parent/module artifactIds in the
respective cases:
(A)** WITH 2.0-alpha-4 (correct results):
parent coordinates are [org.foo:purchase-order-parent:1.0-SNAPSHOT]
and
sub-module coordinates are [org.foo:purchase-order-module:1.0-SNAPSHOT]
- parent coordinates in sub-module are
[org.foo:purchase-order-parent:1.0-SNAPSHOT]
(B)** WITH 2.0-alpha-5 (incorrect results):
parent coordinates are [org.foo:purchase-order-parent:1.0-SNAPSHOT]
and
sub-module coordinates are [org.foo:purchase-order-module:1.0-SNAPSHOT]
- parent coordinates in sub-module are [org.foo:purchase-order:1.0-SNAPSHOT]
In case (B) the '-parent' portion of the parent artifactId is missing. Instead
of using the actual rootArtifactId (purchase-order-parent), the 'entered'
artifactId is being used (purchase-order).
The second case (B) will not build because the parent artifactId in the
sub-module is not correct for the respective parent.
--
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: (DOXIA-388) Use internal xdoc and fml xsds for validation when in offline mode
[ http://jira.codehaus.org/browse/DOXIA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219694#action_219694 ] Dave Meibusch commented on DOXIA-388: - Note that without internet connection != (necessarily) offline mode. Intranet use of Maven, in online mode, without internet access is also common. > Use internal xdoc and fml xsds for validation when in offline mode > -- > > Key: DOXIA-388 > URL: http://jira.codehaus.org/browse/DOXIA-388 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Fml, Module - Xdoc, Module - Xhtml, Modules >Reporter: Lukas Theussl > > I think that at least xdoc and fml (maybe xhtml) modules should include the > necessary files do enable validation without internet connection. -- 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-477) href's drop the leading character in the href
href's drop the leading character in the href
---
Key: MSITE-477
URL: http://jira.codehaus.org/browse/MSITE-477
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.1, 2.0.1
Reporter: Andrew Hughes
parent pom.xml:
{noformat}
module-a
{noformat}
parent site.xml:
{noformat}
{noformat}
The generated html links to "module-a" look like this
{noformat}
module-a
{noformat}
Note, the href is missing the leading character "m", it should be..
{noformat}
module-a
{noformat}
I tried to run this wil 2.0.1 and 2.1 - but got the same result with both.
Hopfully this is a mis-configuration on my part, but if it is then perhaps it
can be tested by the plugin and can fail the build.
Thanks for reading :)
--
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
