Bugzilla – Full Text Bug Listing
| Summary: | Simplify Developer & Contributor Setup | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Xtend | Reporter: | Sven Efftinge <sven.efftinge> | ||||||||
| Component: | Core | Assignee: | Project Inbox <xtend-inbox> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | dennis.huebner, eclipse, lieven.lemiengre, lorenzo.bettini, txmikester, zombi | ||||||||
| Version: | 2.4.0 | Keywords: | helpwanted | ||||||||
| Target Milestone: | --- | Flags: | sven.efftinge:
kepler+
|
||||||||
| Hardware: | PC | ||||||||||
| OS: | Mac OS X | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 397423 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Sven Efftinge
@Christian Do you have time to start working on this? However a good start point is the buckminster contributors wiki page: http://wiki.eclipse.org/Getting_started_with_Buckminster#Installation_for_Buckminster_contributors I'm not quiet sure how up-to-date it is, but as I used it a couple of month ago, it worked very good. I told Sven in a comment on his blog that I could work on this, and I apologize for not getting to it sooner. If Christian has already started working on it, that's fine, or maybe we could work together. Maybe this goes beyond the scope of this single enhancement, but an idea I've had for a long time is to write a DSL to describe Eclipse installations. Given a model of an Eclipse "profile", we could then create generators to materialize that profile in a number of ways: a) we could transform it to the needed Buckminster models, generate the needed configuration files and then run Buckminster headless b) we could generate POMs to materialize the profile using Maven/Tycho c) we could generate batch files and/or ant scripts and use the p2 Director One thing I think would be cool is a small, lightweight download with a simple UI over the p2 Director and/or Buckminster, that used a common URL to discover available profiles. Then any Eclipse project (or even outside Eclipse) could publish their profile models to make them easily accessible. It would be like the old p2 Installer app on steroids. Imagine for the Kepler (or maybe Kepler+1)download, there's a single 15-20MB download, and when you run it, it checks the discovery site and presents all the EPP packages on the main screen, and you just pick one (or five). It's setup to use a shared bundle pool, so you can create as many profiles as you want and easily switch between them. There's also a "Get Involved" tab or something like that, and when you switch to it, there are lists of development profiles for all the Eclipse projects that participate. I've been wanting something like this forever, since I usually have several different Eclipse instances I'm juggling and maintaining. And yes, I'm aware of the commercial offerings out there, and I've tried them all but they have various problems. This would be a simpler straightforward approach for managing Eclipse instances and installing development profiles, without all the Enterprise-focused management (some would say "restricting") features. I would like to get feedback from you guys, and maybe start working on some of this as part of this particular enhancement. I haven't started to work on this, because currently I do not have much time for this due to the situations in the projects of my customers :-(. Nevertheless I'm basically willing to contribute, but I've never worked with Buckminster and therefore have to learn a little bit about it. I think we must identify what has to be done and than define a list of tasks that can be processed more or less seperatly. It also would be nice to know what the "all plugins we use for development" (see point 1 from Sven's description) are. A more generic way to solve this problem might be a highly demanded feature in many scenarios. But for this particular bug I'd like to keep it as simple as possible. I don't think DSLs or other generalizations will help us enough that it is worth developing and maintaing them. For a first start I propose to go with a simple Import wizard which checks out the git repositories, imports the projects into the right working sets and sets the target platform. That import wizard should be located in a small independent plug-in which declares dependencies to all the plugins we use and need for development (Antlr generator, Xtext, Xtend, EGit) We might not be able to host it at Eclipse.org, because some non approved plug-ins are used (i.e. Antlr generator). Is there existing documentation for (manually) setting up the development environment? I looked around and couldn't find any, but I might have just missed it. Mike, I think there isn't such a documentation, but I might have missed it, too. I asked in the Google Group for such a "getting started guide" and didn't get a positive answer. I agree with Sven that the solution needs to be simple and like the idea of importing the projects into a workspace like one could do that with the example projects. But indeed: a detailed list of required plugins and their versions would be helpful. ... P.S. While waiting on a build job I checked out/cloned "org.eclipse.xtext.git", imported the projects as existing projects into workspace and got 360 errors (21 with "An API baseline has not been set for the current workspace."). Here a list of bundles that can not be resolved: Bundle 'org.eclipse.orbit.mongodb' cannot be resolved Bundle 'org.xtext.mongobeans' cannot be resolved Bundle 'org.easymock' cannot be resolved Bundle 'org.xtext.builddsl.lib' cannot be resolved Bundle 'org.xtext.builddsl' cannot be resolved Bundle 'org.xtext.httprouting' cannot be resolved Bundle 'org.xtext.httprouting.ui' cannot be resolved Bundle 'org.xtext.tortoiseshell.lib' cannot be resolved Bundle 'org.xtext.tortoiseshell' cannot be resolved Bundle 'org.xtext.mongobeans.lib' cannot be resolved Bundle 'org.xtext.mongobeans.ui' cannot be resolved Bundle 'org.eclipse.xtext.example.domainmodel' cannot be resolved Bundle 'org.eclipse.xtext.xdoc' cannot be resolved Bundle 'org.eclipse.xtend.bootstrapdoc' cannot be resolved Bundle 'org.eclipse.xtext.example.arithmetics' cannot be resolved Bundle 'org.xtext.template.examples' cannot be resolved Bundle 'org.xtext.template.ui' cannot be resolved Bundle 'org.eclipse.xtext.example.fowlerdsl' cannot be resolved Bundle 'org.xtext.httprouting.examples' cannot be resolved Bundle 'org.xtext.template' cannot be resolved Bundle 'org.xtext.builddsl.ui' cannot be resolved Bundle 'org.xtext.guicemodules' cannot be resolved Are there any news about this issue? I'm willing to help, and I have some knowledge about Buckminster, which already provides many features to setup a working workspace, git clone, and target platform. Hi Lorenzo, AFAIK nobody is actively working on this atm. Any help would be most welcome. :-) (In reply to comment #7) > Are there any news about this issue? > > I'm willing to help, and I have some knowledge about Buckminster, which > already provides many features to setup a working workspace, git clone, and > target platform. OK! :) a good starting point would be the files you use for headless builds in hudson: any pointer? (In reply to comment #9) > OK! :) > a good starting point would be the files you use for headless builds in > hudson: any pointer? Hi Lorenzo, see http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/releng/org.eclipse.xtext.releng you can also look into the hudson configuration. Regards, Dennis. Created attachment 226865 [details] Ant script to setup the workspace This is the first version of a possible self-contained ant file which headlessly creates the workspace for Xtext; it relies on buckminster headless, but the ant script installs that if it is not present (default buckminster.home=${user.home}/buckminster). Basically only ant is required in your system: just run ant -f workspace.ant The following properties can be passed to the script (with standard syntax -Dkey=value) WORSPACE (default to ${user.home}/workspaces/xtext-sources): where the workspace will be generated git.clone.dest (default to ${user.home}/git/org.eclipse.xtext): where the git clone is (or will be cloned if it does not exist) If one has already a git clone of Xtext, he can specify that with the above property so that it will not be cloned again (in a possible different path). An ant script is required (instead of a materialization in the IDE) because of the api baseline which must be set beforehand. I took inspiration from the Hudson job https://hudson.eclipse.org/hudson/view/Modeling/job/Xtext-nightly-HEAD/ so I'm not sure I'm performing the right operations :) The script does the following: - cleanup: cleans the output workspace if it exists (but does not remove an existing target platform, bundle pool and possible mylyn configurations) - resolve the releng project using the remote cquery http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/plain/releng/org.eclipse.xtext.releng/releng/local/xtext.cquery but does not "import" it. This step is basically required to clone the git repository if it is not present - create the api-baseline (using releng/org.eclipse.xtext.releng/api-baseline/api-baseline.target) and sets it in the workspace - resolve the releng/org.eclipse.xtext.releng/releng/xtext-platform-Galileo.mspec which creates the target platform according to xtext-platform-Galileo.cquery - resolve releng/org.eclipse.xtext.releng/releng/xtext.cquery which actually imports the projects into the workspace - peforms a build after the script has finished the workspace is created into ${WORKSPACE} and that can be opened with Eclipse (the api baseline and the target platform have been set by the script in this workspace). This works for me; I opened the workspace with a Kepler Eclipse with Xtext installed from "latest" repository. I noticed that domain model, arithmetics and fowler example projects are not imported in the workspace; I think this is due to the CSPEC of the .build project which does not depend on them. If I perform a cleanup some projects report errors but I can't tell whether this is due to some missing dependencies, to the version of Xtend in my Eclipse, or something else. It is not clear to me with which version of Eclipse one should use Xtext sources. I look forward to getting feedback! :) Created attachment 227028 [details]
Some Windows fixes
Hi Lorenzo!
I've tried it out, it' pretty cool!
The new xtext workspace compiles with Kepler M5 DSL package.
Have you an idea how to import Working sets to the created workspace?
I had some problems with pathes under windows, see the attachment.
Created attachment 227034 [details] increased jvm memory arguments Thanks for the feedback Dennis! I should have tested that under windows as well, sorry :) this is slightly modified version starting from your fixed script to increase jvm memory arguments in order to avoid out of memory errors during resolution <jvmarg line=" -Xms256m -Xmx1024m -XX:MaxPermSize=256M" /> concerning the working set, as far as I know, it is still not implemented, see http://www.eclipse.org/forums/index.php/m/376003/ https://bugs.eclipse.org/bugs/show_bug.cgi?id=219452 I think one can provide a workspace template that is used during materialization (this is implemented in buckminster) but that would only contain predefined working sets: then the programmer should assign the projects to the working set manually... I tried also Kepler M5 DSL package as you said and I don't get errors if rebuilding :) thus the idea is that you use Xtext shipped with Kepler M5 DSL to develop the current Xtext sources, right? however, some Java files generated by Xtend get modified... I've tried it ones again on a windows machine and it seem to hang somehow during git clone. I also noticed that "Build automatically" is off by default in the new created workspace. I think there were a possibility in buckminster to set this property on. (In reply to comment #14) > I've tried it ones again on a windows machine and it seem to hang somehow > during git clone. I've just tried that on windows for the first time, and it worked for me... it's just that it took about 40 minutes to clone the 300Mb of xtext repository :) are you sure it hanged or was it just downloading? with the previous version of the ant script it worked cloning from scratch? I basically only added parameters to increase jvm memory... > I also noticed that "Build automatically" is off by > default in the new created workspace. I think there were a possibility in > buckminster to set this property on. I see here https://bugs.eclipse.org/bugs/show_bug.cgi?id=305417 that it was removed since it was causing problems... I think that setting it on again manually could be OK? (In reply to comment #15) > are you sure it hanged or was it just downloading? with the previous > version of the ant script it worked cloning from scratch? I basically only > added parameters to increase jvm memory... I'm not sure, you may be right, yesterday there were some technical problems with eclipse infra. > I see here https://bugs.eclipse.org/bugs/show_bug.cgi?id=305417 that it was > removed since it was causing problems... I think that setting it on again > manually could be OK? It's probably ok. Would workspace template help? Or maybe buckminster would provide cmdline.prefmapping for: instance/org.eclipse.core.resources.prefs/description.autobuilding[true/false] so one can call setpref autobuilding=true as the last command. (In reply to comment #16) > > I see here https://bugs.eclipse.org/bugs/show_bug.cgi?id=305417 that it was > > removed since it was causing problems... I think that setting it on again > > manually could be OK? > It's probably ok. Would workspace template help? Or maybe buckminster would > provide cmdline.prefmapping for: > instance/org.eclipse.core.resources.prefs/description.autobuilding[true/ > false] > so one can call setpref autobuilding=true as the last command. I don't think template would help: as far as I understand when running headless, buckminster sets build automatically off anyway; from the bugzilla above I seem to understand that it would be a problem to set it on since as soon as you do that a new build would start... that's why they disabled it (but I may be wrong). do you think the script is usable anyway? This script works, however, it still feel the whole process a bit strange, and complicated. To simplify things, I would rather put these script into the source repo, and modify to build the workspace into 'target/xtext-workspaces' and download buckminster into 'target/buckminster', so it would help the life of the simple contributors, with providing sensible defaults. Yes, that sounds like a good idea. We also need to have some text (maybe on the Eclipse wiki for now) explaining the steps needed to get a working development environment. When I first wrote the ant script I was actually assuming that it would have been put in the git source repo, and it could be downloaded via web through the git web interface. Just running the script will then clone the whole git repository. (The idea behind the script is in comment 11. For the user it should be enough to download the ant script and run it :) I'll adjust the default output directory as suggested. Sorry for not adding it to the repo and coming up with a propoer description somewhere. We really need to do that ASAP (i.e. after Kepler). I've created a new project "o.e.x.contributor" to hold related files together. http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/plain/devtools/org.eclipse.xtext.contributor/ The whole process works based on Lorenzo's workspase.ant script, but with less steps. I've also added some new features like workspace settings import and gitconfig setup (gerrit settings). A Project set file is also contributed. There is also a little readme, but we definitely need a detailed description on our website and/or wiki. Requested via bug 522520. -M. Requested via bug 522520. -M. |