[jira] Commented: (MAVENUPLOAD-1968) JDom 1.1 is out
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136936#action_136936 ] Benjamin Bentmann commented on MAVENUPLOAD-1968: These comments indicate dependencies that don't match exactly the JARs included in the JDOM 1.1 distribution, similar to the comments in the [jdom-1.0.pom|http://repo1.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.pom]. For instance, JDOM comes with a Jaxen lib that they patched themselves, i.e. is no official release at all. Their Xalan lib is [2.5.D1|http://xml.apache.org/xalan-j/readme.html#notes_250] which was a developer release immediately before the 2.5.0 that I specified in the POM. I wasn't too scary to make these adjustments as all of them affect merely optional dependencies, i.e. the JDOM client is expected to choose these libraries on his own discretion (see the maven-release-manager). In practice, the implementations bundles with JRE 1.4+ will suffice. > JDom 1.1 is out > --- > > Key: MAVENUPLOAD-1968 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968 > Project: Maven Upload Requests > Issue Type: New Feature >Reporter: Mirko Steinle >Assignee: Carlos Sanchez > Attachments: jdom-1.1-bundle.jar, pom-relocation.xml > > > Hello! > JDom has released a major version (1.1) last november. Could you please > upload it? > All files can be found at http://www.jdom.org/ > Thank you very much. > Mirko > P.S. I am only a user of JDom, but I guess the team won't have anything > against seeing their latest release uploaded... -- 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: (MJAVADOC-167) Mixing Standard/Custom Tags for Ordering Failure
[ http://jira.codehaus.org/browse/MJAVADOC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-167. Resolution: Not A Bug This issue duplicates MNG-3385, and it is related to Maven not javadoc plugin. You need to readd your plugin configuration in > Mixing Standard/Custom Tags for Ordering Failure > > > Key: MJAVADOC-167 > URL: http://jira.codehaus.org/browse/MJAVADOC-167 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: JDK 1.6.0_04, W2K >Reporter: André Fügenschuh >Priority: Minor > Attachments: jdoc-tags-test.zip > > > Placing a standard tag at the end of the tags list to enforce ordering > doesn't work. > Example: > .foo.. > author > version > .bar.. > see > Error Output: > Note: Custom tags that override standard tags: @see > causing expected problems within the docs (no occurrence, no linking if a > custom 'head' is given etc.) > Placing a custom tag at the end and it works: > .foo.. > author > version > .bar.. > see > .bob.. > see: MJAVADOC-130 -- 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-209) Extend Wagon API to support the Stage Plugin
[
http://jira.codehaus.org/browse/WAGON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136943#action_136943
]
Brett Porter commented on WAGON-209:
yes, I linked it to -5. IMO, this is something to figure out in the stage
plugin. Wagon already supports all the operations needed - the command executor
is used to perform some server-side for effeciency.
> Extend Wagon API to support the Stage Plugin
>
>
> Key: WAGON-209
> URL: http://jira.codehaus.org/browse/WAGON-209
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-provider-api
>Affects Versions: 1.0-beta-2
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>
> From the source of the [Maven Stage
> Plugin|http://maven.apache.org/plugins/maven-stage-plugin/]:
> {code:java}
> ( (ScpWagon) targetWagon ).executeCommand( command );
> {code}
> This smells: The plugin is downcasting to an implementation class, happily
> breaking the interface design and making the target wagon non-interchangeable.
> The atomic Wagon operations required by the plugin should be identified and
> added to the Wagon API. Wagons that can't support these new operations could
> simply implement the methods by throwing an {{UnsupportedOperationException}}
> exception.
--
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-209) Extend Wagon API to support the Stage Plugin
[
http://jira.codehaus.org/browse/WAGON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136938#action_136938
]
Benjamin Bentmann commented on WAGON-209:
-
Brett, you noticed the link to the issue MSTAGE-5, did you? The point of this
feature request was to enable the Stage Plugin to work with an ordinary Wagon
object and to completely avoid any casting. While {{CommandExecutor}} is part
of the wagon-provider-api, it looks like a design flaw (aka quick fix) that
wagons are supposed to offer execution services. As far as I understand, Wagon
is meant as an abstraction layer for transport protocols, this has not much to
do with command executions (interestingly, only the SSH-based wagons seem to
support {{CommandExecutor}}).
With this issue I wanted to trigger an investigation of what operations the
Stage Plugin (and maybe others) require from a wagon in terms of transport
operations such that the plugin doesn't need to hack its way by executing
remote commands. Ideally, {{CommandExecutor}} would disappear some day from the
API, i.e. commands become an implementation detail of the wagon, not a public
interface.
> Extend Wagon API to support the Stage Plugin
>
>
> Key: WAGON-209
> URL: http://jira.codehaus.org/browse/WAGON-209
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-provider-api
>Affects Versions: 1.0-beta-2
>Reporter: Benjamin Bentmann
>Assignee: Brett Porter
>
> From the source of the [Maven Stage
> Plugin|http://maven.apache.org/plugins/maven-stage-plugin/]:
> {code:java}
> ( (ScpWagon) targetWagon ).executeCommand( command );
> {code}
> This smells: The plugin is downcasting to an implementation class, happily
> breaking the interface design and making the target wagon non-interchangeable.
> The atomic Wagon operations required by the plugin should be identified and
> added to the Wagon API. Wagons that can't support these new operations could
> simply implement the methods by throwing an {{UnsupportedOperationException}}
> exception.
--
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: (MJAVADOC-144) Cannot generate Javadoc on Mac OS X if path contains space characters
[
http://jira.codehaus.org/browse/MJAVADOC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136944#action_136944
]
Brett Porter commented on MJAVADOC-144:
---
the changes work for me, however I now see a test failure in testQuotedPath on
trunk:
{code}
---
Test set: org.apache.maven.plugin.javadoc.JavadocReportTest
---
Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 30.902 sec <<<
FAILURE!
testQuotedPath(org.apache.maven.plugin.javadoc.JavadocReportTest) Time
elapsed: 0.927 sec <<< ERROR!
org.apache.maven.plugin.MojoExecutionException: An error has occurred in
JavaDocs report generation:Exit code: 2 - /bin/sh: -c: line 0: unexpected EOF
while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
Command line
was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc
@options @argfile
at
org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:226)
at
org.apache.maven.plugin.javadoc.JavadocReportTest.testQuotedPath(JavadocReportTest.java:517)
Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 2 -
/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
Command line
was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc
@options @argfile
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1674)
at
org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:127)
at
org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:222)
... 27 more
{code}
> Cannot generate Javadoc on Mac OS X if path contains space characters
> -
>
> Key: MJAVADOC-144
> URL: http://jira.codehaus.org/browse/MJAVADOC-144
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_07
> OS name: "mac os x" version: "10.4.10" arch: "i386"
>Reporter: Claes Buckwalter
>
> Running 'mvn javadoc:javadoc' fails if the path to the current directory
> contains a space character. It works with the 2.0 version of the plugin. It
> also works if I rename the directory so that it does not contain a space
> character.
> presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'javadoc'.
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]task-segment: [javadoc:javadoc] (aggregator-style)
> [INFO]
>
> [INFO] Preparing javadoc:javadoc
> [INFO]
>
> [INFO] Building The Elk Framework
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org/apache/velocity/runtime/defaults/velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : init
[jira] Created: (MAVENUPLOAD-2087) rsync_ssh delete for caelum-stella.sourceforge.net
rsync_ssh delete for caelum-stella.sourceforge.net -- Key: MAVENUPLOAD-2087 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2087 Project: Maven Upload Requests Issue Type: Wish Reporter: Cauê Haucke Porta Guerra Could you please delete the following repo: "net.sf.caelum-stella","[EMAIL PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, 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] Reopened: (MAVENUPLOAD-2071) rsync_ssh request for seleniumdsl.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cauê Haucke Porta Guerra reopened MAVENUPLOAD-2071: --- I swear it is the last time... I give the wrong line again. the correct one should be: the line should be: "br.com.caelum.seleniumdsl","[EMAIL PROTECTED]:/home/groups/s/se/seleniumdsl/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, instead of: "br.com.caelum.seleniumdsl","[EMAIL PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, And please, could you delete this repo? "net.sf.seleniumdsl","[EMAIL PROTECTED]:/home/groups/s/se/seleniumdsl/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, > rsync_ssh request for seleniumdsl.sourceforge.net > - > > Key: MAVENUPLOAD-2071 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2071 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Cauê Haucke Porta Guerra >Assignee: Carlos Sanchez > > "net.sf.seleniumdsl","[EMAIL > PROTECTED]:/home/groups/s/se/seleniumdsl/htdocs/m2repo","rsync_ssh","Caue > Guerra","[EMAIL PROTECTED]",, > Project page generated by maven hosted at project domain: > http://seleniumdsl.sourceforge.net/team-list.html -- 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-2088) xercesMinimal from nekohtml
xercesMinimal from nekohtml --- Key: MAVENUPLOAD-2088 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2088 Project: Maven Upload Requests Issue Type: Wish Reporter: Brett Porter Assignee: Brett Porter -- 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: (MAVENUPLOAD-2088) xercesMinimal from nekohtml
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MAVENUPLOAD-2088. - Resolution: Fixed > xercesMinimal from nekohtml > --- > > Key: MAVENUPLOAD-2088 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2088 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Brett Porter >Assignee: Brett Porter > -- 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-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-89. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-3) only "connect" throws an authentication exception (as expected). get/put, etc all throw authorization exceptions, which is to be expected as certain files may require different permissions > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136951#action_136951 ] Jason van Zyl commented on WAGON-89: You misunderstand. If someone is doing work that never requires authentication which is a lot of the time then throwing an exception is confusing. It's not expected if you're not authenticating. > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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: (MARTIFACT-20) Introduce the use of a SAT solver
Introduce the use of a SAT solver - Key: MARTIFACT-20 URL: http://jira.codehaus.org/browse/MARTIFACT-20 Project: Maven Artifact Issue Type: New Feature Reporter: Jason van Zyl Try using the same SAT solver that p2 is using to resolve ranges of dependencies. -- 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: (MARTIFACT-20) Introduce the use of a SAT solver
[ http://jira.codehaus.org/browse/MARTIFACT-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MARTIFACT-20: -- Attachment: patch-mercury-2008-06-01_10-42_PST.txt patch against Mercury trunk as of indicated (in the file name) date > Introduce the use of a SAT solver > - > > Key: MARTIFACT-20 > URL: http://jira.codehaus.org/browse/MARTIFACT-20 > Project: Maven Artifact > Issue Type: New Feature >Reporter: Jason van Zyl > Attachments: patch-mercury-2008-06-01_10-42_PST.txt > > > Try using the same SAT solver that p2 is using to resolve ranges of > dependencies. -- 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: (MAVENUPLOAD-2081) grails-maven-plugin 0.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVENUPLOAD-2081. Resolution: Fixed I put a rsync with my account @ apache : /home/aheritier/rsync-to-central > grails-maven-plugin 0.3 > --- > > Key: MAVENUPLOAD-2081 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2081 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Trygve Laugstol >Assignee: Arnaud Heritier > > The upload bundles was created by me from: > http://forge.octo.com/archiva/browse/com.octo.mtg/grails-maven-plugin/0.3 > I'm a developer on the project, see -- 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-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened WAGON-89: --- got it - so it should be removed from the connect methods that don't pass authentication > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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: (WAGON-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-89: -- Comment: was deleted > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136966#action_136966 ] Brett Porter commented on WAGON-89: --- I see what you mean, but any simple http retrieval has a chance of requiring authentication - isn't it fair to throw an AuthenticationException for attempting to connect without credentials when they are required? Or would you prefer to just roll that into a ConnectionException? > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136967#action_136967 ] Jason van Zyl commented on WAGON-89: Doesn't need to be fixed now, and it would change the API which is probably a bad thing. I would just imagine connectWithAuthentication( AuthGoop ), or have some request parameter and throw a runtime exception. I haven't thought about it too much, I just raised the issue when I was coding against the API to retrieve a file and I had to throw that exception when I know I was never going to require auth. I don't think you can change it until after the 1.0. > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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: (WAGON-89) When you use a call that doesn not use authentication the call should not throw an authentication exception
[ http://jira.codehaus.org/browse/WAGON-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated WAGON-89: -- Fix Version/s: 1.x yeah, makes sense. > When you use a call that doesn not use authentication the call should not > throw an authentication exception > > > Key: WAGON-89 > URL: http://jira.codehaus.org/browse/WAGON-89 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-provider-api >Affects Versions: 1.0-beta-2 >Reporter: Jason van Zyl >Assignee: Brett Porter > Fix For: 1.x > > > A general problem with the way we make requests. We should differentiate > between authenticated and non-authenticated requests. To make a call that > requires no authentication like a simple file or http retrieval and have to > trap an authentication error makes no sense and is confusing to consumers of > the API. -- 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-2089) bouncycastle 139 bundles for bcmail and bcprov
bouncycastle 139 bundles for bcmail and bcprov -- Key: MAVENUPLOAD-2089 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2089 Project: Maven Upload Requests Issue Type: Task Reporter: Xavier Le Vourch Two bundles to upload bouncycastle's bcprov and bcmail jar files: http://brittanysoftware.com/tmp/bcmail-jdk14-139-bundle.jar http://brittanysoftware.com/tmp/bcprov-jdk14-139-bundle.jar Note that I am not associated with the BouncyCastle project. -- 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-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136970#action_136970 ] Jeremy Hanna commented on MNG-3379: --- Are there any plans to patch this into a version of maven 2? I had hoped it would make it into 2.0.9. I was really looking forward to the speed improvements as a result of parallel/asynchronous downloads of dependencies. > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown >Assignee: Brett Porter > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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: (MARTIFACT-20) Introduce the use of a SAT solver
[ http://jira.codehaus.org/browse/MARTIFACT-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MARTIFACT-20: -- Attachment: patch-mercury-2008-06-01_20-14_PST.txt The tree we started drawing pictures with now works! See DefaultSatSolverTest.testResolution() > Introduce the use of a SAT solver > - > > Key: MARTIFACT-20 > URL: http://jira.codehaus.org/browse/MARTIFACT-20 > Project: Maven Artifact > Issue Type: New Feature >Reporter: Jason van Zyl > Attachments: patch-mercury-2008-06-01_10-42_PST.txt, > patch-mercury-2008-06-01_20-14_PST.txt > > > Try using the same SAT solver that p2 is using to resolve ranges of > dependencies. -- 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: (MARTIFACT-20) Introduce the use of a SAT solver
[ http://jira.codehaus.org/browse/MARTIFACT-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136977#action_136977 ] Jason van Zyl commented on MARTIFACT-20: Patches applied. > Introduce the use of a SAT solver > - > > Key: MARTIFACT-20 > URL: http://jira.codehaus.org/browse/MARTIFACT-20 > Project: Maven Artifact > Issue Type: New Feature >Reporter: Jason van Zyl > Attachments: patch-mercury-2008-06-01_10-42_PST.txt, > patch-mercury-2008-06-01_20-14_PST.txt > > > Try using the same SAT solver that p2 is using to resolve ranges of > dependencies. -- 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
