Bugzilla – Full Text Bug Listing
| Summary: | Migrate modeling builds to build.eclipse.org | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Modeling | Reporter: | Nick Boldt <nboldt> | ||||
| Component: | Releng | Assignee: | Nick Boldt <nboldt> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | davidms, Ed.Merks, give.a.damus, Kenn.Hussey, lzhangl | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 168774, 178142, 178475 | ||||||
| Bug Blocks: | 171427 | ||||||
| Attachments: |
|
||||||
|
Description
Nick Boldt
Log viewer is broken; can't exec() in order to head or tail thru files. Need another, secure way to display log files (other than direct console access). build scripts are failing due to hard-coded paths; must generalize, a la: $writableBuildRoot = $isBuildDotEclipseServer ? "/opt/public/modeling" : "/home/www-data"; or if [[ isBuildDotEclipseServer ]]; then writableBuildRoot="/opt/public/modeling"; else writableBuildRoot="/home/www-data"; fi or else replace old path w/ new and set up symlinks on other servers, so all servers can use the same (new) paths. Dave: any objections to creating a symlink from /home/www-data to /opt/public/modeling on emf.toro? My first reaction is, why would something called writable build root ever be a directory under /opt? /opt is supposed to be static, where add-on (i.e. non-OS-provided) applications are installed. Variable data belongs under /var, a user's home, or some other non-standard directory tree created for that purpose. See the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES In general, I think parameterizing is better than creating symlinks all over the place, but that might not always be true. MDT EODM build successfully built and tested on build.eclipse.org. Now to verify build contents are correct, then repeat for rest of MDT, EMFT, EMF... (In reply to comment #4) > MDT EODM build successfully built and tested on build.eclipse.org. Now to > verify build contents are correct, then repeat for rest of MDT, EMFT, EMF... Damn. Spoke too soon. Javadoc is failing, examples have shrunk... Before: SDK (Runtime, Source) 2.7M (md5) Runtime 491.3K (md5) Examples 107.2K (md5) Automated Tests 201.4K (md5) After: SDK (Runtime, Source) 1.2M (md5) Runtime 392.9K (md5) Examples 11.2K (md5) Automated Tests 200.0K (md5) There's also a test failure w/ the build.eclipse.org / IBM-JDK5.0-ppc build that's not there in the emft.eclipse.org / Sun-JDK5.0-x86 build: http://build.eclipse.org/modeling/mdt/eodm/downloads/drops/2.0.0/N200703231458/testresults/html/org.eclipse.eodm.tests_linux.gtk.html (In reply to comment #5) There seems to be some problem with the map generation. I choose "Generate Map, No Tagging" option in a EODM build, but the map generated still uses a build stamp in it instead of HEAD. See the map file http://emf.torolab.ibm.com/modeling/mdt/eodm/downloads/drops/2.0.0/N200703270522/directory.txt for the build http://emf.torolab.ibm.com/modeling/mdt/downloads/index.php?showAll=1&hlbuild=N200703270522&project=eodm#N200703270522 BTW, the shrunk of EODM example code is correct. I intentionally removed old example code plugin from the example feature. Fixed the compilation errors. 25 warnings remain. Compare: http://build.eclipse.org/modeling/mdt/downloads/?showAll=1&hlbuild=N200703281943&sortBy=date&project=eodm#N200703281943 http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=N200703282004&sortBy=date&project=eodm#N200703282004 Also figured out why the emf.toro builds' mapfiles weren't getting "HEAD" but "build_200702161050"... wrong JDK (acutally, missing .so file which prevents the JDK from working on that server). Fixed. However, if I compare the latest w/ one from the "build_200702161050" tag, I see that these plugins are now gone: org.eclipse.eodm.doc_0.8.0.v200703281933.jar (1.5M) org.eclipse.eodm.edit_0.8.0.v200703281933.jar (108.5K) org.eclipse.eodm.editor_0.8.0.v200703281933.jar (90.8K) org.eclipse.eodm.examples_0.8.0.v200703281933.jar (96.3K) The other jars are there, but smaller. Clearly, missing .doc is a problem. Did you remove the other ones from your SDK, or is something Very Wrong here? ;-) Created attachment 62317 [details] comparing new mapfile w/ old one Note that in the new, generated one, there's: plugin@org.eclipse.eodm.tests.precheckin=HEAD,:pserver:anonymous@dev.eclipse.org:/cvsroot/modeling,,org.eclipse.mdt/org.eclipse.eodm/tests/org.eclipse.eodm.tests.precheckin and in the old one: plugin@org.eclipse.eodm=build_200702161050,:ext:nickb@dev.eclipse.org:/cvsroot/modeling,,org.eclipse.mdt/org.eclipse.eodm/plugins/org.eclipse.eodm plugin@org.eclipse.eodm.edit=build_200702161050,:ext:nickb@dev.eclipse.org:/cvsroot/modeling,,org.eclipse.mdt/org.eclipse.eodm/plugins/org.eclipse.eodm.edit In other words - one plugin is missing from the static mapfile, and two are missing from the generated one. Have any of these been refactored or removed? More problems (both servers):
[exec] javadoc:
[exec] [javadoc] Generating Javadoc
[exec] [javadoc] Javadoc execution
[exec] [javadoc] javadoc: error - Illegal package name: "org.eclipse.eodm.owl_2.0.0.v200703281943.src.org.eclipse.eodm.owl.reasoner"
[exec] [javadoc] javadoc: error - Illegal package name: "org.eclipse.eodm.owl_2.0.0.v200703281943.src.org.eclipse.eodm.owl.reasoner.structural"
[exec] [javadoc] javadoc: error - Illegal package name: "org.eclipse.eodm.owl_2.0.0.v200703281943.src.org.eclipse.eodm.owl.resource"
[exec] [javadoc] javadoc: error - Illegal package name: "org.eclipse.eodm.owl_2.0.0.v200703281943.src.org.eclipse.eodm.owl.resource.parser"
This doesn't look like build problems - this looks more like plugin/feature problems. Frankly, I've never seen this before, but if it's related to the new code you added when moving from 0.8.0 -> 2.0.0, then it could be related to that rather than to the build infra. I suppose I can verify this theory by trying another project's build.
(In reply to comment #9) > This doesn't look like build problems - this looks more like plugin/feature > problems. I can verify this theory by trying another project's build. OCL build migrated to build.eclipse.org without a problem. Reference build: http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=I200703271636&sortBy=date&project=ocl#I200703271636 Regen on emf.toro (use static map): http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=N200703291912&sortBy=date&project=ocl#N200703291912 Regen on build.eclipse: http://build.eclipse.org/modeling/mdt/downloads/?showAll=1&hlbuild=N200703291913&sortBy=date&project=ocl#N200703291913 Christian: The I200703281811 build was faulty. Compare the file sizes and you'll see something's rather odd. Since that build, though, sizes have returned to normal. http://emf.torolab.ibm.com/modeling/mdt/downloads/index.php?showAll=1&hlbuild=I200703281811&sortBy=date&project=ocl#I200703281811 Note also that if you compare the sizes from the first three above with your last promoted build (http://emf.torolab.ibm.com/modeling/mdt/downloads/index.php?showAll=1&hlbuild=I200703151745&sortBy=date&project=ocl#I200703151745) you'll notice things have increased in size. Looks like there's been a lot of new code (and thus javadoc, too) added. This all appears fine. Lei: This means the EODM problems are source code related, not build/releng. Can you have a look and see what you can do to fix these plugins? Thanks! The map file differences come from some redundant entries in the static eodm.map file. Fixed. The javadoc errors are due to the inclusion of eodm.source/src directory in javadoc. It contains sub-directories like org.eclipse.eodm.owl_2.0.0.v200703281943 which javadoc treats as the start of a package name. I fixed it by safely skipping the eodm.source/src directory in javadoc. See line 84 of the latest version (1.19) of antJavadoc.sh in eodm.doc/build directory. Nick, I am not a shell script writer, please help check my syntax for e.g. cross-platform issues. I intentionally removed the edit and editor plugins which are not available in this version. The result is a N build http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=N200704021159&sortBy=date&project=eodm#N200704021159 that looks good except for the warnings. (In reply to comment #11) http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=N200704021159&sortBy=date&project=eodm#N200704021159 > that looks good except for the warnings. Great, thanks. Ran again - with tests this time - on both emf.toro and build.eclipse, and BOTH ran okay but seem to be failing sporadically on a single JUnit. http://build.eclipse.org/modeling/mdt/eodm/downloads/drops/2.0.0/N200704021413/testresults/html/org.eclipse.eodm.tests_linux.gtk.html http://emf.torolab.ibm.com/modeling/mdt/eodm/downloads/drops/2.0.0/N200704021438/testresults/html/org.eclipse.eodm.tests_linux.gtk.html http://build.eclipse.org/modeling/mdt/eodm/downloads/drops/2.0.0/N200704021337/testresults/html/org.eclipse.eodm.tests_linux.gtk.html Please note that the error message in each JUnit failure is DIFFERENT across the two different JDKs used (sun-java2-5.0 (jdk1.5.0_10) on emf.toro vs. ibm-java2-ppc-50 (java2-ppc-50) on build.eclipse. I can't speculate WHY this is happening, but maybe you can rewrite the test so it's not JDK-variant? JUnit failures are definitely sporadic. Re-ran them again and both servers' results were fine... unless someone else changed the code at the same time, that is. ;-) http://build.eclipse.org/modeling/mdt/downloads/?showAll=1&hlbuild=N200704021504&sortBy=date&project=eodm#N200704021504 http://emf.torolab.ibm.com/modeling/mdt/downloads/?showAll=1&hlbuild=N200704021604&sortBy=date&project=eodm#N200704021604 Nick, I failed to promote the EODM build using the promoteToEclipse.sh script in the /home/www-data/build/modeling/scripts directory:
[promote] Started 22:52:05. Executing with the following options:
-user lzhang
-sub eodm
[loading ./promoteToEclipse.eodm.properties ... done]
-branch 2.0.0
-buildID I200704040217
-Q
-announce
The script asks me to enter password for zhanglei@download1.eclipse.org, but actually my account is lzhang@download1.eclipse.org. It seems that the account name mismatch (zhanglei@emf.toro and lzhang@eclipse) causes some problem in the script although I used the -user lzhang option.
(In reply to comment #14) Problem fixed by Dave and Nick. I now get the lzhang user name on emf.torolab and can ssh in. Marking as dupe of 238626. *** This bug has been marked as a duplicate of bug 238626 *** |