| Re[2]: [higgins-dev] preliminary proposed change to BuildFileCreator.java |
I agree that it would be better to check out dependency projects into workspace directly then to temporary folder but didn't want to make significant changes to the existing script from nightly builds just to show the idea. With regards to failure most likely it was because of Windows path separators used there... Attached one should work fine. Please note that you don't need execs.xml anymore because now it is already in higgins.auto. Monday, October 22, 2007, 8:44:18 PM, you wrote: > Yes, the plugins path is hard-coded. This works for all the > projects I care about. I agree that a more usable approach is > needed. I was not seeing anything being communicated about it, so I > figured this was on the backburner. > Also, correct, it doesn't pull down 3r'd party libs, but would if > all 3rd party libs were in plugin projects as Paul suggested (still > leaves the problem of non-redistributables) > While I prefer a model where each project's build is more > self-contained (doesn't require me to use the auto build project) I > think that's fine if that's what we have. I tired the config script > and it began working but then failed with: > runHigginsAuto: > [copy] Copying 1 file to > /home/jimse/Desktop/temp/deployment.idas.basic/build/temp/build/org.eclipse.higgins.auto/runtime > [exec] Buildfile: > /home/jimse/Desktop/temp/deployment.idas.basic\build\temp\build/org.eclipse.higgins.auto/runtime/execs.xml does not exist! > [exec] Build failed > [exec] Result: 1 > configure: > BUILD FAILED > /home/jimse/Desktop/temp/deployment.idas.basic/config.xml:38: > /home/jimse/Desktop/temp/deployment.idas.basic/build/temp/work/bDir not found. > note that execs.xml is in my project's folder. > I would rather have the result of such a script be that the > dependency projects are actually checked into sibling directories as > the project I'm running (not into temp directories). This is how my > workspace exists today -- I want things to work the way they do > today, only automated such that if I don't yet have everything > checked out (or if I have the wrong version checked out), the build > will fix things up for me. I don't like the idea of lots of > churning going on to copy stuff down to temp directories. But > that's just me -- if everyone else likes this, then I'll be a silent minority :) > >>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 10/22/07 10:28 AM >>> > Hi Jim, > The only problem I see with that is that repository path you're using > is hard coded (i.e. org.eclipse.higgins/plugins/) but not all our > projects are located there. Also it can't download 3rd party libs if > necessary. > I'd propose another target which uses resoureLocation.xml from > higgins.auto... > Please try attached config.xml script. > It has few problems right now but it show the idea. > In order to use it place both attached scripts into the project folder > (single project checked out into empty workspace) and run "ant -f > config.xml". As the result you should get all project dependencies > fetched with all 3rd party libraries downloaded. > Valery > Monday, October 22, 2007, 8:50:19 AM, you wrote: >> All, >> The change outlined in this patch will add a target to build.xml >> called "fetch-subprojects". If your build.properties file contains a line like this: >> ensure.dependencies.version = HEAD >> (where HEAD can be any cvs tag), then the fetch-subprojects target >> will use cvs to pull down all dependency projects (recursively) >> using the version specified in build.properties. >> If ensure.dependencies.version is not set, then nothing happens for the fetch-subprojects target. >> Anyone have issues with me adding this? >> Jim > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev
Attachment:
config.xml
Description: XML document