Kedar Mhaswade wrote:
> I ended up checking out clean and building it fresh. As expected,
> it worked fine.
Thanks for letting us know Kedar.
Now, could anyone explain what went behind this time, and how did maven
did not bump into the missing artifact problem? I'm still curious about
this randomness (i call) in maven, which I hate :-) and trying to
eliminate..
-hg
>
> -Kedar
>
> Sahoo wrote:
>> Stephen Connolly wrote:
>>> This is probably because some dependencies are being kept as
>>> -SNAPSHOT dependencies when they should not be, while other
>>> dependencies are not being kept as -SNAPSHOT dependencies when they
>>> should be.
>>>
>>> A quick rule of thumb is if the dependencies are within the same
>>> master pom & scm root, then they can all be -SNAPSHOT. If they are
>>> in different SCM roots, and there is no single pom.xml that will
>>> build them all then either they should be tied with non-SNAPSHOT
>>> versions or you will need to update them both and build them both
>>> repeatedly.
>>>
>>> What I tend to do when working on two or three trees in different
>>> SCMs in between releases is create a local pom that links all the
>>> separate SCM roots on my machine. That way I can keep the
>>> dependencies as -SNAPSHOT and work on the latest without having
>>> these build problems
>> We plan to move to this model soon for components that are evolving
>> together yet maintained in different SCMs.
>>
>> Thanks,
>> Sahoo
>>>
>>> On Mon, Jul 28, 2008 at 6:15 AM, Harsha Godugu
>>> <Harsha.Godugu_at_sun.com <mailto:Harsha.Godugu_at_sun.com>> wrote:
>>>
>>> Jagadish Prasath Ramu wrote:
>>>
>>> Not sure why it is failing. Is your workspace in sync w.r.t my
>>> checkin :
>>> svn log -v -r 21412 ?
>>>
>>> Yes, the only option I could think of now is to remove ~/.m2
>>> This should never be the option if maven -U does what it is
>>> expected of doing. Looks like there is a randomness or
>>> uncertainty associated with maven. One could easily decide some
>>> of the problem artifacts are not pushed to the maven repo or there
>>> could be a network problem, in this case.
>>>
>>> If deleting entire ~/.m2 is a problem, one can use
>>> -Dmaven.repo.local, to set up a project-wise private repo so
>>> that it can be deleted, when one starts a fresh checkout of the
>>> same project.
>>>
>>> -hg
>>>
>>>
>>> Thanks,
>>> -Jagadish
>>>
>>> On Fri, 2008-07-25 at 20:44 -0700, Kedar Mhaswade wrote:
>>> Hi Jagadish,
>>>
>>> Thank you, but that did not help. It fails with the same
>>> error.
>>> Do I have to clean ~/.m2 and start afresh?
>>>
>>> Thanks,
>>> Kedar
>>>
>>> Jagadish Prasath Ramu wrote:
>>> Hi Kedar,
>>> Are you facing this issue since morning (PT) ?
>>> I have made some changes for jdbc-ra, moved it to a
>>> top-level module.
>>> Not sure why it fails, it passes for me, hudson.
>>>
>>> Could you update from the top level (v3), remove
>>> ~/.m2/repository/...../jdbc-ra/*
>>> and do mvn -U clean install at top level ?
>>>
>>> Thanks,
>>> -Jagadish
>>>
>>>
>>>
>>> On Fri, 2008-07-25 at 19:23 -0700, Kedar Mhaswade
>>> wrote:
>>> What am I missing?
>>>
>>> - checked out and built a couple days back.
>>> - made changes to distributions module.
>>> - tried to do mvn clean install, mvn -U clean
>>> install
>>> and every time it fails with:
>>> [INFO]
>>>
>>> ------------------------------------------------------------------------
>>>
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>>
>>> ------------------------------------------------------------------------
>>>
>>> [INFO] Failed to resolve artifact.
>>>
>>> Missing:
>>> ----------
>>> 1)
>>>
>>> org.glassfish.jdbc.jdbc-ra.jdbc-ra-distribution:jdbc-ra:distribution-fragment:10.0-SNAPSHOT
>>>
>>>
>>> Try downloading the file manually from the
>>> project website.
>>>
>>>
>>> I am sure fresh checkout and build works fine.
>>>
>>> TIA,
>>> -Kedar
>>>
>>>
>>> ---------------------------------------------------------------------
>>>