[jira] Created: (MAVENUPLOAD-1396) Upload UmlGraph 4.6
Upload UmlGraph 4.6 --- Key: MAVENUPLOAD-1396 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1396 Project: maven-upload-requests Issue Type: Task Reporter: Antonio Petrelli Attachments: UmlGraph-bundle-4.6.jar Hi, Can you deploy the attached bundle, that permits to everyone running maven to easily generate javadocs annotated with uml diagrams like in: http://www.andrea-aime.name/static/gt2-api/ Notice that I can't set SCM URL because there is no accessible SCM system. Thanks, Antonio -- 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-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88539
]
Phil Webb commented on WAGON-73:
My mirror list is fairly simple, it only consists of a single mirror to an
inhouse installation of maven-proxy
maven-proxy
Maven-Proxy Mirror
http://releaseserver:8080/maven-proxy-webapp/repository/
central
I have not provided a patch (sorry Eugene) because I am not totally sure of how
the code should work, so I am not totally confident of my proposed fix. I am
looking at it fairly blind, just trying to fix a problem that I had. If you
want me to attach one please let me know.
I still have a bit of a problem understanding the code, even after the updates.
Should the connect method not return if it is successful?
If you follow the path of the code, if the hasMirror() method returns true,
then the this.impl.connect(); is called. If this method connects then I assume
that no exceptions are thrown? After this the method will loop around the
while ( hasMirror() ) again? I would have thought that if the connection is
successful here then there should be no need to loop around again. Likewise
with the get method.
Sorry if I am missing something, I am just trying to understand.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
> Assigned To: Joakim Erdfelt
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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-2577) Allow interpolation of Properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88540 ] Dimitar Dimitrov commented on MNG-2577: --- I spent half a day trying to achieve the setup described in 'Better Builds with Maven' chapter 7.2 It could have been a good idea to document what is actually implemented and what is just a neat idea. That said, is there any reason for not including this patch into the next minor release? > Allow interpolation of Properties in settings.xml > - > > Key: MNG-2577 > URL: http://jira.codehaus.org/browse/MNG-2577 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4, 2.0.5 >Reporter: Michael Locher >Priority: Critical > Attachments: DefaultMavenSettingsBuilder.java.diff > > > the attached patch (against 2.0.4) allows interpolation of system properties > into the .m2/settings.xml > and interpolation of system properties and the properties of profiles found > in .m2/settings.xml (if they are activeByDefault) into conf/settings.xml > these features are necessary in order to propagate user account settings > defined in user-specific .m2/settings.xml into server sections of the > institution-wide conf/settings.xml -- 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-2362) Deployed POM is not valid XML
[ http://jira.codehaus.org/browse/MNG-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88542 ] Joerg Schaible commented on MNG-2362: - Hi Jason, the POM is not rewritten anymore installing or deploying the artifact with M2.0.5. The entities are kept in the local and remote repo. However the issue remains with the release plugin, the modificated POMs are invalid and also the ones used to build the release. So I guess, this issue should be assigned to the release plugin now. - Jörg > Deployed POM is not valid XML > - > > Key: MNG-2362 > URL: http://jira.codehaus.org/browse/MNG-2362 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Joerg Schaible >Priority: Critical > Fix For: 2.0.6 > > Attachments: MNG-2362.zip > > > If the POM has utf-8 encoding and you make usage of entities to support > extended characters, these characters are no longer encoded as entities in > the repository (well, the effect is already visible in > target/effective-pom.xml). This is not a rule of general, POMs with packaging > "pom" are installed and deployed correclty. -- 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: (MDEP-66) Sources goal not implemented
Sources goal not implemented Key: MDEP-66 URL: http://jira.codehaus.org/browse/MDEP-66 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1, 1.0, 2.0-alpha-3, 2.0-alpha-2, 2.0 Reporter: van steen yves Assigned To: Brian Fox Attachments: ResolveSourcesFix.patch An issue exist when trying the dependency:sources goad. It does nothing. I look at the latest source code of the plugin and it doesn't seem te be implemented. I recently wanted to use the dependency plugin to download the sources but when executing it didn't seem to do much. So I download the code from the maven subversion repo and looked at the problem. It didn't seem to be fully implemented. I now created a patch for this. I tried to follow the design ideas by it's creater (brianf) I left 2 items open (check todo tags): 1) implementation of the markers file 2) use of the groupid check (don't know it's function) If he wants I can further implement these items to. the patch was created on the 506840 revision. -- 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: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88557 ] Anton Katernoga commented on SCM-165: - I've found a problem related to system property approach which appears in continuum, I've filed it as C's issue CONTINUUM-1183. But it's an scm bug and I think it should be fixed in the scope of this issue. > PerforceChangeLogCommand needs to use the same clientspec as the update > command > --- > > Key: SCM-165 > URL: http://jira.codehaus.org/browse/SCM-165 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0-beta-3 >Reporter: John Didion > Assigned To: Mike Perham >Priority: Critical > Fix For: 1.0-beta-4 > > Attachments: PerforceChangeLogCommand.diff, svn.diff > > > The PerforceChangeLogCommand as written does not work if the update was done > with the client spec generated by the checkout/update command. The attached > diff will fix the problem. -- 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-2849) nonProxyHosts element's value separator
nonProxyHosts element's value separator Key: MNG-2849 URL: http://jira.codehaus.org/browse/MNG-2849 Project: Maven 2 Issue Type: Wish Components: Sites & Reporting Affects Versions: 2.0.5 Reporter: Sang-Jea Shin Priority: Trivial According to this article proxy separator is "|". http://maven.apache.org/guides/mini/guide-proxies.html But according to this article, separator is ",". http://maven.apache.org/ref/2.0.4/maven-settings/settings.html Which one is correct? Or both works? I wish to correct these description. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-294) Test resources not found in classpath
Test resources not found in classpath - Key: SUREFIRE-294 URL: http://jira.codehaus.org/browse/SUREFIRE-294 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin), 1.5.3 (2.1.3 plugin), 2.4 Environment: Linux, JDK 1.5 Reporter: Jim Crossley Priority: Blocker Attachments: surefire-classpath-test.zip Attached is a simple project demonstrating that the Surefire plugin cannot find the correct META-INF/persistence.xml when trying to create a JPA EntityManagerFactory in the setup method of AppTest.java. There are two persistence units defined: the "real" one in src/main/resources/META-INF/persistence.xml and the "fake" one in src/test/resources/META-INF/persistence.xml. The test case should work if Surefire can find the "fake" one, which it currently can't. Incidentally, it can't even find the "real" one. It's as if the resources directories are simply not added to the classpath during test invocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (SCM-281) Perforce problem: incorrect client spec is used
[ http://jira.codehaus.org/browse/SCM-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Perham moved CONTINUUM-1183 to SCM-281: Affects Version/s: (was: 1.0.3) 1.0-beta-4 Component/s: (was: SCM) maven-scm-provider-perforce Key: SCM-281 (was: CONTINUUM-1183) Project: Maven SCM (was: Continuum) > Perforce problem: incorrect client spec is used > --- > > Key: SCM-281 > URL: http://jira.codehaus.org/browse/SCM-281 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0-beta-4 >Reporter: Anton Katernoga > Attachments: patch.p4.txt > > > I have 2 projects set up which use the same perforce scm url. One is run each > 5 mins, the other is a nightly tests build. I've noticed that the latter > never gets run-the message is that the dir is up-to date. It appeared that > after the first project is run, its client spec is set to system variable in > PerforceCheckOutCommand (maven-scm perforce provider) class and afterwards > the value of the var is used instead of a correct client spec. I didn't > remove the property set, as it is a fix to SCM-165, but rather the place > where prop is used. Now works fine. > Patch is attached. -- 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: (SCM-281) Perforce problem: incorrect client spec is used
[ http://jira.codehaus.org/browse/SCM-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88570 ] Mike Perham commented on SCM-281: - Does Continuum have a way to set the environment variables for a build before the build is executed? If yes, you should be setting the clientspec system property to the proper value for each build beforehand. That patch is unacceptable because it removes the ability to specify the clientspec as a system property. > Perforce problem: incorrect client spec is used > --- > > Key: SCM-281 > URL: http://jira.codehaus.org/browse/SCM-281 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0-beta-4 >Reporter: Anton Katernoga > Attachments: patch.p4.txt > > > I have 2 projects set up which use the same perforce scm url. One is run each > 5 mins, the other is a nightly tests build. I've noticed that the latter > never gets run-the message is that the dir is up-to date. It appeared that > after the first project is run, its client spec is set to system variable in > PerforceCheckOutCommand (maven-scm perforce provider) class and afterwards > the value of the var is used instead of a correct client spec. I didn't > remove the property set, as it is a fix to SCM-165, but rather the place > where prop is used. Now works fine. > Patch is attached. -- 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: (SUREFIRE-180) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/SUREFIRE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88573 ] Adrian commented on SUREFIRE-180: - Will this be fixed soon and added to the 2.3 release? It is very important for our project. Cheers. > Ability to add additions to classpath > - > > Key: SUREFIRE-180 > URL: http://jira.codehaus.org/browse/SUREFIRE-180 > Project: Maven Surefire > Issue Type: Improvement > Environment: N/A >Reporter: David J. M. Karlsen > Assigned To: fabrizio giustina > Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, > SurefirePlugin.java-diff > > > There should be a possibility to add arbritary resources to the classpath > while executing the tests. These resources would only be available while > executing the tests, so they won't be added in the archive. > i suggest a configuration element > > some/path > /some/other/path > > This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / > ability to exclude/include filtering in archiver/jar-plugin -- 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: (MJXR-21) Jxr plugin fails if xdoclet executed without sources generation
[
http://jira.codehaus.org/browse/MJXR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88578
]
Fernando Lindner commented on MJXR-21:
--
Dennis,
here comes a build tag example for this bug (It includes the workaround):
{code:xml}
...
org.codehaus.mojo
xdoclet-maven-plugin
generate-sources
xdoclet
...
{code}
> Jxr plugin fails if xdoclet executed without sources generation
> ---
>
> Key: MJXR-21
> URL: http://jira.codehaus.org/browse/MJXR-21
> Project: Maven 2.x JXR Plugin
> Issue Type: Bug
>Reporter: Fernando Lindner
>Priority: Critical
>
> JXR plugin always tries to find directory "target/generated-sources/xdoclet"
> if a xdoclet execution is set. For instance, if a webdoclet task is used, no
> "target/generated-sources/xdoclet" directory should be created, resulting in
> a build error.
--
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: (SUREFIRE-132) Running tests in JAR files
[ http://jira.codehaus.org/browse/SUREFIRE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugo Palma closed SUREFIRE-132. --- Resolution: Fixed Yep. That does it for me. > Running tests in JAR files > -- > > Key: SUREFIRE-132 > URL: http://jira.codehaus.org/browse/SUREFIRE-132 > Project: Maven Surefire > Issue Type: New Feature >Affects Versions: 2.0 (2.2 plugin) >Reporter: Hugo Palma >Priority: Minor > Fix For: 2.4 > > > AFAIK it's not possible to run tests that are in a dependency jar and not in > the tested module source files. > It would be great if this was possible. -- 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-2850) DependencyVisitor bug fix & more tests
DependencyVisitor bug fix & more tests -- Key: MNG-2850 URL: http://jira.codehaus.org/browse/MNG-2850 Project: Maven 2 Issue Type: Improvement Components: Sandbox Reporter: Mark Hobson Priority: Minor Attachments: maven-dependency-analyzer.patch o Fixed bug in DependencyVisitor o Improved test coverage -- 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-2850) DependencyVisitor bug fix & more tests
[ http://jira.codehaus.org/browse/MNG-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88577 ] Mark Hobson commented on MNG-2850: -- Patch is for https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-dependency-analyzer/ > DependencyVisitor bug fix & more tests > -- > > Key: MNG-2850 > URL: http://jira.codehaus.org/browse/MNG-2850 > Project: Maven 2 > Issue Type: Improvement > Components: Sandbox >Reporter: Mark Hobson >Priority: Minor > Attachments: maven-dependency-analyzer.patch > > > o Fixed bug in DependencyVisitor > o Improved test coverage -- 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: (MRM-276) HTTP error 500 when artifact is not found
[ http://jira.codehaus.org/browse/MRM-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-276. -- Resolution: Fixed Patch has been commited. Thanks! > HTTP error 500 when artifact is not found > - > > Key: MRM-276 > URL: http://jira.codehaus.org/browse/MRM-276 > Project: Archiva > Issue Type: Bug > Environment: tomcat 5.5.2 >Reporter: Antoine Véret > Assigned To: Joakim Erdfelt > Attachments: ConvertHTTP500To404.patch > > > HTTP 500 error cause unexpected behaviour with Maven, for exemple it doesnt > search dependencies in all managed repositories. > Archiva should return HTTP 404 error intead of HTTP 500 error. > The patch catch all ResourceDoesNotExistException in the ProxiedDavServer > class. -- 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: (MRM-294) Repository purge feature for snapshots
Repository purge feature for snapshots -- Key: MRM-294 URL: http://jira.codehaus.org/browse/MRM-294 Project: Archiva Issue Type: New Feature Affects Versions: 1.0 Reporter: Wendy Smoak We need a way to purge a repository of snapshots older than a certain date, (optionally retaining the most recent one) and fixing the metadata. -- 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88592 ] Archimedes Trajano commented on MNG-2045: - We have the normal case, but it won't work unless we before an install first. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox > Fix For: 2.1.x > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88593 ] Archimedes Trajano commented on MNG-2045: - We have the normal case, but it won't work unless we do an install first. So mvn clean install on the project will run the tests correctly. But mvn clean test won't because the test-jar dependency won't resolve. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox > Fix For: 2.1.x > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- 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: (NMAVEN-9) Need Solution For Executing Assemblies with Dependencies that are not within the .NET framework or within the GAC
Need Solution For Executing Assemblies with Dependencies that are not within the .NET framework or within the GAC - Key: NMAVEN-9 URL: http://jira.codehaus.org/browse/NMAVEN-9 Project: NMaven Issue Type: Improvement Reporter: Shane Isbell Priority: Minor If a .NET executable resides in the local repo, it can only be directly executed if its dependencies are located within the .NET framework or within the GAC. Need a solution to handle executing assemblies directly from the repo when the executable has dependencies that are not within the .NET framework or within the GAC. -- 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: (NMAVEN-10) Test Compile Fails For Unit Testing .NET Modules
Test Compile Fails For Unit Testing .NET Modules Key: NMAVEN-10 URL: http://jira.codehaus.org/browse/NMAVEN-10 Project: NMaven Issue Type: Bug Reporter: Shane Isbell Priority: Minor Attachments: bug.txt Test compile fails for unit testing .NET modules. During compile, the compiler is using a reference field for the .netmodule, it should be using the addmodule field. -- 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: (CONTINUUM-1185) Can't get past "General Configuration" in r511964
Can't get past "General Configuration" in r511964 - Key: CONTINUUM-1185 URL: http://jira.codehaus.org/browse/CONTINUUM-1185 Project: Continuum Issue Type: Bug Affects Versions: 1.1 Environment: Continuum 1.1-SNAPSHOT r511964 Reporter: Wendy Smoak Continuum r511964 has a problem, you can't get out of General Configuration. All the integration tests are failing. >From a fresh install, here's what happens: 1. Create Admin user 2. General Configuration 3. Save 4. Login screen 5. Login as admin 6. General Configuration 7. Any other link -> General Configuration It used to be: 1. Create Admin user 2. Login screen 3. Log in as admin 4. General Configuration 5. proceed as usual -- 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: (CONTINUUM-1186) Application should unpack to continuum-${version}
Application should unpack to continuum-${version}
-
Key: CONTINUUM-1186
URL: http://jira.codehaus.org/browse/CONTINUUM-1186
Project: Continuum
Issue Type: Improvement
Environment: 1.1-SNAPSHOT r511964
Reporter: Wendy Smoak
The Plexus app currently unpacks to 'continuum'. It should have the version
number in the top level directory.
--
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: (MRM-295) Application should unpack to archiva-${version}
Application should unpack to archiva-${version}
---
Key: MRM-295
URL: http://jira.codehaus.org/browse/MRM-295
Project: Archiva
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Wendy Smoak
Priority: Minor
The Plexus app currently unpacks to 'archiva'. It should have the version
number in the top level directory.
--
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: (SUREFIRE-294) Test resources not found in classpath
[ http://jira.codehaus.org/browse/SUREFIRE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Crossley closed SUREFIRE-294. - Resolution: Fixed Nevermind. I'm sorry. My bad. I was misinterpreting the error message to mean that META-INF/persistence.xml couldn't be found. They were being found alright, but they were misconfigured. Adding deps for hibernate-entitymanager and hsqldb to the pom, and adding this to persistence.xml yielded the correct results... org.hibernate.ejb.HibernatePersistence Sorry for the trouble. > Test resources not found in classpath > - > > Key: SUREFIRE-294 > URL: http://jira.codehaus.org/browse/SUREFIRE-294 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 1.5.3 (2.1.3 plugin), 2.0 (2.2 plugin), 2.4 > Environment: Linux, JDK 1.5 >Reporter: Jim Crossley >Priority: Blocker > Attachments: surefire-classpath-test.zip > > > Attached is a simple project demonstrating that the Surefire plugin cannot > find the correct META-INF/persistence.xml when trying to create a JPA > EntityManagerFactory in the setup method of AppTest.java. There are two > persistence units defined: the "real" one in > src/main/resources/META-INF/persistence.xml and the "fake" one in > src/test/resources/META-INF/persistence.xml. The test case should work if > Surefire can find the "fake" one, which it currently can't. Incidentally, it > can't even find the "real" one. It's as if the resources directories are > simply not added to the classpath during test invocation. -- 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-2850) DependencyVisitor bug fix & more tests
[ http://jira.codehaus.org/browse/MNG-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88606 ] Joerg Schaible commented on MNG-2850: - Applied with svn 512020. > DependencyVisitor bug fix & more tests > -- > > Key: MNG-2850 > URL: http://jira.codehaus.org/browse/MNG-2850 > Project: Maven 2 > Issue Type: Improvement > Components: Sandbox >Reporter: Mark Hobson > Assigned To: Joakim Erdfelt >Priority: Minor > Attachments: maven-dependency-analyzer.patch > > > o Fixed bug in DependencyVisitor > o Improved test coverage -- 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-111) Can't release when I use javadoc aggregate/groups
[ http://jira.codehaus.org/browse/MJAVADOC-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88608 ] Rob Baily commented on MJAVADOC-111: I encountered the same issue as well. For now we're thinking about trying to put this in a profile so it is not affecting our normal release and then checking out the tag and pushing the site out after. > Can't release when I use javadoc aggregate/groups > - > > Key: MJAVADOC-111 > URL: http://jira.codehaus.org/browse/MJAVADOC-111 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: XP Pro >Reporter: David Hoffer > Attachments: FailedToReleaseDueToJavadoc.txt > > > I added the following section to my parent POM and can't release anymore, I > will attach the error log. > > true > > > Public Packages > > com.xrite.xdsiii:com.xrite.xdsiii.driver:com.xrite.xdsiii.driver.* > > > Internal Packages - API Subject To > Change > > com.xrite.awt:com.xrite.swing:com.xrite.util:com.xrite.xdsiii.instrument:com.xrite.xdsiii.instrument.* > > > > It looks like it needs the jars that have not jet been released yet (that's > what the release goal is for). -- 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: (MEV-503) AOP alliance needs a URL
[ http://jira.codehaus.org/browse/MEV-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-503. -- Assignee: Carlos Sanchez Resolution: Fixed > AOP alliance needs a URL > > > Key: MEV-503 > URL: http://jira.codehaus.org/browse/MEV-503 > Project: Maven Evangelism > Issue Type: Improvement > Components: Incomplete POM >Reporter: Daniel Kulp > Assigned To: Carlos Sanchez > > Pom should have: > http://aopalliance.sourceforge.net/ -- 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-1396) Upload UmlGraph 4.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88611 ] Carlos Sanchez commented on MAVENUPLOAD-1396: - cannot stat `UmlGraph-4.6.jar': No such file or directory > Upload UmlGraph 4.6 > --- > > Key: MAVENUPLOAD-1396 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1396 > Project: maven-upload-requests > Issue Type: Task >Reporter: Antonio Petrelli > Attachments: UmlGraph-bundle-4.6.jar > > > Hi, > Can you deploy the attached bundle, that permits to everyone running maven to > easily generate javadocs annotated > with uml diagrams like in: http://www.andrea-aime.name/static/gt2-api/ > Notice that I can't set SCM URL because there is no accessible SCM system. > Thanks, > Antonio -- 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-1394) jsch 0.1.31
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1394. --- Assignee: Carlos Sanchez Resolution: Fixed > jsch 0.1.31 > --- > > Key: MAVENUPLOAD-1394 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1394 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > > jsch 0.1.31 > (needed for fixing WAGONSSH-49 ) -- 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-1395) Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88612 ] Carlos Sanchez commented on MAVENUPLOAD-1395: - you need a groupId, you can't deploy to org.apache.maven.plugins eg. net.sf.maven-jlex > Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java. > - > > Key: MAVENUPLOAD-1395 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1395 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevin Conaway > > http://maven-jlex.sourceforge.net/maven-jlex-plugin-1.0-bundle.jar > http://maven-jlex.sourceforge.net/ > http://maven-jlex.sourceforge.net/team-list.html > Maven-jlex is a maven plugin for jlex, a lexical analyzer generator for Java. > It allows users to integreate the generation of lexical analyzers into the > maven build lifecycle -- 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-1393) xulfaces 0.9 Release for maven 2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88613 ] Carlos Sanchez commented on MAVENUPLOAD-1393: - the javadocs need to be inside the bundle do you own xulfaces.org? > xulfaces 0.9 Release for maven 2 > > > Key: MAVENUPLOAD-1393 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1393 > Project: maven-upload-requests > Issue Type: Task >Reporter: Olivier SCHMITT > Attachments: xulfaces-renderkit-0.9-bundle.jar, > xulfaces-renderkit-0.9-javadoc.jar > > > xulfaces is a JSF RenderKit for XUL. It is an open source project under LGPL > license. > xulfaces integrates JSF with XUL > My name is olivier SCHMITT, alias [EMAIL PROTECTED], i'am the xulfaces admin. > It satisfies the following goals: > * Light deployment. > Mozilla and Firefox have an integrated XUL engine, so you can use your > favorite web browser to run an XUL application. > * Keep the business layer on the server side. > JSF and Ajax are used to build a bridge between the client and the server. > * rich UI features. > XUL offers a rich UI for business applications. XUL is a simple XML language. > There are trees, tabbed panes, list boxes, wizards and so on. You have the > ability to refresh the entire screen or a part of it. > Add power to xulfaces via this Tapestry-like framework based on JSF. > xulfaces is a JSF custom RenderKit and generates pure XUL. -- 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-1391) New version of TableLayout
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1391. --- Assignee: Carlos Sanchez Resolution: Fixed Uploaded with jars from https://tablelayout.dev.java.net/servlets/ProjectDocumentList?folderID=3487&expandFolder=3487&folderID=0 > New version of TableLayout > -- > > Key: MAVENUPLOAD-1391 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1391 > Project: maven-upload-requests > Issue Type: Task >Reporter: John David N. Dionisio > Assigned To: Carlos Sanchez > > http://www.cs.lmu.edu/~dondi/maven/TableLayout-20050920-bundle.jar > https://tablelayout.dev.java.net > This is the latest version of the TableLayout project; the current version on > ibiblio is for 20020517 only. I am not an official developer on the project > (yet --- my request is pending but I have gotten no response). However, the > bundle is built directly from the CVS trunk of the above project on > tablelayout.dev.java.net. I simply wrote a POM and built via > repository:bundle-create. If you wish, just use my POM and rebuild the > bundle, so that you are sure that the JAR is indeed derived from the project. > 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] Closed: (MAVENUPLOAD-1220) Upload mx4j 3.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1220. --- Resolution: Incomplete > Upload mx4j 3.0.2 > - > > Key: MAVENUPLOAD-1220 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevan Miller > Assigned To: Carlos Sanchez > > The mx4j project has created a service release of mx4j. This release fixes > problems found in Geronimo testing. > I'm not a developer on mx4j, but have exchanged notes with Simone Bordet (who > is). He requested that I submit the upload request. > These new poms and jars mirror the 3.0.1 mx4j poms and jars already on > ibiblio. -- 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-1392) Upload of jasypt 1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1392. --- Assignee: Carlos Sanchez Resolution: Fixed You should create a synced repo as described in http://maven.apache.org/guides/mini/guide-central-repository-upload.html for easier and faster uploads > Upload of jasypt 1.1 > > > Key: MAVENUPLOAD-1392 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1392 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Fernández > Assigned To: Carlos Sanchez > > http://www.jasypt.org/jasypt-1.1-bundle.jar > http://www.jasypt.org/jasypt-hibernate-1.1-bundle.jar > http://www.jasypt.org/jasypt-spring-security-1.1-bundle.jar > http://www.jasypt.org > http://www.jasypt.org/team.html > Jasypt is a java library which allows the developer to add basic encryption > capabilities to his/her projects with minimum effort, and without the need of > having deep knowledge on how cryptography 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: (MEV-504) Jetty 5.1.10 and 5.1.11 missing poms
[ http://jira.codehaus.org/browse/MEV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88618 ] Greg Wilkins commented on MEV-504: -- We have never used maven to build or publish jetty 5. But we could perhaps manually build a jetty 5 repository so that older versions can be referenced. Carlos - is this advised or not? > Jetty 5.1.10 and 5.1.11 missing poms > > > Key: MEV-504 > URL: http://jira.codehaus.org/browse/MEV-504 > Project: Maven Evangelism > Issue Type: Improvement > Components: Missing POM >Reporter: Daniel Kulp > > The NEW versions of Jetty (6.x) have correct poms that include all the > information. > However, the 5.1.11 and 5.1.12 are missing poms. I've used information from > the 6.1 version and 5.1.10 versions to create: > 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 > jetty > org.mortbay.jetty > 5.1.11 > http://jetty.mortbay.org > Jetty Server > > > Apache License Version 2.0 > http://www.apache.org/licenses/LICENSE-2.0 > > > > Mort Bay Consulting > http://www.mortbay.com > > > jira > http://jira.codehaus.org/browse/Jetty > > > > Jetty Discuss List > > http://lists.sourceforge.net/lists/listinfo/jetty-discuss > > > http://www.nabble.com/Jetty-Discuss-f60.html > > > > Jetty Support List > > http://lists.sourceforge.net/lists/listinfo/jetty-support > > > http://www.nabble.com/Jetty-Support-f61.html > > > > Jetty Announce List > > http://lists.sourceforge.net/lists/listinfo/jetty-announce > > > http://www.nabble.com/Jetty---Announce-f2649.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] Commented: (MNG-2830) Source plugin packages each module with *all* module's sources, in multi-module build
[ http://jira.codehaus.org/browse/MNG-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88620 ] Howard M. Lewis Ship commented on MNG-2830: --- That does appear to fix it. Nope ... now I'm having trouble reproducing it. I suspect a fix crept in at some point. > Source plugin packages each module with *all* module's sources, in > multi-module build > - > > Key: MNG-2830 > URL: http://jira.codehaus.org/browse/MNG-2830 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts >Affects Versions: 2.0.5 >Reporter: Howard M. Lewis Ship > > Just upgraded from 2.0.4 to 2.0.5. > Performed a mvn clean install on my project. > Everything built correctly, but the source plugin: > > > org.apache.maven.plugins > > maven-source-plugin > > > > jar > > > > > Packaged each sub-module's -sources.jar with all the sources from all the > modules. -- 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: (MEV-504) Jetty 5.1.10 and 5.1.11 missing poms
[ http://jira.codehaus.org/browse/MEV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88622 ] Carlos Sanchez commented on MEV-504: you can put poms in the jetty m1 repo in the "jetty" groupId, and they'll be synced. Just be careful with the dependencies as things may break. > Jetty 5.1.10 and 5.1.11 missing poms > > > Key: MEV-504 > URL: http://jira.codehaus.org/browse/MEV-504 > Project: Maven Evangelism > Issue Type: Improvement > Components: Missing POM >Reporter: Daniel Kulp > > The NEW versions of Jetty (6.x) have correct poms that include all the > information. > However, the 5.1.11 and 5.1.12 are missing poms. I've used information from > the 6.1 version and 5.1.10 versions to create: > 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 > jetty > org.mortbay.jetty > 5.1.11 > http://jetty.mortbay.org > Jetty Server > > > Apache License Version 2.0 > http://www.apache.org/licenses/LICENSE-2.0 > > > > Mort Bay Consulting > http://www.mortbay.com > > > jira > http://jira.codehaus.org/browse/Jetty > > > > Jetty Discuss List > > http://lists.sourceforge.net/lists/listinfo/jetty-discuss > > > http://www.nabble.com/Jetty-Discuss-f60.html > > > > Jetty Support List > > http://lists.sourceforge.net/lists/listinfo/jetty-support > > > http://www.nabble.com/Jetty-Support-f61.html > > > > Jetty Announce List > > http://lists.sourceforge.net/lists/listinfo/jetty-announce > > > http://www.nabble.com/Jetty---Announce-f2649.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: (NMAVEN-11) Can't generate resources for an executable that contains an exe.config file
Can't generate resources for an executable that contains an exe.config file --- Key: NMAVEN-11 URL: http://jira.codehaus.org/browse/NMAVEN-11 Project: NMaven Issue Type: Bug Environment: Windows, Microsoft Framework 2.0 Reporter: Shane Isbell Priority: Minor When a project that has both a src/main/resource/resgen folder and a config file under src/main/config, the build fails with the following error: [ERROR] NMAVEN-9000-002: Unable to generate resources: System.Exception: NMAVEN-9000-003: Could not find exe.config file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-295) Ability to set working directory while forking
Ability to set working directory while forking -- Key: SUREFIRE-295 URL: http://jira.codehaus.org/browse/SUREFIRE-295 Project: Maven Surefire Issue Type: Improvement Components: plugin Affects Versions: 2.3 Environment: N/A Reporter: David J. M. Karlsen Some tests might depend on relative-filenames, and the forking directory might influence the resolving, thus there should be a parameter to set the working-directory when forking. See http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html for details on the resolving of relative filenames. -- 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-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88626
]
Stanislav Spiridonov commented on WAGON-73:
---
I have the same behavior with a mirror of central:
jresearch-proxy-central
http://fire.jresearch.org/proxy/repository
central
I think we use the same proxy application (http://maven-proxy.codehaus.org/).
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
> Assigned To: Joakim Erdfelt
>Priority: Critical
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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
