Yep. In my haste to install 1.4.1 for testing, I inadvertently had the local and remote assigned identically. I will keep a note on that!
I do have another issue, but it will require an enhancement, so it will be against a different release. Sent from my iPad On Jun 11, 2012, at 11:41, Brett Porter <br...@apache.org> wrote: > Did this help, Louis? > > - Brett > > On 25/05/2012, at 5:14 PM, Brett Porter wrote: > >> If I've understood you correctly, then I think that likely explains both >> problems. Maven's remote repository is intentionally different to its local >> repository - the handling of snapshot metadata differs, and there's no >> concurrency protection. If you are using "mvn install" to populate a >> directory that is then served as a remote repository, it will cause some >> confusion. >> >> I recommend you instead keep the default isolated local repository, and use >> "mvn deploy" to push to the location you want. That can still be a separate >> file:// URL. Of course I'd encourage running a repository manager, like >> Archiva (or Artifactory or Nexus), to manage that hosted repository since it >> can also trim out the timestamped and released snapshots, as well as do the >> proxying for the other artifacts that you have in there. >> >> Hope that helps! >> >> - Brett >> >> On 23/05/2012, at 9:42 PM, Louis Smith wrote: >> >>> This is a server that I installed to test this environment. Continuum is >>> running under glassfish 3.1.1 on the box; the builds are being done by >>> continuum with the "install" goal. The links I sent are to the external >>> URL of the box. I have the distribution point mapped so that other apps >>> can get my -SNAPSHOT files as their dependencies - so the "local install >>> point" is my own "remote access url" - I have my svn setup with both SVN:// >>> and HTTP:// access as well to the shared repository. Sorry for not >>> explaining that. Everything I have sent is from a single box - just both >>> the internal and external point of view. >>> >>> so - I have a pom.xml as a "parent" or "master" pom. As I'm testing >>> through the reporting issue, I want to be able to change it, install it, >>> then test a child app to see if the reports run. So the child app refers >>> to the master pom as its parent, as artifactId: components-pom version: >>> 1.0.2-SNAPSHOT, as it should. >>> >>> However, when I run the "install" of the components-pom project (just a pom >>> file), instead of publishing it as "components-pom-1.0.2-SNAPSHOT", it gets >>> published as one of the timestamp formatted names.... which of course, the >>> other projects can't see. If I do a release, the released file has a >>> correct name. >>> >>> As to the 4.0K pom files, they contain the first 4K bytes of a valid pom. >>> It just stops writing to the file at 4.0K. They aren't "bad".. just >>> truncated. >>> >>> Feel free to hit the links...they are valid.. it is one of my registered >>> domains - you can see the contents of the files yourself. As I said, I >>> threw this box together for testing and only have a few demos on it that I >>> use frequently for testing anyway. >>> >>> On Wed, May 23, 2012 at 7:00 AM, Brett Porter <br...@apache.org> wrote: >>> >>>> Hi Louis, >>>> >>>> On 22/05/2012, at 9:39 PM, Louis Smith wrote: >>>> >>>>> What I mean is that when I do an "install" at all - a new timestamped >>>>> version is created - not a "1.0.2-SNAPSHOT" which is what should be >>>>> created. Here is a text convert of the links I sent. As you can see, >>>> each >>>>> time I ran the install, it creates a new version (-1.pom, -2.pom), but >>>> all >>>>> have a timestamp in the name which shouldn't be there. This is a "master >>>>> pom" project and I'm working on getting the reports to run (finally >>>>> discovered there is a bug in APIViz under JDK 1.7 - so converting to >>>>> UMLGraph for now). Since the install doesn't create the desired/expected >>>>> file (components-pom-1.0.2-SNAPSHOT.pom), my other projects can't >>>> reference >>>>> it. I have to keep doing a release and use the "live" version for >>>> testing. >>>> >>>> Apologies, I'm still not following where your problem is, so let me break >>>> it down. >>>> >>>> 1) Timestamps vs. SNAPSHOT >>>> >>>> Where I'm lost here is that you are looking at a remote repository, but >>>> referring to "install" which deals with a local repository in Maven. I >>>> wonder if you are using the "deployment repository" in Continuum to >>>> populate it? >>>> >>>> The normal set up would be that you have Continuum running "mvn deploy", >>>> and the project configured to deploy to the remote repository - with >>>> snapshots. There should never be a bare SNAPSHOT in the remote repository - >>>> it's handled transparently by Maven and the metadata files. >>>> >>>> 2) Truncated POM >>>> >>>> What's the content of the 4K POM? Do you have a link to the problem, as >>>> you said it had happened before? It seems like it might be closely related >>>> to the previous mechanism being different to what was expected. >>>> >>>> You might have to describe your setup a bit more so I can understand the >>>> context of the errors you're getting - there's clearly these two problems >>>> in the data you've provided, but I don't know enough about how you're >>>> getting things there to speculate on the cause. >>>> >>>> - Brett >>>> >>>> -- >>>> Brett Porter >>>> br...@apache.org >>>> http://brettporter.wordpress.com/ >>>> >>>> >>> >>> >>> -- >>> Dr. Louis Smith, ThD >>> Chief Technology Officer, Kyra InfoTech >>> Colonel, Commemorative Air Force >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> http://au.linkedin.com/in/brettporter >> http://twitter.com/brettporter >> >> >> >> >> > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > http://twitter.com/brettporter > > > > >
