maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Kolotyluk <eric.koloty...@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 14:51:38 GMT
@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.

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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message