[jira] Created: (MRM-761) Exception when trying to retrieve a Maven 1 artifact of type zip
Exception when trying to retrieve a Maven 1 artifact of type zip Key: MRM-761 URL: http://jira.codehaus.org/browse/MRM-761 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Reporter: Ivan POPOV Through my browser, I try to access my artifact : the url is http://localhost:8080/archiva/repository/maven1/jdk/zips/jre-1.0.zip and the exception is Error 404 Not Found The following resource does not exist: http://localhost:8080/repository/jdk/distributions/jre-1.0.zip org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: mismatch on extension [zip] and layout specified type [distributions] (which maps to extension: [distribution]) on path [jdk/distributions/jre-1.0.zip] at org.apache.maven.archiva.repository.content.LegacyPathParser.toArtifactReference(LegacyPathParser.java:190) at org.apache.maven.archiva.repository.content.RepositoryRequest.toArtifactReference(RepositoryRequest.java:135) at org.apache.maven.archiva.repository.content.RepositoryRequest.toNativePath(RepositoryRequest.java:281) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:193) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) at org.apache.maven.archiva.web.repository.RepositoryServlet.service(RepositoryServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) The artifact has been correctly deployed on archiva and what is strange is that it tries to access jdk/distributions/jre-1.0.zip instead of jdk/zips/jre-1.0.zip If I install my artifact under le directory jdk/distributions, this don't solve the problem and if I try to retrieve the artifact with maven it fails 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-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129501#action_129501 ] Maria Odea Ching commented on MRM-123: -- Initial commit in -r643826. add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- 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-579) Restricted access to remote repositories
[ http://jira.codehaus.org/browse/MRM-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-579: - Fix Version/s: (was: 1.x) 1.1 Restricted access to remote repositories Key: MRM-579 URL: http://jira.codehaus.org/browse/MRM-579 Project: Archiva Issue Type: Wish Components: remote proxy, Users/Security Affects Versions: 1.0-beta-3 Reporter: Arne Degenring Fix For: 1.1 Originally discussed on http://www.nabble.com/Rights-management-for-Proxy-Connectors-tf4752902s177.html#a13590815 It should be possible to configure Archiva in a way, that access to repo1 through a proxy connector is available only for a few super users (= repository managers). In my scenario, normal users should only be able to access the artifacts available in the internal repository. In case they need a new artifact from repo1, they ask the repository manager to add it. The repository manager checks whether the artifact complies to e.g. company licensing rules, whether the metadata on repo1 is ok (which is mostly but not always the case), and so on. If everything is ok, he downloads the artifact including all dependencies. Afterwards the artifact should be available to everybody inside the company. Wendy Smoak and Brett Porter noticed that a permission on the remote repository probably would make most sense. -- 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-727) Archiva does not download plugin artifacts in Geronimo
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-727: - Fix Version/s: (was: 1.0.x) 1.0.2 Archiva does not download plugin artifacts in Geronimo -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea Ching Fix For: 1.0.2 Attachments: maven-resources-plugin-maven-metadata-central.xml, MRM-727-build-stack-trace.txt, MRM-727-geronimo-tomcat-log-0.0.0.0_access_log.2008-03-10.txt, MRM727.diff, settings-wrong.xml When i have an initially blank local maven repo and for example start maven with mvn clean, no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a normal artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-762) Footer doesn't stretch across repositoryScanning and database pages
Footer doesn't stretch across repositoryScanning and database pages --- Key: MRM-762 URL: http://jira.codehaus.org/browse/MRM-762 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0.1 Reporter: Doron Solomon Priority: Trivial The footer doesn't stretch all the way across the page for the repositoryScanning and database pages. This is because the footer DIV is being generated inside the contentBox DIV instead of outside of it. Upon inspecting the pages repositoryScanning.jsp and database.jsp (in WEB-INF/jsp/admin) I found that the DIV tag div id=contentArea is never closed at the end of the file, causing the observed behaviour. This can easily be fixed by simply adding a second /div before the closing body and html tags in both 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
