You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Brett Porter <br...@apache.org> on 2012/06/11 17:41:10 UTC
Re: SNAPSHOT issue on 1.4.1
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
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>>
>>>
>>
>>
>> --
>> Dr. Louis Smith, ThD
>> Chief Technology Officer, Kyra InfoTech
>> Colonel, Commemorative Air Force
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: SNAPSHOT issue on 1.4.1
Posted by dr...@gmail.com.
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
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr. Louis Smith, ThD
>>> Chief Technology Officer, Kyra InfoTech
>>> Colonel, Commemorative Air Force
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>