[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gemini-dev] DBAccess refactoring
|
Hi Juergen,
I just linked the common source to the DBACCESS_COMMON workspace
variable. If you declare that variable in your workspace and set it to
the common folder in DBAccess SVN checkout then we should be able to
work on the same DBAccess project files (without creating an additional
project for the common stuff). Try loading it in, though, and let me
know if it doesn't work for you.
-Mike
On 12/20/2010 11:44 AM, Kissner, Juergen wrote:
Hi Mike,
even if you exchange the absolute paths by relative ones, there is still be a problem:
In eclipse, when importing the SVN Depot, you can do that conveniently by choosing "Import project from SVN". One of the following steps is "Find projects in children of selected resource". Unless "common" contains an Eclipse project, the IDE does not even sync "common" to disk. Of course, that could be done that manually. So I guess, one should make "common" an Eclipse project too...
Best Regards,
Juergen
-----Original Message-----
From: gemini-dev-bounces@xxxxxxxxxxx [mailto:gemini-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Keith
Sent: Montag, 20. Dezember 2010 16:03
To: Gemini and sub-projects developer discussions
Subject: Re: [gemini-dev] DBAccess refactoring
The common branch is common code for each DB bundle to include, not a
common bundle. I believe it is easier to have a single DBAccess bundle
for each DB platform, rather than a hierarchy of bundles to have to
manage. By maintaining the common code in a single common place,
however, it will be easier to develop, fix and upgrade.
I always get burned by the source links in Eclipse when it hardcodes
pathnames in the project file. I will fix the project file and check it
in. In the meantime, you can just change the link in the .project file
to point to the "common" directory in your environment.
If, by "uploading build artifacts" you mean to make bundles available
for download, that involves putting the files on the download server:
download.eclipse.org/gemini/dbaccess. I created an r1.0/milestones
folder there where you can add zip files.
-Mike
On 12/20/2010 9:32 AM, Kissner, Juergen wrote:
Hi Mike,
Our refactoring attempts unfortunately coincided --- even worse(for me): you were slightly faster ;-). With the current project setup, however, DBAccess does not compile any more. It looks as if the new "common" branch does not contain any bundles.
Maybe I made a mistake? Shall I open a bug?
Best regards,
Jürgen
Ps.: It is still unclear to me how to upload build artifacts to Eclipse. Do you know a link that explains that?
-----Original Message-----
From: gemini-dev-bounces@xxxxxxxxxxx [mailto:gemini-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Keith
Sent: Montag, 20. Dezember 2010 15:10
To: Gemini Dev List
Subject: [gemini-dev] DBAccess refactoring
Juergen,
I did what I had been meaning to do for the last few months -- refactor
the DBAccess code base to make it more extensible for other DB
platforms. I also checked in the support for MySQL. I haven't added the
tests, yet, because that is going to involve doing some test refactoring
as well. Not sure if you have any specific ideas about how you you would
like the tests to be structured to cover different databases.
Anyway, feel free to reorg it again, but at least now it should be
really easy to add support for new DB platforms.
-Mike
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
