You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Richard Milner-Watts <rm...@salmon.com> on 2014/10/09 15:53:30 UTC
Archiva upgrade issues (related to issue MRM-1859)
Hi Folks,
I'm experiencing a bit of an issue with Archiva after upgrading that appears to be issue MRM-1859 - however that issue is only mentioned against version 2.1.1 - I'm experiencing it on versions 2.0.1, 2.1.0 and 2.1.1.
Some quick background in what I'm trying to actually do, on one of our projects here the development team have chosen to use Maven for builds/dependency resolution - artifacts are then stored in Archiva. They haven't been incrementing the X.X.X-SNAPSHOT version numbers properly, so I may find anywhere from 10's to 100's of builds against a given SNAPSHOT version.
I'm trying to write a remote deployment framework which will pull multiple artifacts out of Archiva (using Ant & bash) and store the latest build of said artifacts at that particular point in time, which I can then package up and distribute/deploy appropriately across disparate remote servers. Having spent a fair bit of time trying to work out how to get an artifact out of Archiva programmatically and onto the filesystem, I've settled on the REST interface. I'm using /restServices/archivaServices/browseService/artifactDownloadInfos/g/a/v/ to get the JSON document with the download URL, parsing it and then downloading the artifacts - so far so good.
My development was done against a different Archiva installation that my team use for a different project (Archiva 2.0.1 standalone, OpenJDK 1.7.0.45, RedHat 6.4) and everything works as expected. I went to test against the projects' Archiva and found they are running Archiva 1.3.6 still - therefore the REST interfaces aren't available. Note that the projects' Archiva is running on a Windows machine using the Oracle JRE 1.7.0.67.
So I decided to upgrade their Archiva to 2.1.1 to get the REST functionality, migrating the repositories and user databases and duplicating a small number of configuration tweaks they'd made to the out of the box Archiva configuration (Archiva.xml, Jetty.xml). I experienced the exact issue described in MRM-1859 (https://jira.codehaus.org/browse/MRM-1859) when trying to browse artifacts via the web UI or via the REST interface.
Fair enough, so I tried the same upgrade process to version 2.1.0 with the same results. Alright, well I *know* 2.0.1 works as I have it working elsewhere, so I upgraded to 2.0.1 the third time around and still had the same issue...
In my mind this potentially signifies three possible culprits:
- The repository database itself or some of our customisations to the archiva.xml configuration are causing this problem.
- There's an issue with the Oracle JRE we are using (latest 1.7, upgraded yesterday when I clocked that Archiva 2.x needs a 1.7 JRE)
- There is a Windows specific issue here
Does anyone have any potential solutions to suggest here, either to solve my original problem without upgrading Archiva or as to why I'm having issues with these resolver-status.properties files?
Many thanks in advance for any help/suggestions.
Richard Milner-Watts
Infrastructure Architect
Salmon Ltd * 2nd Floor * 64 Clarendon Rd * Watford * Herts * WD17 1DA
Tel: +44 (0)1923 320000 * Fax: +44 (0)1923 320023
www.salmon.com<http://www.salmon.com>
Unique Approach * Unique Solutions
________________________________
Information contained in this e-mail and any attachments is confidential and intended for the use of the addressee only. Dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. If you have received this transmission in error, please advise the originator by reply e-mail and delete it. Thank you.
Salmon's Registered Address is: 27 Farm Street, London, W1J 5RJ. Registered in England 2360867.
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Re: Archiva upgrade issues (related to issue MRM-1859)
Posted by Deng Ching-Mallete <oc...@apache.org>.
Yep, that is correct. The properties file was getting created by one of the
Maven libraries used in dependency resolution when browsing an artifact.
Then upon viewing the artifacts tab, the properties file is being resolved
as an artifact since it's not included in the list of excluded files (e.g.
metadata files & checksums), but it's actually not so it fails the
validation check.
Thanks,
Deng
On Fri, Oct 10, 2014 at 9:18 PM, Nerderman,Adam <ne...@oclc.org> wrote:
> I was the one that brought this up and Deng was able to reproduce it and
> created the issue. This had to do with if you try to view the artifacts tab
> for a snapshot artifact in Archiva it is creating the
> resolver-status.properties file in the data for some reason and then either
> not ignoring it or not removing it. This makes it impossible to view the
> actually files associated with a snapshot artifact in Archiva 2.1.1 and the
> previous versions Richard mentioned.
> ________________________________________
> From: Brett Porter <br...@porterclan.net> on behalf of Brett Porter <
> brett@apache.org>
> Sent: Friday, October 10, 2014 12:00 AM
> To: users@archiva.apache.org
> Subject: Re: Archiva upgrade issues (related to issue MRM-1859)
>
> Hi Richard,
>
> Maybe Deng, one of the developers who filed this issue, can shed some
> light. I'm not sure why that log would cause an issue (nor why
> resolver-status.properties would be on the filesystem, since that's a Maven
> local repository concept as far as I know).
>
> To your original problem: maybe you can get what you need from the
> repository just using Maven conventions, rather than the REST API. For
> example, the following Puppet module does similar actions to what you've
> described: https://forge.puppetlabs.com/maestrodev/maven
>
> The structure of a Maven repository is predictable. As for versions - it
> is intended that you keep deploying the "SNAPSHOT" version, and Maven takes
> care of timestamping that in the repository. The maven-metadata.xml file
> tracks the latest timestamp in use, and Archiva can be enabled to
> automatically purge old versions. Does that help at all?
>
> Cheers,
> Brett
>
>
> On 10 Oct 2014, at 12:53 am, Richard Milner-Watts <rm...@salmon.com>
> wrote:
>
> > Hi Folks,
> >
> > I'm experiencing a bit of an issue with Archiva after upgrading that
> appears to be issue MRM-1859 - however that issue is only mentioned against
> version 2.1.1 - I'm experiencing it on versions 2.0.1, 2.1.0 and 2.1.1.
> >
> > Some quick background in what I'm trying to actually do, on one of our
> projects here the development team have chosen to use Maven for
> builds/dependency resolution - artifacts are then stored in Archiva. They
> haven't been incrementing the X.X.X-SNAPSHOT version numbers properly, so I
> may find anywhere from 10's to 100's of builds against a given SNAPSHOT
> version.
> >
> > I'm trying to write a remote deployment framework which will pull
> multiple artifacts out of Archiva (using Ant & bash) and store the latest
> build of said artifacts at that particular point in time, which I can then
> package up and distribute/deploy appropriately across disparate remote
> servers. Having spent a fair bit of time trying to work out how to get an
> artifact out of Archiva programmatically and onto the filesystem, I've
> settled on the REST interface. I'm using
> /restServices/archivaServices/browseService/artifactDownloadInfos/g/a/v/ to
> get the JSON document with the download URL, parsing it and then
> downloading the artifacts - so far so good.
> >
> > My development was done against a different Archiva installation that my
> team use for a different project (Archiva 2.0.1 standalone, OpenJDK
> 1.7.0.45, RedHat 6.4) and everything works as expected. I went to test
> against the projects' Archiva and found they are running Archiva 1.3.6
> still - therefore the REST interfaces aren't available. Note that the
> projects' Archiva is running on a Windows machine using the Oracle JRE
> 1.7.0.67.
> >
> > So I decided to upgrade their Archiva to 2.1.1 to get the REST
> functionality, migrating the repositories and user databases and
> duplicating a small number of configuration tweaks they'd made to the out
> of the box Archiva configuration (Archiva.xml, Jetty.xml). I experienced
> the exact issue described in MRM-1859 (
> https://jira.codehaus.org/browse/MRM-1859) when trying to browse
> artifacts via the web UI or via the REST interface.
> >
> > Fair enough, so I tried the same upgrade process to version 2.1.0 with
> the same results. Alright, well I *know* 2.0.1 works as I have it working
> elsewhere, so I upgraded to 2.0.1 the third time around and still had the
> same issue...
> >
> > In my mind this potentially signifies three possible culprits:
> >
> >
> > - The repository database itself or some of our customisations
> to the archiva.xml configuration are causing this problem.
> >
> > - There's an issue with the Oracle JRE we are using (latest
> 1.7, upgraded yesterday when I clocked that Archiva 2.x needs a 1.7 JRE)
> >
> > - There is a Windows specific issue here
> >
> > Does anyone have any potential solutions to suggest here, either to
> solve my original problem without upgrading Archiva or as to why I'm having
> issues with these resolver-status.properties files?
> >
> > Many thanks in advance for any help/suggestions.
> >
> > Richard Milner-Watts
> > Infrastructure Architect
> >
> > Salmon Ltd * 2nd Floor * 64 Clarendon Rd * Watford * Herts * WD17 1DA
> > Tel: +44 (0)1923 320000 * Fax: +44 (0)1923 320023
> > www.salmon.com<http://www.salmon.com>
> >
> > Unique Approach * Unique Solutions
> >
> >
> > ________________________________
> > Information contained in this e-mail and any attachments is confidential
> and intended for the use of the addressee only. Dissemination,
> distribution, copying or use of this communication without prior permission
> of the addressee is strictly prohibited. If you have received this
> transmission in error, please advise the originator by reply e-mail and
> delete it. Thank you.
> >
> > Salmon's Registered Address is: 27 Farm Street, London, W1J 5RJ.
> Registered in England 2360867.
> >
> >
> >
> > This message has been scanned for viruses by BlackSpider MailControl -
> www.blackspider.com
>
>
>
--
Maria Odea "Deng" Ching-Mallete | oching@apache.org |
http://www.linkedin.com/in/oching
Re: Archiva upgrade issues (related to issue MRM-1859)
Posted by "Nerderman,Adam" <ne...@oclc.org>.
I was the one that brought this up and Deng was able to reproduce it and created the issue. This had to do with if you try to view the artifacts tab for a snapshot artifact in Archiva it is creating the resolver-status.properties file in the data for some reason and then either not ignoring it or not removing it. This makes it impossible to view the actually files associated with a snapshot artifact in Archiva 2.1.1 and the previous versions Richard mentioned.
________________________________________
From: Brett Porter <br...@porterclan.net> on behalf of Brett Porter <br...@apache.org>
Sent: Friday, October 10, 2014 12:00 AM
To: users@archiva.apache.org
Subject: Re: Archiva upgrade issues (related to issue MRM-1859)
Hi Richard,
Maybe Deng, one of the developers who filed this issue, can shed some light. I'm not sure why that log would cause an issue (nor why resolver-status.properties would be on the filesystem, since that's a Maven local repository concept as far as I know).
To your original problem: maybe you can get what you need from the repository just using Maven conventions, rather than the REST API. For example, the following Puppet module does similar actions to what you've described: https://forge.puppetlabs.com/maestrodev/maven
The structure of a Maven repository is predictable. As for versions - it is intended that you keep deploying the "SNAPSHOT" version, and Maven takes care of timestamping that in the repository. The maven-metadata.xml file tracks the latest timestamp in use, and Archiva can be enabled to automatically purge old versions. Does that help at all?
Cheers,
Brett
On 10 Oct 2014, at 12:53 am, Richard Milner-Watts <rm...@salmon.com> wrote:
> Hi Folks,
>
> I'm experiencing a bit of an issue with Archiva after upgrading that appears to be issue MRM-1859 - however that issue is only mentioned against version 2.1.1 - I'm experiencing it on versions 2.0.1, 2.1.0 and 2.1.1.
>
> Some quick background in what I'm trying to actually do, on one of our projects here the development team have chosen to use Maven for builds/dependency resolution - artifacts are then stored in Archiva. They haven't been incrementing the X.X.X-SNAPSHOT version numbers properly, so I may find anywhere from 10's to 100's of builds against a given SNAPSHOT version.
>
> I'm trying to write a remote deployment framework which will pull multiple artifacts out of Archiva (using Ant & bash) and store the latest build of said artifacts at that particular point in time, which I can then package up and distribute/deploy appropriately across disparate remote servers. Having spent a fair bit of time trying to work out how to get an artifact out of Archiva programmatically and onto the filesystem, I've settled on the REST interface. I'm using /restServices/archivaServices/browseService/artifactDownloadInfos/g/a/v/ to get the JSON document with the download URL, parsing it and then downloading the artifacts - so far so good.
>
> My development was done against a different Archiva installation that my team use for a different project (Archiva 2.0.1 standalone, OpenJDK 1.7.0.45, RedHat 6.4) and everything works as expected. I went to test against the projects' Archiva and found they are running Archiva 1.3.6 still - therefore the REST interfaces aren't available. Note that the projects' Archiva is running on a Windows machine using the Oracle JRE 1.7.0.67.
>
> So I decided to upgrade their Archiva to 2.1.1 to get the REST functionality, migrating the repositories and user databases and duplicating a small number of configuration tweaks they'd made to the out of the box Archiva configuration (Archiva.xml, Jetty.xml). I experienced the exact issue described in MRM-1859 (https://jira.codehaus.org/browse/MRM-1859) when trying to browse artifacts via the web UI or via the REST interface.
>
> Fair enough, so I tried the same upgrade process to version 2.1.0 with the same results. Alright, well I *know* 2.0.1 works as I have it working elsewhere, so I upgraded to 2.0.1 the third time around and still had the same issue...
>
> In my mind this potentially signifies three possible culprits:
>
>
> - The repository database itself or some of our customisations to the archiva.xml configuration are causing this problem.
>
> - There's an issue with the Oracle JRE we are using (latest 1.7, upgraded yesterday when I clocked that Archiva 2.x needs a 1.7 JRE)
>
> - There is a Windows specific issue here
>
> Does anyone have any potential solutions to suggest here, either to solve my original problem without upgrading Archiva or as to why I'm having issues with these resolver-status.properties files?
>
> Many thanks in advance for any help/suggestions.
>
> Richard Milner-Watts
> Infrastructure Architect
>
> Salmon Ltd * 2nd Floor * 64 Clarendon Rd * Watford * Herts * WD17 1DA
> Tel: +44 (0)1923 320000 * Fax: +44 (0)1923 320023
> www.salmon.com<http://www.salmon.com>
>
> Unique Approach * Unique Solutions
>
>
> ________________________________
> Information contained in this e-mail and any attachments is confidential and intended for the use of the addressee only. Dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. If you have received this transmission in error, please advise the originator by reply e-mail and delete it. Thank you.
>
> Salmon's Registered Address is: 27 Farm Street, London, W1J 5RJ. Registered in England 2360867.
>
>
>
> This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Re: Archiva upgrade issues (related to issue MRM-1859)
Posted by Brett Porter <br...@apache.org>.
Hi Richard,
Maybe Deng, one of the developers who filed this issue, can shed some light. I'm not sure why that log would cause an issue (nor why resolver-status.properties would be on the filesystem, since that's a Maven local repository concept as far as I know).
To your original problem: maybe you can get what you need from the repository just using Maven conventions, rather than the REST API. For example, the following Puppet module does similar actions to what you've described: https://forge.puppetlabs.com/maestrodev/maven
The structure of a Maven repository is predictable. As for versions - it is intended that you keep deploying the "SNAPSHOT" version, and Maven takes care of timestamping that in the repository. The maven-metadata.xml file tracks the latest timestamp in use, and Archiva can be enabled to automatically purge old versions. Does that help at all?
Cheers,
Brett
On 10 Oct 2014, at 12:53 am, Richard Milner-Watts <rm...@salmon.com> wrote:
> Hi Folks,
>
> I'm experiencing a bit of an issue with Archiva after upgrading that appears to be issue MRM-1859 - however that issue is only mentioned against version 2.1.1 - I'm experiencing it on versions 2.0.1, 2.1.0 and 2.1.1.
>
> Some quick background in what I'm trying to actually do, on one of our projects here the development team have chosen to use Maven for builds/dependency resolution - artifacts are then stored in Archiva. They haven't been incrementing the X.X.X-SNAPSHOT version numbers properly, so I may find anywhere from 10's to 100's of builds against a given SNAPSHOT version.
>
> I'm trying to write a remote deployment framework which will pull multiple artifacts out of Archiva (using Ant & bash) and store the latest build of said artifacts at that particular point in time, which I can then package up and distribute/deploy appropriately across disparate remote servers. Having spent a fair bit of time trying to work out how to get an artifact out of Archiva programmatically and onto the filesystem, I've settled on the REST interface. I'm using /restServices/archivaServices/browseService/artifactDownloadInfos/g/a/v/ to get the JSON document with the download URL, parsing it and then downloading the artifacts - so far so good.
>
> My development was done against a different Archiva installation that my team use for a different project (Archiva 2.0.1 standalone, OpenJDK 1.7.0.45, RedHat 6.4) and everything works as expected. I went to test against the projects' Archiva and found they are running Archiva 1.3.6 still - therefore the REST interfaces aren't available. Note that the projects' Archiva is running on a Windows machine using the Oracle JRE 1.7.0.67.
>
> So I decided to upgrade their Archiva to 2.1.1 to get the REST functionality, migrating the repositories and user databases and duplicating a small number of configuration tweaks they'd made to the out of the box Archiva configuration (Archiva.xml, Jetty.xml). I experienced the exact issue described in MRM-1859 (https://jira.codehaus.org/browse/MRM-1859) when trying to browse artifacts via the web UI or via the REST interface.
>
> Fair enough, so I tried the same upgrade process to version 2.1.0 with the same results. Alright, well I *know* 2.0.1 works as I have it working elsewhere, so I upgraded to 2.0.1 the third time around and still had the same issue...
>
> In my mind this potentially signifies three possible culprits:
>
>
> - The repository database itself or some of our customisations to the archiva.xml configuration are causing this problem.
>
> - There's an issue with the Oracle JRE we are using (latest 1.7, upgraded yesterday when I clocked that Archiva 2.x needs a 1.7 JRE)
>
> - There is a Windows specific issue here
>
> Does anyone have any potential solutions to suggest here, either to solve my original problem without upgrading Archiva or as to why I'm having issues with these resolver-status.properties files?
>
> Many thanks in advance for any help/suggestions.
>
> Richard Milner-Watts
> Infrastructure Architect
>
> Salmon Ltd * 2nd Floor * 64 Clarendon Rd * Watford * Herts * WD17 1DA
> Tel: +44 (0)1923 320000 * Fax: +44 (0)1923 320023
> www.salmon.com<http://www.salmon.com>
>
> Unique Approach * Unique Solutions
>
>
> ________________________________
> Information contained in this e-mail and any attachments is confidential and intended for the use of the addressee only. Dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. If you have received this transmission in error, please advise the originator by reply e-mail and delete it. Thank you.
>
> Salmon's Registered Address is: 27 Farm Street, London, W1J 5RJ. Registered in England 2360867.
>
>
>
> This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com