maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
Date Thu, 01 Sep 2011 15:06:00 GMT
On 1 September 2011 15:51, Eric Kolotyluk <eric.kolotyluk@gmail.com> wrote:
> @guillaume
>
> OK, it seems that because the version in my child POMs had version
> 0.0.1-SNAPSHOT for the parent, but the parent was assuming everything was
> 0.0.2-SNAPSHOT, things were just not building properly. Now that my versions
> all match up doing a package on the parent recursively does a package on the
> children.

mvn versions:update-parent

would have sorted that out for you

>
> Cheers, Eric
>
> On Thu, Sep 1, 2011 at 7:31 AM, Guillaume Polet
> <guillaume.polet@gmail.com>wrote:
>
>> Well, it also aggregates your whole  build together.
>> If you do an 'mvn package' on your parent project, it will package your
>> parent and all its children. If you don't define the modules in your parent,
>> doing an 'mvn package' will only result in the packaging of your parent pom.
>>
>> Guillaume
>>
>> Le 1/09/2011 16:28, Eric Kolotyluk a écrit :
>>
>>> OK, I think I am strategy (1) - although the only thing the parent
>>> actually
>>> agrregates is the javadoc. Or does aggregator have another meaning here?
>>>
>>> Is there some way I can set things up so that I only have to change the
>>> parent version and the children will all follow. The problem I ran into is
>>> that the child POMs contain the version for the parent (and the problem
>>> was
>>> they did not match), Can this be removed so the children just assume the
>>> parent version?
>>>
>>> Cheers, Eric
>>>
>>> On Thu, Sep 1, 2011 at 12:59 AM, Guillaume Polet
>>> <guillaume.polet@gmail.com>**wrote:
>>>
>>>  For me, there are two strategies there:
>>>> 1) You use the parent pom as an aggregator (your parent pom reference its
>>>> children through modules) of several projects that always work together
>>>> and
>>>> make a coherent package-->parent/children should keep the same version,
>>>> it's
>>>> just simpler to anyone's mind and simpler to maintain.
>>>> 2) You use a parent pom to define well-defined practices, coherent set of
>>>> dependencies, general properties used across all your projects, plugins
>>>> and
>>>> their configuration that you don't want to repeat in all your projects,
>>>> but
>>>> the parent does not know about its "children"-->Then children should
>>>> necessarily follow your  parent version
>>>>
>>>> Cheers,
>>>>
>>>> Guillaume
>>>>
>>>> Le 1/09/2011 06:57, Eric Kolotyluk a écrit :
>>>>
>>>>  OK, seems the problem was some data inconsistency with some things
>>>>> pointing to 0.0.2-SNAPSHOT and other things still pointing to
>>>>> 0.0.1-SNAPSHOT
>>>>>
>>>>> What is the best practice for when you want to change the version of
the
>>>>> parent POM, and have all the children follow?
>>>>>
>>>>> I'm trying to use managed dependencies as much as possible, but somehow
>>>>> that is not enough.
>>>>>
>>>>> Also, is there some simple way to remove all 0.0.1-SNAPSHOT artifacts
>>>>> from
>>>>> Nexus?
>>>>>
>>>>> Cheers, Eric
>>>>>
>>>>> On 2011-08-31 8:54 PM, Eric Kolotyluk wrote:
>>>>>
>>>>>  Is it just me, or does anyone else ever get tired of the message
>>>>>>
>>>>>> resolution will not be reattempted until the update interval of nexus
>>>>>> has
>>>>>> elapsed or updates are forced
>>>>>>
>>>>>> Everything was working fine yesterday. For some reason, that I cannot
>>>>>> explain, now my builds keep failing with this symptom. I have not
>>>>>> actually
>>>>>> changed any pom files or really anything - other than to stop and
>>>>>> restart
>>>>>> Eclipse. The same problem happens whether I build from Eclipse or
the
>>>>>> command line. I cannot seem to find any combination of '-U' or 'clean'
>>>>>> or
>>>>>> 'deploy' or anything to correct things. I feel like a chicken who
pecks
>>>>>> randomly at things until one of them is food.
>>>>>>
>>>>>> It is really unnerving that maven is so fragile and unpredictable,
and
>>>>>> things so randomly go from working to broken. While Maven is way
better
>>>>>> than
>>>>>> Ant in most respects, Ant is still head and shoulders above Maven
in
>>>>>> stability.
>>>>>>
>>>>>> [ERROR] Failed to execute goal on project intersystem-jni4net: Could
>>>>>> not
>>>>>> resolve dependencies for project com.kodak.intersystem:**
>>>>>> intersystem-jni4net:jar:0.0.2-****SNAPSHOT: The following artifacts
>>>>>> could
>>>>>> not be resolved: com.kodak.intersystem:****
>>>>>> intersystem-common:jar:0.0.2-****SNAPSHOT,
>>>>>> com.kodak.intersystem:****intersystem-client:jar:0.0.2-****SNAPSHOT,
>>>>>> com.kodak.intersystem:****intersystem-service:jar:0.0.2-****SNAPSHOT,
>>>>>> com.kodak.intersystem:color-****repository:jar:0.0.2-SNAPSHOT: Failure
>>>>>> to
>>>>>> find com.kodak.intersystem:****intersystem-common:jar:0.0.2-****SNAPSHOT
>>>>>> in
>>>>>> http://nexus:8081/nexus/****content/groups/public<http://nexus:8081/nexus/**content/groups/public>
>>>>>> <http://**nexus:8081/nexus/content/**groups/public<http://nexus:8081/nexus/content/groups/public>>was
>>>>>> cached in the local repository, resolution will not be reattempted
until
>>>>>>
>>>>>> the update interval of nexus has elapsed or updates are forced ->
>>>>>>  [Help 1]
>>>>>>
>>>>>> When I look in my local repository I can see
>>>>>>
>>>>>> intersystem-common-0.0.2-****SNAPSHOT.jar.lastUpdated
>>>>>> intersystem-common-0.0.2-****SNAPSHOT.pom.lastUpdated
>>>>>>
>>>>>> but
>>>>>>
>>>>>> intersystem-common-0.0.2-****SNAPSHOT.jar
>>>>>> intersystem-common-0.0.2-****SNAPSHOT.pom
>>>>>>
>>>>>> are missing. Why is that when the previous 'deploy' succeeded?
>>>>>>
>>>>>>  ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>> <users-unsubscribe@**maven.apache.org<users-unsubscribe@maven.apache.org>
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>  ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>> <users-unsubscribe@**maven.apache.org<users-unsubscribe@maven.apache.org>
>>>> >
>>>>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message