Community
Participate
Working Groups
I am trying to run a Dali standalone build and I have noticed that the builder is generating a feature@org.eclipse.jpt_sdk.assembly.feature.xml file with cvsRoot set to ":local:/cvsroot/webtools". I guess I need to replace the ":local:" string, but I haven't found where it is done in the builder.
(In reply to comment #0)- From David Williams But in short, to get around the issue, you will have to "pass in" the normal default values to prevent our scripts from changing them to "build machine defaults". If you use localBuildProperties directory already you can put a file in there named maptasks.properties with following properties and values. If not, you can pass them in as -D parameters, I'd guess (but not done it that way, myself). rewriteMapsLine=:pserver:anonymous@dev.eclipse.org: rewriteMapsLineEscaped=\:pserver\:anonymous@dev.eclipse.org\:
Created attachment 201841 [details] Build output David, I am using localBuildProperties, and I have changed the property values as you mentioned, however I am getting the same result (see attachment).
Created attachment 201842 [details] fetch_org.eclipse.jpt_sdk.assembly.feature.xml
Created attachment 201843 [details] fetch_org.eclipse.jpt_sdk.assembly.feature.xml
Just a quick guess ... have you gotten the map files once -- and only once -- , ran the build, got the error, then added the properties and still see the error? If so, your map files would still be the modified versions ... with :local: already in them, from a previous run. (That's what the "rewrite" is rewriting ... the map files). If not that, I'm not sure what it'd be. I've taken a quick look and nothing jumps out at me ... I'd have to do "deep debugging" ... which you could do yourself ... I'd start off by putting some "echo" elements in there to make sure it is picking up your local properties as expected.
Created attachment 201878 [details] fetch_org.eclipse.jpt_sdk.assembly.feature.xml You were right I haven't started from a fresh work directory. The cvsRoot property looks correct now, however I am still unable to run generated fetch script. I have started deep debugging, but it did not strike me until now that the generated script fetch_org.eclipse.jpt_sdk.assembly.feature.xml is truncated. It ends after: <target name="fetch.plugins" if="featureAndPlugins"> Have you experience this in the past?
Created attachment 201879 [details] retrieve.xml
> ... the > generated script fetch_org.eclipse.jpt_sdk.assembly.feature.xml is truncated. > It ends after: > <target name="fetch.plugins" if="featureAndPlugins"> > > Have you experience this in the past? No. I have not seen. And, sounds nearly impossible :/ ... well, you know, something "outside" of ant ... such as, an error occurs before the write buffer is flushed, or some odd thing. You are using Linux, right? :)
(In reply to comment #8) > > ... the > > generated script fetch_org.eclipse.jpt_sdk.assembly.feature.xml is truncated. > > It ends after: > > <target name="fetch.plugins" if="featureAndPlugins"> > > > > Have you experience this in the past? > > No. I have not seen. And, sounds nearly impossible :/ ... well, you know, > something "outside" of ant ... such as, an error occurs before the write buffer > is flushed, or some odd thing. You are using Linux, right? :) No I always have ran the standalone build on Windows (first time on Windows 7 though)
Well this is the hard way to find out that cvs is not installed :(... On previous machines cvs was already there so I did not had to install it prior to running the build. So this time, it did not occur to me to install cvs; I guess I was counting on the build to tell me if I missed something.
Created attachment 201962 [details] Build output 2 I made further progress, now the build failed where it tries to download EclipseLink. I have overrode rewriteHttpLines in maptasks localBuildProperties but the generated script still referring to http://fullmoon.rtp.raleigh.ibm.com/. Any suggestion? Thanks.
(In reply to comment #11) > I have overrode rewriteHttpLines in maptasks localBuildProperties but the > generated script still referring to http://fullmoon.rtp.raleigh.ibm.com/. Any > suggestion? Thanks. I am not sure when the substitutions occurred, but jpt map and orbit map had http://fullmoon.rtp.raleigh.ibm.com/ in it. I replaced the maps and it could resolve the URL.
that's good to know that missing "cvs" does not fail very gracefully. While I know we don't check for it explicitly, I would have though the "cvs fetch factory", or something, would have produced some better messages. As for "fullmoon", that's pretty weird, but I am 100% certain there's nothing "hard coded" for that ... it is never used on "build.ecliplse.org" servers, so ... My guess is that, at some point if not still, you are getting and using the "localBuildExample" from releng.wtpbuilder. It is the only place that refers to fullmoon. While it is clear this is only an "example directory", so I doubt you would have blindly copied the values there, my guess it you have set up your local build so that LOCAL_BUILD_PROPERTIES_DIR is set to point to .../releng.wtpbuilder/localBuildExample, you changed values there, and then it got overwritten with a fresh copy of releng.control? I could be off base, but suspect it bears repeating ... LOCAL_BUILD_PROPERTIES_DIR should point to some directory outside the normal directories ... someplace safe on your file system, since you never want that to be overwritten by automatic checkouts. Everything in there should be your own custom "tweaks" to override the behavior that works on build.eclipse.org. Likewise, your value for LOCAL_BUILD_PROPERTIES_DIR should be set in commonVariations.shsource and that file itself should also be out of your normal file structure, on your path, so that 'source' will include it first, rather than the one in the releng.control. ... oh, you are using windows? Not sure how all that works, there. Suggestions welcome ... well, patches welcome :) Such as to check that cvs in installed on system and fail fast if not. I think all you have to do, is grep -r "fullmoon" * and for short run, just get rid of that line. and b) long term figure how/why you are provding that file and location to the builder ... its just an exaemple to get someone started, and should be in a safe place to avoid being overwritten. I hope this helps some, and you would be doing a great service to the community (and, yourself in 6 months when you forget again :) to write down this experience and how you got past them. Good luck,
Hope you've made progress? But, either way, let's close this bug as "working as designed" and leave it around to document the fact that local builds require the oddity of specifying cvs location, even though you'd think that would be the default. This reason it is not the default is that a) it is desirable to use "local" on the local file system on build.eclipse.org, and it is hard to write scripts that work "out of the box" for both build.eclipse.org machines and also other hosts. There could certainly be ways to improve things, and/or change who has the responsibility to specify which properties, and if anyone wants to work on that, or document that request, feel free to open enhancement request. Otherwise, let's count this effort as "documentation" and open new bugs for the other problems you are experiencing. (FYI: the bug to use "local" is documented in bug 338481 though that doesn't give details where webmasters have mentioned it would be better ... you can search on Community, Servers components or similar if interested). I've changed the title to try and make it easier to "find" this bug/documentation in future searches. Greatest thanks for documenting it ... and please do open new bugs if continuing to have trouble. You'll need to provide more details about steps you are following, results you see, etc. But, suspect is is something completely different that the ":local:" issue for which this was original opened.
Thanks David things are going well. I am still having a few dependency issues, but it is not related to this bug. I will open another bug if necessary, and an enhancement request for the builder issues I encountered when setting up a standalone build.
