[jira] Commented: (MRM-773) Improve RSS feed generation
[ http://jira.codehaus.org/browse/MRM-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130833#action_130833 ] Maria Odea Ching commented on MRM-773: -- Also, clicking the rss feed icon in the repositories page results to a 404 error if the rss feed file does not exist yet. > Improve RSS feed generation > --- > > Key: MRM-773 > URL: http://jira.codehaus.org/browse/MRM-773 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.1 > > > - add check to control file size of generated RSS feeds > - make sure that the when the client requests the RSS, it gets the right > headers to not try and update it if it hasn't changed for performance > - get the urls of the feeds from the rss feed request > More info in: > http://www.nabble.com/Re%3A-svn-commit%3A-r645833---in--archiva-trunk%3A-archiva-jetty-src-main-conf-jetty.xml-archiva-modules-archiva-web-archiva-rss-src-main-java-org-apache-archiva-rss-processor-NewArtifactsRssFeedProcessor.java-td16562163.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-781) Removal of Archiva-Webdav implementation in favor of Jackrabbit-webdav
Removal of Archiva-Webdav implementation in favor of Jackrabbit-webdav -- Key: MRM-781 URL: http://jira.codehaus.org/browse/MRM-781 Project: Archiva Issue Type: Improvement Components: WebDAV interface Affects Versions: 1.1 Reporter: James William Dumay Attachments: archiva-jackrabbit-webdav.patch This patch removes plexus-webdav in favor of Jackrabbit's webdav servlet implementation. It is not yet 100% completed and tested. HTTP GET and PUT should work correctly. The following needs to happen before integration: 1) New Jackrabbit classes need to be correctly unit tested. 2) Webdav properties need to be implemented 3) Testing of common webdav clients - Mac OS X, Windows, Wagon-Dav, etc -- 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-778) DefaultDavServerManager.createServer doesn't create server
[
http://jira.codehaus.org/browse/MRM-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130826#action_130826
]
carloscs edited comment on MRM-778 at 4/14/08 8:05 PM:
---
Patch follows for this issue.
application.xml: remove injection of DavServerComponent to DavServerManager.
DavServerManager.createServer: add parameter ServletConfig config .
DefaultDavServerManager.createServer: add parameter ServletConfig config and
fetch server from spring.
BasicWebDavServlet and MultiplexedWebDavServlet add config parameter to
createServer call.
was (Author: carloscs):
Patch follows for this issue.
application.xml: remove injection of DavServerComponent to DavServerManager.
DavServerManager.createServer: add parameter ServletConfig config .
DefaultDavServerManager.createSerber: add parameter ServletConfig config and
fetch server from spring.
BasicWebDavServlet and MultiplexedWebDavServlet add config parameter to
createServer call.
> DefaultDavServerManager.createServer doesn't create server
> --
>
> Key: MRM-778
> URL: http://jira.codehaus.org/browse/MRM-778
> Project: Archiva
> Issue Type: Bug
> Components: WebDAV interface
>Affects Versions: 1.1
>Reporter: Carlos Costa e Silva
>Priority: Blocker
> Attachments: ServerManager.zip
>
>
> In DefaultDavServerManager, the createServer method instead of creating a new
> server each time it's called is reusing the same server for all paths.
> The "DavServerComponent server" needs to be created each time createServer is
> called instead of being injected by plexus when the DavServerManager is
> created.
> This bug makes multiple repositories with different settings not work.
> For example "internal" has snapshots disabled, while "snapshots" has
> snapshots enabled. When a request comes for the snapshots repository, webdav
> is using the metadata for the "internal" server which has snapshots disabled
> and refuses to download snapshots.
> It's possible that if it downloaded snapshots they would be put on the wrong
> repository ("internal"), but I haven't verified 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] Commented: (MRM-778) DefaultDavServerManager.createServer doesn't create server
[
http://jira.codehaus.org/browse/MRM-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130826#action_130826
]
Carlos Costa e Silva commented on MRM-778:
--
Patch follows for this issue.
application.xml: remove injection of DavServerComponent to DavServerManager.
DavServerManager.createServer: add parameter ServletConfig config .
DefaultDavServerManager.createSerber: add parameter ServletConfig config and
fetch server from spring.
BasicWebDavServlet and MultiplexedWebDavServlet add config parameter to
createServer call.
> DefaultDavServerManager.createServer doesn't create server
> --
>
> Key: MRM-778
> URL: http://jira.codehaus.org/browse/MRM-778
> Project: Archiva
> Issue Type: Bug
> Components: WebDAV interface
>Affects Versions: 1.1
>Reporter: Carlos Costa e Silva
>Priority: Blocker
> Attachments: ServerManager.zip
>
>
> In DefaultDavServerManager, the createServer method instead of creating a new
> server each time it's called is reusing the same server for all paths.
> The "DavServerComponent server" needs to be created each time createServer is
> called instead of being injected by plexus when the DavServerManager is
> created.
> This bug makes multiple repositories with different settings not work.
> For example "internal" has snapshots disabled, while "snapshots" has
> snapshots enabled. When a request comes for the snapshots repository, webdav
> is using the metadata for the "internal" server which has snapshots disabled
> and refuses to download snapshots.
> It's possible that if it downloaded snapshots they would be put on the wrong
> repository ("internal"), but I haven't verified 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] Updated: (MRM-778) DefaultDavServerManager.createServer doesn't create server
[
http://jira.codehaus.org/browse/MRM-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Costa e Silva updated MRM-778:
-
Attachment: ServerManager.zip
Patch v 1.0 for this issue.
> DefaultDavServerManager.createServer doesn't create server
> --
>
> Key: MRM-778
> URL: http://jira.codehaus.org/browse/MRM-778
> Project: Archiva
> Issue Type: Bug
> Components: WebDAV interface
>Affects Versions: 1.1
>Reporter: Carlos Costa e Silva
>Priority: Blocker
> Attachments: ServerManager.zip
>
>
> In DefaultDavServerManager, the createServer method instead of creating a new
> server each time it's called is reusing the same server for all paths.
> The "DavServerComponent server" needs to be created each time createServer is
> called instead of being injected by plexus when the DavServerManager is
> created.
> This bug makes multiple repositories with different settings not work.
> For example "internal" has snapshots disabled, while "snapshots" has
> snapshots enabled. When a request comes for the snapshots repository, webdav
> is using the metadata for the "internal" server which has snapshots disabled
> and refuses to download snapshots.
> It's possible that if it downloaded snapshots they would be put on the wrong
> repository ("internal"), but I haven't verified 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] Commented: (MRM-701) Buggy documentation on "separating the base from the installation"
[ http://jira.codehaus.org/browse/MRM-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130724#action_130724 ] Doron Solomon commented on MRM-701: --- I too was able to get this working following the procedure above, although I didn't need to do step 4 since I'm using Archiva 1.0.2. However, in my opinion copying the conf directory could cause confusion for someone who is unsure which conf directory (the one in the installation or the one in $PLEXUS_BASE) is the "real" configuration. I would suggest instead one of the following two options. The first option would be to modify the procedure to say that only the xml files in conf/ should be moved to PLEXUS_BASE; the classworlds.conf file should remain with the installation. The second option would be to modify the path to classworlds.conf in all wrapper.conf files as well as the plexus.bat and plexus.sh files; the path should find classworlds.conf in $PLEXUS_BASE instead of $PLEXUS_HOME. I personally prefer this option since it makes a simpler manual process to separate the base from the installation. > Buggy documentation on "separating the base from the installation" > -- > > Key: MRM-701 > URL: http://jira.codehaus.org/browse/MRM-701 > Project: Archiva > Issue Type: Bug > Components: documentation >Affects Versions: 1.0.1 >Reporter: Martin Höller >Assignee: Brett Porter >Priority: Minor > Fix For: 1.0.2 > > > The documentation on > http://maven.apache.org/archiva/docs/1.0.1/adminguide/standalone.html says in > "Separating the base from the installation" > "2. Move the conf and data directories from the Archiva installation to the > new location." > But there is no "data" directory in a fresh installation. -- 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-780) Access to indexes files with a browser is not possible
Access to indexes files with a browser is not possible -- Key: MRM-780 URL: http://jira.codehaus.org/browse/MRM-780 Project: Archiva Issue Type: Bug Components: browser Affects Versions: 1.0.2 Environment: Linux, standalone bundle of archiva 1.0.2 (with jetty) Reporter: fabrice Priority: Critical http://tl-em-1.mycompany.local:8082/archiva/repository/internal/.index/filecontent/segments.gen Is translated by archiva into : http://tl-em-1.mycompany.local:8082/repository//.index/filecontent/segments.gen and display in my browser (firefox or IE) org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: legacy paths should have an expected type ending in [s] in the second part of the path. at org.apache.maven.archiva.repository.content.LegacyPathParser.toArtifactReference(LegacyPathParser.java:105) at org.apache.maven.archiva.repository.content.RepositoryRequest.toArtifactReference(RepositoryRequest.java:96) at org.apache.maven.archiva.repository.content.RepositoryRequest.toNativePath(RepositoryRequest.java:242) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:192) 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) So the .index folder seems to create some problems during the translation of url. It is a blocking bug for users who want use the search fonctionnality of m2eclipse because it uses the .index folder to download indexes datas. -- 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
