Re: Local module repos and SNAPSHOT artifacts
On Feb 27, 2007, at 1:01 PM, Prasad Kashyap wrote: pom.xml: http://rifers.org/paste/show/3692 log: http://rifers.org/paste/show/3693 I think I am missing something very glaringly obvious here. Here's the glaringly obvious mistake I had made. Had set snaps to true and releases to false. Now it works. Check this into trunk... and then we can merge to m3, though I still don't think its worth the trouble for m3 since that branch is not going to live for too much longer. --jason
Re: Local module repos and SNAPSHOT artifacts
On 2/27/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > Folks, the local module repository thing is a massive hack, not meant > to be used as much as we are using it... and really it should *not* > have SNAPSHOT artifacts in it. > > When using snaps in these local artifacts, strange artifact > resolution failures are bound to occur when Maven decides its time to > go update snaps (daily for us). This causes problems when building a > module which depends on another module which has a module local repo > that contains snapshots, since the current module does not have > access to the dependency's repo it will cause an artifact resolution > exception. > > I did not check _all_ of the module local repos that we have in > server/trunk, but I know that at least in configs/jasper/repository > there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really > acceptable. First, its bad enough that we have to have this repo > here in the first place (the myfaces team should just publish snaps > like all other projects) and second, these artifacts are SNAPSHOT > which causes build problems as noted above. > > *If you must* use a module local repo, then *do not* put SNAPSHOT > artifacts in there... *if you must* then include the _timestamp- > build_ artifacts and configure your pom to use them, so that > dependent projects don't freak-out when mvn tries to update snaps. > > * * * > > I'm still working out a simply/elegant way to solve this problem of > remote repos and local repos, etc... but until I get that we need to > becareful about how we use these local repos and which remote repos > we include (I notice we still have a few legacy repos, which are a > big no-no). > > David Jencks mentioned in IRC today that it might be better if we > just had one location where all of these module-local repos artifacts > are kept. IMO, the module-local repos suck... but having one sucks > less than having more than one, so I'm inclined to agree this is a > good idea for the short-term. To make this work, we basically create > another top-level module (peer to modules and configs, etc) say named > "repository" (or whatever). This module contains the single local- > module repository in m2 format, which is only configured in that > modules pom. Then the pom lists all of the artifacts as dependencies > which are in the repo to force them to get installed into Maven's > local cache. This is exactly what I had tried too. Theoretically, this should have worked. A straightforward move from a lower module pom to a higher pom. But it fails to resolve the artifacts from module repo and move it to maven local repo. pom.xml: http://rifers.org/paste/show/3692 log: http://rifers.org/paste/show/3693 I think I am missing something very glaringly obvious here. Here's the glaringly obvious mistake I had made. Had set snaps to true and releases to false. Now it works. Cheers Prasad Cheers Prasad > > This module is added first, before all other children in the reactor, > which will *hopefully* always get that module executed first, those > deps installed and then other modules which depend on those custom > bits will already have them resolved in the local maven cache. It > sucks... but it sucks-less IMO than handful of repos that we have now > scattered through the project tree. > > I'm still working on getting a better solution to the entire remote > repo/repeatable build/blah, blah stuff... but until then I think this > is a decent step to simplify things a tiny bit more and help reduce > strange problems from popping up. > > * * * > > Comments? Unless there are any objections, I'll implement this in > the next day or so... BUT, still need someone to deal with the > myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we > leave the repos asis, or move to this one single short-term local repo. > > --jason >
Re: Local module repos and SNAPSHOT artifacts
On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Folks, the local module repository thing is a massive hack, not meant to be used as much as we are using it... and really it should *not* have SNAPSHOT artifacts in it. When using snaps in these local artifacts, strange artifact resolution failures are bound to occur when Maven decides its time to go update snaps (daily for us). This causes problems when building a module which depends on another module which has a module local repo that contains snapshots, since the current module does not have access to the dependency's repo it will cause an artifact resolution exception. I did not check _all_ of the module local repos that we have in server/trunk, but I know that at least in configs/jasper/repository there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really acceptable. First, its bad enough that we have to have this repo here in the first place (the myfaces team should just publish snaps like all other projects) and second, these artifacts are SNAPSHOT which causes build problems as noted above. *If you must* use a module local repo, then *do not* put SNAPSHOT artifacts in there... *if you must* then include the _timestamp- build_ artifacts and configure your pom to use them, so that dependent projects don't freak-out when mvn tries to update snaps. * * * I'm still working out a simply/elegant way to solve this problem of remote repos and local repos, etc... but until I get that we need to becareful about how we use these local repos and which remote repos we include (I notice we still have a few legacy repos, which are a big no-no). David Jencks mentioned in IRC today that it might be better if we just had one location where all of these module-local repos artifacts are kept. IMO, the module-local repos suck... but having one sucks less than having more than one, so I'm inclined to agree this is a good idea for the short-term. To make this work, we basically create another top-level module (peer to modules and configs, etc) say named "repository" (or whatever). This module contains the single local- module repository in m2 format, which is only configured in that modules pom. Then the pom lists all of the artifacts as dependencies which are in the repo to force them to get installed into Maven's local cache. This is exactly what I had tried too. Theoretically, this should have worked. A straightforward move from a lower module pom to a higher pom. But it fails to resolve the artifacts from module repo and move it to maven local repo. pom.xml: http://rifers.org/paste/show/3692 log: http://rifers.org/paste/show/3693 I think I am missing something very glaringly obvious here. Cheers Prasad This module is added first, before all other children in the reactor, which will *hopefully* always get that module executed first, those deps installed and then other modules which depend on those custom bits will already have them resolved in the local maven cache. It sucks... but it sucks-less IMO than handful of repos that we have now scattered through the project tree. I'm still working on getting a better solution to the entire remote repo/repeatable build/blah, blah stuff... but until then I think this is a decent step to simplify things a tiny bit more and help reduce strange problems from popping up. * * * Comments? Unless there are any objections, I'll implement this in the next day or so... BUT, still need someone to deal with the myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we leave the repos asis, or move to this one single short-term local repo. --jason
Re: Local module repos and SNAPSHOT artifacts
Excellent. Thanks Matthias! Best wishes, Paul On 2/24/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: Hello, currently continuum is building and deploying to: http://people.apache.org/repo/m2-snapshot-repository/ HTH, Matthias On 2/23/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > OK I think Matthias is watching this thread. > > Best wishes, > Paul > > On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > > Why do they need the deploy automated by Continuum to get something > > out in the snap repo? > > > > Someone should publish the first set by hand now so we can consume > > them... > > > > --jason > > > > > > On Feb 23, 2007, at 11:53 AM, Paul McMahan wrote: > > > > > There's a discussion right now on [EMAIL PROTECTED] about how to get their > > > 1.2 snapshots published to the ASF snapshot repo. I'm inclined to > > > leave the local repo in place for now since they appear to be close to > > > a solution, just working out some permission bits on contiuum I think. > > > But if there are immediate concerns I can adjust the jasper config to > > > use the staging repo that Matthias has kindly provided. Just let me > > > know. And of course Jason if you feel like moving things around then > > > don't let my foot dragging get in your way ;-) > > > > > > Best wishes, > > > Paul > > > > > > > > > On 2/23/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: > > >> > > >> --- Jason Dillon <[EMAIL PROTECTED]> wrote: > > >> > > >> > Folks, the local module repository thing is... and > > >> >really it should *not* have SNAPSHOT artifacts in it. > > >> I was tempted to change it 1.2.0-. Every morning my offline > > >> build fails in jasper config. I build jasper config online, which > > >> marks > > >> SNAPSHOTs as updated. After that everything works fine. Since > > >> there are > > >> two of us who have noticed it, it is time to change the SNAPSHOT to > > >> something else. > > >> > > >> Thanks > > >> Anita > > >> > > >> > > >> > > >> _ > > >> ___ > > >> Cheap talk? > > >> Check out Yahoo! Messenger's low PC-to-Phone call rates. > > >> http://voice.yahoo.com > > >> > > > > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
Hello, currently continuum is building and deploying to: http://people.apache.org/repo/m2-snapshot-repository/ HTH, Matthias On 2/23/07, Paul McMahan <[EMAIL PROTECTED]> wrote: OK I think Matthias is watching this thread. Best wishes, Paul On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > Why do they need the deploy automated by Continuum to get something > out in the snap repo? > > Someone should publish the first set by hand now so we can consume > them... > > --jason > > > On Feb 23, 2007, at 11:53 AM, Paul McMahan wrote: > > > There's a discussion right now on [EMAIL PROTECTED] about how to get their > > 1.2 snapshots published to the ASF snapshot repo. I'm inclined to > > leave the local repo in place for now since they appear to be close to > > a solution, just working out some permission bits on contiuum I think. > > But if there are immediate concerns I can adjust the jasper config to > > use the staging repo that Matthias has kindly provided. Just let me > > know. And of course Jason if you feel like moving things around then > > don't let my foot dragging get in your way ;-) > > > > Best wishes, > > Paul > > > > > > On 2/23/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: > >> > >> --- Jason Dillon <[EMAIL PROTECTED]> wrote: > >> > >> > Folks, the local module repository thing is... and > >> >really it should *not* have SNAPSHOT artifacts in it. > >> I was tempted to change it 1.2.0-. Every morning my offline > >> build fails in jasper config. I build jasper config online, which > >> marks > >> SNAPSHOTs as updated. After that everything works fine. Since > >> there are > >> two of us who have noticed it, it is time to change the SNAPSHOT to > >> something else. > >> > >> Thanks > >> Anita > >> > >> > >> > >> _ > >> ___ > >> Cheap talk? > >> Check out Yahoo! Messenger's low PC-to-Phone call rates. > >> http://voice.yahoo.com > >> > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
OK I think Matthias is watching this thread. Best wishes, Paul On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Why do they need the deploy automated by Continuum to get something out in the snap repo? Someone should publish the first set by hand now so we can consume them... --jason On Feb 23, 2007, at 11:53 AM, Paul McMahan wrote: > There's a discussion right now on [EMAIL PROTECTED] about how to get their > 1.2 snapshots published to the ASF snapshot repo. I'm inclined to > leave the local repo in place for now since they appear to be close to > a solution, just working out some permission bits on contiuum I think. > But if there are immediate concerns I can adjust the jasper config to > use the staging repo that Matthias has kindly provided. Just let me > know. And of course Jason if you feel like moving things around then > don't let my foot dragging get in your way ;-) > > Best wishes, > Paul > > > On 2/23/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: >> >> --- Jason Dillon <[EMAIL PROTECTED]> wrote: >> >> > Folks, the local module repository thing is... and >> >really it should *not* have SNAPSHOT artifacts in it. >> I was tempted to change it 1.2.0-. Every morning my offline >> build fails in jasper config. I build jasper config online, which >> marks >> SNAPSHOTs as updated. After that everything works fine. Since >> there are >> two of us who have noticed it, it is time to change the SNAPSHOT to >> something else. >> >> Thanks >> Anita >> >> >> >> _ >> ___ >> Cheap talk? >> Check out Yahoo! Messenger's low PC-to-Phone call rates. >> http://voice.yahoo.com >>
Re: Local module repos and SNAPSHOT artifacts
Why do they need the deploy automated by Continuum to get something out in the snap repo? Someone should publish the first set by hand now so we can consume them... --jason On Feb 23, 2007, at 11:53 AM, Paul McMahan wrote: There's a discussion right now on [EMAIL PROTECTED] about how to get their 1.2 snapshots published to the ASF snapshot repo. I'm inclined to leave the local repo in place for now since they appear to be close to a solution, just working out some permission bits on contiuum I think. But if there are immediate concerns I can adjust the jasper config to use the staging repo that Matthias has kindly provided. Just let me know. And of course Jason if you feel like moving things around then don't let my foot dragging get in your way ;-) Best wishes, Paul On 2/23/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: --- Jason Dillon <[EMAIL PROTECTED]> wrote: > Folks, the local module repository thing is... and >really it should *not* have SNAPSHOT artifacts in it. I was tempted to change it 1.2.0-. Every morning my offline build fails in jasper config. I build jasper config online, which marks SNAPSHOTs as updated. After that everything works fine. Since there are two of us who have noticed it, it is time to change the SNAPSHOT to something else. Thanks Anita _ ___ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Re: Local module repos and SNAPSHOT artifacts
There's a discussion right now on [EMAIL PROTECTED] about how to get their 1.2 snapshots published to the ASF snapshot repo. I'm inclined to leave the local repo in place for now since they appear to be close to a solution, just working out some permission bits on contiuum I think. But if there are immediate concerns I can adjust the jasper config to use the staging repo that Matthias has kindly provided. Just let me know. And of course Jason if you feel like moving things around then don't let my foot dragging get in your way ;-) Best wishes, Paul On 2/23/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: --- Jason Dillon <[EMAIL PROTECTED]> wrote: > Folks, the local module repository thing is... and >really it should *not* have SNAPSHOT artifacts in it. I was tempted to change it 1.2.0-. Every morning my offline build fails in jasper config. I build jasper config online, which marks SNAPSHOTs as updated. After that everything works fine. Since there are two of us who have noticed it, it is time to change the SNAPSHOT to something else. Thanks Anita Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Re: Local module repos and SNAPSHOT artifacts
--- Jason Dillon <[EMAIL PROTECTED]> wrote: > Folks, the local module repository thing is... and >really it should *not* have SNAPSHOT artifacts in it. I was tempted to change it 1.2.0-. Every morning my offline build fails in jasper config. I build jasper config online, which marks SNAPSHOTs as updated. After that everything works fine. Since there are two of us who have noticed it, it is time to change the SNAPSHOT to something else. Thanks Anita Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Re: Local module repos and SNAPSHOT artifacts
Good, any idea when the 1.2.0-SNAPSHOT artifacts will make it into there? This would allow us to drop one of the module-local repos I was referring to. I'd rather not configure yet another remote repository URL though, and each time we do that it slows the build down, we've already got a few in there which I'd like to get rid of ;-) --jason On Feb 23, 2007, at 4:14 AM, Matthias Wessendorf wrote: at least into the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Are you folks eventually going to merge these artifacts into the main apache repos? --jason On Feb 23, 2007, at 4:02 AM, Matthias Wessendorf wrote: > Jason, > > I just created a staging repo for the myfaces 12 snapshot things. > We are working on getting the myfaces12 build by continuum every > night. > > However, here the stage goes: > http://people.apache.org/~matzew/myfaces12-stage/ > > -M > > On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Folks, the local module repository thing is a massive hack, not meant >> to be used as much as we are using it... and really it should *not* >> have SNAPSHOT artifacts in it. >> >> When using snaps in these local artifacts, strange artifact >> resolution failures are bound to occur when Maven decides its time to >> go update snaps (daily for us). This causes problems when building a >> module which depends on another module which has a module local repo >> that contains snapshots, since the current module does not have >> access to the dependency's repo it will cause an artifact resolution >> exception. >> >> I did not check _all_ of the module local repos that we have in >> server/trunk, but I know that at least in configs/jasper/ repository >> there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really >> acceptable. First, its bad enough that we have to have this repo >> here in the first place (the myfaces team should just publish snaps >> like all other projects) and second, these artifacts are SNAPSHOT >> which causes build problems as noted above. >> >> *If you must* use a module local repo, then *do not* put SNAPSHOT >> artifacts in there... *if you must* then include the _timestamp- >> build_ artifacts and configure your pom to use them, so that >> dependent projects don't freak-out when mvn tries to update snaps. >> >> * * * >> >> I'm still working out a simply/elegant way to solve this problem of >> remote repos and local repos, etc... but until I get that we need to >> becareful about how we use these local repos and which remote repos >> we include (I notice we still have a few legacy repos, which are a >> big no-no). >> >> David Jencks mentioned in IRC today that it might be better if we >> just had one location where all of these module-local repos artifacts >> are kept. IMO, the module-local repos suck... but having one sucks >> less than having more than one, so I'm inclined to agree this is a >> good idea for the short-term. To make this work, we basically create >> another top-level module (peer to modules and configs, etc) say named >> "repository" (or whatever). This module contains the single local- >> module repository in m2 format, which is only configured in that >> modules pom. Then the pom lists all of the artifacts as dependencies >> which are in the repo to force them to get installed into Maven's >> local cache. >> >> This module is added first, before all other children in the reactor, >> which will *hopefully* always get that module executed first, those >> deps installed and then other modules which depend on those custom >> bits will already have them resolved in the local maven cache. It >> sucks... but it sucks-less IMO than handful of repos that we have now >> scattered through the project tree. >> >> I'm still working on getting a better solution to the entire remote >> repo/repeatable build/blah, blah stuff... but until then I think this >> is a decent step to simplify things a tiny bit more and help reduce >> strange problems from popping up. >> >> * * * >> >> Comments? Unless there are any objections, I'll implement this in >> the next day or so... BUT, still need someone to deal with the >> myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we >> leave the repos asis, or move to this one single short-term local >> repo. >> >> --jason >> > > > -- > Matthias Wessendorf > http://tinyurl.com/fmywh > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
at least into the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Are you folks eventually going to merge these artifacts into the main apache repos? --jason On Feb 23, 2007, at 4:02 AM, Matthias Wessendorf wrote: > Jason, > > I just created a staging repo for the myfaces 12 snapshot things. > We are working on getting the myfaces12 build by continuum every > night. > > However, here the stage goes: > http://people.apache.org/~matzew/myfaces12-stage/ > > -M > > On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Folks, the local module repository thing is a massive hack, not meant >> to be used as much as we are using it... and really it should *not* >> have SNAPSHOT artifacts in it. >> >> When using snaps in these local artifacts, strange artifact >> resolution failures are bound to occur when Maven decides its time to >> go update snaps (daily for us). This causes problems when building a >> module which depends on another module which has a module local repo >> that contains snapshots, since the current module does not have >> access to the dependency's repo it will cause an artifact resolution >> exception. >> >> I did not check _all_ of the module local repos that we have in >> server/trunk, but I know that at least in configs/jasper/repository >> there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really >> acceptable. First, its bad enough that we have to have this repo >> here in the first place (the myfaces team should just publish snaps >> like all other projects) and second, these artifacts are SNAPSHOT >> which causes build problems as noted above. >> >> *If you must* use a module local repo, then *do not* put SNAPSHOT >> artifacts in there... *if you must* then include the _timestamp- >> build_ artifacts and configure your pom to use them, so that >> dependent projects don't freak-out when mvn tries to update snaps. >> >> * * * >> >> I'm still working out a simply/elegant way to solve this problem of >> remote repos and local repos, etc... but until I get that we need to >> becareful about how we use these local repos and which remote repos >> we include (I notice we still have a few legacy repos, which are a >> big no-no). >> >> David Jencks mentioned in IRC today that it might be better if we >> just had one location where all of these module-local repos artifacts >> are kept. IMO, the module-local repos suck... but having one sucks >> less than having more than one, so I'm inclined to agree this is a >> good idea for the short-term. To make this work, we basically create >> another top-level module (peer to modules and configs, etc) say named >> "repository" (or whatever). This module contains the single local- >> module repository in m2 format, which is only configured in that >> modules pom. Then the pom lists all of the artifacts as dependencies >> which are in the repo to force them to get installed into Maven's >> local cache. >> >> This module is added first, before all other children in the reactor, >> which will *hopefully* always get that module executed first, those >> deps installed and then other modules which depend on those custom >> bits will already have them resolved in the local maven cache. It >> sucks... but it sucks-less IMO than handful of repos that we have now >> scattered through the project tree. >> >> I'm still working on getting a better solution to the entire remote >> repo/repeatable build/blah, blah stuff... but until then I think this >> is a decent step to simplify things a tiny bit more and help reduce >> strange problems from popping up. >> >> * * * >> >> Comments? Unless there are any objections, I'll implement this in >> the next day or so... BUT, still need someone to deal with the >> myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we >> leave the repos asis, or move to this one single short-term local >> repo. >> >> --jason >> > > > -- > Matthias Wessendorf > http://tinyurl.com/fmywh > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
Are you folks eventually going to merge these artifacts into the main apache repos? --jason On Feb 23, 2007, at 4:02 AM, Matthias Wessendorf wrote: Jason, I just created a staging repo for the myfaces 12 snapshot things. We are working on getting the myfaces12 build by continuum every night. However, here the stage goes: http://people.apache.org/~matzew/myfaces12-stage/ -M On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Folks, the local module repository thing is a massive hack, not meant to be used as much as we are using it... and really it should *not* have SNAPSHOT artifacts in it. When using snaps in these local artifacts, strange artifact resolution failures are bound to occur when Maven decides its time to go update snaps (daily for us). This causes problems when building a module which depends on another module which has a module local repo that contains snapshots, since the current module does not have access to the dependency's repo it will cause an artifact resolution exception. I did not check _all_ of the module local repos that we have in server/trunk, but I know that at least in configs/jasper/repository there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really acceptable. First, its bad enough that we have to have this repo here in the first place (the myfaces team should just publish snaps like all other projects) and second, these artifacts are SNAPSHOT which causes build problems as noted above. *If you must* use a module local repo, then *do not* put SNAPSHOT artifacts in there... *if you must* then include the _timestamp- build_ artifacts and configure your pom to use them, so that dependent projects don't freak-out when mvn tries to update snaps. * * * I'm still working out a simply/elegant way to solve this problem of remote repos and local repos, etc... but until I get that we need to becareful about how we use these local repos and which remote repos we include (I notice we still have a few legacy repos, which are a big no-no). David Jencks mentioned in IRC today that it might be better if we just had one location where all of these module-local repos artifacts are kept. IMO, the module-local repos suck... but having one sucks less than having more than one, so I'm inclined to agree this is a good idea for the short-term. To make this work, we basically create another top-level module (peer to modules and configs, etc) say named "repository" (or whatever). This module contains the single local- module repository in m2 format, which is only configured in that modules pom. Then the pom lists all of the artifacts as dependencies which are in the repo to force them to get installed into Maven's local cache. This module is added first, before all other children in the reactor, which will *hopefully* always get that module executed first, those deps installed and then other modules which depend on those custom bits will already have them resolved in the local maven cache. It sucks... but it sucks-less IMO than handful of repos that we have now scattered through the project tree. I'm still working on getting a better solution to the entire remote repo/repeatable build/blah, blah stuff... but until then I think this is a decent step to simplify things a tiny bit more and help reduce strange problems from popping up. * * * Comments? Unless there are any objections, I'll implement this in the next day or so... BUT, still need someone to deal with the myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we leave the repos asis, or move to this one single short-term local repo. --jason -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
Jason, I just created a staging repo for the myfaces 12 snapshot things. We are working on getting the myfaces12 build by continuum every night. However, here the stage goes: http://people.apache.org/~matzew/myfaces12-stage/ -M On 2/23/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Folks, the local module repository thing is a massive hack, not meant to be used as much as we are using it... and really it should *not* have SNAPSHOT artifacts in it. When using snaps in these local artifacts, strange artifact resolution failures are bound to occur when Maven decides its time to go update snaps (daily for us). This causes problems when building a module which depends on another module which has a module local repo that contains snapshots, since the current module does not have access to the dependency's repo it will cause an artifact resolution exception. I did not check _all_ of the module local repos that we have in server/trunk, but I know that at least in configs/jasper/repository there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really acceptable. First, its bad enough that we have to have this repo here in the first place (the myfaces team should just publish snaps like all other projects) and second, these artifacts are SNAPSHOT which causes build problems as noted above. *If you must* use a module local repo, then *do not* put SNAPSHOT artifacts in there... *if you must* then include the _timestamp- build_ artifacts and configure your pom to use them, so that dependent projects don't freak-out when mvn tries to update snaps. * * * I'm still working out a simply/elegant way to solve this problem of remote repos and local repos, etc... but until I get that we need to becareful about how we use these local repos and which remote repos we include (I notice we still have a few legacy repos, which are a big no-no). David Jencks mentioned in IRC today that it might be better if we just had one location where all of these module-local repos artifacts are kept. IMO, the module-local repos suck... but having one sucks less than having more than one, so I'm inclined to agree this is a good idea for the short-term. To make this work, we basically create another top-level module (peer to modules and configs, etc) say named "repository" (or whatever). This module contains the single local- module repository in m2 format, which is only configured in that modules pom. Then the pom lists all of the artifacts as dependencies which are in the repo to force them to get installed into Maven's local cache. This module is added first, before all other children in the reactor, which will *hopefully* always get that module executed first, those deps installed and then other modules which depend on those custom bits will already have them resolved in the local maven cache. It sucks... but it sucks-less IMO than handful of repos that we have now scattered through the project tree. I'm still working on getting a better solution to the entire remote repo/repeatable build/blah, blah stuff... but until then I think this is a decent step to simplify things a tiny bit more and help reduce strange problems from popping up. * * * Comments? Unless there are any objections, I'll implement this in the next day or so... BUT, still need someone to deal with the myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we leave the repos asis, or move to this one single short-term local repo. --jason -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Local module repos and SNAPSHOT artifacts
Oh ya... insert :-) every few lines... :-P --jason On Feb 23, 2007, at 2:27 AM, Jason Dillon wrote: Folks, the local module repository thing is a massive hack, not meant to be used as much as we are using it... and really it should *not* have SNAPSHOT artifacts in it. When using snaps in these local artifacts, strange artifact resolution failures are bound to occur when Maven decides its time to go update snaps (daily for us). This causes problems when building a module which depends on another module which has a module local repo that contains snapshots, since the current module does not have access to the dependency's repo it will cause an artifact resolution exception. I did not check _all_ of the module local repos that we have in server/trunk, but I know that at least in configs/jasper/repository there are myfaces 1.2.0-SNAPSHOT artifacts. This is not really acceptable. First, its bad enough that we have to have this repo here in the first place (the myfaces team should just publish snaps like all other projects) and second, these artifacts are SNAPSHOT which causes build problems as noted above. *If you must* use a module local repo, then *do not* put SNAPSHOT artifacts in there... *if you must* then include the _timestamp- build_ artifacts and configure your pom to use them, so that dependent projects don't freak-out when mvn tries to update snaps. * * * I'm still working out a simply/elegant way to solve this problem of remote repos and local repos, etc... but until I get that we need to becareful about how we use these local repos and which remote repos we include (I notice we still have a few legacy repos, which are a big no-no). David Jencks mentioned in IRC today that it might be better if we just had one location where all of these module-local repos artifacts are kept. IMO, the module-local repos suck... but having one sucks less than having more than one, so I'm inclined to agree this is a good idea for the short-term. To make this work, we basically create another top-level module (peer to modules and configs, etc) say named "repository" (or whatever). This module contains the single local-module repository in m2 format, which is only configured in that modules pom. Then the pom lists all of the artifacts as dependencies which are in the repo to force them to get installed into Maven's local cache. This module is added first, before all other children in the reactor, which will *hopefully* always get that module executed first, those deps installed and then other modules which depend on those custom bits will already have them resolved in the local maven cache. It sucks... but it sucks-less IMO than handful of repos that we have now scattered through the project tree. I'm still working on getting a better solution to the entire remote repo/repeatable build/blah, blah stuff... but until then I think this is a decent step to simplify things a tiny bit more and help reduce strange problems from popping up. * * * Comments? Unless there are any objections, I'll implement this in the next day or so... BUT, still need someone to deal with the myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even if we leave the repos asis, or move to this one single short-term local repo. --jason
