[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366824#comment-17366824
]
Joakim Erdfelt commented on MRESOLVER-153:
--
Builds of some Eclipse projects using Maven 3.8.1 are experiencing the
"java.lang.IllegalArgumentException: Malformed \u encoding." issue as well.
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=574316]
* [https://www.eclipse.org/lists/cbi-dev/msg02389.html]
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on
[jira] [Commented] (MSITE-857) Jetty engine fails to resolve web.xml DTD behind corporate proxy
[
https://issues.apache.org/jira/browse/MSITE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106482#comment-17106482
]
Joakim Erdfelt commented on MSITE-857:
--
Web App 2.3 DTD is not in the Jetty schema XML catalog.
The oldest Web App DTD in the XML catalog is version 2.4
[https://github.com/eclipse/jetty.toolchain/blob/master/jetty-schemas/src/main/resources/jakarta/servlet/catalog.xml]
> Jetty engine fails to resolve web.xml DTD behind corporate proxy
>
>
> Key: MSITE-857
> URL: https://issues.apache.org/jira/browse/MSITE-857
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:run
>Affects Versions: 3.9.0
> Environment: Windows 10, Intel 4 cores, 16GB RAM
>Reporter: Valentino Pinna
>Priority: Critical
>
> To reproduce, ensure to be behind corporate proxy (with settings.xml
> correctly configured) and execute:
> {code:java}
> mvn -X org.apache.maven.plugins:maven-site-plugin:3.9.0:run
> {code}
> Extract from log:
> {code:java}
> [DEBUG] resolveEntity(-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN,
> http://java.sun.com/dtd/web-app_2_3.dtd)
> [DEBUG] Can't exact match entity in redirect map, trying web-app_2_3.dtd
> [WARNING] Failed startup of context
> o.e.j.w.WebAppContext@523a7801{/,file:///C:/Users/m027907/eclipse-workspace/vtl/target/site-stage/,UNAVAILABLE}
> java.net.ConnectException: Connection timed out: connect
> at java.net.PlainSocketImpl.connect0 (Native Method)
> at java.net.PlainSocketImpl.socketConnect (PlainSocketImpl.java:101)
> at java.net.AbstractPlainSocketImpl.doConnect
> (AbstractPlainSocketImpl.java:399)
> at java.net.AbstractPlainSocketImpl.connectToAddress
> (AbstractPlainSocketImpl.java:242)
> at java.net.AbstractPlainSocketImpl.connect
> (AbstractPlainSocketImpl.java:224)
> at java.net.Socket.connect (Socket.java:609)
> at java.net.Socket.connect (Socket.java:558)
> at sun.net.NetworkClient.doConnect (NetworkClient.java:182)
> at sun.net.www.http.HttpClient.openServer (HttpClient.java:474)
> at sun.net.www.http.HttpClient.openServer (HttpClient.java:569)
> at sun.net.www.http.HttpClient. (HttpClient.java:242)
> at sun.net.www.http.HttpClient.New (HttpClient.java:341)
> at sun.net.www.http.HttpClient.New (HttpClient.java:362)
> at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient
> (HttpURLConnection.java:1248)
> at sun.net.www.protocol.http.HttpURLConnection.plainConnect0
> (HttpURLConnection.java:1187)
> at sun.net.www.protocol.http.HttpURLConnection.plainConnect
> (HttpURLConnection.java:1081)
> at sun.net.www.protocol.http.HttpURLConnection.connect
> (HttpURLConnection.java:1015)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0
> (HttpURLConnection.java:1587)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream
> (HttpURLConnection.java:1515)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity
> (XMLEntityManager.java:676)
> at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity
> (XMLEntityManager.java:1398)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity
> (XMLEntityManager.java:1364)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource
> (XMLDTDScannerImpl.java:257)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch
> (XMLDocumentScannerImpl.java:1152)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next
> (XMLDocumentScannerImpl.java:1040)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
> (XMLDocumentScannerImpl.java:943)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:605)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:534)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:888)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:824)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:635)
> at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse
> (SAXParserImpl.java:324)
>
[jira] Commented: (MNG-3762) Relocation not working for plugins
[
https://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279117#comment-279117
]
Joakim Erdfelt commented on MNG-3762:
-
Seems to work in Maven 3.x
Here's a test project.
https://github.com/joakime/maven-llama-plugin-relocation
Just build from the top, and use the test-project to see it using the
maven-llama-plugin.
Then uncomment the relocation in maven-llama-plugin/pom.xml, mvn clean install,
and then execute the test-project again.
> Relocation not working for plugins
> --
>
> Key: MNG-3762
> URL: https://jira.codehaus.org/browse/MNG-3762
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "i386" Family: "unix"
>Reporter: Wendy Smoak
> Fix For: Issues to be reviewed for 3.x
>
>
> As discussed on the user list, the relocation pom for the Jetty plugin does
> not seem to work correctly.
> See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
> To reproduce, create a project from the webapp archetype, and introduce the
> Jetty plugin:
> {noformat}
>
>...
>
>
>org.mortbay.jetty
>maven-jetty-plugin
>7.0.0pre3
>
>
> {noformat}
> Attempting to build the project results in an error:
> {noformat}
> $ mvn install
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building mywebapp Maven Webapp
> [INFO]task-segment: [install]
> [INFO]
>
> Downloading:
> http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] A required plugin was not found: Plugin could not be found -
> check that the goal name is correct: Unable to download the artifact
> from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
>mvn install:install-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
>mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
> -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
> -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
> [INFO] Final Memory: 3M/7M
> [INFO]
>
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-551) On Linux (Ubuntu) it fails to escape all special characters when forking commands.
[
http://jira.codehaus.org/browse/SUREFIRE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179089#action_179089
]
Joakim Erdfelt commented on SUREFIRE-551:
-
How to reproduce (short way)
# Create a maven 2 project in a path with "(" character. eg:
/home/user/code/project-foo(trunk)/pom.xml
# Create intentional test failure in the codebase
# Build: mvn clean install
# Notice, no test failures are reported (and no tests are run!)
How to reproduce (the long way)
# Load a maven 2 project into a Hudson instance.
# Set your project name in Hudson to "Project (foo)"
# Add an intentional test failure to the codebase, one that will generate a
test failures.
# Build the project in hudson
# No test failures are reported, as the /bin/sh: Syntax Error: "(" unexpected
occurs
> On Linux (Ubuntu) it fails to escape all special characters when forking
> commands.
> --
>
> Key: SUREFIRE-551
> URL: http://jira.codehaus.org/browse/SUREFIRE-551
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4.2
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_13
> OS name: "linux" version: "2.6.28-11-server" arch: "amd64" Family: "unix"
>Reporter: Sean Montgomery
>Priority: Blocker
>
> Our project folder name has ()'s in it and this seems to be causing a problem
> for surefire as it is not escaping them when forking off.
> [INFO] Surefire report directory: /opt/paml/hudson/jobs/Site - XXX
> (1234)/workspace/trunk/target/surefire-reports
> Forking command line: /bin/sh -c "cd /opt/paml/hudson/jobs/Site\ -\ XXX\
> (1234)/workspace/trunk && /usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java -jar
> /tmp/surefirebooter7806691896360428397.jar
> /tmp/surefire3396974786525533977tmp /tmp/surefire4621871739825375135tmp"
> /bin/sh: Syntax error: "(" unexpected
> [ERROR] There are test failures.
--
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-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147820#action_147820 ] Joakim Erdfelt commented on MNG-3580: - Once I roll in the patch from MNG-3573, I can now see the error messages for bad parent pom information. The original ModelUtils NPE goes away if I fix the bad parent pom information on the corporate repository. So, the result of all of this is ... 1) ModelUtils iterates thru a parentPlugins List that has a null entry. 2) The null entry occurs due to a pom parsing error on bad UTF8 encoding. 2.a) The IBM JDK allows this null entry to be created in the List. 3) The root cause of the null entry (the bad parsing) is incorrectly reported to the system as a Unable to Find Artifact. 4) The crucial information, "There is a bad pom" is not communicated, to the user, or the system. I think we can close this Jira, apply MNG-3753, and create a new Jira for clearer error messages on bad poms. Funny enough, better error messages on bad poms has (kinda) been started as MNG-3392 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz > Fix For: 2.0.11 > > Attachments: debug-output.patch, maven.log, > MNG-3580-ibm-jdk-issues.zip, MNG-3580-maven-core.patch, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(D
[jira] Updated: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MNG-3580: Attachment: MNG-3580-maven-core.patch Attaching MNG-3580-maven-core.patch This patch adds a JUnit test to the maven-core project that demonstrates one of the NPEs encountered while operating within the IBM JDK. NOTE: This patch does not fix the issue, just adds a Unit test to tickle one of the bugs. > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz > Fix For: 2.0.11 > > Attachments: debug-output.patch, maven.log, > MNG-3580-ibm-jdk-issues.zip, MNG-3580-maven-core.patch, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
[jira] Updated: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MNG-3580: Attachment: MNG-3580-ibm-jdk-issues.zip Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works. This example needs more work to show the same NPE's found in other more complex projects. I'll attach another example when I get a use-case that is repeatable. > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz > Fix For: 2.0.11 > > Attachments: debug-output.patch, maven.log, > MNG-3580-ibm-jdk-issues.zip, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) > at java.lang.refl
[jira] Issue Comment Edited: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143909#action_143909 ] joakime edited comment on MNG-3580 at 8/1/08 4:01 PM: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs on the following IBM JDK / JRE's ... $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 /* Sorry about the multi-edits, my old keyboard apparently didn't survive the move without some gremlins :-( */ was (Author: joakime): I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildIntern
[jira] Issue Comment Edited: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143909#action_143909 ] joakime edited comment on MNG-3580 at 8/1/08 3:59 PM: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 was (Author: joakime): I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs with the IBM JDK 1.6.0 SR2 on Win32 And it also occurs with IBM JDK 1.5.0 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings
[jira] Reopened: (MNG-3580) FATAL ERROR and NPE on start
[ http://jira.codehaus.org/browse/MNG-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt reopened MNG-3580: - I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs with the IBM JDK 1.6.0 SR2 on Win32 And it also occurs with IBM JDK 1.5.0 > FATAL ERROR and NPE on start > > > Key: MNG-3580 > URL: http://jira.codehaus.org/browse/MNG-3580 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Linux iitm50ws1106 2.6.25.3-2-default #1 SMP 2008-05-10 > 07:46:36 +0200 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0" > Java(TM) SE Runtime Environment (build pxa6460sr1-20080416_01(SR1)) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 > jvmxa6460-20080415_18762 (JIT enabled, AOT enabled) > J9VM - 20080415_018762_LHdSMr > JIT - r9_20080415_1520 > GC - 20080415_AA) > JCL - 20080412_01 >Reporter: Erik Putrycz >Assignee: Brett Porter > Attachments: maven.log, MNG-3580.patch > > > Any mvn command does give me the following error message > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Business Rules Extractor > [INFO] Business Rules Extractor core functions > [INFO] COBOL Parser and ANTLR Tools > [INFO] Business Rules Extractor data model > [INFO] Documentation Extractor module > [INFO] Extractor module > [INFO] Business Rules Navigator > WAGON_VERSION: 1.0-beta-2 > [INFO] > > [INFO] Building Business Rules Extractor > [INFO]task-segment: [install] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) > at > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) > at java.lang.reflect.Method.invoke(Method.java:612) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >
[jira] Closed: (WAGON-218) Link Parsing in http is flawed
[ http://jira.codehaus.org/browse/WAGON-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed WAGON-218. Resolution: Fixed Work completed in revision 662070 After a sample LinkParser replacement is P.o.C. in a wagon-http-with-webdav branch, and a discussion in the [EMAIL PROTECTED] mailing list. The following changes have been made. 1) Replaced jtidy with nekohtml This resulted in a smaller dependency list and improved memory utilization. 2) Replaces reliance of String URL manipulation with use of java.net.URI This change makes the detection of content that belongs to the page more accurate, as well as enables some complex relative uri resolution almost trivial. 3) Added more unit tests for real world scenarios encountered since the original implementation was loose on the world. > Link Parsing in http is flawed > -- > > Key: WAGON-218 > URL: http://jira.codehaus.org/browse/WAGON-218 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > > The link parsing in wagon http has a few issues. > a) not all links detected. > b) the various ways that page content is identified via url string > manipulation isn't working in many example cases. > c) the use of jtidy introduces a large dependency and high memory usage. -- 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: (WAGON-218) Link Parsing in http is flawed
Link Parsing in http is flawed -- Key: WAGON-218 URL: http://jira.codehaus.org/browse/WAGON-218 Project: Maven Wagon Issue Type: Improvement Components: wagon-http, wagon-http-lightweight Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt The link parsing in wagon http has a few issues. a) not all links detected. b) the various ways that page content is identified via url string manipulation isn't working in many example cases. c) the use of jtidy introduces a large dependency and high memory usage. -- 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-217) dav:http:// and dav:https:// do not conform to URI spec
[ http://jira.codehaus.org/browse/WAGON-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136922#action_136922 ] Joakim Erdfelt commented on WAGON-217: -- Note: the existing protocols of dav:http:// and dav:https:// are still in place, this change is backward compatible. It merely adds more protocol prefixes that WebdavWagon wlil respond to. This should ease the integration points for wagon. These extra protocols should also reduce the number of incidents of issues and support requests around using webdav with wagon. > dav:http:// and dav:https:// do not conform to URI spec > --- > > Key: WAGON-217 > URL: http://jira.codehaus.org/browse/WAGON-217 > Project: Maven Wagon > Issue Type: New Feature > Components: wagon-webdav >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > The dav:http:// and dav:https:// protocol "prefix" defined for wagon-webdav > does not conform to the URI spec. > This adds a layer of extra work for wagon integrators. > Proposal: > * Add more mappings to the WebdavWagon to allow use of protocols that conform > to the URI spec. > Existing Protocols > * dav:http:// = http:// > * dav:https:// = https:// > > New Mappings > * dav:// = http:// > * davs:// = https:// > * dav+http:// = http:// > * dav+https:// = https:// -- 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-217) dav:http:// and dav:https:// do not conform to URI spec
[ http://jira.codehaus.org/browse/WAGON-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed WAGON-217. Resolution: Fixed Fix Version/s: 1.0-beta-3 Work completed on revision: 662092 > dav:http:// and dav:https:// do not conform to URI spec > --- > > Key: WAGON-217 > URL: http://jira.codehaus.org/browse/WAGON-217 > Project: Maven Wagon > Issue Type: New Feature > Components: wagon-webdav >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > The dav:http:// and dav:https:// protocol "prefix" defined for wagon-webdav > does not conform to the URI spec. > This adds a layer of extra work for wagon integrators. > Proposal: > * Add more mappings to the WebdavWagon to allow use of protocols that conform > to the URI spec. > Existing Protocols > * dav:http:// = http:// > * dav:https:// = https:// > > New Mappings > * dav:// = http:// > * davs:// = https:// > * dav+http:// = http:// > * dav+https:// = https:// -- 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: (WAGON-217) dav:http:// and dav:https:// do not conform to URI spec
dav:http:// and dav:https:// do not conform to URI spec --- Key: WAGON-217 URL: http://jira.codehaus.org/browse/WAGON-217 Project: Maven Wagon Issue Type: New Feature Components: wagon-webdav Reporter: Joakim Erdfelt The dav:http:// and dav:https:// protocol "prefix" defined for wagon-webdav does not conform to the URI spec. This adds a layer of extra work for wagon integrators. Proposal: * Add more mappings to the WebdavWagon to allow use of protocols that conform to the URI spec. Existing Protocols * dav:http:// = http:// * dav:https:// = https:// New Mappings * dav:// = http:// * davs:// = https:// * dav+http:// = http:// * dav+https:// = https:// -- 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: (MRM-731) variable in url pom are not replaced.
[
http://jira.codehaus.org/browse/MRM-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126363
]
Joakim Erdfelt commented on MRM-731:
Which url line in the pom is that specified in?
We have a TestCase setup for expression evaluation (as a result of MRM-487 and
MRM-488), I'd like to use your pom.xml to further the testing.
See the following test case.
http://svn.apache.org/viewvc/maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/project/filters/ProjectModelExpressionExpanderTest.java?view=markup
{code}
/**
* [MRM-487] pom version is not resolved
* [MRM-488] properties in pom are not resolved (at least while browsing)
*
* This is to ensure that any expression within the pom is evaluated properly.
*/
public void testExpressionHell()
{code}
> variable in url pom are not replaced.
> -
>
> Key: MRM-731
> URL: http://jira.codehaus.org/browse/MRM-731
> Project: Archiva
> Issue Type: Bug
>Reporter: Benoit Decherf
>
> In my pom, the url of the project is :
>
> http:///docs/${project.groupId}/${project.artifactId}/${project.version}
> So I expect that archiva replace the ${} variables of this URL, but it
> doesn't :( .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-99) Make webdav support automatic
[ http://jira.codehaus.org/browse/WAGON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125253 ] Joakim Erdfelt commented on WAGON-99: - The experimental branch https://svn.apache.org/repos/asf/maven/wagon/branches/wagon-http-with-webdav has added WebDAV support to the heavyweight wagon-http provider. Hopefully this wagon-http provider can make it into the standard distribution as part of the MNG-2664 effort > Make webdav support automatic > - > > Key: WAGON-99 > URL: http://jira.codehaus.org/browse/WAGON-99 > Project: wagon > Issue Type: Improvement > Components: wagon-webdav >Reporter: Paul Gier > > It would be helpful if projects could be deployed over webdav without > requiring the build extensions. > What is the reason why the deploy plugin can't automatically use webdav? -- 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-710) Use commons-lang instead of Plexus Utils
Use commons-lang instead of Plexus Utils Key: MRM-710 URL: http://jira.codehaus.org/browse/MRM-710 Project: Archiva Issue Type: Task Components: design Affects Versions: 1.1 Reporter: Joakim Erdfelt Per conversation in Archiva-Dev. Migrate away from Plexus Utils to commons-lang (where appropriate) This is the other half of MRM-709 In our effort to migrate away from plexus towards Spring, we need to eliminate our usage of plexus-utils. -- 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: (ARCHETYPE-119) Ability to Create directories and files above /src
[ http://jira.codehaus.org/browse/ARCHETYPE-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124539 ] Joakim Erdfelt commented on ARCHETYPE-119: -- I'd like to toss my vote in for this issue. I'd personally like to set up a few archetypes with IDE configuration files too. > Ability to Create directories and files above /src > -- > > Key: ARCHETYPE-119 > URL: http://jira.codehaus.org/browse/ARCHETYPE-119 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0-alpha-7 > Environment: All >Reporter: Emil A. Lefkof III > > I have a need to create two default directories called /messages and /xsd > which are mandated by the client's preferred directory structure. These > directories and files need to go at the same level as /src. Currently you > can only create resources underneath of the /src directory where I need my > directory to come out looking like > /messages >---readme.txt > /src >/main >/java >/resources > /xsd > --readme.txt > Right now there is no way to create an archetype that does this. -- 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: (MEV-563) castor:xml-one-london has impossible version
castor:xml-one-london has impossible version Key: MEV-563 URL: http://jira.codehaus.org/browse/MEV-563 Project: Maven Evangelism Issue Type: Bug Reporter: Joakim Erdfelt http://repo1.maven.org/maven2/castor/xml-one-london/ http://repo1.maven.org/maven2/castor/xml-one-london/20010322%20/ Filed as MAVENREPOMAINT-3 too. -- 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: (MEV-562) jcharts has namespace overlap in windows.
jcharts has namespace overlap in windows. - Key: MEV-562 URL: http://jira.codehaus.org/browse/MEV-562 Project: Maven Evangelism Issue Type: Bug Components: Problem with Jar Reporter: Joakim Erdfelt http://repo1.maven.org/maven2/jcharts/jcharts/0.6.0/ http://repo1.maven.org/maven2/jcharts/jCharts/0.6.0/ The existence of 2 artifactIds with the same name but different case causes problems on windows. -- 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-613) [FEATURE] Archiva ArtifactRank
[FEATURE] Archiva ArtifactRank -- Key: MRM-613 URL: http://jira.codehaus.org/browse/MRM-613 Project: Archiva Issue Type: New Feature Components: reporting Affects Versions: 1.1 Reporter: Joakim Erdfelt This is a new feature request. ArtifactRank (the Archiva version of Googles PageRank) I'd like to see some badging of the health of the artifact, encourage the proper creation of artifacts this way. We can provide a graphic on the artifact page (and even the artifact search results and browse screens). This rank can also be used to increase the importance of hits on the search results. 100% = Gold Award for excellence. 70% to 99% = Green Award (Good) 40% to 69% = Yellow Award (Warning) 0% to 39% = Red Badge(Warning++) * How many other projects use the artifact. (junit would be highly ranked) * License is fully defined. * License file exists in the artifact archive. * URL is defined. * At least 1 contact point is defined. (Developer email address or mailing list) * A POM is defined. * Checksums are defined. * The maven pom manifest information exists. * All dependencies exist in the repository too. * All parent poms exist in the repository too. * All plugins used exist in the repository too. * If the artifact contains java ... ** All of the *.class files are within the same groupId that is defined in the POM. This is to indicate bad deployment, or bad ** All of the declared imports have an associated dependency defined. ** The manifest.mf file contains the version specified. ** The source.jar exists. ** The javadoc.jar exists. This list of checks can feed the reporting too. And the list of checks should be able to be extended / enhanced by administrators of Archiva installs too. -- 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: (MRM-578) unfinished scanning after NPE
[
http://jira.codehaus.org/browse/MRM-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113253
]
Joakim Erdfelt commented on MRM-578:
I've tested this with 1.0-beta-3 and the current archiva/trunk on my full
central (ibiblio) mirror.
I cannot reproduce this error.
{noformat}
12384893 [pool-2-thread-1] INFO
org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning -
Finished repository task:
.\ Scan of ibiblio \.__
Repository Dir: /home/repo1/ibiblio
Repository Name : Ibiblio Mirror
Repository Layout : default
Known Consumers : (5 configured)
create-missing-checksums
update-db-artifact
index-content
auto-rename
auto-remove
Invalid Consumers :
Duration : 1 Hour 35 Seconds 590 Milliseconds
When Gathered : 11/6/07 2:02 PM
Total File Count : 281074
Avg Time Per File : 12 Milliseconds
__
{noformat}
> unfinished scanning after NPE
> -
>
> Key: MRM-578
> URL: http://jira.codehaus.org/browse/MRM-578
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0-beta-3
> Environment: macosx 1.4, jdk 1.5, archiva beta3
>Reporter: Milos Kleint
> Fix For: 1.0-beta-4
>
> Attachments: error.txt, error2.txt
>
>
> I repeatedly tried to index a mirror of central repository. In previous
> attempts, usually got "Too many files opened" kind of errors. This time it's
> a NPE, see attached console output
--
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-564) Audit log is not populated when artifacts are deployed
[ http://jira.codehaus.org/browse/MRM-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-564. -- Resolution: Fixed Closing this jira as fixed, as it only mentions logging Deployed content. If we decide to log other content (see Mailing List) then we will open a new jira for that content. Thread: http://www.nabble.com/-DISCUSS---MRM-564--Audit-Logging.-tf4772818.html > Audit log is not populated when artifacts are deployed > -- > > Key: MRM-564 > URL: http://jira.codehaus.org/browse/MRM-564 > Project: Archiva > Issue Type: Improvement > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > The audit.log file should contain an entry when any of the following events > occurs: create directory, remove directory, create file, modify file, remove > file. > After a release, the audit.log file only contained: > 2007-09-13 19:27:55 - Logging Initialized. > There are no other audit log files. (I would have expected to see some with > dates in the filename, the others are configured to roll on a daily basis.) > (Needs to be verified with 1.0-beta-3 or later.) -- 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: (MRM-564) Audit log is not populated when artifacts are deployed
[ http://jira.codehaus.org/browse/MRM-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113221 ] Joakim Erdfelt commented on MRM-564: Committed fix to archiva/trunk at revision 593246. Still need to hook up repository purge to audit log. Unanswered questions. Do we need audit logging for the following? 1) Repository Configuration Create 2) Repository Configuration Edit 3) Repository Configuration Delete 4) Proxy Connector Create 5) Proxy Connector Edit 6) Proxy Connector Delete 7) Metadata Merge 8) Auto-Remove Consumer 9) Auto-Rename Consumer 10) Scan Start 11) Scan End In a discussion with Wendy on IRC the only concern would be what would we use for the userid / remote ip / and whatnot? Moving this discussion over to mailing list. > Audit log is not populated when artifacts are deployed > -- > > Key: MRM-564 > URL: http://jira.codehaus.org/browse/MRM-564 > Project: Archiva > Issue Type: Improvement > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > The audit.log file should contain an entry when any of the following events > occurs: create directory, remove directory, create file, modify file, remove > file. > After a release, the audit.log file only contained: > 2007-09-13 19:27:55 - Logging Initialized. > There are no other audit log files. (I would have expected to see some with > dates in the filename, the others are configured to roll on a daily basis.) > (Needs to be verified with 1.0-beta-3 or later.) -- 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-582) Remote Repositories with empty and fields shouldn't be created in configuration.
[ http://jira.codehaus.org/browse/MRM-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-582. -- Resolution: Fixed Fixed in archiva/trunk revision 593220. Implemented on-load cleanup of remote repo username/password (instead of on-save) Implemented proper check for blank username/password in proxy connectors. > Remote Repositories with empty and fields shouldn't be > created in configuration. > -- > > Key: MRM-582 > URL: http://jira.codehaus.org/browse/MRM-582 > Project: Archiva > Issue Type: Bug > Components: system >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > It is possible for a section in the archiva configuration > file to be created with an empty and/or fields. > Need to prevent empty/blank username and password fields from being created > in the archiva configuration. > Also need to prevent loading blank username and password fields from the > archiva configuration. -- 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-440) If webdav URL lacks a trailing /, navigating to all links in the listing return 404.
[ http://jira.codehaus.org/browse/MRM-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-440. -- Resolution: Fixed Fixed in archiva/trunk revision 593215. Issuing a redirect to the proper URL in the specific situation of a GET request to an existing resource that is a directory, but doesn't contain a slash at the end of the URL. > If webdav URL lacks a trailing /, navigating to all links in the listing > return 404. > > > Key: MRM-440 > URL: http://jira.codehaus.org/browse/MRM-440 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-4 > > > If you go to: > http://localhost:8080/archiva/repository/releases > then click a link, you get 404. > But if you go to: > http://localhost:8080/archiva/repository/releases/ > everything works as expected. -- 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-204) Request for Documentation answers
[ http://jira.codehaus.org/browse/MRM-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-204. -- Assignee: Joakim Erdfelt Resolution: Fixed Questions have been answered or are no longer valid. > Request for Documentation answers > - > > Key: MRM-204 > URL: http://jira.codehaus.org/browse/MRM-204 > Project: Archiva > Issue Type: Wish > Components: documentation >Reporter: Henri Yandell >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > Attachments: MRM-204-wsmoak1.diff > > > Could somebody explain what the following mean and are used for: > Identifiers. > Proxied Repositories. > Observers. -- 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-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-459. -- Resolution: Fixed Work completed in archiva/trunk revision 593206. Removing commons-logging-api everywhere Removing slf4j-simple Removing velocity-dep > prune the distributed dependencies > -- > > Key: MRM-459 > URL: http://jira.codehaus.org/browse/MRM-459 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > a large number of unneeded dependencies are distributed with Archiva (or if > they are needed, we might want to review why). > For example: ant-optional (probably for jsp compiler), commons-logging impl + > slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we > have geronimo-jat already), classworlds (we have plexus-classworlds already), > backport (we require JDK 5, no need for this). > I'm also uncertain if all the maven libraries are still needed. -- 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: (MRM-568) Error in 'update-db-project' consumer during database scanning when a repo that has been removed was re-added again
[ http://jira.codehaus.org/browse/MRM-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113203 ] Joakim Erdfelt commented on MRM-568: I am unable to reproduce this. Can you verify? Or provide a larger stack trace? > Error in 'update-db-project' consumer during database scanning when a repo > that has been removed was re-added again > --- > > Key: MRM-568 > URL: http://jira.codehaus.org/browse/MRM-568 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-3 >Reporter: Maria Odea Ching > Fix For: 1.0-beta-4 > > > This was the error from the console > jvm 1| 2007-10-24 10:44:46,186 [pool-1-thread-1] INFO > org.apache.maven.archiva.consumers.DatabaseUnprocessedArtifactConsumer:update-db-project > - Adding project model to database - > org.jruby.plugins:jruby-rake-plugin:1.0RC1-20070506.090132-4 > jvm 1| 2007-10-24 10:44:46,187 [pool-1-thread-1] ERROR > org.apache.maven.archiva.consumers.DatabaseUnprocessedArtifactConsumer:update-db-project > - Unable to process model > /home/deng/TestFiles/sample-local-repo/org/jruby/plugins/jruby-rake-plugin/1.0RC1-SNAPSHOT/jruby-rake-plugin-1.0RC1-20070506.090132-4.pom > due to : javax.jdo.JDOUserException : Field > org.apache.maven.archiva.model.ArchivaProjectModel.origin is null, but is > mandatory as its described in the jdo metadata > jvm 1| javax.jdo.JDOUserException: Field > org.apache.maven.archiva.model.ArchivaProjectModel.origin is null, but is > mandatory as its described in the jdo metadata > jvm 1| at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:120) > jvm 1| at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > jvm 1| at > org.apache.maven.archiva.model.ArchivaProjectModel.jdoProvideField(ArchivaProjectModel.java) > ... > Steps to reproduce: > 1. Added a new m2 repository 'sample-local-repo' (which already exists in my > local file system and has artifacts in it) > 2. Scanned the repository > 3. Updated the database > 4. Removed the repository > 5. Added it back again, with the same name, identifier and location. > 6. Scanned the repository > 7. Updated the database (this is where the error occurred) -- 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-185) revise logging granularity
[ http://jira.codehaus.org/browse/MRM-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-185. -- Assignee: Joakim Erdfelt Resolution: Fixed Closing as fixed. Logging has undergone a slow, but steady cleanup over the past 3 months. The logging is fairly lean now. > revise logging granularity > -- > > Key: MRM-185 > URL: http://jira.codehaus.org/browse/MRM-185 > Project: Archiva > Issue Type: Improvement > Components: system >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > in particular, check that JPOX logging is at the correct level, but generally > turn the noise down. -- 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: (MRM-490) add xwork exception handling pages for presentable error reporting
[ http://jira.codehaus.org/browse/MRM-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-490: --- Fix Version/s: (was: 1.0-beta-4) 1.x Moving to 1.x as this change will affect all xwork actions/pages/jsps. Too big of a change right now. > add xwork exception handling pages for presentable error reporting > -- > > Key: MRM-490 > URL: http://jira.codehaus.org/browse/MRM-490 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter > Fix For: 1.x > > > if anyone gets a stack trace, they should have an easy way to report it as a > bug (though this should also be configurable since in a production > environment the admin would want to be contacted instead) -- 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-531) Unable to download snapshots behind proxy with authentication
[ http://jira.codehaus.org/browse/MRM-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-531. -- Assignee: Joakim Erdfelt Resolution: Fixed Unable to reproduce the problem with Archiva 1.0-beta-3, closing ticket. Setup a the following test environment. 1) Workstation - using maven client Setup repo1.maven.org in my /etc/hosts pointing at 192.168.5.5 (a bad non-routable ip) 2) Server 1 - setup Archiva 1.0-beta-3 Setup repo1.maven.org in /etc/hosts pointing at 192.168.6.6 (a bad non-routable ip) 3) Server 2 - setup Squid 2.6 (http proxy) Configured authentication. Test 1) With this setup, I then tested a compile of a simple project that requires dependencies, while on Workstation. (No $HOME/.m2 directory present, all maven defaults). This failed (as expected). Test 2) Now, I configured the Archiva Server on Server 1 with a simple proxy connector (no network proxy) for a managed repository called 'internal' and a remote repository called 'central' of http://repo1.maven.org/maven2 I now setup a $HOME/.m2/settings.xml on Workstation to central pointing at the 'internal' repository on the Archiva Server. Test the build. Failed again. Which was expected (basically, just testing that a normal direct connection to repo1.maven.org is not possible) Test 3) Now I configured the Archiva Server on Server 1 to use the Squid http proxy at Server 2 as a configured Network Proxy in Archiva. Test the build. Success! The process works as expected. NOTE: Archiva supports only simple authentication on the network proxy, advanced authentication options such as NTLM, Kerberos, and Public/Private key exchange are not supported. > Unable to download snapshots behind proxy with authentication > - > > Key: MRM-531 > URL: http://jira.codehaus.org/browse/MRM-531 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 > Environment: solaris 5.10, jdk1.6.0_02, proxy with basic > authentication >Reporter: Mathias Arens >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > I am able to download artifacts from several remote repositories into the > internal repository. But I cannot download any dependencies into the > snapshots repository. I always get a http-'Server redirected too many times > (20)'-error. I read that this error occurs if the proxy authentication > properties are not set correctly in the http client. I am behind a proxy with > basic authentication and an empty password. This configuration works fine for > the internal repository, but not for the snapshot repository. > Here are the logs: > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [ignored] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to IGNORED. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [disabled] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update, > release policy does not apply for snapshot versions. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [daily] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update > snapshots, local file does not exist. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,988 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/artifact/maven-artifact/3.0-SNAPSHOT/mave > n-artifact-3.0-SNAPSHOT.pom from Apache Snapshots Repository if updated > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:09,087 > [SocketListener0-7] WARN > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Download > failure:Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | > org.apache.maven.wagon.TransferFailedException: Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(
[jira] Created: (MRM-582) Remote Repositories with empty and fields shouldn't be created in configuration.
Remote Repositories with empty and fields shouldn't be created in configuration. -- Key: MRM-582 URL: http://jira.codehaus.org/browse/MRM-582 Project: Archiva Issue Type: Bug Components: system Affects Versions: 1.0-beta-3 Reporter: Joakim Erdfelt It is possible for a section in the archiva configuration file to be created with an empty and/or fields. Need to prevent empty/blank username and password fields from being created in the archiva configuration. Also need to prevent loading blank username and password fields from the archiva configuration. -- 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-516) Search results return results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-516. -- Resolution: Fixed Completed work merged from branch to trunk in revision 592513. > Search results return results for all repositories, regardless of security. > --- > > Key: MRM-516 > URL: http://jira.codehaus.org/browse/MRM-516 > Project: Archiva > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The UserAllowedToSearchRepositoryPredicate needs to be finished. > It should take the current user, their RBAC roles, and filter based on the > roles available to the user. -- 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-569) Browse shows results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-569. -- Resolution: Fixed Completed work merged from branch to trunk in revision 592513. > Browse shows results for all repositories, regardless of security. > -- > > Key: MRM-569 > URL: http://jira.codehaus.org/browse/MRM-569 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > When browsing archiva (using the browse link on the left hand navigation > bar), the results are for all repositories, regardless of security. > This needs to be filtered based on access rights of the user. -- 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: (MRM-516) Search results return results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112610 ] Joakim Erdfelt commented on MRM-516: Implemented in the archiva-backend-security branch revision 591500. https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-backend-security/ > Search results return results for all repositories, regardless of security. > --- > > Key: MRM-516 > URL: http://jira.codehaus.org/browse/MRM-516 > Project: Archiva > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The UserAllowedToSearchRepositoryPredicate needs to be finished. > It should take the current user, their RBAC roles, and filter based on the > roles available to the user. -- 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: (MRM-569) Browse shows results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112594 ] Joakim Erdfelt commented on MRM-569: Fix is committed to archiva-backend-security branch revision 591410. https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-backend-security Needs to be reviewed and merged into trunk. > Browse shows results for all repositories, regardless of security. > -- > > Key: MRM-569 > URL: http://jira.codehaus.org/browse/MRM-569 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > When browsing archiva (using the browse link on the left hand navigation > bar), the results are for all repositories, regardless of security. > This needs to be filtered based on access rights of the user. -- 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-1542) Surefire Report in continuum contains excess/superfluous test methods.
Surefire Report in continuum contains excess/superfluous test methods. -- Key: CONTINUUM-1542 URL: http://jira.codehaus.org/browse/CONTINUUM-1542 Project: Continuum Issue Type: Bug Components: Testing Reporter: Joakim Erdfelt When looking at the surefire test results within a continuum build that reported a failure, the list of test methods for the tested class contains extra methods from other tested classes. Continuum on maven.zones.apache.org [surefire report example with problem|http://maven.zones.apache.org/continuum/surefireReport.action;jsessionid=10vfs6g7jbl9f?buildId=32827&projectId=296#org.apache.maven.archiva.web.repository.RepositoryServletProxiedReleasePolicyTest] If you look at the list of test methods for RepositoryServletProxiedReleasePolicyTest you can see that the report shows the correct # of tests at the top with 15, but when you goto the details for that test, you see well over 15 tests. In fact, when you look at the section that starts with "Test Cases" you can see that the list of tests for each Test class is actually the list of tests from the previous Test class + the tests for the current Test class. Example: +RepositoryServletNoProxyMetadataTest+ (/) testGetVersionMetadataDefaultLayout (/) testGetProjectMetadataDefaultLayout (/) testGetSnapshotVersionMetadataDefaultLayout +ArchivaMimeTypeLoaderTest+ (/) -testGetVersionMetadataDefaultLayout- (/) -testGetProjectMetadataDefaultLayout- (/) -testGetSnapshotVersionMetadataDefaultLayout- (/) testArchivaTypes +RepositoryServletProxiedPluginSnapshotPolicyTest+ (/) -testGetVersionMetadataDefaultLayout- (/) -testGetProjectMetadataDefaultLayout- (/) -testGetSnapshotVersionMetadataDefaultLayout- (/) -testArchivaTypes- (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedNewer (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedOlder (/) testGetProxiedSnapshotsArtifactPolicyAlwaysNoManagedContent (/) testGetProxiedSnapshotsArtifactPolicyDailyFail ... -- 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: (MRM-548) proxy connectors: default policies for added repositories may not be optimal
[ http://jira.codehaus.org/browse/MRM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112312 ] Joakim Erdfelt commented on MRM-548: Current default settings in archiva/trunk (checked on revision 590908). (NOTE: These use the new terms as outlined in MRM-547) Releases: Hourly Snapshots: Hourly Cached-Failures: No Checksum Policy: Fix If this is satisfactory, then this jira can be closed. > proxy connectors: default policies for added repositories may not be optimal > > > Key: MRM-548 > URL: http://jira.codehaus.org/browse/MRM-548 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0-beta-4 > > > the default for snapshots and releases is "ignored" for updates. This is > inconsistent with Maven default behaviour - should it be daily? -- 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-547) proxy connectors: cache failures options are confusing
[ http://jira.codehaus.org/browse/MRM-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-547. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in archiva/trunk revision 590908. > proxy connectors: cache failures options are confusing > -- > > Key: MRM-547 > URL: http://jira.codehaus.org/browse/MRM-547 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-4 > > > I think this should be renamed to just "failures" which can be "cached" or > "ignored", or otherwise be changed to a yes/no value for "cached failures". -- 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-549) proxy connectors: no "always" option for releases and snapshots policies
[ http://jira.codehaus.org/browse/MRM-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-549. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in archiva/trunk revision 590908. > proxy connectors: no "always" option for releases and snapshots policies > > > Key: MRM-549 > URL: http://jira.codehaus.org/browse/MRM-549 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > -- 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: (MRM-547) proxy connectors: cache failures options are confusing
[
http://jira.codehaus.org/browse/MRM-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112303
]
Joakim Erdfelt commented on MRM-547:
A discussion and decision has been made in the mailing list.
All policy settings are getting a thorough cleanup.
{noformat}
Releases (how often to check for)
(old) IGNORED, ONCE, HOURLY, DAILY, DISABLED
(new) ALWAYS, ONCE, HOURLY, DAILY, NEVER
Snapshots (for often to check for)
(old) IGNORED, ONCE, HOURLY, DAILY, DISABLED
(new) ALWAYS, ONCE, HOURLY, DAILY, NEVER
Cache-Failures
(old) IGNORED, CACHED
(new) NO, YES
Checksum
(old) IGNORED, FIX, FAIL
(new) IGNORE, FIX, FAIL
{noformat}
With new descriptions:
(for releases / snapshots policies)
* ALWAYS : Means that the artifact is always updated from the remote repo.
* ONCE : Means the artifact is updated only ever ONCE from the remote repo. If
it exists on the local repo, the remote repo is never hit for that artifact.
* HOURLY : Means the artifact is updated from the remote repo, only if it is at
least one hour old on the local repo.
* DAILY : Means the artifact is updated from the remote repo, only if it is at
least 1 day old on the local repo.
* NEVER : Means the artifact is never updated from the remote repo.
(for cache-failures)
* NO : Means that the existence of old failures is not checked. All resource
requests are allowed thru to the remote repo.
* YES : Means that the existence of old failures is checked, and will prevent
the request from being performed against the remote repo.
(for checksum)
* IGNORE : Means the contents / validity of the checksum files is ignored.
* FIX : Means that the checksum files are regenerated from the downloaded
resources.
* FAIL : Means that the checksum files are validated against the downloaded
resource, if the resource does not pass the checksum validation, the resource
and the checksum files are deleted from the local repository and a failure is
issued for the transfer.
> proxy connectors: cache failures options are confusing
> --
>
> Key: MRM-547
> URL: http://jira.codehaus.org/browse/MRM-547
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-2
>Reporter: Brett Porter
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> I think this should be renamed to just "failures" which can be "cached" or
> "ignored", or otherwise be changed to a yes/no value for "cached failures".
--
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-577) Release policy of disabled fails all metadata requests.
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-577.
--
Resolution: Fixed
Fixing release and snapshot policies to not apply their policy rules to
non-artifacts. (namely maven-metadata.xml files)
Workaround: do not use DISABLED setting for the policies.
Fix committed to archiva/trunk revision 590858.
> Release policy of disabled fails all metadata requests.
> ---
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
> Components: repository interface
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> Unable to successfully download maven-metadata.xml files when the release
> policy is set to disabled.
> To reproduce it:
> 1) Setup a proxy connector to repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> 1a) Set the Release policy to "disabled".
> 2) And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
> 3) Attempt to compile the 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] Updated: (MRM-577) Release policy of disabled fails all metadata requests.
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-577:
---
Priority: Minor (was: Major)
Description:
Unable to successfully download maven-metadata.xml files when the release
policy is set to disabled.
To reproduce it:
1) Setup a proxy connector to repo of snapshots at apache :
http://people.apache.org/repo/m2-snapshot-repository
1a) Set the Release policy to "disabled".
2) And in your project you add this plugin declaration :
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2-SNAPSHOT
{code}
3) Attempt to compile the project.
was:
To reproduce it you proxy the repo of snapshots at apache :
http://people.apache.org/repo/m2-snapshot-repository
And in your project you add this plugin declaration :
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2-SNAPSHOT
{code}
Fix Version/s: 1.0-beta-4
Component/s: repository interface
Summary: Release policy of disabled fails all metadata requests.
(was: Metadata aren't generated by archiva)
Correcting reason for failure.
> Release policy of disabled fails all metadata requests.
> ---
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
> Components: repository interface
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> Unable to successfully download maven-metadata.xml files when the release
> policy is set to disabled.
> To reproduce it:
> 1) Setup a proxy connector to repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> 1a) Set the Release policy to "disabled".
> 2) And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
> 3) Attempt to compile the 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: (MRM-577) Metadata aren't generated by archiva
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112249
]
Joakim Erdfelt commented on MRM-577:
Its not that metadata isn't generated, it simply isn't even being downloaded
from the remote proxies. :-(
I can sniff the traffic and see the request going into archiva for the
maven-metadata.xml, but not out of archiva to the proxy.
> Metadata aren't generated by archiva
>
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>
> To reproduce it you proxy the repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
--
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: (MRM-577) Metadata aren't generated by archiva
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112250
]
Joakim Erdfelt commented on MRM-577:
Archiva responds with a HTTP 404 on the request for that maven-metadata.xml,
researching cause now.
> Metadata aren't generated by archiva
>
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>
> To reproduce it you proxy the repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
--
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: (MRM-571) Create UserRepositories object in archiva-security
[ http://jira.codehaus.org/browse/MRM-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-571: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > Create UserRepositories object in archiva-security > -- > > Key: MRM-571 > URL: http://jira.codehaus.org/browse/MRM-571 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > Create a component to aide in filtering of ManagedRepositories based on user > permissions. > The two methods definitely needed (could be more) > * List getAllowedObservingRepositories( > String principal ); > * List getAllowedManagingRepositories( String > principal ); > Care will be needed to ensure that these lookups performs well (possible > caching needed). -- 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: (MRM-569) Browse shows results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-569: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > Browse shows results for all repositories, regardless of security. > -- > > Key: MRM-569 > URL: http://jira.codehaus.org/browse/MRM-569 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > When browsing archiva (using the browse link on the left hand navigation > bar), the results are for all repositories, regardless of security. > This needs to be filtered based on access rights of the user. -- 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: (MRM-572) Migrate continuum builds of archiva-security to new svn url
[ http://jira.codehaus.org/browse/MRM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-572: --- Priority: Critical (was: Major) Affects Version/s: 1.0-beta-3 Fix Version/s: 1.0-beta-4 Component/s: Users/Security > Migrate continuum builds of archiva-security to new svn url > --- > > Key: MRM-572 > URL: http://jira.codehaus.org/browse/MRM-572 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > -- 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-572) Migrate continuum builds of archiva-security to new svn url
Migrate continuum builds of archiva-security to new svn url --- Key: MRM-572 URL: http://jira.codehaus.org/browse/MRM-572 Project: Archiva Issue Type: Sub-task Components: Users/Security Affects Versions: 1.0-beta-3 Reporter: Joakim Erdfelt Fix For: 1.0-beta-4 -- 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: (MRM-516) Search results return results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-516: --- Fix Version/s: (was: 1.0-beta-3) 1.0-beta-4 > Search results return results for all repositories, regardless of security. > --- > > Key: MRM-516 > URL: http://jira.codehaus.org/browse/MRM-516 > Project: Archiva > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The UserAllowedToSearchRepositoryPredicate needs to be finished. > It should take the current user, their RBAC roles, and filter based on the > roles available to the user. -- 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: (MRM-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/
[ http://jira.codehaus.org/browse/MRM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-570: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > archiva-security/ needs to move from archiva-webapp/ to archiva-base/ > - > > Key: MRM-570 > URL: http://jira.codehaus.org/browse/MRM-570 > Project: Archiva > Issue Type: Task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > Since we need to implement backend security around the browse (MRM-569) and > search (MRM-516) facilities, the archiva-security module needs to be > decoupled from archiva-webapp and brought into archiva-base for the general > use of all archiva-base modules. > Leaving archiva-security like it is now will result in pulling in many webapp > specific libraries and concepts that are not needed in the archiva-base > heirarchy. -- 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-571) Create UserRepositories object in archiva-security
Create UserRepositories object in archiva-security -- Key: MRM-571 URL: http://jira.codehaus.org/browse/MRM-571 Project: Archiva Issue Type: Sub-task Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Create a component to aide in filtering of ManagedRepositories based on user permissions. The two methods definitely needed (could be more) * List getAllowedObservingRepositories( String principal ); * List getAllowedManagingRepositories( String principal ); Care will be needed to ensure that these lookups performs well (possible caching needed). -- 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-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/
archiva-security/ needs to move from archiva-webapp/ to archiva-base/ - Key: MRM-570 URL: http://jira.codehaus.org/browse/MRM-570 Project: Archiva Issue Type: Task Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Since we need to implement backend security around the browse (MRM-569) and search (MRM-516) facilities, the archiva-security module needs to be decoupled from archiva-webapp and brought into archiva-base for the general use of all archiva-base modules. Leaving archiva-security like it is now will result in pulling in many webapp specific libraries and concepts that are not needed in the archiva-base heirarchy. -- 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-569) Browse shows results for all repositories, regardless of security.
Browse shows results for all repositories, regardless of security. -- Key: MRM-569 URL: http://jira.codehaus.org/browse/MRM-569 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt When browsing archiva (using the browse link on the left hand navigation bar), the results are for all repositories, regardless of security. This needs to be filtered based on access rights of the user. -- 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: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111609
]
Joakim Erdfelt commented on MRM-560:
I've updated archiva/trunk (as of revision 588808) to be more resilient when it
comes to bad graph data, and also present more information on what archiva
considers to be bad graph data.
I am unable to reproduce this error, and I need more information on what is
going on.
The information that olamy has provided me in IRC is insufficient to reproduce
this bug.
olamy, can you use the current archiva/trunk and attempt to reproduce this bug?
If you can, I need the entire complete stack trace. (it'll be pretty big).
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-3
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.intercept
[jira] Commented: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111608
]
Joakim Erdfelt commented on MRM-560:
That last exception mentioning "Unable to create ArchivaArtifact with empty
version" should have some follow up Caused-By exceptions with some more details.
Can you get those to us?
Attach them to this jira (if you feel it is too big of a stack trace)
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-3
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInt
[jira] Closed: (MRM-481) Artifact requests with a .xml.zip extension fail with a 404 Error
[ http://jira.codehaus.org/browse/MRM-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-481. -- Resolution: Fixed Fixed in archiva/trunk revision 588732. > Artifact requests with a .xml.zip extension fail with a 404 Error > - > > Key: MRM-481 > URL: http://jira.codehaus.org/browse/MRM-481 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Cédric Vidal >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: multi-dots-ext-404-error.htm > > > This issue might also apply to any multi dots extension request but I didn't > check. > Regards, > Cédric -- 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-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-567.
--
Resolution: Fixed
Adding units tests for SNAPSHOT plugin downloading into archiva/trunk revision
588460.
Tested with actual archiva instance and maven project.
Verified that tests with SNAPSHOT plugins work too.
Closing as fixed.
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111475
]
Joakim Erdfelt commented on MRM-567:
Updates to archiva/trunk seem to have solved the snapshots dependencies issues.
There are now unit tests for requesting a snapshot artifact from archiva's
repository, with every possible configuration of the snapshot policy setup.
Now to test the snapshots plugin issue.
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-567:
---
Priority: Blocker (was: Critical)
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-564) Audit log is not populated when artifacts are deployed
[ http://jira.codehaus.org/browse/MRM-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-564: --- Affects Version/s: 1.0-beta-3 Fix Version/s: 1.0-beta-4 Component/s: Users/Security > Audit log is not populated when artifacts are deployed > -- > > Key: MRM-564 > URL: http://jira.codehaus.org/browse/MRM-564 > Project: Archiva > Issue Type: Improvement > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > The audit.log file should contain an entry when any of the following events > occurs: create directory, remove directory, create file, modify file, remove > file. > After a release, the audit.log file only contained: > 2007-09-13 19:27:55 - Logging Initialized. > There are no other audit log files. (I would have expected to see some with > dates in the filename, the others are configured to roll on a daily basis.) > (Needs to be verified with 1.0-beta-3 or later.) -- 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: (MRM-564) Audit log is not populated when artifacts are deployed
[ http://jira.codehaus.org/browse/MRM-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111290 ] Joakim Erdfelt commented on MRM-564: A fix has been committed to archiva/trunk revision 587908. A review of the message text would be useful now. > Audit log is not populated when artifacts are deployed > -- > > Key: MRM-564 > URL: http://jira.codehaus.org/browse/MRM-564 > Project: Archiva > Issue Type: Improvement >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > > The audit.log file should contain an entry when any of the following events > occurs: create directory, remove directory, create file, modify file, remove > file. > After a release, the audit.log file only contained: > 2007-09-13 19:27:55 - Logging Initialized. > There are no other audit log files. (I would have expected to see some with > dates in the filename, the others are configured to roll on a daily basis.) > (Needs to be verified with 1.0-beta-3 or later.) -- 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-565) Archiva 1.0-beta-3 fails in 404 on all legacy request.
[ http://jira.codehaus.org/browse/MRM-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-565. -- Resolution: Fixed Fixed in archiva/trunk revision 587710. > Archiva 1.0-beta-3 fails in 404 on all legacy request. > -- > > Key: MRM-565 > URL: http://jira.codehaus.org/browse/MRM-565 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-beta-3 >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > Archiva 1.0-beta-3 fails in 404 on all legacy request. > example : > http://localhost:8080/archiva/repository/internal/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar > returns the expected jar > http://localhost:8080/archiva/repository/internal/javax.servlet/jars/servlet-api-2.3.jar > -> 404. -- 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-554) Wrong generated links at root of repository browsing
[ http://jira.codehaus.org/browse/MRM-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-554. -- Assignee: Joakim Erdfelt Resolution: Duplicate Fix Version/s: (was: 1.x) 1.0-beta-4 Closing: Duplicate of MRM-440 > Wrong generated links at root of repository browsing > > > Key: MRM-554 > URL: http://jira.codehaus.org/browse/MRM-554 > Project: Archiva > Issue Type: Bug > Components: browser >Affects Versions: 1.0-beta-2 >Reporter: Kristof Jozsa >Assignee: Joakim Erdfelt >Priority: Trivial > Fix For: 1.0-beta-4 > > > Browsing "http://localhost:9000/archiva/repository/internal"; (with no > trailing slash!) all the links try to lead to /archiva/repository/ > missing the repo name 'internal'. It does not happen browsing > "http://localhost:9000/archiva/repository/internal/"; though (with the > trailing slash). -- 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-142) project builder cache needs to be configurable to prevent memory leaking
[ http://jira.codehaus.org/browse/MRM-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-142. -- Assignee: Joakim Erdfelt Resolution: Fixed Fix Version/s: (was: Future) 1.0-beta-4 Fixed by removing maven/components from process, this is no longer an issue. > project builder cache needs to be configurable to prevent memory leaking > > > Key: MRM-142 > URL: http://jira.codehaus.org/browse/MRM-142 > Project: Archiva > Issue Type: Bug > Components: indexing >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > Original Estimate: 1 hour > Time Spent: 30 minutes > Remaining Estimate: 30 minutes > > need to investigate if there is a memory leak, since the server received an > OOME some time after successfully completing a full index with 1Gb heap with > just some browsing/searching. It is most likely in the indexing itself, but > there may be some in the browse/search interface too -- 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-567) Unable to download plugin SNAPSHOT's from proxy.
Unable to download plugin SNAPSHOT's from proxy.
Key: MRM-567
URL: http://jira.codehaus.org/browse/MRM-567
Project: Archiva
Issue Type: Bug
Components: remote proxy
Affects Versions: 1.0-beta-3
Reporter: Joakim Erdfelt
Reported in IRC.
{noformat}
Hi all
is there someone who tried to test to proxy a repository with plugins
snapshots
like people.apache.org/maven2
with the last beta
I'm not sure but I think I have an issue
Arnaud: I'll try cleaning my local repo and see
Arnaud: havent had time to test yet :(
get in line :)
;-)
I put archiva in debug
I can get those plugins
org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
There were a host of plugin related fixed commit'd yesterday.
not sure your issue is related tho.
in proxy connectors I have :
cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
Arnaud, what's the remote repo url?
http://people.apache.org/repo/m2-snapshot-repository
lemme file the ticket.
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-440) If webdav URL lacks a trailing /, navigating to all links in the listing return 404.
[ http://jira.codehaus.org/browse/MRM-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-440: --- Fix Version/s: (was: 1.x) 1.0-beta-4 > If webdav URL lacks a trailing /, navigating to all links in the listing > return 404. > > > Key: MRM-440 > URL: http://jira.codehaus.org/browse/MRM-440 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0-beta-4 > > > If you go to: > http://localhost:8080/archiva/repository/releases > then click a link, you get 404. > But if you go to: > http://localhost:8080/archiva/repository/releases/ > everything works as expected. -- 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-492) repository failures can present as a 404 from proxy
[ http://jira.codehaus.org/browse/MRM-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-492. -- Assignee: Joakim Erdfelt Resolution: Cannot Reproduce Cannot reproduce in archiva/trunk. I suspect the changes around MRM-563 fixed this. Reopen if it occurs again. > repository failures can present as a 404 from proxy > --- > > Key: MRM-492 > URL: http://jira.codehaus.org/browse/MRM-492 > Project: Archiva > Issue Type: Improvement > Components: remote proxy >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > if multiple repositories are a proxy source and it is not found on some, and > an error occurs on one or more - the end result is a "not found", where there > should be some indication of error in case the artifact may exist on the > repository with the 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: (MRM-561) Error 500 while deleting a proxy connector
[
http://jira.codehaus.org/browse/MRM-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-561.
--
Resolution: Fixed
Fixed in archiva/trunk revision 587351.
> Error 500 while deleting a proxy connector
> --
>
> Key: MRM-561
> URL: http://jira.codehaus.org/browse/MRM-561
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: Linux, JDK 6
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> This error occurs when I try to remove the default proxy connector for
> maven2-repository.dev.java.net
> Web :
> {code}
> HTTP ERROR: 500
> Neither confirm() nor doConfirm() is found in action class
> org.apache.maven.archiva.web.action.admin.connectors.proxy.DeleteProxyConnectorAction
> RequestURI=/archiva/admin/deleteProxyConnector!confirm.action
> {code}
> Log :
> {code}
> INFO | jvm 1| 2007/10/22 12:17:40 | WARNING:
> /archiva/admin/deleteProxyConnector!confirm.action?source=internal&target=maven2-repository.dev.java.net:
> INFO | jvm 1| 2007/10/22 12:17:40 | java.lang.IllegalArgumentException:
> Neither confirm() nor doConfirm() is found in action class
> org.apache.maven.arch
> iva.web.action.admin.connectors.proxy.DeleteProxyConnectorAction
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:360)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:1
> 75)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:5
> 3)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInter
> ceptor.java:118)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.jav
> a:159)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:124
> )
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:1
> 75)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 |
[jira] Closed: (MRM-313) archiva fails to serve maven2 plugin from legacy repository
[ http://jira.codehaus.org/browse/MRM-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-313. -- Resolution: Fixed Fix Version/s: (was: 1.x) 1.0-beta-4 Fixed in archiva/trunk as a result of work done in MRM-557, MRM-562, MRM-563 > archiva fails to serve maven2 plugin from legacy repository > --- > > Key: MRM-313 > URL: http://jira.codehaus.org/browse/MRM-313 > Project: Archiva > Issue Type: Improvement > Components: remote proxy >Affects Versions: 1.0-alpha-1 >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-4 > > > Archiva is configured to proxy http://dist.codehaus.org/ (legacy layout) > the xdoclet2 maven2 plugin is deployed under /xdoclet/maven-plugins. This > looks right as the type is set to "maven-plugin". > trying to download > http://archiva/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar > fails > archiva has no info from the specified URL about trying to get a maven-plugin > ! > http://archiva/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-plugin > works as expected. > 2 options (suggestions are wecome) : > - use a "-plugin" pattern that a plugin is required (just a hack, and > requires all plugin to follow this convention) > - read the requested artifact POM to get the artifact type. -- 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-557) repair or remove commented out test cases in proxy module
[ http://jira.codehaus.org/browse/MRM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-557. -- Resolution: Fixed Fixed with work in MRM-563 > repair or remove commented out test cases in proxy module > -- > > Key: MRM-557 > URL: http://jira.codehaus.org/browse/MRM-557 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > commit r583412 commented out two test cases: > archiva-base/archiva-proxy/src/test/java/org/apache/maven/archiva/proxy/ManagedDefaultTransferTest.java:392: > /* FIXME > archiva-base/archiva-proxy/src/test/java/org/apache/maven/archiva/proxy/ManagedLegacyTransferTest.java:129: > /* FIXME > The tests are broken if uncommented - we need to check why they were > commented out, and either fix the code, fix the tests, or remove them if they > are no longer valid. -- 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-563) Proxy connector logic for getIfModified is backwards.
[ http://jira.codehaus.org/browse/MRM-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-563. -- Resolution: Fixed Fixed in archiva/trunk revision 587318. > Proxy connector logic for getIfModified is backwards. > - > > Key: MRM-563 > URL: http://jira.codehaus.org/browse/MRM-563 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The logic for fetching content that exists locally, and remotely, but hasn't > changed remotely is backwards. > All fetches for new content results in a .getIfNewer() with a modified > timestamp of 0. > And all fetches for existing content results in .get() request. -- 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: (MRM-563) Proxy connector logic for getIfModified is backwards.
[ http://jira.codehaus.org/browse/MRM-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-563: --- Priority: Critical (was: Major) Fix Version/s: 1.0-beta-4 > Proxy connector logic for getIfModified is backwards. > - > > Key: MRM-563 > URL: http://jira.codehaus.org/browse/MRM-563 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The logic for fetching content that exists locally, and remotely, but hasn't > changed remotely is backwards. > All fetches for new content results in a .getIfNewer() with a modified > timestamp of 0. > And all fetches for existing content results in .get() request. -- 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-563) Proxy connector logic for getIfModified is backwards.
Proxy connector logic for getIfModified is backwards. - Key: MRM-563 URL: http://jira.codehaus.org/browse/MRM-563 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-3 Reporter: Joakim Erdfelt Fix For: 1.0-beta-4 The logic for fetching content that exists locally, and remotely, but hasn't changed remotely is backwards. All fetches for new content results in a .getIfNewer() with a modified timestamp of 0. And all fetches for existing content results in .get() request. -- 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-562) Artifact type "maven-plugin" is not detected correctly in .toArtifactReference() methods.
[ http://jira.codehaus.org/browse/MRM-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-562. -- Resolution: Fixed Fixed in archiva/trunk revision 587224. > Artifact type "maven-plugin" is not detected correctly in > .toArtifactReference() methods. > - > > Key: MRM-562 > URL: http://jira.codehaus.org/browse/MRM-562 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > When working from a path to an ArtifactReference, the 'maven-plugin' type is > not detected correctly. -- 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: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110859
]
Joakim Erdfelt commented on MRM-560:
Can you provide us with the project that you attempted to get the dep tree on
when this occured?
For now, I'll fix this to not flow the exception back to the user, but I'm
curious as to why the graph is null.
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:124)
>
> com.opensym
[jira] Updated: (MRM-561) Error 500 while deleting a proxy connector
[
http://jira.codehaus.org/browse/MRM-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-561:
---
Priority: Blocker (was: Major)
> Error 500 while deleting a proxy connector
> --
>
> Key: MRM-561
> URL: http://jira.codehaus.org/browse/MRM-561
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: Linux, JDK 6
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> This error occurs when I try to remove the default proxy connector for
> maven2-repository.dev.java.net
> Web :
> {code}
> HTTP ERROR: 500
> Neither confirm() nor doConfirm() is found in action class
> org.apache.maven.archiva.web.action.admin.connectors.proxy.DeleteProxyConnectorAction
> RequestURI=/archiva/admin/deleteProxyConnector!confirm.action
> {code}
> Log :
> {code}
> INFO | jvm 1| 2007/10/22 12:17:40 | WARNING:
> /archiva/admin/deleteProxyConnector!confirm.action?source=internal&target=maven2-repository.dev.java.net:
> INFO | jvm 1| 2007/10/22 12:17:40 | java.lang.IllegalArgumentException:
> Neither confirm() nor doConfirm() is found in action class
> org.apache.maven.arch
> iva.web.action.admin.connectors.proxy.DeleteProxyConnectorAction
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:360)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:1
> 75)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:5
> 3)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInter
> ceptor.java:118)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.jav
> a:159)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:124
> )
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:1
> 75)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> INFO | jvm 1| 2007/10/22 12:17:40 | at
> com.opensympho
[jira] Updated: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-560:
---
Priority: Blocker (was: Major)
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInterceptor.java:124)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
[jira] Updated: (MRM-562) Artifact type "maven-plugin" is not detected correctly in .toArtifactReference() methods.
[ http://jira.codehaus.org/browse/MRM-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-562: --- Fix Version/s: 1.0-beta-4 > Artifact type "maven-plugin" is not detected correctly in > .toArtifactReference() methods. > - > > Key: MRM-562 > URL: http://jira.codehaus.org/browse/MRM-562 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > > When working from a path to an ArtifactReference, the 'maven-plugin' type is > not detected correctly. -- 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-562) Artifact type "maven-plugin" is not detected correctly in .toArtifactReference() methods.
Artifact type "maven-plugin" is not detected correctly in .toArtifactReference() methods. - Key: MRM-562 URL: http://jira.codehaus.org/browse/MRM-562 Project: Archiva Issue Type: Bug Components: repository interface Affects Versions: 1.0-beta-3 Reporter: Joakim Erdfelt When working from a path to an ArtifactReference, the 'maven-plugin' type is not detected correctly. -- 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: (MRM-552) Download link should be entitled "Plugin", not "Jar" for maven plugins
[ http://jira.codehaus.org/browse/MRM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110297 ] Joakim Erdfelt edited comment on MRM-552 at 10/19/07 11:09 PM: --- Current: The download link works off of the filename. The filename does not contain enough information to glean the proper type. Possible: Using "maven-.\*-plugin" or ".\*-maven-plugin" as an identification string is possible. was: Current: The download link works off of the filename. The filename does not contain enough information to glean the proper type. Possible: Using maven-.*-plugin or .*-maven-plugin as an identification string is possible. > Download link should be entitled "Plugin", not "Jar" for maven plugins > -- > > Key: MRM-552 > URL: http://jira.codehaus.org/browse/MRM-552 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter > Fix For: 1.x > > -- 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-520) Proxy Connectors are not deleted with the deletion of a Repository.
[ http://jira.codehaus.org/browse/MRM-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-520. -- Resolution: Fixed Commit'd to archiva/trunk revision 586635. > Proxy Connectors are not deleted with the deletion of a Repository. > --- > > Key: MRM-520 > URL: http://jira.codehaus.org/browse/MRM-520 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > When you delete a repository (managed or remote) if there is a proxy > connector established for that former repository, then the proxy connector > itself remains. > Desired Outcome: > # When you delete a repository, associated Proxy Connectors should be deleted > too. > # If a proxy connector is going to be deleted, this should also be outlined > in the delete confirmation screens. -- 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-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-398. -- Resolution: Fixed Fixed in trunk revision 586622. Tested with pristine environment. > configure guest access by default for pre-configured repositories > - > > Key: MRM-398 > URL: http://jira.codehaus.org/browse/MRM-398 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > I think it makes sense for repositories to be readable by guests by default > for a good OOTB experience. -- 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: (MRM-548) proxy connectors: default policies are not correct on add
[ http://jira.codehaus.org/browse/MRM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110351 ] Joakim Erdfelt commented on MRM-548: I think you might be mis-interpreting the policy settings. See http://docs.codehaus.org/display/MAVENUSER/Archiva+Proxy+Policies > proxy connectors: default policies are not correct on add > - > > Key: MRM-548 > URL: http://jira.codehaus.org/browse/MRM-548 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter > > the default for snapshots and releases is "ignored" for updates. This is > inconsistent with Maven default behaviour - should it be daily? -- 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: (MRM-549) proxy connectors: no "always" option for releases and snapshots policies
[ http://jira.codehaus.org/browse/MRM-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110350 ] Joakim Erdfelt commented on MRM-549: I think you might be mis-interpreting the policy settings. See http://docs.codehaus.org/display/MAVENUSER/Archiva+Proxy+Policies > proxy connectors: no "always" option for releases and snapshots policies > > > Key: MRM-549 > URL: http://jira.codehaus.org/browse/MRM-549 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: 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] Commented: (MRM-549) proxy connectors: no "always" option for releases and snapshots policies
[ http://jira.codehaus.org/browse/MRM-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110343 ] Joakim Erdfelt commented on MRM-549: The option for 'ignore' is the same thing. This kinda falls into line with the on-screen instructions and details that I started to outline in MRM-366. > proxy connectors: no "always" option for releases and snapshots policies > > > Key: MRM-549 > URL: http://jira.codehaus.org/browse/MRM-549 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: 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] Commented: (MRM-552) Download link should be entitled "Plugin", not "Jar" for maven plugins
[ http://jira.codehaus.org/browse/MRM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110297 ] Joakim Erdfelt commented on MRM-552: Current: The download link works off of the filename. The filename does not contain enough information to glean the proper type. Possible: Using maven-.*-plugin or .*-maven-plugin as an identification string is possible. > Download link should be entitled "Plugin", not "Jar" for maven plugins > -- > > Key: MRM-552 > URL: http://jira.codehaus.org/browse/MRM-552 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: 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] Commented: (MRM-523) Appearance Actions do not work when ${user.home} is invalid.
[
http://jira.codehaus.org/browse/MRM-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110243
]
Joakim Erdfelt commented on MRM-523:
The creation of $HOME/.m2/archiva is a result of reliance on the maven core
components, and should be filed as a separate bug.
This wasn't filed as critical, just major.
If someone decides to enter the appearance screens, as they are now, that whole
process fails.
Once the appearance screens have been activated, then the logs fill up
ridiculously fast with the exceptions, all tracked down to the appearance /
logo logic attempting to resolve content, on every access to every screen in
the application.
This is a severe problem.
We must address it.
Maybe not for the next pre-1.0 release, but definitely before 1.0 final.
> Appearance Actions do not work when ${user.home} is invalid.
>
>
> Key: MRM-523
> URL: http://jira.codehaus.org/browse/MRM-523
> Project: Archiva
> Issue Type: Bug
> Components: system
>Affects Versions: 1.0-beta-2
>Reporter: Joakim Erdfelt
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 1.x
>
>
> The reliance on maven core components with regards to Appearance / Company
> Info / Edit Pom actions, prevents server installations without a valid user
> $HOME directory. ( such as /dev/null )
> We should migrate away from maven core components at our earliest opportunity.
--
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: (MRM-546) Duplicate repositories show up while editing.
[
http://jira.codehaus.org/browse/MRM-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110241
]
Joakim Erdfelt commented on MRM-546:
It comes up often enough, I've seen it, others have seen it.
It's a bug. I filed it.
Copy/Paste from IRC this morning ...
{noformat}
I have a strange problem
all my snapshot are duplicated when I edit one
all my repositories are duplicated when I edit one
[ forget the snapshot line ]
Topic " forget the snapshot line " does not exist
I mean, in my repositories page, I have each repository repeated 3
times ATM
If I edit one, I'll get every repository repeated 4 times right after
eskatos: what version?
1.0-beta2
a workaround is to just edit archiva.xml and don't use the web ui
I'm building the latest to check it, though joakim may be faster...
eskatos, that's a but that i've been trying to get brett to fix. :-)
eskatos, do this for a workaround. go into your $HOME/.m2/archiva.xml
and remove the element and all content under it.
s/that's a but/that's a bug/
not a butt either
ok thanks, I'll try this
is it in JIRA? doesn't sound familiar.
Can't find it.
eskatos: can you (search and) open an issue for that problem?
I'm opening it.
nice
not something I've seen it do myself. but not surprising given the
other things it's done. :)
I won't try the workaround now, don't have much time today
MRM-546
{noformat}
> Duplicate repositories show up while editing.
> -
>
> Key: MRM-546
> URL: http://jira.codehaus.org/browse/MRM-546
> Project: Archiva
> Issue Type: Bug
> Components: system
>Affects Versions: 1.0-beta-2
>Reporter: Joakim Erdfelt
>Assignee: Brett Porter
>Priority: Critical
>
> Environment: Using a pre 1.0-beta-2 archiva install that has been upgraded to
> 1.0-beta-2.
> Situation: When editing the repositories, the repositories get duplicated.
> This is likely due to the fact that the configuration "upgrade" technique
> from to and is not
> removing the section properly..
> Several efforts in the code have been made to correct this, but with no
> success. See revision 583903 in archiva/trunk for details.
--
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-546) Duplicate repositories show up while editing.
Duplicate repositories show up while editing. - Key: MRM-546 URL: http://jira.codehaus.org/browse/MRM-546 Project: Archiva Issue Type: Bug Components: system Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Critical Environment: Using a pre 1.0-beta-2 archiva install that has been upgraded to 1.0-beta-2. Situation: When editing the repositories, the repositories get duplicated. This is likely due to the fact that the configuration "upgrade" technique from to and is not removing the section properly.. Several efforts in the code have been made to correct this, but with no success. See revision 583903 in archiva/trunk for details. -- 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: (MRM-523) Appearance Actions do not work when ${user.home} is invalid.
[
http://jira.codehaus.org/browse/MRM-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110179
]
Joakim Erdfelt commented on MRM-523:
Actually, no.
We have mitigated all other ${user.home} situations.
And we have 2 known users now that run Archiva on a Unix environment with a
homeless user (a common security practice).
> Appearance Actions do not work when ${user.home} is invalid.
>
>
> Key: MRM-523
> URL: http://jira.codehaus.org/browse/MRM-523
> Project: Archiva
> Issue Type: Bug
> Components: system
>Affects Versions: 1.0-beta-2
>Reporter: Joakim Erdfelt
>Assignee: Brett Porter
>Priority: Minor
> Fix For: 1.x
>
>
> The reliance on maven core components with regards to Appearance / Company
> Info / Edit Pom actions, prevents server installations without a valid user
> $HOME directory. ( such as /dev/null )
> We should migrate away from maven core components at our earliest opportunity.
--
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-535) metadata-updater is changing lastUpdating timestamp when it shouldn't
[ http://jira.codehaus.org/browse/MRM-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-535. -- Resolution: Fixed Fixed in archiva/trunk revision 584994. > metadata-updater is changing lastUpdating timestamp when it shouldn't > - > > Key: MRM-535 > URL: http://jira.codehaus.org/browse/MRM-535 > Project: Archiva > Issue Type: Bug > Components: repository scanning > Environment: JDK 1.5.0_11, Maven 2.0.7 >Reporter: ajbanck >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-3 > > > This is a bit of a trivial 'bug' and the result is not harmfull, but I think > the metadata-updater should not change data that is valid. > As far as I could find the lastUpdated field is the timestamp on which the > metadata was last updated, so should not be touched in this case. > During scanning, some (~200) maven-metadata.xml files are updated in my > repository . > The metadata being updated is: > > com.informatica.profiling.services > profiling-model-persist > 1.0-SNAPSHOT > > > 20070213.050129 > 79 > > 20070213050130 > > > After update the lastUpdated field is changed to 20070213050129: > 20070213050129 > As far as I could find the lastUpdated field is the timestamp on which the > metadata was last updated, so should not be touched in this case. > Scanlog: > 2007-10-05 14:38:41,043 [pool-2-thread-1] DEBUG > org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - > Sending to consumer: metadata-updater > 2007-10-05 14:38:41,090 [pool-2-thread-1] INFO > org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater > - Updated metadata: > com/xxx/profiling/services/profiling-model-persist/1.0-SNAPSHOT/maven-metadata.xml > 2007-10-05 14:38:46,356 [pool-2-thread-1] INFO > org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater > - Updated metadata: > com/xxx/profiling/services/profiling-model-persist/maven-metadata.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] Closed: (MRM-543) Versions (latest and release) wrong after regeneration of maven-metadata.xml
[
http://jira.codehaus.org/browse/MRM-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-543.
--
Resolution: Fixed
This was recently fixed in archiva/trunk revision 583412.
> Versions (latest and release) wrong after regeneration of maven-metadata.xml
>
>
> Key: MRM-543
> URL: http://jira.codehaus.org/browse/MRM-543
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0-beta-2
> Environment: Debian GNU/Linux, Apache Tomcat 6.0.14, Archiva
> 1.0-beta-2, SUN JVM 1.5.0_12
>Reporter: Duncan Doyle
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 1.0-beta-3
>
>
> Hello,
> I've setup an Archiva server (1.0-beta-2) on a Debian Linux machine (Tomcat
> 6.0.14, Sun JVM 1.5.0_12). I have a managed local repository
> ("internal-central") which is connected via a proxy connector to the central
> repository. I have another managed local repository ("release") for my own
> development and deployment. I've created a Maven2 plugin (to deal with our CA
> Harvest SCM system) which I deploy to the "release" repository. The generated
> maven-metadata.xml file looks as follows:
>
> org.test.maven.plugins
> maven-harvest-plugin
> 1.0
>
> 1.0
> 1.0
>
> 1.0
>
> 20071009112946
>
>
> When I then use a client to retrieve the pluging (by calling the 'mvn
> harvest:update' mojo), I get the following error:
> "The plugin 'org.test.maven.plugins:maven-harvest-plugin' does not exist or
> no valid version could be found"
> When I look at the 'maven-metadata.xml' file in the repository it contains
> this:
>
>
> org.test.maven.plugins
> maven-harvest-plugin
>
>
> 1.0
>
>
>
> For some reason, Archiva has regenerated the 'maven-metadata.xml ' file,
> removing the 'latest','release' and 'lastUpdated' version information. This,
> as far as I know, results in the 'no valid version could be found' error.
> I've seen this behaviour also on the proxied repository ("internal-central").
> For example when proxying spring jars, I notice that the 'latest' and
> 'release' version information, which is present in the metadata files at '
> repo1.maven.org', are not present in the local central repository.
> The regeneration seems to happen even when the 'metadata-updater' consumer is
> switched off (it doesn't update the metadata when scanning the repository
> when it is switched off, but the metadata is regenerated when a client tries
> to download the plugin).
> The workaround for my problem is to specify the exact version of the plugin
> to be used in my pom.xml, which is something I don't want because the plugin
> is under heavy development. I also don't seem to understand why Archiva
> should even regenerate the 'maven-metadata.xml' files.
--
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: (MRM-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110011 ] Joakim Erdfelt edited comment on MRM-459 at 10/15/07 5:12 PM: -- * xml-apis contains an updated set of apis (newer than provided in JDK 1.5) needed by various xml transformation providers. * velocity-dep sounds like a good candidate. * Removing clogging-api and slf4j-simple sounds reasonable. * jtidy is part of wagon-http and is required. * as for jca lib alternatives, can't find a legit one using local archiva's FTS/lucene of ibiblio mirror. * maven libs are currently used by the appearance libs. (I want to simplify them!) was: *xml-apis contains an updated set of apis (newer than provided in JDK 1.5) needed by various xml transformation providers. *velocity-dep sounds like a good candidate. *Removing clogging-api and slf4j-simple sounds reasonable. * jtidy is part of wagon-http and is required. * as for jca lib alternatives, can't find a legit one using local archiva's FTS/lucene of ibiblio mirror. * maven libs are currently used by the appearance libs. (I want to simplify them!) > prune the distributed dependencies > -- > > Key: MRM-459 > URL: http://jira.codehaus.org/browse/MRM-459 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > a large number of unneeded dependencies are distributed with Archiva (or if > they are needed, we might want to review why). > For example: ant-optional (probably for jsp compiler), commons-logging impl + > slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we > have geronimo-jat already), classworlds (we have plexus-classworlds already), > backport (we require JDK 5, no need for this). > I'm also uncertain if all the maven libraries are still needed. -- 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: (MRM-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110011 ] Joakim Erdfelt commented on MRM-459: *xml-apis contains an updated set of apis (newer than provided in JDK 1.5) needed by various xml transformation providers. *velocity-dep sounds like a good candidate. *Removing clogging-api and slf4j-simple sounds reasonable. * jtidy is part of wagon-http and is required. * as for jca lib alternatives, can't find a legit one using local archiva's FTS/lucene of ibiblio mirror. * maven libs are currently used by the appearance libs. (I want to simplify them!) > prune the distributed dependencies > -- > > Key: MRM-459 > URL: http://jira.codehaus.org/browse/MRM-459 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > a large number of unneeded dependencies are distributed with Archiva (or if > they are needed, we might want to review why). > For example: ant-optional (probably for jsp compiler), commons-logging impl + > slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we > have geronimo-jat already), classworlds (we have plexus-classworlds already), > backport (we require JDK 5, no need for this). > I'm also uncertain if all the maven libraries are still needed. -- 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-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-398. -- Resolution: Fixed Partial revert of previous solution. (The part that sets all new repositories to have guest access read-only) Different solution commit'd to archiva/trunk revision 584906. > configure guest access by default for pre-configured repositories > - > > Key: MRM-398 > URL: http://jira.codehaus.org/browse/MRM-398 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > I think it makes sense for repositories to be readable by guests by default > for a good OOTB experience. -- 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: (MRM-535) metadata-updater is changing lastUpdating timestamp when it shouldn't
[ http://jira.codehaus.org/browse/MRM-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109806 ] Joakim Erdfelt commented on MRM-535: It needs to keep up that field to date. But going backwards on the lastUpdated field is just bad. What is being implemented and tested on archiva/trunk right now. (project view is working, version view is not, yet) * Never decrease the value of the lastUpdated field. Technique 1) Read the existing metadata's lastUpdated timestamp (if it exists) 2) Iterate through the artifacts on the managed repository for their timestamps. (filename or file last modified date/time). 3) Iterate through the proxy metadata files for their lastUpdated. 4) Use the highest value found. > metadata-updater is changing lastUpdating timestamp when it shouldn't > - > > Key: MRM-535 > URL: http://jira.codehaus.org/browse/MRM-535 > Project: Archiva > Issue Type: Bug > Components: repository scanning > Environment: JDK 1.5.0_11, Maven 2.0.7 >Reporter: ajbanck >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-3 > > > This is a bit of a trivial 'bug' and the result is not harmfull, but I think > the metadata-updater should not change data that is valid. > As far as I could find the lastUpdated field is the timestamp on which the > metadata was last updated, so should not be touched in this case. > During scanning, some (~200) maven-metadata.xml files are updated in my > repository . > The metadata being updated is: > > com.informatica.profiling.services > profiling-model-persist > 1.0-SNAPSHOT > > > 20070213.050129 > 79 > > 20070213050130 > > > After update the lastUpdated field is changed to 20070213050129: > 20070213050129 > As far as I could find the lastUpdated field is the timestamp on which the > metadata was last updated, so should not be touched in this case. > Scanlog: > 2007-10-05 14:38:41,043 [pool-2-thread-1] DEBUG > org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - > Sending to consumer: metadata-updater > 2007-10-05 14:38:41,090 [pool-2-thread-1] INFO > org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater > - Updated metadata: > com/xxx/profiling/services/profiling-model-persist/1.0-SNAPSHOT/maven-metadata.xml > 2007-10-05 14:38:46,356 [pool-2-thread-1] INFO > org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater > - Updated metadata: > com/xxx/profiling/services/profiling-model-persist/maven-metadata.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] Closed: (MRM-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-398. -- Resolution: Fixed Fixed in archiva/trunk revision Newly created repositories are setup to be automatically assigned to the guest user in read-only mode. There are no provisions in redback to assign roles on first startup only. Using redback ALONE to automatically assign the read-only role to the shipped repositories is not possible. Closing issue. We can't hard-code the repository ids either, as corporate installations of archiva will often pre-configure their archiva.xml before starting the first time. Created a new jira MRM-539 for alternative approach that was poo-poo'd in an earlier comment by brett in this jira. > configure guest access by default for pre-configured repositories > - > > Key: MRM-398 > URL: http://jira.codehaus.org/browse/MRM-398 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > I think it makes sense for repositories to be readable by guests by default > for a good OOTB experience. -- 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
