Bugzilla – Full Text Bug Listing
| Summary: | Expand the CDO definition framework to support server configuration | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Steve Robenalt <steve> | ||||||||||||||
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> | ||||||||||||||
| Status: | NEW --- | QA Contact: | Eike Stepper <stepper> | ||||||||||||||
| Severity: | enhancement | ||||||||||||||||
| Priority: | P3 | CC: | enrodri86, lu.xingxiao, martin.fluegge, nacor, stepper, techteam | ||||||||||||||
| Version: | 4.13 | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows 7 | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Steve Robenalt
Created attachment 203809 [details]
net4j.db.defs ecore model
A preliminary, incomplete version of the model for early feedback.
Created attachment 203810 [details]
cdo.server.defs ecore model
A preliminary, incomplete version of the model for feedback.
Created attachment 203811 [details]
cdo.server.db.defs ecore model
A preliminary, incomplete version of the model for early feedback.
Created attachment 203812 [details]
cdo.server.net4j.db.defs ecore model
A preliminary, incomplete version of the model for early feedback.
Comment on attachment 203809 [details]
net4j.db.defs ecore model
Fixed the model name.
Unfortunately the cross ecore links are a pain to get right. Can you start the prototyping with all ecore file in a single model folder? (In reply to comment #6) > Unfortunately the cross ecore links are a pain to get right. Can you start the > prototyping with all ecore file in a single model folder? I can, but I was following the precedent set with the existing projects (and I'm used to combining multiple models in this manner). If I do combine them, it will introduce dependencies in the defs framework that don't exist with the separate defs models that I've already created. Also, does this mean you'd like me to combine the existing defs projects so there is a single master model? Misunderstanding. I definitely prefer a decoupled design, i.e., one model per def plugin. But you've not delivered these def plugins, just a set of model files. Because these model files are interconnected through relative hrefs it requires me to manually setup a particular folder structure which is kind of tedious especially if it comes to multiple reviews of different versions. That's why I suggested to stay with a simpler "setup" only during prototyping phase. Now I think that it would be even simpler and clearer if you provide a zip with all ecore files in their correct folders. I'll prepare and attach one such zip in a minute... Addition: A proper folder structure is not enough. They should even be (plugin) projects so that they can easily be imported. What about a Github project for the prototyping phase? Created attachment 203877 [details]
4 defs plugins
Hi Eike, Actually, each defs ecore model is part of a plugin project already, so zipping them is easy enough. Yesterday, each project only contained the ecore file, but today I got through initial model generation, and am starting to populate the createInstance and validateDefinition methods. I hope to be able to create a CDO Server using a defs model by tomorrow, but we'll see how it goes. In any case, I'll update the plugin projects with my own zip tomorrow. Since there are currently no .edit plugins created, I'll add those for all of the defs models (existing and added), and an editor project as well so we can create new defs models with a basic emf editor. I'm basing my projects on a current (as of 2 days ago) version of the CDO source, though the projects could probably target CDO 4.0.0 GA without any issues. One issue I'm encountering with the defs models involves determining how to pass arbitrary properties to (for example) a data source, where both the name and value are unknown to the defs model. There may be an example in the existing defs models, which I'll use if so; otherwise, I was thinking about using a delimited string, probably like an http url-encoded query string, and possibly with a way to override delimiter characters. Opinions? A GitHub project may be appropriate - it'll finally push me into using Git (my local repositories are svn). Steve (In reply to comment #10) > Created attachment 203877 [details] > 4 defs plugins Created attachment 203878 [details]
defs with diagrams and comments
(In reply to comment #11) > [...] Since > there are currently no .edit plugins created, I'll add those for all of the defs > models (existing and added), Argh, I'm scared of the enourmous number of plugins we're going to create. Don't you think we can generate the edit stuff into the model plugins? Related: Should we combine the cdo.server and cdo.server.net4j defs? There's currently not much chance to use CDO without Net4j. BTW., the cdo client defs seem to be missing the Net4j stuff. Probably because that separation has taken place after the defs had been created. > and an editor project as well so we can create new > defs models with a basic emf editor. A single editor will be enough, right? > I'm basing my projects on a current (as of > 2 days ago) version of the CDO source, though the projects could probably target > CDO 4.0.0 GA without any issues. No API must be added to 4.0 ;-( > > One issue I'm encountering with the defs models involves determining how to pass > arbitrary properties to (for example) a data source, where both the name and > value are unknown to the defs model. There may be an example in the existing > defs models, which I'll use if so; otherwise, I was thinking about using a > delimited string, probably like an http url-encoded query string, and possibly > with a way to override delimiter characters. Opinions? I added a related comment to the net4j.db.defs diagram. Generally I don't like these "low-semantics" very much. Separate concrete sub defs of DataSourceConnectionProvider would be nicer, me thinks. > A GitHub project may be appropriate - it'll finally push me into using Git (my > local repositories are svn). Note that we're almost done with our Git evaluation. A migration is pending within the next couple of weeks. So you'll be able to profit from your experience ;-) (In reply to comment #13) > (In reply to comment #11) > > [...] Since > > there are currently no .edit plugins created, I'll add those for all of the defs > > models (existing and added), > > Argh, I'm scared of the enourmous number of plugins we're going to create. > Don't you think we can generate the edit stuff into the model plugins? Seems like that would be relatively easy. To take it a step further, should the model and edit classes be added to the plugin for which they are acting? This would extend as well to other plugins that could augment the defs framework, such as new data sources (see below). > > Related: Should we combine the cdo.server and cdo.server.net4j defs? > There's currently not much chance to use CDO without Net4j. That should be your call, though my approach at this point (based on the earlier defs work) was to add a defs plugin for each plugin that needed one. > > BTW., the cdo client defs seem to be missing the Net4j stuff. > Probably because that separation has taken place after the defs had been > created. > > > and an editor project as well so we can create new > > defs models with a basic emf editor. > > A single editor will be enough, right? > Yes, a single editor should suffice, though we should be sure it can support registration of new defs model extensions contributed with data sources or transport types. > > I'm basing my projects on a current (as of > > 2 days ago) version of the CDO source, though the projects could probably target > > CDO 4.0.0 GA without any issues. > > No API must be added to 4.0 ;-( > I understand, but it would be useful to add this functionality into a CDO 4.0 base, rather than requiring a CDO update to use, though this probably isn't feasible if (as I mentioned above) we decide that it's best to pull the defs classes into the plugins they provide configuration for. > > > > One issue I'm encountering with the defs models involves determining how to pass > > arbitrary properties to (for example) a data source, where both the name and > > value are unknown to the defs model. There may be an example in the existing > > defs models, which I'll use if so; otherwise, I was thinking about using a > > delimited string, probably like an http url-encoded query string, and possibly > > with a way to override delimiter characters. Opinions? > > I added a related comment to the net4j.db.defs diagram. > Generally I don't like these "low-semantics" very much. > Separate concrete sub defs of DataSourceConnectionProvider would be nicer, me > thinks. I agree that concrete sub-defs are desirable, provided they can be contributed to the existing editor as I mentioned above. This would lead to a nice systematic way of contributing CDO extensions that would also be able to participate in the configuration via the defs framework. > > > A GitHub project may be appropriate - it'll finally push me into using Git (my > > local repositories are svn). > > Note that we're almost done with our Git evaluation. > A migration is pending within the next couple of weeks. > So you'll be able to profit from your experience ;-) A couple of follow-on thoughts from my prototyping thus far: 1) The defs model elements in general are effectively derived from a subset of the attributes and references of the classes they provide configuration for. It seems like it would be feasible to derive most, if not all defs model elements from the processing of annotations placed on the relevant classes, attributes, and references. This would have the advantage of allowing defs models to be generated (and regenerated) over time with minimal effort. The annotations themselves could also provide attributes that could also specify constraints on the defs model, which could be used to derive many of the checks in the validateDefinition method of the generated Def class. 2) To a large extent, the createInstance method of each defs class replicates the functionality of factory methods in the Util class. The main difference involves the internal chaining of createInstance methods for referenced classes. It might be worth considering moving contents of the createInstance method into a factory method on the Util class that takes the Def class as an argument. This would allow the createInstance method to delegate to the Util class, which means the method could be generated. The implications of the above are that it may be feasible to fully generate a valid defs class for each class that requires one, driven by a set of annotations, which would simplify maintenance of the whole process. I haven't tried this yet, of course, but it does seem like it's not too much different than what I'm doing by hand right now. I'm just about to call it a day, but one thing strikes me as misleading: It's somewhat unlikely that we will move the defs *into* the plugins with the to-be-defined concepts. One reason is the size of the core plugins, but more important, not all plugins (e.g. net4j) does not depend on EMF and we don't even want optional such dependencies in the core code. I really prefer to see the definition framework as fully separate and optional to the core(s). If we continue to follow this principle we can also not move the creation responsibility into the core Util classes. I'll look more closely at your other comments tomorrow... (In reply to comment #16) > I'm just about to call it a day, but one thing strikes me as misleading: It's > somewhat unlikely that we will move the defs *into* the plugins with the > to-be-defined concepts. One reason is the size of the core plugins, but more > important, not all plugins (e.g. net4j) does not depend on EMF and we don't > even want optional such dependencies in the core code. I really prefer to see > the definition framework as fully separate and optional to the core(s). I understand. I was just pointing out possible alternatives to the proliferation of plugins. > > If we continue to follow this principle we can also not move the creation > responsibility into the core Util classes. The advantage of moving the creation responsibility into the Util classes was that it would yield a clean separation of generated code from non-generated code. > > I'll look more closely at your other comments tomorrow... There are some variants of my alternative that could avoid the runtime dependencies on EMF and still allow the defs framework to be mostly fully generated, but they may not be worth the additional complexity. Hi all, I have created a GitHub repository to share my work in progress on the prototype. The URL for the GitHub project is: git://github.com/sarobenalt/cdo_server_defs_prototype.git As of now, there is still a lot of work to do on the model itself, and it's still not in a working state, but I'm working through issues and continuing to add capabilities. Those monitoring the project should note that the code that is on GitHub is not committed CDO API - it's a prototype. In its current state, it is using the org.eclipse.emf.cdo.* and org.eclipse.net4j.* namespaces because these are a pain to change from "provisional". It also reflects a version of 4.1 for CDO, though it may or may not end up as part of that release. That being said, there are currently new projects added to the defs framework where they are needed (4 plugins so far), modified versions of the existing projects (5 plugins + 2 features), and a new basic EMF editor that is intended to allow definition models to be created. The models themselves are a work in progress, representing a partial set of definitions of configurable elements. There are still attributes and references missing, and not all of the references are using proper containment. Also, the methods on the generated classes are incomplete or empty. These issues will be addressed over the next few days, and will be pushed to the GitHub repository as they are completed. With all of that in mind, please feel free to pull code from the GitHub project and log any prototype-specific comments as GitHub issues. Note that the GitHub project will be removed when/if the code becomes part of CDO. This means that comments that should outlive the prototype should still be logged on this bugzilla entry. Steve Hi Steve, I've checked out your *added* plugins. Some notes: 1) FailoverAgentDef is not needed because the underlying FailoverMonitor.agents list is not a configurable item but process state. 2) CDOServerDef is not needed because there's already the DefContainer. 3) org.eclipse.emf.cdo.defs.editor should be org.eclipse.net4j.util.defs.editor There are lots of smaller issues with the various models but I have the feeling that it wold be much easier for me to just change them rather than writing endless notes. But perhaps it's better to wait until you explicitely say that you're done ;-) (In reply to comment #19) > Hi Steve, > > I've checked out your *added* plugins. Some notes: > > 1) FailoverAgentDef is not needed because the underlying FailoverMonitor.agents > list is not a configurable item but process state. > > 2) CDOServerDef is not needed because there's already the DefContainer. > > 3) org.eclipse.emf.cdo.defs.editor should be org.eclipse.net4j.util.defs.editor > > There are lots of smaller issues with the various models but I have the feeling > that it wold be much easier for me to just change them rather than writing > endless notes. But perhaps it's better to wait until you explicitely say that > you're done ;-) It's probably easiest if I just give you read/write access to the repository. I'd rather have the major changes sooner than later if you have the time to review them and put them in. Then I can be sure I'm "finishing" only necessary classes. I'll also rebuild the editor based on the net4j.util.defs project rather than the cdo.defs project. I based it on the cdo.defs project under the assumption that most users would be doing CDO configurations that included net4j, rather than doing standalone net4j configurations. (In reply to comment #20) > It's probably easiest if I just give you read/write access to the repository. > I'd rather have the major changes sooner than later if you have the time to > review them and put them in. Then I can be sure I'm "finishing" only necessary > classes. Good idea. I'll fork a branch when I have time. Note that I'll be off until Wednesday. Processing the backlog takes some time, too :P Hi guys, I haven't had time yet to look to the model, but today a played a bit with Graphiti. It took only half a day to understand the basic concepts and to re-implement the basic features of the famous Dawn Acore GMF editor. I am still a rookie with this stuff but it seems to by pretty simply and straight forward. So if you still want to provide a graphical editor, what do you think about using Graphiti? (In reply to comment #22) > Hi guys, > > I haven't had time yet to look to the model, but today a played a bit with > Graphiti. > > It took only half a day to understand the basic concepts and to re-implement > the basic features of the famous Dawn Acore GMF editor. I am still a rookie > with this stuff but it seems to by pretty simply and straight forward. So if > you still want to provide a graphical editor, what do you think about using > Graphiti? I have no problem with using Graphiti. I just think it'll be pretty cool to have a graphical editor for the configurations. ;-) > I have no problem with using Graphiti. I just think it'll be pretty cool to have a graphical editor for the configurations. ;-)
Absolutely.
Then I continue my experiments and if the model reached the final version we can start working on the graphical editor ;)
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Moving all outstanding enhancements to 4.3 Moving all open enhancement requests to 4.4 Moving all open enhancement requests to 4.4 Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |