You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Aaron Digulla (JIRA)" <ji...@codehaus.org> on 2006/12/04 15:20:41 UTC
[jira] Created: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Mirror/Proxy functionality is broken in Archiva
-----------------------------------------------
Key: MRM-244
URL: http://jira.codehaus.org/browse/MRM-244
Project: Archiva
Issue Type: Bug
Components: remote proxy
Reporter: Aaron Digulla
Priority: Critical
Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
This approach has several drawbacks:
- Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
- Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
- In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
If the port number is != 80, you can add another level for the port.
This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Joakim Erdfelt (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joakim Erdfelt closed MRM-244.
------------------------------
Assignee: Joakim Erdfelt
Resolution: Fixed
Current archiva trunk supports the following.
* For every local/managed repository you can have 0...n remote repository sources. (This is called a Proxy Connector)
* For every Proxy Connector you have::
** A configurable set of pre-download policies. (to determine if the download via the Proxy Connector should even occur)
** A configurable set of post-download policies. (to determine if the already downloaded file should be passed onto the local/managed repository or not)
** A configurable list of whitelist patterns. (to specify which inclusive content is acceptable)
** A configurable list of blacklist patterns. (to specify which exclusive content is unacceptable to download)
This should address your concerns.
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Affects Versions: 1.0-alpha-1
> Reporter: Aaron Digulla
> Assignee: Joakim Erdfelt
> Priority: Critical
> Fix For: 1.0
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Joakim Erdfelt (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joakim Erdfelt updated MRM-244:
-------------------------------
Affects Version/s: 1.0-alpha-1
Fix Version/s: (was: 1.0)
1.0-alpha-1
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Affects Versions: 1.0-alpha-1
> Reporter: Aaron Digulla
> Assignee: Joakim Erdfelt
> Priority: Critical
> Fix For: 1.0-alpha-1
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=all ]
Brett Porter updated MRM-244:
-----------------------------
Fix Version/s: 1.0
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Reporter: Aaron Digulla
> Priority: Critical
> Fix For: 1.0
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Joakim Erdfelt (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joakim Erdfelt reopened MRM-244:
--------------------------------
Reopening to correct "fix version".
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Affects Versions: 1.0-alpha-1
> Reporter: Aaron Digulla
> Assignee: Joakim Erdfelt
> Priority: Critical
> Fix For: 1.0-alpha-1
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Joakim Erdfelt (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joakim Erdfelt closed MRM-244.
------------------------------
Resolution: Fixed
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Affects Versions: 1.0-alpha-1
> Reporter: Aaron Digulla
> Assignee: Joakim Erdfelt
> Priority: Critical
> Fix For: 1.0-alpha-1
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-244) Mirror/Proxy functionality is broken in
Archiva
Posted by "Aaron Digulla (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85682 ]
Aaron Digulla commented on MRM-244:
-----------------------------------
I have now implemented a proxy which allows to mirror arbitrary maven repositories and which can inject patches in the download process transparently.
The project page is at http://www.pdark.de/dsmp/
The source is only a few hundred lines. I'm not sure if it would make sense to merge this with Archiva, though (see http://www.pdark.de/dsmp/faq.html).
> Mirror/Proxy functionality is broken in Archiva
> -----------------------------------------------
>
> Key: MRM-244
> URL: http://jira.codehaus.org/browse/MRM-244
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Reporter: Aaron Digulla
> Priority: Critical
> Fix For: 1.0
>
>
> Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up.
> This approach has several drawbacks:
> - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized.
> - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources.
> This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example.
> - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use "codehaus.org", some use "codehaus". I've seen POMs which think "codehaus.org" is for snapshots while they use "codehaus" for the releases.
> In the end, there is no way to map repository "IDs" to mirrors which will work for all maven projects out there.
> Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva.
> Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from "http://people.apache.org/maven-snapshot-repository/" would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\..."
> If the port number is != 80, you can add another level for the port.
> This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira