You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Eric Kolotyluk <er...@gmail.com> on 2011/09/01 05:54:14 UTC
resolution will not be reattempted until the update interval of nexus
has elapsed or updates are forced
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 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.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced
Posted by Stephen Connolly <st...@gmail.com>.
On 1 September 2011 15:51, Eric Kolotyluk <er...@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
> <gu...@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
>>> <gu...@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>
>>>>> <us...@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>
>>>> <us...@maven.apache.org>
>>>> >
>>>>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@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
Re: resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced
Posted by Eric Kolotyluk <er...@gmail.com>.
@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
<gu...@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
>> <gu...@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>
>>>> <us...@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>
>>> <us...@maven.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Guillaume Polet <gu...@gmail.com>.
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
> <gu...@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>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.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@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
Re: resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced
Posted by Eric Kolotyluk <er...@gmail.com>.
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
<gu...@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>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.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/09/2011 9:42 AM, Matta, Sunil wrote:
> Ron, all: this is exactly what I have been going through over the last few weeks.
>
> Coming from a C++/makefile environment, this is my first foray into the maven world.
> We have 70+ projects as well, and the plan has been to only release that were modified, followed by projects that depend on them, and so on.
> So, we have to modify each pom, go up the dependency tree and figure out the inverse transitive dependencies.
We made our life a bit easier:
- we separated out the database access stuff into a set of modules
- we organized our utilities and common functions into modules with few
dependencies on each other.
We also organized our release plan spreadsheet so that it had a build
group sequence associated with each module so that you could build all
of the "1"s before doing the "2"s and so on.
We only had to do the dependency analysis once and did a review of the
sequence as part of the planning session for a new release.
As a very small team, we tended to work on a few modules at once so we
did not need a massive rebuild script.
The developer just updated the pom and the code for the module, tested
it and deployed the SNAPSHOT and moved to the next one in the sequence
which had been assigned to them.
Ron
> This release process takes forever when we have to do a FULL release. Even incremental releases can be painful if one of the most dependent project have been updated/released.
>
> I too wanted to keep all versions of modules in the parent pom file. Much like a top level make file. So, I am very curious in why this parent pom file approach didn't work ??
>
> Here is what I have done to help with the release process:
> I wrote a perl module to go through the full tree to figure out the projects that need to be released, and modify the relevant pom files.
> However, the order of release is still a concern. I can use the output of the mvn command to release, but this gives me the _name_ of the project, and not the artifactId. I could keep a mapping but this is error prone and should not be necessary.
>
>
> To complete the process, I have a couple of questions though:
>
> 1) What prints the output of a simple "mvn clean" command ? Is it some plugin ? Reactor ? Or maven itself ??
> 2) Is there a configuration to get the artificatId instead of/in addition to the project name from the mvn output ?
>
>
> tia,
>
>
> Sunil
>
>
>
> -----Original Message-----
> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Sent: 2011, September, 01 9:26 AM
> To: users@maven.apache.org
> Subject: Re: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
>
> We started by changing the version of every module but eventually went to a policy of only changing the versions of modules that changed.
>
> The project was a portal with 70+ modules so it was a PITA to change all the versions.
> Not a big project overhead but we got tired of it and once we had moved much of the architecture to SOA with Web Services, it became clear that in a new release of the portal, most of the modules did not actually change.
>
> We then just reversioned the changed modules, produced a new parent version and a new version of the core modules that dealt with the persistence since the database had changed.
>
> We used a simple spreadsheet to document the versions of the modules that were required to build the new version of the portal.
>
> Made our lives a lot simpler and we started to think of our own code in the same way that we viewed third party libraries - if we did not need to upgrade to fix a bug or get new functionality then we left the old version intact.
>
> This obviously had a lot of benefits in testing and reduction of useless builds.
>
> We did not use the parent for managing the versions of dependencies in the modules since we had a better scheme for managing that.
>
> Ron
>
> On 01/09/2011 3:59 AM, Guillaume Polet 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 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.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
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ________________________________________
>
> This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above.
>
> The sender does not waive any of its rights, privileges or other protections respecting this information.
>
> Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited.
>
> If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately.
>
> This E-Mail (including any attachments) has been scanned for viruses.
>
> It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened.
>
> However, it is the responsibility of the recipient to ensure that it is virus free.
>
> The sender accepts no responsibility for any loss or damage arising in any way from its use.
>
> E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel.
>
> Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
>
> IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVICE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
RE: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
Posted by "Matta, Sunil" <su...@rbccm.com>.
Ron, all: this is exactly what I have been going through over the last few weeks.
Coming from a C++/makefile environment, this is my first foray into the maven world.
We have 70+ projects as well, and the plan has been to only release that were modified, followed by projects that depend on them, and so on.
So, we have to modify each pom, go up the dependency tree and figure out the inverse transitive dependencies.
This release process takes forever when we have to do a FULL release. Even incremental releases can be painful if one of the most dependent project have been updated/released.
I too wanted to keep all versions of modules in the parent pom file. Much like a top level make file. So, I am very curious in why this parent pom file approach didn't work ??
Here is what I have done to help with the release process:
I wrote a perl module to go through the full tree to figure out the projects that need to be released, and modify the relevant pom files.
However, the order of release is still a concern. I can use the output of the mvn command to release, but this gives me the _name_ of the project, and not the artifactId. I could keep a mapping but this is error prone and should not be necessary.
To complete the process, I have a couple of questions though:
1) What prints the output of a simple "mvn clean" command ? Is it some plugin ? Reactor ? Or maven itself ??
2) Is there a configuration to get the artificatId instead of/in addition to the project name from the mvn output ?
tia,
Sunil
-----Original Message-----
From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Sent: 2011, September, 01 9:26 AM
To: users@maven.apache.org
Subject: Re: resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
We started by changing the version of every module but eventually went to a policy of only changing the versions of modules that changed.
The project was a portal with 70+ modules so it was a PITA to change all the versions.
Not a big project overhead but we got tired of it and once we had moved much of the architecture to SOA with Web Services, it became clear that in a new release of the portal, most of the modules did not actually change.
We then just reversioned the changed modules, produced a new parent version and a new version of the core modules that dealt with the persistence since the database had changed.
We used a simple spreadsheet to document the versions of the modules that were required to build the new version of the portal.
Made our lives a lot simpler and we started to think of our own code in the same way that we viewed third party libraries - if we did not need to upgrade to fix a bug or get new functionality then we left the old version intact.
This obviously had a lot of benefits in testing and reduction of useless builds.
We did not use the parent for managing the versions of dependencies in the modules since we had a better scheme for managing that.
Ron
On 01/09/2011 3:59 AM, Guillaume Polet 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 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.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
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
________________________________________
This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protections respecting this information.
Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited.
If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately.
This E-Mail (including any attachments) has been scanned for viruses.
It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened.
However, it is the responsibility of the recipient to ensure that it is virus free.
The sender accepts no responsibility for any loss or damage arising in any way from its use.
E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel.
Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVICE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Guillaume Polet <gu...@gmail.com>.
Le 1/09/2011 16:45, Eric Kolotyluk a écrit :
> Interesting - thanks for sharing that.
>
> At the moment I do not really need to change versions, I was experimenting
> to see if I could understand the process. Do I have the following ideas
> right?
>
> 1. I changed my version from 0.0.1-SNAPSHOT to 0.0.2-SNAPSHOT as a test
> to see what happens. Since I have not actually done a release, then
> technically I really do not need to increment the version.
Yes indeed, this is not needed. Once you have created a release,
requests for the snapshot will be answered with the release version and
it is strongly discouraged to overwrite a release.
> 2. Would the normal practice be to:
> - Perform a mvn release
> - Create a new SCM branch from the current release on the main branch
> - Increment the version(s) on the main branch
That would be my way to do it.
> 3. Or would it be better to:
> - Create a new SCM branch from main
> - Perform a mvn release from the new branch
> - Increment the version(s) on the main branch
That would not be my way to do it, but I guess this is as valid.
> 4. In my case I have less than a dozen modules and they are tightly
> related, so I want all the versions to match the parent. It would be nice if
> I could just change the version of the parent POM and have everything fall
> out from there, but I seem to have to change it elsewhere too.
Maven release is your friend there: on multi-module projects, you can
ask to move all version to the same new one. If you do this manually,
then yes, there is no alternative but to modify all pom's file.
>
> Cheers, Eric
Guillaume
>
> On Thu, Sep 1, 2011 at 6:26 AM, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> We started by changing the version of every module but eventually went to a
>> policy of only changing the versions of modules that changed.
>>
>> The project was a portal with 70+ modules so it was a PITA to change all
>> the versions.
>> Not a big project overhead but we got tired of it and once we had moved
>> much of the architecture to SOA with Web Services, it became clear that in a
>> new release of the portal, most of the modules did not actually change.
>>
>> We then just reversioned the changed modules, produced a new parent version
>> and a new version of the core modules that dealt with the persistence since
>> the database had changed.
>>
>> We used a simple spreadsheet to document the versions of the modules that
>> were required to build the new version of the portal.
>>
>> Made our lives a lot simpler and we started to think of our own code in the
>> same way that we viewed third party libraries - if we did not need to
>> upgrade to fix a bug or get new functionality then we left the old version
>> intact.
>>
>> This obviously had a lot of benefits in testing and reduction of useless
>> builds.
>>
>> We did not use the parent for managing the versions of dependencies in the
>> modules since we had a better scheme for managing that.
>>
>> Ron
>>
>>
>> On 01/09/2011 3:59 AM, Guillaume Polet 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>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.**apache.org<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/09/2011 10:45 AM, Eric Kolotyluk wrote:
> Interesting - thanks for sharing that.
>
> At the moment I do not really need to change versions, I was experimenting
> to see if I could understand the process. Do I have the following ideas
> right?
>
> 1. I changed my version from 0.0.1-SNAPSHOT to 0.0.2-SNAPSHOT as a test
> to see what happens. Since I have not actually done a release, then
> technically I really do not need to increment the version.
> 2. Would the normal practice be to:
> - Perform a mvn release
> - Create a new SCM branch from the current release on the main branch
> - Increment the version(s) on the main branch
> 3. Or would it be better to:
> - Create a new SCM branch from main
> - Perform a mvn release from the new branch
> - Increment the version(s) on the main branch
> 4. In my case I have less than a dozen modules and they are tightly
> related, so I want all the versions to match the parent. It would be nice if
> I could just change the version of the parent POM and have everything fall
> out from there, but I seem to have to change it elsewhere too.
Yes.
When preparing a new release, you will need to take 10 minutes to
prepare a new set of poms that match up.
If you are not changing anything else in the configuration - same third
party libraries - then you are done.
In the parent, you change its version and in the children you change the
version of the children and that of the parent. No big deal for 12 modules.
Rebuild to see that you did not forget a dot or a digit and you are
ready to release the hounds.
It is not worth automating or worrying about.
Prior to that, in the SCM, we tag or branch the old release and work on
the head if we are doing new development.
If we are bug-fixing an older release while development is progressing
on a new release, we create a branch on the buggy release if it does not
already exist and work on that branch.
Not worth automating if you have a decent IDE and SCM. 10-15 minutes
tops for a junior programmer.
Ron
>
> Cheers, Eric
>
>
> On Thu, Sep 1, 2011 at 6:26 AM, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> We started by changing the version of every module but eventually went to a
>> policy of only changing the versions of modules that changed.
>>
>> The project was a portal with 70+ modules so it was a PITA to change all
>> the versions.
>> Not a big project overhead but we got tired of it and once we had moved
>> much of the architecture to SOA with Web Services, it became clear that in a
>> new release of the portal, most of the modules did not actually change.
>>
>> We then just reversioned the changed modules, produced a new parent version
>> and a new version of the core modules that dealt with the persistence since
>> the database had changed.
>>
>> We used a simple spreadsheet to document the versions of the modules that
>> were required to build the new version of the portal.
>>
>> Made our lives a lot simpler and we started to think of our own code in the
>> same way that we viewed third party libraries - if we did not need to
>> upgrade to fix a bug or get new functionality then we left the old version
>> intact.
>>
>> This obviously had a lot of benefits in testing and reduction of useless
>> builds.
>>
>> We did not use the parent for managing the versions of dependencies in the
>> modules since we had a better scheme for managing that.
>>
>> Ron
>>
>>
>> On 01/09/2011 3:59 AM, Guillaume Polet 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>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.**apache.org<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced
Posted by Eric Kolotyluk <er...@gmail.com>.
Interesting - thanks for sharing that.
At the moment I do not really need to change versions, I was experimenting
to see if I could understand the process. Do I have the following ideas
right?
1. I changed my version from 0.0.1-SNAPSHOT to 0.0.2-SNAPSHOT as a test
to see what happens. Since I have not actually done a release, then
technically I really do not need to increment the version.
2. Would the normal practice be to:
- Perform a mvn release
- Create a new SCM branch from the current release on the main branch
- Increment the version(s) on the main branch
3. Or would it be better to:
- Create a new SCM branch from main
- Perform a mvn release from the new branch
- Increment the version(s) on the main branch
4. In my case I have less than a dozen modules and they are tightly
related, so I want all the versions to match the parent. It would be nice if
I could just change the version of the parent POM and have everything fall
out from there, but I seem to have to change it elsewhere too.
Cheers, Eric
On Thu, Sep 1, 2011 at 6:26 AM, Ron Wheeler
<rw...@artifact-software.com>wrote:
> We started by changing the version of every module but eventually went to a
> policy of only changing the versions of modules that changed.
>
> The project was a portal with 70+ modules so it was a PITA to change all
> the versions.
> Not a big project overhead but we got tired of it and once we had moved
> much of the architecture to SOA with Web Services, it became clear that in a
> new release of the portal, most of the modules did not actually change.
>
> We then just reversioned the changed modules, produced a new parent version
> and a new version of the core modules that dealt with the persistence since
> the database had changed.
>
> We used a simple spreadsheet to document the versions of the modules that
> were required to build the new version of the portal.
>
> Made our lives a lot simpler and we started to think of our own code in the
> same way that we viewed third party libraries - if we did not need to
> upgrade to fix a bug or get new functionality then we left the old version
> intact.
>
> This obviously had a lot of benefits in testing and reduction of useless
> builds.
>
> We did not use the parent for managing the versions of dependencies in the
> modules since we had a better scheme for managing that.
>
> Ron
>
>
> On 01/09/2011 3:59 AM, Guillaume Polet 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>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.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Ron Wheeler <rw...@artifact-software.com>.
We started by changing the version of every module but eventually went
to a policy of only changing the versions of modules that changed.
The project was a portal with 70+ modules so it was a PITA to change all
the versions.
Not a big project overhead but we got tired of it and once we had moved
much of the architecture to SOA with Web Services, it became clear that
in a new release of the portal, most of the modules did not actually change.
We then just reversioned the changed modules, produced a new parent
version and a new version of the core modules that dealt with the
persistence since the database had changed.
We used a simple spreadsheet to document the versions of the modules
that were required to build the new version of the portal.
Made our lives a lot simpler and we started to think of our own code in
the same way that we viewed third party libraries - if we did not need
to upgrade to fix a bug or get new functionality then we left the old
version intact.
This obviously had a lot of benefits in testing and reduction of useless
builds.
We did not use the parent for managing the versions of dependencies in
the modules since we had a better scheme for managing that.
Ron
On 01/09/2011 3:59 AM, Guillaume Polet 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 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.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
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Guillaume Polet <gu...@gmail.com>.
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 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.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
Re: resolution will not be reattempted until the update interval
of nexus has elapsed or updates are forced
Posted by Eric Kolotyluk <er...@gmail.com>.
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 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.apache.org
For additional commands, e-mail: users-help@maven.apache.org