On 1 September 2011 15:51, Eric Kolotyluk <[email protected]> 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 > <[email protected]>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 >>> <[email protected]>**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<[email protected]> >>>>> > >>>>> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>>> --**--------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>> <users-unsubscribe@**maven.apache.org<[email protected]> >>>> > >>>> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@maven.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
