problem with velocity:velocity:1.5

[TomHuybrechts]

Hi all,

I just installed artifactory and am attempting to do my normal builds from a clean repository.
These are failing because of problems with Velocity. Apparently one of my Maven plugins depends on velocity:velocity1.5. Unfortunately, this artifact's POM in central is faulty: it has a different groupId than its actual location.

This means that artifactory does not download the POM although it does download the jar. Maven will complain, but continue. But at runtime everything falls apart because velocity's transitive dependencies are not available.

Is there anything I can do about this ? Updating the artifact that has the dependency is not an option.
The problem can be reproduced on the demo install:
http://www.jfrog.org/artifactory/repo/velocity/velocity/1.5/velocity-1.5.pom

Tom

[Yoav Landman]

You have 2 options:
Either fix the POM and deploy it into a local repository (preferably
dedicated to third party libraries), where it will be found before the
corrupt POM from repo1. You can also add the POM to the excludes
pattern of the remote repo1 repository to make sure it is never
downloaded.
Or, run Artifactory with
-Dartifactory.maven.suppressPomConsistencyChecks=true to suppress this
consistency checks and have the broken POM silently installed (not
recommended, and if you choose to go this way it is best to turn the
checks back on and restart Artifactory).

HTH,

Yoav

On Jan 21, 2008 10:14 PM, TomHuybrechts <tom.huybrechts@...> wrote:

>
> Hi all,
>
> I just installed artifactory and am attempting to do my normal builds from a
> clean repository.
> These are failing because of problems with Velocity. Apparently one of my
> Maven plugins depends on velocity:velocity1.5. Unfortunately, this
> artifact's POM in central is faulty: it has a different groupId than its
> actual location.
>
> This means that artifactory does not download the POM although it does
> download the jar. Maven will complain, but continue. But at runtime
> everything falls apart because velocity's transitive dependencies are not
> available.
>
> Is there anything I can do about this ? Updating the artifact that has the
> dependency is not an option.
> The problem can be reproduced on the demo install:
> http://www.jfrog.org/artifactory/repo/velocity/velocity/1.5/velocity-1.5.pom
>
> Tom
> --
> View this message in context: http://www.nabble.com/problem-with-velocity%3Avelocity%3A1.5-tp15005415p15005415.html
> Sent from the Artifactory-Users mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Artifactory-users mailing list
> Artifactory-users@...
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[Clifton]

Is there a process where POM corruption like this can be reported/fixed on repo1? It makes me a little nervous to see these issues in the middle of crunch time where we really don't have the availability to add a cmd line option, restart, remove the option and restart. It's also a bit much to fight with recoding someone else's pom which seems to imply testing cycles to make sure transitive dependencies are correctly resolved and so on. Has there been any talk of an auto-fix for corrupt poms using a best guess algorithm? Would that open the door to many other dangers?

Yoav Landman wrote:

You have 2 options:
Either fix the POM and deploy it into a local repository (preferably
dedicated to third party libraries), where it will be found before the
corrupt POM from repo1. You can also add the POM to the excludes
pattern of the remote repo1 repository to make sure it is never
downloaded.
Or, run Artifactory with
-Dartifactory.maven.suppressPomConsistencyChecks=true to suppress this
consistency checks and have the broken POM silently installed (not
recommended, and if you choose to go this way it is best to turn the
checks back on and restart Artifactory).

HTH,

Yoav

On Jan 21, 2008 10:14 PM, TomHuybrechts <[e-mail]> wrote:
>
> Hi all,
>
> I just installed artifactory and am attempting to do my normal builds from a
> clean repository.
> These are failing because of problems with Velocity. Apparently one of my
> Maven plugins depends on velocity:velocity1.5. Unfortunately, this
> artifact's POM in central is faulty: it has a different groupId than its
> actual location.
>
> This means that artifactory does not download the POM although it does
> download the jar. Maven will complain, but continue. But at runtime
> everything falls apart because velocity's transitive dependencies are not
> available.
>
> Is there anything I can do about this ? Updating the artifact that has the
> dependency is not an option.
> The problem can be reproduced on the demo install:
> http://www.jfrog.org/artifactory/repo/velocity/velocity/1.5/velocity-1.5.pom
>
> Tom
> --
> View this message in context: http://www.nabble.com/problem-with-velocity%3Avelocity%3A1.5-tp15005415p15005415.html
> Sent from the Artifactory-Users mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Artifactory-users mailing list
> [e-mail]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Artifactory-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[Yoav Landman]

There's a dedicated JIRA project in Maven for uploading files to repo1, including corruption fixes I think.
I guess that technically it is feasible to automatically fix the POM on the fly according to the request data (assuming the user dependency was specified correctly and resolved, but to a corrupt POM).

On Wed, Apr 30, 2008 at 4:04 PM, Clifton <clifton.craig@...> wrote:

Is there a process where POM corruption like this can be reported/fixed on
repo1? It makes me a little nervous to see these issues in the middle of
crunch time where we really don't have the availability to add a cmd line
option, restart, remove the option and restart. It's also a bit much to
fight with recoding someone else's pom which seems to imply testing cycles
to make sure transitive dependencies are correctly resolved and so on. Has
there been any talk of an auto-fix for corrupt poms using a best guess
algorithm? Would that open the door to many other dangers?

Yoav  Landman wrote:
>
> You have 2 options:
> Either fix the POM and deploy it into a local repository (preferably
> dedicated to third party libraries), where it will be found before the
> corrupt POM from repo1. You can also add the POM to the excludes
> pattern of the remote repo1 repository to make sure it is never
> downloaded.
> Or, run Artifactory with
> -Dartifactory.maven.suppressPomConsistencyChecks=true to suppress this
> consistency checks and have the broken POM silently installed (not
> recommended, and if you choose to go this way it is best to turn the
> checks back on and restart Artifactory).
>
> HTH,
>
> Yoav
>
> On Jan 21, 2008 10:14 PM, TomHuybrechts <tom.huybrechts@...> wrote:
>>
>> Hi all,
>>
>> I just installed artifactory and am attempting to do my normal builds
>> from a
>> clean repository.
>> These are failing because of problems with Velocity. Apparently one of my
>> Maven plugins depends on velocity:velocity1.5. Unfortunately, this
>> artifact's POM in central is faulty: it has a different groupId than its
>> actual location.
>>
>> This means that artifactory does not download the POM although it does
>> download the jar. Maven will complain, but continue. But at runtime
>> everything falls apart because velocity's transitive dependencies are not
>> available.
>>
>> Is there anything I can do about this ? Updating the artifact that has
>> the
>> dependency is not an option.
>> The problem can be reproduced on the demo install:
>> http://www.jfrog.org/artifactory/repo/velocity/velocity/1.5/velocity-1.5.pom
>>
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/problem-with-velocity%3Avelocity%3A1.5-tp15005415p15005415.html
>> Sent from the Artifactory-Users mailing list archive at Nabble.com.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Artifactory-users mailing list
>> Artifactory-users@...
>> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Artifactory-users mailing list
> Artifactory-users@...
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
>

--
View this message in context: http://www.nabble.com/problem-with-velocity%3Avelocity%3A1.5-tp15005415p16982029.html

Sent from the Artifactory-Users mailing list archive at Nabble.com.


-------------------------------------------------------------------------

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Artifactory-users mailing list
Artifactory-users@...
https://lists.sourceforge.net/lists/listinfo/artifactory-users

[dkernekins]

I was able to finally solve this. See: http://www.nabble.com/Archetype%3Acreate-broken--tt17503659.html#a18133939

What do I not understand about the process of posting new versions to internet repos?
More than a month has gone by and still, this appears not to be fixed?
In the .pom i just downloaded, it was still "wrong" and I patched it manually from http://repo1.maven.org/maven2/org/apache/velocity/velocity/1.5/velocity-1.5.pom

Is there something I / We out here, using this in production shops can do to help?

Also, if there is an alternate "better way", I would appreciate having it posted. I am still planning to play with either
1) create a <distributionManagement> <relocation> in the velocity:velocity:pom:1.5 to the "corrected" version on org.apache.velocity:velocity:pom:1.5
or
2) just deploy to Artifactory manually the org.apache.velocity:velocity:pom:1.5 to velocity:velocity:pom:1.5 so that the rest of the team does not have to patch their local repo....
-- dke

Yoav Landman wrote:

There's a dedicated JIRA project in Maven for uploading files to repo1,
including corruption fixes I think.
I guess that technically it is feasible to automatically fix the POM on the
fly according to the request data (assuming the user dependency was
specified correctly and resolved, but to a corrupt POM).

On Wed, Apr 30, 2008 at 4:04 PM, Clifton <[e-mail]> wrote:

>
> Is there a process where POM corruption like this can be reported/fixed on
> repo1? It makes me a little nervous to see these issues in the middle of
> crunch time where we really don't have the availability to add a cmd line
> option, restart, remove the option and restart. It's also a bit much to
> fight with recoding someone else's pom which seems to imply testing cycles
> to make sure transitive dependencies are correctly resolved and so on. Has
> there been any talk of an auto-fix for corrupt poms using a best guess
> algorithm? Would that open the door to many other dangers?
>
>
> Yoav  Landman wrote:
> >
> > You have 2 options:
> > Either fix the POM and deploy it into a local repository (preferably
> > dedicated to third party libraries), where it will be found before the
> > corrupt POM from repo1. You can also add the POM to the excludes
> > pattern of the remote repo1 repository to make sure it is never
> > downloaded.
> > Or, run Artifactory with
> > -Dartifactory.maven.suppressPomConsistencyChecks=true to suppress this
> > consistency checks and have the broken POM silently installed (not
> > recommended, and if you choose to go this way it is best to turn the
> > checks back on and restart Artifactory).
> >
> > HTH,
> >
> > Yoav
> >
> > On Jan 21, 2008 10:14 PM, TomHuybrechts <[e-mail]>
> wrote:
> >>
> >> Hi all,
> >>
> >> I just installed artifactory and am attempting to do my normal builds
> >> from a
> >> clean repository.
> >> These are failing because of problems with Velocity. Apparently one of
> my
> >> Maven plugins depends on velocity:velocity1.5. Unfortunately, this
> >> artifact's POM in central is faulty: it has a different groupId than
> its
> >> actual location.
> >>
> >> This means that artifactory does not download the POM although it does
> >> download the jar. Maven will complain, but continue. But at runtime
> >> everything falls apart because velocity's transitive dependencies are
> not
> >> available.
> >>
> >> Is there anything I can do about this ? Updating the artifact that has
> >> the
> >> dependency is not an option.
> >> The problem can be reproduced on the demo install:
> >>
> http://www.jfrog.org/artifactory/repo/velocity/velocity/1.5/velocity-1.5.pom
> >>
> >> Tom
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/problem-with-velocity%3Avelocity%3A1.5-tp15005415p15005415.html
> >> Sent from the Artifactory-Users mailing list archive at Nabble.com.
> >>
> >>
> >>
> -------------------------------------------------------------------------
_______________________________________________
Artifactory-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/artifactory-users