Bugzilla – Full Text Bug Listing
| Summary: | Refactor AbstractDataSourceFactory class so that it can be reused | ||
|---|---|---|---|
| Product: | [RT] Gemini.DBaccess | Reporter: | Michael Keith <michael.keith> |
| Component: | Core | Assignee: | Project Inbox <gemini.dbaccess-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | juergen.kissner, krum.tsvetkov, shaun.smith |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Michael Keith
Hi Mike,
The version 52 (the one with the DBACCESS_COMMON) does nearly work, but the link anchor org.eclipse.gemini.dbaccess.derby/common and org.eclipse.gemini.dbaccess.mysql/common do not (yet) exist. After having created the directories, the workspace link could be configured. So I guess, that final patch (adding the two directories) should restore a working state.
However, I see the following drawbacks with the the current IDE project setup:
1) The eclipse SVN project import ("Import project from SVN") does not work any more --- the "common" directory has to be imported manually.
2) For each database platform, the directory link for DBACCESS_COMMON has to be configured (manually?)
3) When configuring the link, you change your .project contents to a setting that is only valid locally. That means, each time you submit you changes, you have to be careful not to submit (the "link" part) of the .project files
4) Any sort of automatic build (like Tycho/Maven) will most likely have difficulties with this setup
5) One of our use case scenarios is to support more than one database platform (also during design time, in you eclipse IDE). In that case, you had the common files multiple times in every bundle.
6) Unit testing of the common part would also be less direct, because common is not an (java) eclipse project.
Especially 1), 2), and 3) might make it difficult for other people to run and test DBAccess. But that could be just my (weird?) way of doing things --- there might be a better and more elegant way. I would therefore be nice, if someone else (Shaun?, Krum?) could try to setup the DBAccess locally (after the patch) and see if they run into the same difficulties.
> The version 52 (the one with the DBACCESS_COMMON) does nearly work, but the > link anchor org.eclipse.gemini.dbaccess.derby/common and > org.eclipse.gemini.dbaccess.mysql/common do not (yet) exist. After having > created the directories, the workspace link could be configured. So I guess, > that final patch (adding the two directories) should restore a working state. > The org.eclipse.gemini.dbaccess.derby/common directory is a linked resource, not a physical directory. No subdir should be created since each of the "common" directories get redirected to the path defined by DBACCESS_COMMON variable defined in your Eclipse workspace. So, if you right click on the "common" entry in your project and choose "Properties", you should see: Path: /org.eclipse.gemini.dbaccess.derby/common Type: Linked Folder Location: DBACCESS_COMMON Resolved Location: <your native path to .../trunk/common> > However, I see the following drawbacks with the the current IDE project setup: > 1) The eclipse SVN project import ("Import project from SVN") does not work any > more --- the "common" directory has to be imported manually. We might be hitting an Eclipse bug that causes the link to not be resolved properly even though the DBACCESS workspace variable is defined. The "common" link should just be present when the project gets loaded. > 2) For each database platform, the directory link for DBACCESS_COMMON has to be > configured (manually?) There should be a single DBACCESS_COMMON variable defined in your workspace and that variable is used by every db platform. > 3) When configuring the link, you change your .project contents to a setting > that is only valid locally. That means, each time you submit you changes, you > have to be careful not to submit (the "link" part) of the .project files The link should only have the variable name in it, not a hard coded-path. See the .project file that you checked out, but everybody should be able to share the exact same project file. > 4) Any sort of automatic build (like Tycho/Maven) will most likely have > difficulties with this setup Not sure I understand why this would be the case. > 5) One of our use case scenarios is to support more than one database > platform (also during design time, in you eclipse IDE). In that case, you had > the common files multiple times in every bundle. The common files should only appear once in each bundle, not multiple times. These are impl classes not API classes so it doesn't matter if they exist in each bundle. > 6) Unit testing of the common part would also be less direct, because common is > not an (java) eclipse project. Common is shared impl that is embedded into each concrete impl. It doesn't/can't get unit tested by itself. > Especially 1), 2), and 3) might make it difficult for other people to run and > test DBAccess. But that could be just my (weird?) way of doing things --- there > might be a better and more elegant way. I would therefore be nice, if someone > else (Shaun?, Krum?) could try to setup the DBAccess locally (after the patch) > and see if they run into the same difficulties. There are a couple other issues that might make this thorny, though. 1) I have been using Eclipse Galileo, which lets me define workspace variables. When Tom tried to do this his workspace variables were not found by the project, so there may be a bug that prevents this from working properly. 2) The path variable feature that allows linked resources seems to have been overhauled in Helios and isn't even the same anymore. Tom could not even see his workspace variables from the linked resource dialog, he could only access his project variables, which we don't want because they store the resolved physical path in the .project file. (In reply to comment #2) > There are a couple other issues that might make this thorny, though. > > 1) I have been using Eclipse Galileo, which lets me define workspace variables. > When Tom tried to do this his workspace variables were not found by the > project, so there may be a bug that prevents this from working properly. > > 2) The path variable feature that allows linked resources seems to have been > overhauled in Helios and isn't even the same anymore. Tom could not even see > his workspace variables from the linked resource dialog, he could only access > his project variables, which we don't want because they store the resolved > physical path in the .project file. I am using Helios too --- and Toms observation is what I have tried to describe above. Additionally, I have to create an empty directory "commom", otherwise I do not see the linked resource... It sounds like I should update to Helios and we can re-evualate what our options are. My hope is still that: 1) We won't need more than one Gemini DBAccess bundle for any given driver. (We would still need one or more bundles containing the DB JDBC drivers.) 2) All of the shared impl code is stored in a single place in SVN. As discussed in the Gemini conf-call: Right now, we have three goals: 1) We want to leave incubation; if possible together with Gemini JPA. 2) It should be possible to build and run Gemini DBAccess with Helios (future plan: it should also be possible to have automated builds and tests). 3) Support more that one database platform -> requires refactoring of DBAccess. This is the topic of this bug. For the graduation, I want to postpone the refactoring and go back to the state before the refactoring. In that state we did not have any issues with Helios, so the project is in a clean and stable state (albeit without the refactoring and the support of MySQL). This state is also reflected in the current state of the release documents, but the release plan should also reflect that. Scheduling the release review for March 2 seems to be possible. Any comments, objections? -- Juergen |