Mailing-List: contact users-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@archiva.apache.org
Received-SPF: pass (nike.apache.org: domain of odeaching@gmail.com designates
 209.85.213.181 as permitted sender)
MIME-Version: 1.0
Sender: odeaching@gmail.com
In-Reply-To: <1412947093393.25108@oclc.org>
References: 
 <33358929B5AF884FBB9E19BAD7E49F4B09D1A56D@sal-exc-01.salmon.ltd.uk>
	<1F003FAC-DA72-4A74-9360-9398013F5BED@apache.org>
	<1412947093393.25108@oclc.org>
Date: Sat, 11 Oct 2014 13:34:29 +0800
Message-ID: 
 <CAPbd=T6u95qG-7Ukt5quvvX81vS8YupxMGSmg4Zfjja47BVkCA@mail.gmail.com>
Subject: Re: Archiva upgrade issues (related to issue MRM-1859)
From: Deng Ching-Mallete <oching@apache.org>
To: "users@archiva.apache.org" <users@archiva.apache.org>
Content-Type: multipart/alternative; boundary=14dae9cfc986fb84f905051f0448

--14dae9cfc986fb84f905051f0448
Content-Type: text/plain; charset=UTF-8

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 <nerderma@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 <brett@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 <rmilnerwatts@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

--14dae9cfc986fb84f905051f0448--