[jira] Created: (SCM-468) Add scm:update-scm-tag
Add scm:update-scm-tag -- Key: SCM-468 URL: http://jira.codehaus.org/browse/SCM-468 Project: Maven SCM Issue Type: New Feature Components: maven-plugin Affects Versions: 1.2 Reporter: Baptiste MATHUS Priority: Minor In each pom, maven users have to maintain the xxxConnection tags to match the actual location of the project. When you checkout or move a project in the repository tree, those tags become incorrect. So you have to update them manually and take care for typos. As the information is present in the scm metadata (subversion, for me, by using "svn info"), those tags could be simply updated automatically by such a goal. Obviously, this goal would be even more useful when being ran at the root of a multimodule project. Thanks a lot. Cheers. -- 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: (DOXIA-311) Character references do not work in xdoc section titles
[ http://jira.codehaus.org/browse/DOXIA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-311: Affects Version/s: (was: 1.1.1) 1.1 > Character references do not work in xdoc section titles > --- > > Key: DOXIA-311 > URL: http://jira.codehaus.org/browse/DOXIA-311 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.1 > Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC >Reporter: Malachi de AElfweald >Priority: Minor > Attachments: testcase.tgz > > > In the attached testcase, you will see that the π reference works in the > paragraph content but is replaced with π in the section title. -- 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: (DOXIA-311) Character references do not work in xdoc section titles
[ http://jira.codehaus.org/browse/DOXIA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-311. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.1.1 Committed a partial fix in r771612: all standard html entities are processed correctly, only custom entities (like &tritPos; from DOXIA-310) still get un-escaped in section titles. I will open a separate issue for that. > Character references do not work in xdoc section titles > --- > > Key: DOXIA-311 > URL: http://jira.codehaus.org/browse/DOXIA-311 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.1 > Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC >Reporter: Malachi de AElfweald >Assignee: Lukas Theussl >Priority: Minor > Fix For: 1.1.1 > > Attachments: testcase.tgz > > > In the attached testcase, you will see that the π reference works in the > paragraph content but is replaced with π in the section title. -- 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: (DOXIA-314) Custom entities do not work in xdoc section titles
Custom entities do not work in xdoc section titles
--
Key: DOXIA-314
URL: http://jira.codehaus.org/browse/DOXIA-314
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xdoc
Affects Versions: 1.1
Reporter: Lukas Theussl
There is a test case in EntitiesVerifier of SiteTools. The following xdoc (cut):
{code:xml}
]>
Local Entities: 'Α' '&tritPos;'
'Α' '&tritPos;'
{code}
produces:
{code:xml}
Local Entities: 'Α' '𝟭'
'Α' '𝟭'
{code}
ie the replacement text for &tritPos; gets un-escaped in the title while it is
correct in the paragraph.
--
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-230) aggregate report requires to have aggregate=true configuration parameter
aggregate report requires to have aggregate=true configuration parameter Key: MJAVADOC-230 URL: http://jira.codehaus.org/browse/MJAVADOC-230 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 2.0.9 Windows XP SP2 Reporter: Gabriel Forro Priority: Minor Project setup: I have a multi-module project (standard nested layout). The reports are configured in the parent project. I use the "aggregate" report to create an aggregated javadoc by the maven-javadoc-plugin: aggregate Problem: The aggregate report is ignored, when I launch the "mvn site" command, unless the aggregated parameter is set to true in the maven-javadoc-plugin configuration. So the following setup is required in pom.xml: UTF-8 true aggregate Desired functionality: Launch the aggregate goal, if it is declared in the report section. Do not require the aggregate parameter=true setting (it is a duplication and also the aggregate parameter is deprecated). The following setup should be enough in pom.xml: UTF-8 aggregate Comment: The aggregate goal works fine (it does not require to have the aggregate=true parameter), if it is launched directly. That is by the "mvn javadoc:aggregate" command. It just does not work, when it is launched indirectly through the site plugin as a report. -- 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: (DOXIA-312) comments in meta properties end up in author content
[ http://jira.codehaus.org/browse/DOXIA-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-312. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.1.1 Fixed in r771654. > comments in meta properties end up in author content > > > Key: DOXIA-312 > URL: http://jira.codehaus.org/browse/DOXIA-312 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.1.1 > Environment: xdoc >Reporter: Malachi de AElfweald >Assignee: Lukas Theussl >Priority: Minor > Fix For: 1.1.1 > > > I was getting ready to remove the xhtml comment from this snippet: > > Balanced Ternary > > Malachi de Ælfweald > > and noticed that page source now shows: > http://jira.codehaus.org/browse/DOXIA-309 --> > Malachi de Ælfweald" /> -- 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-549) TestNg provider does not run junit tests correctly when forkMode=always
TestNg provider does not run junit tests correctly when forkMode=always --- Key: SUREFIRE-549 URL: http://jira.codehaus.org/browse/SUREFIRE-549 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.3 Reporter: Michael Pigg Priority: Minor Attachments: SurefireJunitViaTestngProblem.zip We have both TestNG-based tests for unit testing and Junit-based tests (that use Spring OSGi test framework) for integration testing. When running the JUnit tests we would like to use forkMode=always to force the OSGi container to be created for each test. However, when forkMode=always is set, the TestNG provider does not properly run the JUnit test. In the default forkMode of once, the JUnit tests are executed. The problem is that the TestNGDirectoryTestSuite.execute method is coded to run both TestNG and JUnit tests when run for multiple test sets (which is executed for forkMode=once), but when run for one test it seems to assume that the test is a TestNG test. I think it should check for JUnit tests in either mode of execution. The work-around for the problem is to add the TestNG junit property to the surefire configuration when running the JUnit tests: junit true -- 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-558) Ignoring listed AspectJ dependencies
Ignoring listed AspectJ dependencies Key: MECLIPSE-558 URL: http://jira.codehaus.org/browse/MECLIPSE-558 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: AJDT support Affects Versions: 2.6, 2.7 Reporter: Dale Peakall When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there. Using the none is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc. At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the 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: (DOXIA-314) Custom entities do not work in xdoc section titles
[
http://jira.codehaus.org/browse/DOXIA-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-314.
-
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1.1
done in [r771709|http://svn.apache.org/viewvc?rev=771709&view=rev]
> Custom entities do not work in xdoc section titles
> --
>
> Key: DOXIA-314
> URL: http://jira.codehaus.org/browse/DOXIA-314
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc
>Affects Versions: 1.1
>Reporter: Lukas Theussl
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> There is a test case in EntitiesVerifier of SiteTools. The following xdoc
> (cut):
> {code:xml}
>
>
> ]>
> Local Entities: 'Α' '&tritPos;'
> 'Α' '&tritPos;'
> {code}
> produces:
> {code:xml}
> Local Entities: 'Α' '𝟭'
> 'Α' '𝟭'
> {code}
> ie the replacement text for &tritPos; gets un-escaped in the title while it
> is correct in the paragraph.
--
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-2446) JasperReports 3.5.1 upload
JasperReports 3.5.1 upload -- Key: MAVENUPLOAD-2446 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2446 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sf.net/maven/jasperreports-3.5.1-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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: (SCM-469) Auto-generated config spec during release:perform contains line element * null
Auto-generated config spec during release:perform contains line element * null -- Key: SCM-469 URL: http://jira.codehaus.org/browse/SCM-469 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-clearcase Affects Versions: 1.2 Environment: Maven 2.0.9, Windows XP, Maven-Release-Plugin 2.0-beta-9 Reporter: Torsten Reinhard Priority: Critical When trying to release a module after migrating from maven-release-plugin 2.0-beta-8 to 2.0-beta-9 I got the following error during mvn release:perform: [INFO] [release:perform] [INFO] Checking out the project to perform the release ... [INFO] Executing: c:\LocalViewsRelease>>cmd.exe /X /C "cleartool mkview -snapshot -tag reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT -vws \\d167961\kmdata\reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT.vws C:\LocalViewsRelease\gi [INFO] Created config spec for view 'reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT': element * CHECKEDOUT element * gide-parent-2.3-alpha-1 element * null load /GDCAMS/GDCAMS/src/gide-parent [INFO] Executing: c:\LocalViewsRelease\gide-parent-2.3-alpha-2-SNAPSHOT>>cmd.exe /X /C "cleartool setcs -tag reinhart-d167961-maven-gide-parent-2.3-alpha-2-SNAPSHOT C:\DOKUME~1\reinhart\LOKALE~1\Temp\configspec-reinhart-d167961-maven-gide-parent-2. [INFO] Executing goals 'deploy site-deploy'... [WARNING] Base directory is a file. Using base directory as POM location. [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing Maven. Working directory "C:\LocalViewsRelease\gide-parent-2.3-alpha-2-SNAPSHOT\GDCAMS\GDCAMS\src\gide-parent" does not exist! [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error executing Maven. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing Maven. at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Error executing Maven. at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89) at org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.java:67) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:336) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:282) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:262) at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129) ... 18 more Caused by: org.apache.maven.shared.release.exec.MavenExecutorExcep
[jira] Created: (MAVENUPLOAD-2447) JFreeChart 1.0.12 upload
JFreeChart 1.0.12 upload Key: MAVENUPLOAD-2447 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2447 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sf.net/maven/jfreechart-1.0.12-bundle.jar http://www.jfree.org/jfreechart/ http://sourceforge.net/project/memberlist.php?group_id=15494 Open Source Java Chart Library -- 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-2448) JCommon 1.0.15 upload
JCommon 1.0.15 upload - Key: MAVENUPLOAD-2448 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2448 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sf.net/maven/jcommon-1.0.15-bundle.jar http://www.jfree.org/jcommon/ http://sourceforge.net/project/memberlist.php?group_id=15494 Open Source Java Class Library (used by JFreeChart) -- 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] Reopened: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lee Thompson reopened WAGON-264: If its a server config issue, its a server config issue that http transport clients know how to deal with (except wagon...) I'll download expat with CURL, WGET, and Wagon. Two work, one doesn't. Same for openssl. Wagon corrupts compressed tarballs via http/https. $ mkdir curl wagon wget $ cd curl $ wget http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz--2009-05-05 10:02:00-- http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz Resolving softlayer.dl.sourceforge.net... 74.86.229.28 Connecting to softlayer.dl.sourceforge.net|74.86.229.28|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 318349 (311K) [application/x-gzip] Saving to: `expat-1.95.8.tar.gz' 100%[==>] 318,349 539K/s in 0.6s 2009-05-05 10:02:00 (539 KB/s) - `expat-1.95.8.tar.gz' saved [318349/318349] $ cd ../wget $ wget http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz--2009-05-05 10:02:10-- http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz Resolving softlayer.dl.sourceforge.net... 74.86.229.28 Connecting to softlayer.dl.sourceforge.net|74.86.229.28|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 318349 (311K) [application/x-gzip] Saving to: `expat-1.95.8.tar.gz' 100%[==>] 318,349 554K/s in 0.6s 2009-05-05 10:02:10 (554 KB/s) - `expat-1.95.8.tar.gz' saved [318349/318349] $ HTTP/1.1 200 OK -bash: HTTP/1.1: No such file or directory $ cd ../wagon/ $ mvn wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz -Dwagon.url=http://softlayer.dl.sourceforge.net/sourceforge/expat -Dwagon.toDir=./ [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'wagon'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [wagon:download-single] (aggregator-style) [INFO] [INFO] [wagon:download-single] [INFO] Downloading: http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.98.8.tar.gz to /Users/Lee/junk/downloads/wagon/expat-1.98.8.tar.gz [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue May 05 10:03:59 CDT 2009 [INFO] Final Memory: 4M/8M [INFO] $ $ $ cd .. $ ls -lR total 0 drwxr-xr-x 3 Lee Lee 102 May 5 10:02 curl drwxr-xr-x 3 Lee Lee 102 May 5 10:03 wagon drwxr-xr-x 3 Lee Lee 102 May 5 10:02 wget ./curl: total 624 -rw-r--r-- 1 Lee Lee 318349 Jul 24 2004 expat-1.95.8.tar.gz ./wagon: total 72 -rw-r--r-- 1 Lee Lee 34158 May 5 10:03 expat-1.98.8.tar.gz ./wget: total 624 -rw-r--r-- 1 Lee Lee 318349 Jul 24 2004 expat-1.95.8.tar.gz $ > compressed tarball download problems > > > Key: WAGON-264 > URL: http://jira.codehaus.org/browse/WAGON-264 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 >Reporter: Lee Thompson >Assignee: John Casey > Fix For: 1.0-beta-5 > > > HTTP wagon will uncompress tarballs it downloads, sometimes badly. > Downloading openssl results in an unpressed download > $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz > -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ > $ tar tzf openssl-0.9.8k.tar.gz > gzip: stdin: not in gzip format > tar: Child returned status 1 > tar: Error exit delayed from previous errors > $ tar tf openssl-0.9.8k.tar.gz | more > openssl-0.9.8k/apps/ > openssl-0.9.8k/apps/app_rand.c > Downloading expat results in a corrupted file > mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz > -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ > $ tar tf expat-1.98.8.tar.gz > tar: This does not look like a tar archive > tar: Skipping to next header > tar: Read 1943 bytes from expat-1.98.8.tar.gz > tar: Error exit delayed from previous errors -- 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: (MGPG-14) With maven 2.1.0 some poms end up with invalid signatures
With maven 2.1.0 some poms end up with invalid signatures - Key: MGPG-14 URL: http://jira.codehaus.org/browse/MGPG-14 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Reporter: Daniel Kulp Attachments: patch.txt The pom-transformed.xml is installed, but gpg is signing the original pom.xml. Thus, the signature is invalid. -- 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: (DOXIA-315) Add new meta Date-Revision and Date-Creation in the default-site.vm
Add new meta Date-Revision and Date-Creation in the default-site.vm
---
Key: DOXIA-315
URL: http://jira.codehaus.org/browse/DOXIA-315
Project: Maven Doxia
Issue Type: Improvement
Components: Site Renderer
Affects Versions: 1.1
Reporter: Vincent Siveton
Should be nice to add the creation and revision dates in the renderer, i.e.:
{noformat}
{noformat}
--
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: (DOXIA-315) Add new meta Date-Revision and Date-Creation in the default-site.vm
[
http://jira.codehaus.org/browse/DOXIA-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-315.
-
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1.1
fixed in [r771801|http://svn.apache.org/viewvc?rev=771801&view=rev]
> Add new meta Date-Revision and Date-Creation in the default-site.vm
> ---
>
> Key: DOXIA-315
> URL: http://jira.codehaus.org/browse/DOXIA-315
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Site Renderer
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> Should be nice to add the creation and revision dates in the renderer, i.e.:
> {noformat}
>
>
> {noformat}
--
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] Moved: (DOXIASITETOOLS-20) Add new meta Date-Revision and Date-Creation in the default-site.vm
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton moved DOXIA-315 to DOXIASITETOOLS-20:
-
Affects Version/s: (was: 1.1)
1.1
Fix Version/s: (was: 1.1.1)
1.1.1
Component/s: (was: Site Renderer)
Key: DOXIASITETOOLS-20 (was: DOXIA-315)
Project: Maven Doxia Sitetools (was: Maven Doxia)
> Add new meta Date-Revision and Date-Creation in the default-site.vm
> ---
>
> Key: DOXIASITETOOLS-20
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-20
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> Should be nice to add the creation and revision dates in the renderer, i.e.:
> {noformat}
>
>
> {noformat}
--
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: (MGPG-14) With maven 2.1.0 some poms end up with invalid signatures
[ http://jira.codehaus.org/browse/MGPG-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175162#action_175162 ] Daniel Kulp commented on MGPG-14: - The attached patch seems to work fine for Maven 2.1.0 and 2.0.9. However, there is a little bit of "hackish" code in there that's I'd like some others to look at before I commit it. > With maven 2.1.0 some poms end up with invalid signatures > - > > Key: MGPG-14 > URL: http://jira.codehaus.org/browse/MGPG-14 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-4 >Reporter: Daniel Kulp > Attachments: patch.txt, patch2.txt > > > The pom-transformed.xml is installed, but gpg is signing the original > pom.xml. Thus, the signature is invalid. -- 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: (MGPG-14) With maven 2.1.0 some poms end up with invalid signatures
[ http://jira.codehaus.org/browse/MGPG-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated MGPG-14: Attachment: patch2.txt New version of patch with comments to explain some of the hacks > With maven 2.1.0 some poms end up with invalid signatures > - > > Key: MGPG-14 > URL: http://jira.codehaus.org/browse/MGPG-14 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-4 >Reporter: Daniel Kulp > Attachments: patch.txt, patch2.txt > > > The pom-transformed.xml is installed, but gpg is signing the original > pom.xml. Thus, the signature is invalid. -- 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-142) Default remote repository id not safe
[ http://jira.codehaus.org/browse/MANTTASKS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTTASKS-142: Assignee: Paul Gier Fix Version/s: (was: 2.1.0) > Default remote repository id not safe > - > > Key: MANTTASKS-142 > URL: http://jira.codehaus.org/browse/MANTTASKS-142 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: dependencies task >Affects Versions: 2.0.9 >Reporter: Benjamin Bentmann >Assignee: Paul Gier >Priority: Minor > Fix For: 2.0.10 > > > The default id for a remote repository is just the repo URL. However, a URL > typically contains all kind of characters that are not safe for usage in > local file paths. E.g. the colon ':' from the URL scheme will just blow up on > Windows. The slashes from the URL also cause troubles for a path that is > meant to be a simple file name instead of a directory spec. > Better choices for the default repo id could be the host name only or just > some hex-encoded MD5-digest of the URL. -- 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-106) Maven ant tasks artifact has maven inside the jar and so can't be used from inside the maven (maven-antrun-plugin) - classes do conflict
[ http://jira.codehaus.org/browse/MANTTASKS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTTASKS-106: Fix Version/s: (was: 2.1.0) > Maven ant tasks artifact has maven inside the jar and so can't be used from > inside the maven (maven-antrun-plugin) - classes do conflict > > > Key: MANTTASKS-106 > URL: http://jira.codehaus.org/browse/MANTTASKS-106 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.7 > Environment: Linux >Reporter: Vitaliy Tymchyshyn >Assignee: Paul Gier > Fix For: 2.0.10 > > > I've previously used maven-artifact-ant that is not updated since 2.0.4. Now > I need a new (2.0.6) feature - to attach additional source and javadoc jar's > from install task. > I've tried to use maven-ant-tasks 2.0.7 but failed. > It gives me > java.lang.ClassCastException: > org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot > be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:34) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Looking at the jar, I can see that it contains (unlike to maven-artifact-ant) > a lot of code not related to ant tasks itself inside it. I suppose this > classes clashes with the "parent" maven classes. > I suppose this to be a bug, because even if you wish to depend on maven code, > you must provide it with dependency mechanism in maven artifact (so that it > could be disabled) and not with including additional classes into the 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: (MANTTASKS-142) Default remote repository id not safe
[ http://jira.codehaus.org/browse/MANTTASKS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTTASKS-142. --- Resolution: Fixed Fixed in [r771907|http://svn.apache.org/viewvc?view=rev&revision=771907] > Default remote repository id not safe > - > > Key: MANTTASKS-142 > URL: http://jira.codehaus.org/browse/MANTTASKS-142 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: dependencies task >Affects Versions: 2.0.9 >Reporter: Benjamin Bentmann >Assignee: Paul Gier >Priority: Minor > Fix For: 2.0.10 > > > The default id for a remote repository is just the repo URL. However, a URL > typically contains all kind of characters that are not safe for usage in > local file paths. E.g. the colon ':' from the URL scheme will just blow up on > Windows. The slashes from the URL also cause troubles for a path that is > meant to be a simple file name instead of a directory spec. > Better choices for the default repo id could be the host name only or just > some hex-encoded MD5-digest of the URL. -- 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: (DOXIASITETOOLS-20) Add new meta Date-Revision and Date-Creation in the default-site.vm
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175187#action_175187
]
Dennis Lundberg commented on DOXIASITETOOLS-20:
---
What are these meta used for? I have never seen them before. Do you have a
reference that describes them?
Also, what's up with the date format? The ISO-8601 date format is "-MM-dd".
Shouldn't we output dates in that format?
> Add new meta Date-Revision and Date-Creation in the default-site.vm
> ---
>
> Key: DOXIASITETOOLS-20
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-20
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> Should be nice to add the creation and revision dates in the renderer, i.e.:
> {noformat}
>
>
> {noformat}
--
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: (WAGON-264) compressed tarball download problems
[ http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175191#action_175191 ] Lee Thompson commented on WAGON-264: I'm reading rfc2616 and indeed, I agree with you that the openssl webserver is misconfigured deviating from HTTP spec. The webserver in this case transmitted Content-Type of gzip with no Content-Encoding but declared in the reply Content-Encoding of gzip. Unfortunately, it looks to me like the openssl config is following the Apache documentation to the letter http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addencoding specifically --> To make this long story short, you should always use x-gzip and x-compress for these two specific encodings. The Apache docs are probably incorrect (or confusing at best) leading to this issue. I'd have to go back to the point that wget, and curl (and I just tested firefox) will all download from these sites and get the correct file. I'd also go back to my point that performance is worse when you ask for GZIP encoding for filetypes that are already compressed. The only typical maven uncompressed file types are the pom XML files and the SHA1 and MD5SUM hash files and these artifacts are so small that the benefit is negligible. While wagon might not have a bug in regards to rfc2616, it does have an issue dealing with sites who read the Apache configuration documentation. Wagon is the only http client I know of that can't download tarballs from sourceforge and openssl. (Lots of sourceforge mirrors have this config problem). The internet is a cooperative media and strict compliance is often compromised when interoperability concerns are brought in. Please make wagon defend itself from badly configured webservers. > compressed tarball download problems > > > Key: WAGON-264 > URL: http://jira.codehaus.org/browse/WAGON-264 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-2, 1.0-beta-3, 1.0-beta-4, 1.0-beta-5 >Reporter: Lee Thompson >Assignee: John Casey > Fix For: 1.0-beta-5 > > > HTTP wagon will uncompress tarballs it downloads, sometimes badly. > Downloading openssl results in an unpressed download > $ mvn -X wagon:download-single -Dwagon.fromFile=openssl-0.9.8k.tar.gz > -Dwagon.url=http://www.openssl.org/source -Dwagon.toDir=./ > $ tar tzf openssl-0.9.8k.tar.gz > gzip: stdin: not in gzip format > tar: Child returned status 1 > tar: Error exit delayed from previous errors > $ tar tf openssl-0.9.8k.tar.gz | more > openssl-0.9.8k/apps/ > openssl-0.9.8k/apps/app_rand.c > Downloading expat results in a corrupted file > mvn -X wagon:download-single -Dwagon.fromFile=expat-1.98.8.tar.gz > -Dwagon.url=http://prdownloads.sourceforge.net/expat -Dwagon.toDir=./ > $ tar tf expat-1.98.8.tar.gz > tar: This does not look like a tar archive > tar: Skipping to next header > tar: Read 1943 bytes from expat-1.98.8.tar.gz > tar: Error exit delayed from previous errors -- 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: (MCOMPILER-71) javac compilation error for package-info.java containing package annotation
[ http://jira.codehaus.org/browse/MCOMPILER-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175200#action_175200 ] Rishabh Chandra commented on MCOMPILER-71: -- I have faced this issue myself. I tried both 2.0 and 2.0.1 and they did not work. Then i used the excludes and got the code to compile. As the package-info file is only for javadoc I just ignored it. This is the only solution i could get to work. org.apache.maven.plugins maven-compiler-plugin true 128m 512m 1.5 1.5 **/package-info.java > javac compilation error for package-info.java containing package annotation > --- > > Key: MCOMPILER-71 > URL: http://jira.codehaus.org/browse/MCOMPILER-71 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Windows XP SP2 > JDK 1.5.0_15 >Reporter: Gabriel Forro > Attachments: compile_error_2.0.2.log > > > The package-info.java files can not be compiled in Maven 2 if the 2.0.2 > maven-compiler-plugin is used. package-info.java files can be compiled by > earlier versions of the maven-compiler-plugin (I have tried 2.0 and 2.0.1). > Newer snapshot versions does not work also and it fails in the same error (I > have tried version 2.1-snapshot). > This problem can be caused by an unusual behavior of the javac from jdk 1.5. > This behavior is as follows: > You can not use '/' file separator during compiling package-info.java (for > instance "javac sk/forro/package-info.java"). You must use '\' separator (for > instance "javac sk\forro\package-info.java"). If you use the '/' separator > you get the the compilation error reported by this bug (package annotations > should be in file package-info.java). This is javac 'feature' has been > removed in jdk 6 and in jdk 6 you can use either '/' or '\' - it does not > matter. > It looks like the maven-compiler-plugin or one of its components (I mean > plexus-x artefacts used by maven-compiler-plugin) uses '/' instead of the '\' > in the MS Windows environment. > I have attached a log file of an unsuccessful build (generated by mvn install > -X) > A possible workaround to solve this problem temporarily: > The compilation successes if I use either an older version of > maven-compiler-plugin or jdk 6 or do not use package-info.java files 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] Created: (MAVENUPLOAD-2449) Automate syncing of existing JetS3t Maven2 repository
Automate syncing of existing JetS3t Maven2 repository - Key: MAVENUPLOAD-2449 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2449 Project: Maven Upload Requests Issue Type: Wish Reporter: James Murty "net.java.dev.jets3t","mavens...@web.sourceforge.net:/home/groups/j/je/jets3t/htdocs/maven2/","rsync_ssh","James Murty","jmu...@dev.java.net",, Please set up automated syncing of my Maven2 repository into the central repository. The "net.java.dev.jets3t" repository already exists in the central repository, but the source provided above contains more recent artifacts, namely versions 0.6.1 and 0.7.0 of JetS3t. I am James Murty, the developer and project owner of JetS3t. I can be contacted via jmu...@dev.java.net (the email address listed in an obfuscated form in the project support page here: http://jets3t.s3.amazonaws.com/support.html) Thanks! -- 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] Issue Comment Edited: (MAVENUPLOAD-2449) Automate syncing of existing JetS3t Maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175204#action_175204 ] James Murty edited comment on MAVENUPLOAD-2449 at 5/6/09 1:44 AM: -- MAVENUPLOAD-1985 was the issue that prompted the creation of the original central repository entry for JetS3t was (Author: jmurty): The issue that prompted the creation of the original central repository entry for JetS3t > Automate syncing of existing JetS3t Maven2 repository > - > > Key: MAVENUPLOAD-2449 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2449 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: James Murty > > "net.java.dev.jets3t","mavens...@web.sourceforge.net:/home/groups/j/je/jets3t/htdocs/maven2/","rsync_ssh","James > Murty","jmu...@dev.java.net",, > Please set up automated syncing of my Maven2 repository into the central > repository. The "net.java.dev.jets3t" repository already exists in the > central repository, but the source provided above contains more recent > artifacts, namely versions 0.6.1 and 0.7.0 of JetS3t. > I am James Murty, the developer and project owner of JetS3t. I can be > contacted via jmu...@dev.java.net (the email address listed in an obfuscated > form in the project support page here: > http://jets3t.s3.amazonaws.com/support.html) > Thanks! -- 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
