[jira] Commented: (DOXIA-313) subsection is printing name instead of title to page

2009-05-04 Thread Lukas Theussl (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175103#action_175103
 ] 

Lukas Theussl commented on DOXIA-313:
-

I don't see the title attribute documented anywhere except in the 
(auto-generated) xsdddocs. As I said, it is a valid html attribute and as such 
simply gets copied over to the html output as is, but otherwise it is ignored 
by the xdoc parser.

> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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-313) subsection is printing name instead of title to page

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175102#action_175102
 ] 

Malachi de AElfweald commented on DOXIA-313:


Actually, no worries I'll just use the name attribute. We probably 
shouldn't list the title attribute in the javadocs though as it is misleading 
for anyone using those for reference.

> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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: (DOXIA-313) subsection is printing name instead of title to page

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175101#action_175101
 ] 

Malachi de AElfweald edited comment on DOXIA-313 at 5/5/09 12:03 AM:
-

It is listed in the attributes if you click on "The full documentation is 
available here. "

http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xdoc/xsddoc/http___maven.apache.org_XDOC_2.0/element/subsection.html#attr_title


  was (Author: malachid69):
It is listed in the attributes if you click on "The full documentation is 
available here. "

http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xdoc/xsddoc/http___maven.apache.org_XDOC_2.0/element/section.html#attr_title

  
> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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-313) subsection is printing name instead of title to page

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175101#action_175101
 ] 

Malachi de AElfweald commented on DOXIA-313:


It is listed in the attributes if you click on "The full documentation is 
available here. "

http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xdoc/xsddoc/http___maven.apache.org_XDOC_2.0/element/section.html#attr_title


> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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-313) subsection is printing name instead of title to page

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175100#action_175100
 ] 

Malachi de AElfweald commented on DOXIA-313:


Here's what it is actually generating:

DecimalComparison

I think this is what it should be generating:

Comparison to Decimal


> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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-313) subsection is printing name instead of title to page

2009-05-04 Thread Lukas Theussl (JIRA)

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

Lukas Theussl closed DOXIA-313.
---

  Assignee: Lukas Theussl
Resolution: Not A Bug

That's the expected behavior AFAIK. "title" is only supported as a standard 
html attribute, it is not an attribute of the xdoc section element, see 
http://maven.apache.org/doxia/references/xdoc-format.html.

> subsection is printing name instead of title to page
> 
>
> Key: DOXIA-313
> URL: http://jira.codehaus.org/browse/DOXIA-313
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Xdoc
>Affects Versions: 1.1.1
>Reporter: Malachi de AElfweald
>Assignee: Lukas Theussl
>
> Doing something like ...
> prints "SomeName" in the box

-- 
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-313) subsection is printing name instead of title to page

2009-05-04 Thread Malachi de AElfweald (JIRA)
subsection is printing name instead of title to page


 Key: DOXIA-313
 URL: http://jira.codehaus.org/browse/DOXIA-313
 Project: Maven Doxia
  Issue Type: Bug
  Components: Module - Xdoc
Affects Versions: 1.1.1
Reporter: Malachi de AElfweald


Doing something like ...
prints "SomeName" in the box

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin

2009-05-04 Thread Jason Chaffee (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175096#action_175096
 ] 

Jason Chaffee commented on MNG-2426:


James,

How does this work with custom packaging and custom types declared in the 
component.xml?  For example, 

bin
bin
bin-bundle

Do I replace "jar" in the above example with "bin" or with "bin-bundle"?

> Artifact copied to local repository with wrong file extension when using 
> jboss-packaging plugin
> ---
>
> Key: MNG-2426
> URL: http://jira.codehaus.org/browse/MNG-2426
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
> Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin 
> 2.0-SNAPSHOT (from mojo-sandbox SVN r2088)
>Reporter: Fredrik Vraalsen
> Fix For: 2.2.x
>
> Attachments: bug.zip, FrigExtensionMojo.java
>
>
> When using the jboss-packaging plugin and setting  to jboss-sar in 
> my pom, the artifact is copied into the local repository with the wrong file 
> extension (.jboss-sar instead of .sar).  The jboss-packaging components.xml 
> has  set to sar.  The file in the build target directory has the 
> correct .sar extension.
> Here's the relevant excerpt from my pom.xml:
> jboss-sar
> ...
> 
> 
> 
> org.codehaus.mojo
> jboss-packaging-maven-plugin
> 2.0-SNAPSHOT
> 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] Updated: (MERCURY-125) review virtual repository strategy regarding reading available versions

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-125:
-

Description: Virtual repository now tries to replace virtuals with actual 
version thus trying to read metadata for all virtuals. Time consuming on clean 
local repository and with lack of negative metadata caching results in 
unnecessary reads
Summary: review virtual repository strategy regarding reading available 
versions  (was: review remote repository strategy regarding reading available 
versions. It now tries to replace virtuals with actual version thus trying to 
read metadata for all virtuals. Time consuming on clean local repository and 
with lack of negative metadata caching)

> review virtual repository strategy regarding reading available versions
> ---
>
> Key: MERCURY-125
> URL: http://jira.codehaus.org/browse/MERCURY-125
> Project: Mercury
>  Issue Type: Sub-task
>Reporter: Oleg Gusakov
>
> Virtual repository now tries to replace virtuals with actual version thus 
> trying to read metadata for all virtuals. Time consuming on clean local 
> repository and with lack of negative metadata caching results in unnecessary 
> reads

-- 
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: (MERCURY-127) remote repository new feature: use Nexus index if available

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-127:
-

Priority: Minor  (was: Major)

> remote repository new feature: use Nexus index if available
> ---
>
> Key: MERCURY-127
> URL: http://jira.codehaus.org/browse/MERCURY-127
> Project: Mercury
>  Issue Type: Sub-task
>  Components: Repository
>Reporter: Oleg Gusakov
>Priority: Minor
>
> use index instead of actually scanning the repository via http client, if 
> possible.
> May have to integrate with IDE which loads indexes anyway

-- 
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: (MERCURY-127) remote repository new feature: use Nexus index if available

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-127:
-

Summary: remote repository new feature: use Nexus index if available  (was: 
alter remote repository to use Nexus index if available)

> remote repository new feature: use Nexus index if available
> ---
>
> Key: MERCURY-127
> URL: http://jira.codehaus.org/browse/MERCURY-127
> Project: Mercury
>  Issue Type: Sub-task
>  Components: Repository
>Reporter: Oleg Gusakov
>
> use index instead of actually scanning the repository via http client, if 
> possible.
> May have to integrate with IDE which loads indexes anyway

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin

2009-05-04 Thread James Roper (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175095#action_175095
 ] 

James Roper commented on MNG-2426:
--

This bug can be worked around in any plugins that experience this problem, by 
adding something like this (I found this code in the Felix bundle plugin):

{code:java}
Artifact mainArtifact = currentProject.getArtifact();

// workaround for MNG-1682: force maven to install artifact using 
the "jar" handler
mainArtifact.setArtifactHandler( 
m_artifactHandlerManager.getArtifactHandler( "jar" ) );
{code}


> Artifact copied to local repository with wrong file extension when using 
> jboss-packaging plugin
> ---
>
> Key: MNG-2426
> URL: http://jira.codehaus.org/browse/MNG-2426
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
> Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin 
> 2.0-SNAPSHOT (from mojo-sandbox SVN r2088)
>Reporter: Fredrik Vraalsen
> Fix For: 2.2.x
>
> Attachments: bug.zip, FrigExtensionMojo.java
>
>
> When using the jboss-packaging plugin and setting  to jboss-sar in 
> my pom, the artifact is copied into the local repository with the wrong file 
> extension (.jboss-sar instead of .sar).  The jboss-packaging components.xml 
> has  set to sar.  The file in the build target directory has the 
> correct .sar extension.
> Here's the relevant excerpt from my pom.xml:
> jboss-sar
> ...
> 
> 
> 
> org.codehaus.mojo
> jboss-packaging-maven-plugin
> 2.0-SNAPSHOT
> 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] Updated: (MERCURY-127) alter remote repository to use Nexus index if available

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-127:
-

Description: 
use index instead of actually scanning the repository via http client, if 
possible.

May have to integrate with IDE which loads indexes anyway
Component/s: Repository

> alter remote repository to use Nexus index if available
> ---
>
> Key: MERCURY-127
> URL: http://jira.codehaus.org/browse/MERCURY-127
> Project: Mercury
>  Issue Type: Sub-task
>  Components: Repository
>Reporter: Oleg Gusakov
>
> use index instead of actually scanning the repository via http client, if 
> possible.
> May have to integrate with IDE which loads indexes anyway

-- 
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: (MERCURY-127) alter remote repository to use Nexus index if available

2009-05-04 Thread Oleg Gusakov (JIRA)
alter remote repository to use Nexus index if available
---

 Key: MERCURY-127
 URL: http://jira.codehaus.org/browse/MERCURY-127
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-123) add evict() call to the metadata cache

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-123:
-

Description: 
Currently metadata cache is written to accommodate one-time usage pattern - 
a'la Maven build, and does not take care of long running use case - the cache 
is not limited and can consume a lot of memory.

Need to introduce a true session-like behavior via LRU strategy and evict() call

  was:
Currently metadata cache is written to accommodate one-time usage pattern - 
a'la Maven build, and does not take care of long running pattern - the cache is 
not limited and can consume a lot of memory.

Need to introduce a true session-like behavior via LRU and evict()


> add evict() call to the metadata cache
> --
>
> Key: MERCURY-123
> URL: http://jira.codehaus.org/browse/MERCURY-123
> Project: Mercury
>  Issue Type: Sub-task
>Reporter: Oleg Gusakov
>
> Currently metadata cache is written to accommodate one-time usage pattern - 
> a'la Maven build, and does not take care of long running use case - the cache 
> is not limited and can consume a lot of memory.
> Need to introduce a true session-like behavior via LRU strategy and evict() 
> call

-- 
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: (MERCURY-123) add evict() call to the metadata cache

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-123:
-

Description: 
Currently metadata cache is written to accommodate one-time usage pattern - 
a'la Maven build, and does not take care of long running pattern - the cache is 
not limited and can consume a lot of memory.

Need to introduce a true session-like behavior via LRU and evict()

> add evict() call to the metadata cache
> --
>
> Key: MERCURY-123
> URL: http://jira.codehaus.org/browse/MERCURY-123
> Project: Mercury
>  Issue Type: Sub-task
>Reporter: Oleg Gusakov
>
> Currently metadata cache is written to accommodate one-time usage pattern - 
> a'la Maven build, and does not take care of long running pattern - the cache 
> is not limited and can consume a lot of memory.
> Need to introduce a true session-like behavior via LRU and evict()

-- 
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: (WAGON-264) compressed tarball download problems

2009-05-04 Thread John Casey (JIRA)

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

John Casey closed WAGON-264.


 Assignee: John Casey
   Resolution: Not A Bug
Fix Version/s: 1.0-beta-5

This is a server configuration issue, not a wagon problem.

> 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: (WAGON-264) compressed tarball download problems

2009-05-04 Thread John Casey (JIRA)

[ 
http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175089#action_175089
 ] 

John Casey commented on WAGON-264:
--

Sorry, the output for the expat download didn't seem correct, so I retried with 
a URL I got from browsing to the expat project:

{noformat}
Betelgeuse:wagon-plugin-tests jdcasey$ curl -X HEAD -i 
http://softlayer.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz
HTTP/1.1 200 OK
Date: Mon, 04 May 2009 20:42:45 GMT
Server: Apache
Last-Modified: Sat, 24 Jul 2004 05:36:30 GMT
ETag: "3136801c-4db8d-22419380"
Accept-Ranges: bytes
Content-Length: 318349
Connection: close
Content-Type: application/x-gzip
{noformat}

> 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
>
> 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: (WAGON-264) compressed tarball download problems

2009-05-04 Thread John Casey (JIRA)

[ 
http://jira.codehaus.org/browse/WAGON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175087#action_175087
 ] 

John Casey commented on WAGON-264:
--

This looks like a configuration issue on the openssl.org website. The first, 
openssl, is using content-encoding 'x-gzip' and appears not to actually be 
re-compressing the file, while the other two websites use no content-encoding. 
I'm guessing they messed up something similar to this:

{noformat}
AddType x-gzip .gz
{noformat}

Here's the output from hitting three different servers with curl:

{noformat}
Betelgeuse:wagon-plugin-tests jdcasey$ curl -X HEAD -i 
http://www.openssl.org/source/openssl-0.9.8k.tar.gz
HTTP/1.1 200 OK
Date: Mon, 04 May 2009 17:40:48 GMT
Server: Apache/1.3.33 (OpenPKG/2.5)
Last-Modified: Wed, 25 Mar 2009 12:21:40 GMT
ETag: "f0c99a-3ac7e3-49ca21d4"
Accept-Ranges: bytes
Content-Length: 3852259
Content-Type: application/x-tar
Content-Encoding: x-gzip

^C
Betelgeuse:wagon-plugin-tests jdcasey$ 
Betelgeuse:wagon-plugin-tests jdcasey$ 
Betelgeuse:wagon-plugin-tests jdcasey$ curl -X HEAD -i 
http://prdownloads.sourceforge.net/expat/expat-1.98.8.tar.gz
HTTP/1.1 301 Moved Permanently
X-Powered-By: PHP/5.2.8
Location: http://sourceforge.net/projects/expat/files
Content-type: text/html
Date: Mon, 04 May 2009 20:30:07 GMT
Server: lighttpd/1.4.19

Betelgeuse:wagon-plugin-tests jdcasey$ curl -X HEAD -i 
http://repo2.maven.org/maven2/org/apache/maven/apache-maven/2.0.10/apache-maven-2.0.10-bin.tar.gz
HTTP/1.1 200 OK
Server: nginx/0.7.19
Date: Mon, 04 May 2009 20:31:13 GMT
Content-Type: application/octet-stream
Content-Length: 2101451
Last-Modified: Tue, 10 Feb 2009 02:58:01 GMT
Connection: keep-alive
Accept-Ranges: bytes
{noformat}


> 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
>
> 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: (MANTTASKS-142) Default remote repository id not safe

2009-05-04 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann commented on MANTTASKS-142:
-

bq. you're right Benjamin (how could I ever imagine the contrary..
Benjamin IS_A human, human IS_A error-prone component ;-)

bq. I propose the following: [...]
+1


> 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
>Priority: Minor
> Fix For: 2.0.10, 2.1.0
>
>
> 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: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error

2009-05-04 Thread Paul Gier (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175084#action_175084
 ] 

Paul Gier commented on MANTTASKS-87:


I spent some time looking into this issue, and it appears that the problem is 
caused by a disconnect between the repositories defined in the ant tasks

{code:xml}

  http://myhouse.com"/>

{code}

And the repositories defined using the normal maven way through profiles in the 
settings or in the pom, etc.

Repositories from the settings.xml or pom.xml are picked up normally by the 
MavenProjectBuilder when the pom project is build.  Unfortunately the 
MavenProjectBuilder doesn't have a simple way to pass extra repositories when 
building the project.  So I believe that's why we currently have the extra step 
of trying to resolve the parent pom (using the ant defined repositories) before 
we build the whole pom project.

Unfortunately that extra resolution step for the parent pom only uses the 
repositories defined in the ant tag.  So you get warnings if the parent pom is 
located in a repository that's defined in settings.xml or pom.xml.

I believe the correct solution to this is to dynamically create an active 
profile that contains all the repositories defined in the ant tag, and then add 
that profile to the profile manager to be used by the MavenProjectBuilder.  
This way all the repositories (defined in maven or in ant) will be available 
when the pom project is built.

This has been changed (and hopefully fixed) in 
[r771425|http://svn.apache.org/viewvc?view=rev&revision=771425]


> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error
> -
>
> Key: MANTTASKS-87
> URL: http://jira.codehaus.org/browse/MANTTASKS-87
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: POM Integration
>Affects Versions: 2.0.9
> Environment: WindowsXP
> Ant version 1.7.0
>Reporter: Jeff Campbell
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 2.0.10
>
> Attachments: CASE.tar.gz, maven-ant-tasks.jar
>
>
> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error.
> This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to 
> maven-ant-tasks-2.0.7.jar and still an issue with the latest 
> maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)).
> Just to see if I had done something wrong with the pom.xml file I tried to 
> run a Maven goal against the pom.xml file.  I found that if I run "mvn clean" 
> from this same directory (where the build.xml and pom.xml file is located), 
> using Maven-2.0.7, I get a build successfull (it was able to find the parent 
> pom.xml file...  so this seems to be isolated to JUST the maven-ant-task not 
> being able to find the parent pom.xml)
>  Sample of the pom.xml file 
> 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
> intuit.sbconnect
> sbclogin
> 1.0.3
> SBCLogin
> 
> 
> mygroup
> CommonPOM
> 1.0.2
> 
> 
>   
> 
> myothergroup
> myartifact
> 1.0
>  
>
> 
>  Line in Ant build.xml file that causes the error: 
> 
>  Error that occurs when this line is executed in ant: 
> Error downloading parent pom: Missing:
> --
> 1) mygroup:CommonPOM:pom:1.0.2
>   Path to dependency:
>  1) unspecified:unspecified:jar:0.0
>  2) mygroup:CommonPOM:pom:1.0.2
> --
> 1 required artifact is missing.
> for artifact:
>   unspecified:unspecified:jar:0.0
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2)

-- 
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: (MANTTASKS-142) Default remote repository id not safe

2009-05-04 Thread Herve Boutemy (JIRA)

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

Herve Boutemy commented on MANTTASKS-142:
-

I just checked: as expected, Maven core does not support remote repositories 
without id
{code}org.apache.maven.artifact.InvalidRepositoryException: Repository ID must 
not be empty (URL is: file://${user.dir}/src/test/repo).
at 
org.apache.maven.project.ProjectUtils.buildArtifactRepository(ProjectUtils.java:101){code}

Then I think Maven Ant Tasks should not really support this case either: any 
algorithm that tries to compute a human readable defautl id cannot work.

I propose the following:
- add a warning if no id is defined
- compute a default value as simple as hex-encoded MD5-digest

> 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
>Priority: Minor
> Fix For: 2.0.10, 2.1.0
>
>
> 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: (MDEP-201) Add option to tree goal to generate tree based on dependencyManagement

2009-05-04 Thread Jim Sellers (JIRA)

[ 
http://jira.codehaus.org/browse/MDEP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175078#action_175078
 ] 

Jim Sellers commented on MDEP-201:
--

This would also be useful for when you are using a pom strictly as a "bill of 
materials" for other projects (imported with scope=import).

If this goal existed, I'd configure it to run as part of the install phase for 
this pom in order to determine if an dependency exists.

> Add option to tree goal to generate tree based on dependencyManagement
> --
>
> Key: MDEP-201
> URL: http://jira.codehaus.org/browse/MDEP-201
> Project: Maven 2.x Dependency Plugin
>  Issue Type: New Feature
>  Components: tree
>Reporter: Paul Gier
>Assignee: Brian Fox
>
> I have a parent pom that controls the dependency versions for a multimodule 
> project.  I would like to be able to generate a dependency tree from this 
> pom, so that I can see the tree for the entire project, but currently the 
> tree goal only looks at actual dependencies and not those in dependency 
> management.

-- 
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-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error

2009-05-04 Thread Paul Gier (JIRA)

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

Paul Gier updated MANTTASKS-87:
---

Fix Version/s: 2.0.10

> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error
> -
>
> Key: MANTTASKS-87
> URL: http://jira.codehaus.org/browse/MANTTASKS-87
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: POM Integration
>Affects Versions: 2.0.9
> Environment: WindowsXP
> Ant version 1.7.0
>Reporter: Jeff Campbell
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 2.0.10
>
> Attachments: CASE.tar.gz, maven-ant-tasks.jar
>
>
> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error.
> This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to 
> maven-ant-tasks-2.0.7.jar and still an issue with the latest 
> maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)).
> Just to see if I had done something wrong with the pom.xml file I tried to 
> run a Maven goal against the pom.xml file.  I found that if I run "mvn clean" 
> from this same directory (where the build.xml and pom.xml file is located), 
> using Maven-2.0.7, I get a build successfull (it was able to find the parent 
> pom.xml file...  so this seems to be isolated to JUST the maven-ant-task not 
> being able to find the parent pom.xml)
>  Sample of the pom.xml file 
> 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
> intuit.sbconnect
> sbclogin
> 1.0.3
> SBCLogin
> 
> 
> mygroup
> CommonPOM
> 1.0.2
> 
> 
>   
> 
> myothergroup
> myartifact
> 1.0
>  
>
> 
>  Line in Ant build.xml file that causes the error: 
> 
>  Error that occurs when this line is executed in ant: 
> Error downloading parent pom: Missing:
> --
> 1) mygroup:CommonPOM:pom:1.0.2
>   Path to dependency:
>  1) unspecified:unspecified:jar:0.0
>  2) mygroup:CommonPOM:pom:1.0.2
> --
> 1 required artifact is missing.
> for artifact:
>   unspecified:unspecified:jar:0.0
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2)

-- 
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: (MANTTASKS-142) Default remote repository id not safe

2009-05-04 Thread Herve Boutemy (JIRA)

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

Herve Boutemy commented on MANTTASKS-142:
-

ok, you're right Benjamin (how could I ever imagine the contrary... ;) )

{code}ant -f sample.build.xml test-deps-two-repos{code}

on my Linux box, I get a weird 
target/tmp/it/ant-tasks/snapshotUniqueFalse/2.0.7-SNAPSHOT/maven-metadata-file: 
directory
I suppose it simply fails on a Windows box...

> 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
>Priority: Minor
> Fix For: 2.0.10, 2.1.0
>
>
> 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: (MERCURY-121) convert API to request/result paradigm to allow easier API changes in the future

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov updated MERCURY-121:
-

Summary: convert API to request/result paradigm to allow easier API changes 
in the future  (was: convert API to request/result paradigm to aloow easier API 
changes in the future)

> convert API to request/result paradigm to allow easier API changes in the 
> future
> 
>
> Key: MERCURY-121
> URL: http://jira.codehaus.org/browse/MERCURY-121
> Project: Mercury
>  Issue Type: Sub-task
>Affects Versions: 1.0-alpha-8
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
>


-- 
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-2445) Upload nekopull 0.2.4

2009-05-04 Thread Niklas Gustavsson (JIRA)
Upload nekopull 0.2.4
-

 Key: MAVENUPLOAD-2445
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2445
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Niklas Gustavsson


The developer of Nekopull, Andy C has approved uploading the artifact. I'm 
merely performing the grunt work. Andy C owns the domain cyberneko.org used as 
the group ID: http://whois.domaintools.com/cyberneko.org

-- 
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: (MERCURY-124) pool HttpClient instances in the VirtualRepositoryReader and RemoteRepoWriterM2 instead of closing them

2009-05-04 Thread Oleg Gusakov (JIRA)
pool HttpClient instances in the VirtualRepositoryReader and RemoteRepoWriterM2 
instead of closing them
---

 Key: MERCURY-124
 URL: http://jira.codehaus.org/browse/MERCURY-124
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-125) review remote repository strategy regarding reading available versions. It now tries to replace virtuals with actual version thus trying to read metadata for all virtuals

2009-05-04 Thread Oleg Gusakov (JIRA)
review remote repository strategy regarding reading available versions. It now 
tries to replace virtuals with actual version thus trying to read metadata for 
all virtuals. Time consuming on clean local repository and with lack of 
negative metadata caching
---

 Key: MERCURY-125
 URL: http://jira.codehaus.org/browse/MERCURY-125
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-126) implement negative cache

2009-05-04 Thread Oleg Gusakov (JIRA)
implement negative cache


 Key: MERCURY-126
 URL: http://jira.codehaus.org/browse/MERCURY-126
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-121) convert API to request/result paradigm to aloow easier API changes in the future

2009-05-04 Thread Oleg Gusakov (JIRA)
convert API to request/result paradigm to aloow easier API changes in the future


 Key: MERCURY-121
 URL: http://jira.codehaus.org/browse/MERCURY-121
 Project: Mercury
  Issue Type: Sub-task
Affects Versions: 1.0-alpha-8
Reporter: Oleg Gusakov
Assignee: Oleg Gusakov




-- 
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: (MERCURY-123) add evict() call to the metadata cache

2009-05-04 Thread Oleg Gusakov (JIRA)
add evict() call to the metadata cache
--

 Key: MERCURY-123
 URL: http://jira.codehaus.org/browse/MERCURY-123
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-122) VirtualRepositoryReader - refactor readArtifact() into 3 pieces, eliminate readArtifactsNoBatch()

2009-05-04 Thread Oleg Gusakov (JIRA)
VirtualRepositoryReader - refactor readArtifact() into 3 pieces, eliminate 
readArtifactsNoBatch()
-

 Key: MERCURY-122
 URL: http://jira.codehaus.org/browse/MERCURY-122
 Project: Mercury
  Issue Type: Sub-task
Reporter: Oleg Gusakov




-- 
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: (MERCURY-120) convert list resolution into single node resolution

2009-05-04 Thread Oleg Gusakov (JIRA)

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

Oleg Gusakov closed MERCURY-120.


Resolution: Fixed

Changed DependencyTreeBuilder: eliminated mutiple tree creation. 
resolveConflicts() now builds a single dependency tree when supplied a list of 
artifact metadada to resolve together.

This resulted in approx. 2x speed increase on large (~50 MDs) resolutions

> convert list resolution into single node resolution
> ---
>
> Key: MERCURY-120
> URL: http://jira.codehaus.org/browse/MERCURY-120
> Project: Mercury
>  Issue Type: Sub-task
>  Components: Dependency Builder
>Affects Versions: 1.0-alpha-8
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
>
> Currently, a multi-artifact resolution creates a dependency tree for each 
> supplied artifact, then creates a tree out of them all and resolves 
> conflicts. This was done as a quick solution when API changed to accomodate 
> multi-artifact use case: processing a POM, Maven resolve API
> Better solution would be to create a single tree with all those artifacts as 
> dependencies and build only this tree (then resolve conflicts). This would 
> allow to eliminate multiple creation of the shared sub-trees.

-- 
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: (MERCURY-120) convert list resolution into single node resolution

2009-05-04 Thread Oleg Gusakov (JIRA)
convert list resolution into single node resolution
---

 Key: MERCURY-120
 URL: http://jira.codehaus.org/browse/MERCURY-120
 Project: Mercury
  Issue Type: Sub-task
  Components: Dependency Builder
Affects Versions: 1.0-alpha-8
Reporter: Oleg Gusakov
Assignee: Oleg Gusakov


Currently, a multi-artifact resolution creates a dependency tree for each 
supplied artifact, then creates a tree out of them all and resolves conflicts. 
This was done as a quick solution when API changed to accomodate multi-artifact 
use case: processing a POM, Maven resolve API

Better solution would be to create a single tree with all those artifacts as 
dependencies and build only this tree (then resolve conflicts). This would 
allow to eliminate multiple creation of the shared sub-trees.

-- 
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: (SCM-467) Make core SCM API objects Serializable

2009-05-04 Thread Andrei Solntsev (JIRA)

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

Andrei Solntsev updated SCM-467:


Attachment: MNG-467-maven-core.patch

Trivial fix: 
1) Added "implements Serializable" to several classes.
2) Generated serialVersionID using Eclipse built-in generator.

> Make core SCM API objects Serializable
> --
>
> Key: SCM-467
> URL: http://jira.codehaus.org/browse/SCM-467
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-api
>Affects Versions: 1.3, 2.0, future
>Reporter: Andrei Solntsev
>Priority: Trivial
> Attachments: MNG-467-maven-core.patch
>
>
> The following classes from package org.apache.maven.scm are Serialzable by 
> nature, but don't implement java.io.Serializable interface:
> AbstractScmVersion, 
> ChangeFile,
> ChangeSet,
> CommandParameter,
> CommandParameters,
> etc.
> Add "implements Serializable" to those 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] Created: (SCM-467) Make core SCM API objects Serializable

2009-05-04 Thread Andrei Solntsev (JIRA)
Make core SCM API objects Serializable
--

 Key: SCM-467
 URL: http://jira.codehaus.org/browse/SCM-467
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-api
Affects Versions: 1.3, 2.0, future
Reporter: Andrei Solntsev
Priority: Trivial


The following classes from package org.apache.maven.scm are Serialzable by 
nature, but don't implement java.io.Serializable interface:
AbstractScmVersion, 
ChangeFile,
ChangeSet,
CommandParameter,
CommandParameters,
etc.

Add "implements Serializable" to those 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: (WAGON-257) java.lang.ArrayIndexOutOfBoundsException: 0 when deploying via scp

2009-05-04 Thread Thomas Vandahl (JIRA)

[ 
http://jira.codehaus.org/browse/WAGON-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175057#action_175057
 ] 

Thomas Vandahl commented on WAGON-257:
--

It doesn't work with 2.0.8. I did not test 2.0.10.

Just a side comment: The stage:copy goal fails when using the scpexe protocol 
with a ClassCastException. scp gives the ArrayIndexOutOfBoundsException: 0 as 
above.

> java.lang.ArrayIndexOutOfBoundsException: 0 when deploying via scp
> --
>
> Key: WAGON-257
> URL: http://jira.codehaus.org/browse/WAGON-257
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-ssh
>Affects Versions: 1.0-beta-5
> Environment: Mac OS X 10.4
>Reporter: Thomas Vandahl
> Fix For: 1.0
>
>
> (Not sure about the version of wagon, I am using Maven 2.1.0 release)
> When I try to deploy something that is supposed to use scp as the protocol, 
> for example "mvn site:deploy", I get the following exception
> ---8<---
> [INFO] [site:deploy]
> Using private key: /xxx/.ssh/id_rsa
> scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ 
> - Session: Connection refused
> scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ 
> - Session: Disconnecting  
> scp://people.apache.org/www/turbine.apache.org/fulcrum/fulcrum-localization/ 
> - Session: Disconnected
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Cannot connect. Reason: 
> java.lang.ArrayIndexOutOfBoundsException: 0
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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 uploading 
> site
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:215)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> ... 16 more
> Caused by: org.apache.maven.wagon.authentication.AuthenticationException: 
> Cannot connect. Reason: java.lang.ArrayIndexOutOfBoundsException: 0
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnectionInternal(AbstractJschWagon.java:137)
> at 
> org.apache.maven.wagon.AbstractWagon.openConnection(AbstractWagon.java:105)
> at 
> org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:207)
> at 
> org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:142)
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184)
> ... 18 more
> Caused by: com.jcraft.jsch.JSchException: 
> java.lang.ArrayIndexOutOfBoundsException: 0
> at com.jcraft.jsch.IdentityFile.(IdentityFile.java:336)
> at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:135)
> at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:130

[jira] Commented: (SCM-461) Support TFS as SCM Provider

2009-05-04 Thread Subhash (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175055#action_175055
 ] 

Subhash commented on SCM-461:
-

Makes sense. I'll add the TCL test cases and resubmit the patch. Thanks

> Support TFS as SCM Provider
> ---
>
> Key: SCM-461
> URL: http://jira.codehaus.org/browse/SCM-461
> Project: Maven SCM
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Subhash
> Attachments: scm-461-maven-scm-provider-tfs.patch
>
>
> Support for Microsoft TFS is being added to Maven by a new scm-provider: 
> maven-scm-provider-tfs. The attached patch file contains the changes made to 
> http://svn.apache.org/repos/asf/maven/scm/trunk

-- 
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: (MNG-2975) test scope does not work with pom dependency

2009-05-04 Thread Parag Srivastava (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175044#action_175044
 ] 

Parag Srivastava edited comment on MNG-2975 at 5/4/09 10:53 AM:


I am also facing the same problem. It will be good if the dependency poms 
worked with test scope as well because we'll be able to have a common 
definition of the test dependency groups as well.

I understand that the tests are private to the artifact but it is also about 
consistency and avoiding repetition.

In my projects, I need a set of 3-4 Glassfish appserver dependencies to run 
test cases. Having the developers add them in each project is not very 
practical, especially when we have seen the advantages of dependency groups 
with compile scope and need the same set used consistently everywhere for 
running the tests.

Can this bug be opened again for fixing?

  was (Author: paragsrivastava):
I am also facing the same problem. It will be good if the dependency poms 
worked with test scope as well because we'll be able to have a common 
definition of the test dependency groups as well.

I understand that the tests are private to the artifact but is also about 
consistency and avoiding repetition.

In my projects, I need a set of 3-4 Glassfish appserver dependencies to run 
test cases. Having the developers add them in each project is not very 
practical, especially when we have seen the advantages of dependency groups 
with compile scope and need the same set used consistently everywhere for 
running the tests.

Can this bug be opened again for fixing?
  
> test scope does not work with pom dependency
> 
>
> Key: MNG-2975
> URL: http://jira.codehaus.org/browse/MNG-2975
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4
> Environment: jdk1.5
>Reporter: Franck HUGOT
>Assignee: Brett Porter
>
> I have a project A with pom packaging (pom) that use 
> this dependency : 
>   
>   org.springframework
>   spring-mock
>   2.0
>   test
>   
> In project B , I try to use the project A like a dependency like this :
>   
>   xxx
>   SOFFWK_LIBS
>   1.0
>   pom
>   
>  I don't get the spring-mock transitive dependency when I compile or test 
> project B.
> Is it because it has a test scope? 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-2975) test scope does not work with pom dependency

2009-05-04 Thread Parag Srivastava (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175044#action_175044
 ] 

Parag Srivastava commented on MNG-2975:
---

I am also facing the same problem. It will be good if the dependency poms 
worked with test scope as well because we'll be able to have a common 
definition of the test dependency groups as well.

I understand that the tests are private to the artifact but is also about 
consistency and avoiding repetition.

In my projects, I need a set of 3-4 Glassfish appserver dependencies to run 
test cases. Having the developers add them in each project is not very 
practical, especially when we have seen the advantages of dependency groups 
with compile scope and need the same set used consistently everywhere for 
running the tests.

Can this bug be opened again for fixing?

> test scope does not work with pom dependency
> 
>
> Key: MNG-2975
> URL: http://jira.codehaus.org/browse/MNG-2975
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4
> Environment: jdk1.5
>Reporter: Franck HUGOT
>Assignee: Brett Porter
>
> I have a project A with pom packaging (pom) that use 
> this dependency : 
>   
>   org.springframework
>   spring-mock
>   2.0
>   test
>   
> In project B , I try to use the project A like a dependency like this :
>   
>   xxx
>   SOFFWK_LIBS
>   1.0
>   pom
>   
>  I don't get the spring-mock transitive dependency when I compile or test 
> project B.
> Is it because it has a test scope? 

-- 
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-312) comments in meta properties end up in author content

2009-05-04 Thread Malachi de AElfweald (JIRA)
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
Priority: Minor


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] Commented: (DOXIA-310) Unable to get custom entity references to work

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175042#action_175042
 ] 

Malachi de AElfweald commented on DOXIA-310:


verified that customized entity names work now

> Unable to get custom entity references to work
> --
>
> Key: DOXIA-310
> URL: http://jira.codehaus.org/browse/DOXIA-310
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.1
> Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC
>Reporter: Malachi de AElfweald
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
> Attachments: testcase.tgz
>
>
> followed these instructions:
> http://svn.apache.org/viewvc/maven/doxia/site/src/site/fml/faq.fml?annotate=739143&pathrev=739143
> to include these entity references:
> http://kallisti.eoti.org/ambrosia/kallisti/trit.ent
> included test case has 3 different examples:
> 1. using the character references defined in the trit.ent. Character 
> references were removed from the table during site:site
> 2. using the character references by number. Character references were 
> replaced with '?' during site:site
> 3. copied site generated test2 and added the character references in by hand. 
> That is the only one that works.

-- 
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-309) Ligature in author name shows up on page

2009-05-04 Thread Malachi de AElfweald (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175041#action_175041
 ] 

Malachi de AElfweald commented on DOXIA-309:


Verified that ligature in author is fixed

> Ligature in author name shows up on page
> 
>
> Key: DOXIA-309
> URL: http://jira.codehaus.org/browse/DOXIA-309
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.1
> Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC
>Reporter: Malachi de AElfweald
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 1.1.1
>
> Attachments: testcase.tgz
>
>
> followed these instructions to include the entity references:
> http://svn.apache.org/viewvc/maven/doxia/site/src/site/fml/faq.fml?annotate=739143&pathrev=739143
> tried to set the author property:
> Malachi de Ælfweald
> The AE-ligature shows up as the first character on the page (top-left corner)
> Testcase attached
> testcase.html shows:
>  media="print" />
>   
> Æ

-- 
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: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error

2009-05-04 Thread Paul Gier (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175034#action_175034
 ] 

Paul Gier commented on MANTTASKS-87:


Pino, can you attach the sources/patch for your fix?

> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error
> -
>
> Key: MANTTASKS-87
> URL: http://jira.codehaus.org/browse/MANTTASKS-87
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: POM Integration
>Affects Versions: 2.0.9
> Environment: WindowsXP
> Ant version 1.7.0
>Reporter: Jeff Campbell
>Assignee: Herve Boutemy
>Priority: Blocker
> Attachments: CASE.tar.gz, maven-ant-tasks.jar
>
>
> Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml 
> will cause a "Error downloading parent pom" error.
> This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to 
> maven-ant-tasks-2.0.7.jar and still an issue with the latest 
> maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)).
> Just to see if I had done something wrong with the pom.xml file I tried to 
> run a Maven goal against the pom.xml file.  I found that if I run "mvn clean" 
> from this same directory (where the build.xml and pom.xml file is located), 
> using Maven-2.0.7, I get a build successfull (it was able to find the parent 
> pom.xml file...  so this seems to be isolated to JUST the maven-ant-task not 
> being able to find the parent pom.xml)
>  Sample of the pom.xml file 
> 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
> intuit.sbconnect
> sbclogin
> 1.0.3
> SBCLogin
> 
> 
> mygroup
> CommonPOM
> 1.0.2
> 
> 
>   
> 
> myothergroup
> myartifact
> 1.0
>  
>
> 
>  Line in Ant build.xml file that causes the error: 
> 
>  Error that occurs when this line is executed in ant: 
> Error downloading parent pom: Missing:
> --
> 1) mygroup:CommonPOM:pom:1.0.2
>   Path to dependency:
>  1) unspecified:unspecified:jar:0.0
>  2) mygroup:CommonPOM:pom:1.0.2
> --
> 1 required artifact is missing.
> for artifact:
>   unspecified:unspecified:jar:0.0
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2)

-- 
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-310) Unable to get custom entity references to work

2009-05-04 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed DOXIA-310.
-

 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 1.1.1

allow pattern to accept 5 chars, snapshot redeployed.

> Unable to get custom entity references to work
> --
>
> Key: DOXIA-310
> URL: http://jira.codehaus.org/browse/DOXIA-310
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.1
> Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC
>Reporter: Malachi de AElfweald
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
> Attachments: testcase.tgz
>
>
> followed these instructions:
> http://svn.apache.org/viewvc/maven/doxia/site/src/site/fml/faq.fml?annotate=739143&pathrev=739143
> to include these entity references:
> http://kallisti.eoti.org/ambrosia/kallisti/trit.ent
> included test case has 3 different examples:
> 1. using the character references defined in the trit.ent. Character 
> references were removed from the table during site:site
> 2. using the character references by number. Character references were 
> replaced with '?' during site:site
> 3. copied site generated test2 and added the character references in by hand. 
> That is the only one that works.

-- 
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-309) Ligature in author name shows up on page

2009-05-04 Thread Vincent Siveton (JIRA)

[ 
http://jira.codehaus.org/browse/DOXIA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175031#action_175031
 ] 

Vincent Siveton commented on DOXIA-309:
---

take care of predefined entities. 

> Ligature in author name shows up on page
> 
>
> Key: DOXIA-309
> URL: http://jira.codehaus.org/browse/DOXIA-309
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1.1
> Environment: maven-site-plugin 2.1-SNAPSHOT w/ XDOC
>Reporter: Malachi de AElfweald
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 1.1.1
>
> Attachments: testcase.tgz
>
>
> followed these instructions to include the entity references:
> http://svn.apache.org/viewvc/maven/doxia/site/src/site/fml/faq.fml?annotate=739143&pathrev=739143
> tried to set the author property:
> Malachi de Ælfweald
> The AE-ligature shows up as the first character on the page (top-left corner)
> Testcase attached
> testcase.html shows:
>  media="print" />
>   
> Æ

-- 
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: (MAVENUPLOAD-2437) Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43

2009-05-04 Thread JIRA

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175027#action_175027
 ] 

Paúl Santapau commented on MAVENUPLOAD-2437:


For me it would also be great, I have these dependencies and my project would 
also rely on the main maven repo. 


> Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43
> 
>
> Key: MAVENUPLOAD-2437
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2437
> Project: Maven Upload Requests
>  Issue Type: Task
>Reporter: Ricardo Borillo
>
> Hi,
> I'm not a developer of the Bouncy Castle project, but it will be nice if you 
> could upload this bundles:
> http://xml-utils.com/maven/bcmail-jdk15-143-bundle.jar
> http://xml-utils.com/maven/bcmail-jdk16-143-bundle.jar
> http://xml-utils.com/maven/bcprov-jdk15-143-bundle.jar
> http://xml-utils.com/maven/bcprov-jdk16-143-bundle.jar
> http://xml-utils.com/maven/bctsp-jdk15-143-bundle.jar 
> http://xml-utils.com/maven/bctsp-jdk16-143-bundle.jar
> Thanks in advance

-- 
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: (MAVENUPLOAD-2437) Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43

2009-05-04 Thread John H. Jackson (JIRA)

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175024#action_175024
 ] 

John H. Jackson commented on MAVENUPLOAD-2437:
--

It would be great to have these uploaded. 

Right now I have to maintain my maven repo only for these ones :(

> Update Bouncy Castle BCPROV/BCMAIL/BCTSP to 1.43
> 
>
> Key: MAVENUPLOAD-2437
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2437
> Project: Maven Upload Requests
>  Issue Type: Task
>Reporter: Ricardo Borillo
>
> Hi,
> I'm not a developer of the Bouncy Castle project, but it will be nice if you 
> could upload this bundles:
> http://xml-utils.com/maven/bcmail-jdk15-143-bundle.jar
> http://xml-utils.com/maven/bcmail-jdk16-143-bundle.jar
> http://xml-utils.com/maven/bcprov-jdk15-143-bundle.jar
> http://xml-utils.com/maven/bcprov-jdk16-143-bundle.jar
> http://xml-utils.com/maven/bctsp-jdk15-143-bundle.jar 
> http://xml-utils.com/maven/bctsp-jdk16-143-bundle.jar
> Thanks in advance

-- 
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: (MAVENUPLOAD-2386) Dozer 5.0 Upload

2009-05-04 Thread Pavel Jakl (JIRA)

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175020#action_175020
 ] 

Pavel Jakl commented on MAVENUPLOAD-2386:
-

Guys, can be version 5.0 uploaded under the net.sf.dozer groupId if there are 
problem with uploading under org.dozer ? Thx

> Dozer 5.0 Upload
> 
>
> Key: MAVENUPLOAD-2386
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2386
> Project: Maven Upload Requests
>  Issue Type: Task
>Reporter: Matt Tierney
> Attachments: dozer-5.0-bundle.jar
>
>
> Dozer is a powerful, yet simple Java Bean to Java Bean mapper that 
> recursively copies data from one object to another. Typically, these Java 
> Beans will be of different complex types.
> Dozer supports simple property mapping, complex type mapping, bi-directional 
> mapping, implicit-explicit mapping, as well as recursive mapping. This 
> includes mapping collection attributes that also need mapping at the element 
> level.
> Dozer not only supports mapping between attribute names, but also converting 
> between types. Many conversion scenarios are supported out of the box, but 
> Dozer also allows you to specify custom conversions via XML.
> The mapper is used any time you need to take one type of Java Bean and map it 
> to another type of Java Bean. Most field mapping can be done automatically by 
> Dozer using reflection, but any custom mapping can be predescribed in XML 
> format. Mapping is bi-directional so only one relationship between classes 
> needs defining. If any property names on both objects are the same you do not 
> even need to do any explicit property mapping for these fields.
> Thanks in advance!

-- 
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-4151) Update maven API to use Java 5 generics

2009-05-04 Thread nicolas de loof (JIRA)
Update maven API to use Java 5 generics
---

 Key: MNG-4151
 URL: http://jira.codehaus.org/browse/MNG-4151
 Project: Maven 2
  Issue Type: Task
  Components: IDEs
Affects Versions: 2.2.x
Reporter: nicolas de loof
Priority: Trivial


As Maven 2.2.x requires Java 5, upgrade maven API to use generics on 
collections. This will help plugin developers to avoid classCastException and 
make the API more comprehensible.

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