Home » Eclipse Projects » DTP » Offer of Code Donation for DTP
| Offer of Code Donation for DTP [message #66] |
Wed, 23 February 2005 11:52  |
 Simon Wilson
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
I have spent the last 6 months working on a commercial-quality plugin
for working with SQL RDBMS systems within the Eclipse IDE.
The feature provides the following capabilities which correspond closely
to the requirements described by the DTP proposal:
* Definition of an extension point for JDBC drivers
Each JDBC driver is published as a plugin. The plugin describes
the database type it targets, the URL format, the driver's class name,
vendor information, version information, etc.
The plugin currently includes JDBC driver plugins for
the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
and Connector-J driver for MySQL.
* Definition of an extension point for database providers
The plugin's provider concept is equivalent to the connection
profile concept described in the DTP proposal. A provider is
responsible for providing the contributing the following:
1) Meta-data provision for tables, functions, user-defined
data-types, schemata, procedures, columns and views. Each
provider can publish additional provider-specific meta-data.
2) Representation of database objects (tables, functions etc) as a
model implementing interfaces defined by the core plugin. Services
provided by this model include navigation through the database
schema (enumeration of tables, etc.), finding of objects for
content assist/auto completion, and the implementation of base
services such as rename and drop.
3) Scripting of common statements such as SELECT (tables, views,
sequences), INSERT, UPDATE and DELETE (tables), CREATE,
DROP (all objects) and EXEC (stored procedures, functions).
4) An optional provider-specific grammar class which describes
the SQL grammar used by the provider. This grammar is then used
by the UI plugin when rendering text with syntax highlighting
for the user. It is also used when reformatting SQL (keyword
identification for keyword case modification). Finally, the
provider can customize dialect-specific operations such as keyword
escaping. A base grammar encapsulates the SQL 99 standard dialect
and can be overridden/extended as required on a per-provider basis.
5) Contribute a UI for the configuration of database connections by
the user.
6) Optional contribution of a class to parse SQL batches into
statements for execution by the JDBC driver. This allows for
provider-specific batch processing.
7) Create a registration object which represents a persistent
database connection. This registration object is then used
to obtain a database object (entry-point into the database's
model) and a connection factory for the execution of ad-hoc
queries.
8) A factory which can rehydrate a registration from
connection configuration information.
Note that providers are decoupled from JDBC drivers. This allows for
a provider to be targeted by multiple drivers (e.g. Microsoft SQL
Server could be targetted by both jTDS and Microsoft's driver) and
also for a single driver to target multiple providers (e.g. jTDS
targetting both Microsoft SQL Server and Sybase).
Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
Experimental support exists for MySQL v4.x.
* A core plugin which defines:
1) The above extension points
2) A set of interfaces for the model.
3) Core classes such as a provider manager and JDBC driver manager.
4) A framework for the implementation of providers including
a set of classes which implement a provider through the
standard INFORMATION_SCHEMA views.
* A UI plugin contributes the following:
1) A database perspective.
2) A schema explorer view for browsing database meta-data.
3) An SQL editor. This editor is used to edit SQL files and
also ad-hoc queries. The queries can be executed against the
selected registration. Several editors may be opened at once.
The editor fully integrates with the Eclipse's resource model,
correctly responding to events from the underlying file objects.
The SQL editor also implements integration with the standard
find/replace dialog and content assist.
4) A placeholder view. The user may use Ant-property-like
placeholders in the SQL editor. These properties automatically
appear in the placeholder view where the user may assign values
to them. The placeholders are then substituted with the values
prior to query execution.
5) A DDL definition view. This view displays a CREATE statement for
the currently selected object in the schema explorer.
6) A script history view. This view displays a history of statements
executed interactively by the user. The script history is full-text
indexed (using Lucene) and can be searched by the user in
real-time.
The UI plugin makes use of Eclipse's adaptor facility to associate
UI logic in an architecturally-clean and non-invasive fashion with
model objects implemented by providers. A set of adapter factories
is implemented as the basis for the hierarchy display in the
schema explorer view. This allows providers to implement their
own adaptor factories and tailor the schema explorer hierarchy to
their own needs.
The UI plugin also defines a set of action delegate object
contributions for types defined by the core model, including the
ability to drop, rename and script objects from the content menu.
Providers may also provide additional contributions (for example, the
PostgreSQL provider contributes an action delegate for a database
vacuuming function).
The UI plugin takes advantage of Eclipse's job framework. For example,
the SQL editor implements a background SQL parser to extract
placeholders from the editor's document as the user types. Also, the
history manager updates the history's full-text index in the
background as a job.
* The plugin was developed on both the MacOS and Windows, and has been
tested to run under Linux/GTK.
* The plugin was developed for Eclipse 3.0 and has been tested with
3.1 M4.
We believe that our set of plugins would provide a solid basis for the
DTP project and that many of the requirements stated in the DTP proposal
are met by the plugin. Please let me know whether the Eclipse Foundation
would be interested in reviewing the code for possible inclusion in the
DTP project's code-base.
I would also be interested in actively participating as a contributor to
the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
Server and Eclipse plugin development experience. Please let me know how
I should go about persuing becoming a contributor to the project.
Simon Wilson
Objectnation GmbH
Zurich, Switzerland
|
|
|
| Re: Offer of Code Donation for DTP [message #71 is a reply to message #66] |
Wed, 23 February 2005 14:54  |
Eclipse User |
|
|
|
Originally posted by: john.graham.sybase.com
Simon,
Thank you very much for the information and contribution offer. We are
definitely interested in talking with you further about these possibilities.
At this stage, we are collecting notices of interest, and in the coming
weeks we plan to discuss matters in more detail with interested parties. (If
you happen to be at EclipseCon next week, it would a chance to meet in
person as well.) We will definitely be back in contact with you in the near
future.
Regards,
John Graham
john.graham@sybase.com
Eclipse DTP
"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
news:cvhqr8$q7j$1@www.eclipse.org...
>I have spent the last 6 months working on a commercial-quality plugin for
>working with SQL RDBMS systems within the Eclipse IDE.
>
> The feature provides the following capabilities which correspond closely
> to the requirements described by the DTP proposal:
>
> * Definition of an extension point for JDBC drivers
>
> Each JDBC driver is published as a plugin. The plugin describes
> the database type it targets, the URL format, the driver's class name,
> vendor information, version information, etc.
>
> The plugin currently includes JDBC driver plugins for
> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
> and Connector-J driver for MySQL.
>
> * Definition of an extension point for database providers
>
> The plugin's provider concept is equivalent to the connection
> profile concept described in the DTP proposal. A provider is
> responsible for providing the contributing the following:
>
> 1) Meta-data provision for tables, functions, user-defined
> data-types, schemata, procedures, columns and views. Each
> provider can publish additional provider-specific meta-data.
>
> 2) Representation of database objects (tables, functions etc) as a
> model implementing interfaces defined by the core plugin. Services
> provided by this model include navigation through the database
> schema (enumeration of tables, etc.), finding of objects for
> content assist/auto completion, and the implementation of base
> services such as rename and drop.
>
> 3) Scripting of common statements such as SELECT (tables, views,
> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
> DROP (all objects) and EXEC (stored procedures, functions).
>
> 4) An optional provider-specific grammar class which describes
> the SQL grammar used by the provider. This grammar is then used
> by the UI plugin when rendering text with syntax highlighting
> for the user. It is also used when reformatting SQL (keyword
> identification for keyword case modification). Finally, the
> provider can customize dialect-specific operations such as keyword
> escaping. A base grammar encapsulates the SQL 99 standard dialect
> and can be overridden/extended as required on a per-provider basis.
>
> 5) Contribute a UI for the configuration of database connections by
> the user.
>
> 6) Optional contribution of a class to parse SQL batches into
> statements for execution by the JDBC driver. This allows for
> provider-specific batch processing.
>
> 7) Create a registration object which represents a persistent
> database connection. This registration object is then used
> to obtain a database object (entry-point into the database's
> model) and a connection factory for the execution of ad-hoc
> queries.
>
> 8) A factory which can rehydrate a registration from
> connection configuration information.
>
> Note that providers are decoupled from JDBC drivers. This allows for
> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
> Server could be targetted by both jTDS and Microsoft's driver) and
> also for a single driver to target multiple providers (e.g. jTDS
> targetting both Microsoft SQL Server and Sybase).
>
> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
> Experimental support exists for MySQL v4.x.
>
> * A core plugin which defines:
>
> 1) The above extension points
>
> 2) A set of interfaces for the model.
>
> 3) Core classes such as a provider manager and JDBC driver manager.
>
> 4) A framework for the implementation of providers including
> a set of classes which implement a provider through the
> standard INFORMATION_SCHEMA views.
>
> * A UI plugin contributes the following:
>
> 1) A database perspective.
>
> 2) A schema explorer view for browsing database meta-data.
>
> 3) An SQL editor. This editor is used to edit SQL files and
> also ad-hoc queries. The queries can be executed against the
> selected registration. Several editors may be opened at once.
> The editor fully integrates with the Eclipse's resource model,
> correctly responding to events from the underlying file objects.
> The SQL editor also implements integration with the standard
> find/replace dialog and content assist.
>
> 4) A placeholder view. The user may use Ant-property-like
> placeholders in the SQL editor. These properties automatically
> appear in the placeholder view where the user may assign values
> to them. The placeholders are then substituted with the values
> prior to query execution.
>
> 5) A DDL definition view. This view displays a CREATE statement for
> the currently selected object in the schema explorer.
>
> 6) A script history view. This view displays a history of statements
> executed interactively by the user. The script history is full-text
> indexed (using Lucene) and can be searched by the user in
> real-time.
>
> The UI plugin makes use of Eclipse's adaptor facility to associate
> UI logic in an architecturally-clean and non-invasive fashion with
> model objects implemented by providers. A set of adapter factories
> is implemented as the basis for the hierarchy display in the
> schema explorer view. This allows providers to implement their
> own adaptor factories and tailor the schema explorer hierarchy to
> their own needs.
>
> The UI plugin also defines a set of action delegate object
> contributions for types defined by the core model, including the
> ability to drop, rename and script objects from the content menu.
>
> Providers may also provide additional contributions (for example, the
> PostgreSQL provider contributes an action delegate for a database
> vacuuming function).
>
> The UI plugin takes advantage of Eclipse's job framework. For example,
> the SQL editor implements a background SQL parser to extract
> placeholders from the editor's document as the user types. Also, the
> history manager updates the history's full-text index in the
> background as a job.
>
> * The plugin was developed on both the MacOS and Windows, and has been
> tested to run under Linux/GTK.
>
> * The plugin was developed for Eclipse 3.0 and has been tested with
> 3.1 M4.
>
> We believe that our set of plugins would provide a solid basis for the DTP
> project and that many of the requirements stated in the DTP proposal are
> met by the plugin. Please let me know whether the Eclipse Foundation would
> be interested in reviewing the code for possible inclusion in the DTP
> project's code-base.
>
> I would also be interested in actively participating as a contributor to
> the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
> Server and Eclipse plugin development experience. Please let me know how I
> should go about persuing becoming a contributor to the project.
>
> Simon Wilson
> Objectnation GmbH
> Zurich, Switzerland
|
|
|
| Re: Offer of Code Donation for DTP [message #73 is a reply to message #71] |
Wed, 23 February 2005 17:34 |
Simon Wilson
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
John,
I won't be making it to EclipseCon unfortunately, but look forward to
discussing the matter with you in more detail in the near future.
With best regards,
Simon Wilson
Objectnation GmbH
Zurich, Switzerland
John Graham wrote:
> Simon,
>
> Thank you very much for the information and contribution offer. We are
> definitely interested in talking with you further about these possibilities.
> At this stage, we are collecting notices of interest, and in the coming
> weeks we plan to discuss matters in more detail with interested parties. (If
> you happen to be at EclipseCon next week, it would a chance to meet in
> person as well.) We will definitely be back in contact with you in the near
> future.
>
> Regards,
> John Graham
> john.graham@sybase.com
> Eclipse DTP
>
> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
> news:cvhqr8$q7j$1@www.eclipse.org...
>
>>I have spent the last 6 months working on a commercial-quality plugin for
>>working with SQL RDBMS systems within the Eclipse IDE.
>>
>>The feature provides the following capabilities which correspond closely
>>to the requirements described by the DTP proposal:
>>
>>* Definition of an extension point for JDBC drivers
>>
>> Each JDBC driver is published as a plugin. The plugin describes
>> the database type it targets, the URL format, the driver's class name,
>> vendor information, version information, etc.
>>
>> The plugin currently includes JDBC driver plugins for
>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>> and Connector-J driver for MySQL.
>>
>>* Definition of an extension point for database providers
>>
>> The plugin's provider concept is equivalent to the connection
>> profile concept described in the DTP proposal. A provider is
>> responsible for providing the contributing the following:
>>
>> 1) Meta-data provision for tables, functions, user-defined
>> data-types, schemata, procedures, columns and views. Each
>> provider can publish additional provider-specific meta-data.
>>
>> 2) Representation of database objects (tables, functions etc) as a
>> model implementing interfaces defined by the core plugin. Services
>> provided by this model include navigation through the database
>> schema (enumeration of tables, etc.), finding of objects for
>> content assist/auto completion, and the implementation of base
>> services such as rename and drop.
>>
>> 3) Scripting of common statements such as SELECT (tables, views,
>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>> DROP (all objects) and EXEC (stored procedures, functions).
>>
>> 4) An optional provider-specific grammar class which describes
>> the SQL grammar used by the provider. This grammar is then used
>> by the UI plugin when rendering text with syntax highlighting
>> for the user. It is also used when reformatting SQL (keyword
>> identification for keyword case modification). Finally, the
>> provider can customize dialect-specific operations such as keyword
>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>> and can be overridden/extended as required on a per-provider basis.
>>
>> 5) Contribute a UI for the configuration of database connections by
>> the user.
>>
>> 6) Optional contribution of a class to parse SQL batches into
>> statements for execution by the JDBC driver. This allows for
>> provider-specific batch processing.
>>
>> 7) Create a registration object which represents a persistent
>> database connection. This registration object is then used
>> to obtain a database object (entry-point into the database's
>> model) and a connection factory for the execution of ad-hoc
>> queries.
>>
>> 8) A factory which can rehydrate a registration from
>> connection configuration information.
>>
>> Note that providers are decoupled from JDBC drivers. This allows for
>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>> Server could be targetted by both jTDS and Microsoft's driver) and
>> also for a single driver to target multiple providers (e.g. jTDS
>> targetting both Microsoft SQL Server and Sybase).
>>
>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>> Experimental support exists for MySQL v4.x.
>>
>>* A core plugin which defines:
>>
>> 1) The above extension points
>>
>> 2) A set of interfaces for the model.
>>
>> 3) Core classes such as a provider manager and JDBC driver manager.
>>
>> 4) A framework for the implementation of providers including
>> a set of classes which implement a provider through the
>> standard INFORMATION_SCHEMA views.
>>
>>* A UI plugin contributes the following:
>>
>> 1) A database perspective.
>>
>> 2) A schema explorer view for browsing database meta-data.
>>
>> 3) An SQL editor. This editor is used to edit SQL files and
>> also ad-hoc queries. The queries can be executed against the
>> selected registration. Several editors may be opened at once.
>> The editor fully integrates with the Eclipse's resource model,
>> correctly responding to events from the underlying file objects.
>> The SQL editor also implements integration with the standard
>> find/replace dialog and content assist.
>>
>> 4) A placeholder view. The user may use Ant-property-like
>> placeholders in the SQL editor. These properties automatically
>> appear in the placeholder view where the user may assign values
>> to them. The placeholders are then substituted with the values
>> prior to query execution.
>>
>> 5) A DDL definition view. This view displays a CREATE statement for
>> the currently selected object in the schema explorer.
>>
>> 6) A script history view. This view displays a history of statements
>> executed interactively by the user. The script history is full-text
>> indexed (using Lucene) and can be searched by the user in
>> real-time.
>>
>> The UI plugin makes use of Eclipse's adaptor facility to associate
>> UI logic in an architecturally-clean and non-invasive fashion with
>> model objects implemented by providers. A set of adapter factories
>> is implemented as the basis for the hierarchy display in the
>> schema explorer view. This allows providers to implement their
>> own adaptor factories and tailor the schema explorer hierarchy to
>> their own needs.
>>
>> The UI plugin also defines a set of action delegate object
>> contributions for types defined by the core model, including the
>> ability to drop, rename and script objects from the content menu.
>>
>> Providers may also provide additional contributions (for example, the
>> PostgreSQL provider contributes an action delegate for a database
>> vacuuming function).
>>
>> The UI plugin takes advantage of Eclipse's job framework. For example,
>> the SQL editor implements a background SQL parser to extract
>> placeholders from the editor's document as the user types. Also, the
>> history manager updates the history's full-text index in the
>> background as a job.
>>
>>* The plugin was developed on both the MacOS and Windows, and has been
>> tested to run under Linux/GTK.
>>
>>* The plugin was developed for Eclipse 3.0 and has been tested with
>> 3.1 M4.
>>
>>We believe that our set of plugins would provide a solid basis for the DTP
>>project and that many of the requirements stated in the DTP proposal are
>>met by the plugin. Please let me know whether the Eclipse Foundation would
>>be interested in reviewing the code for possible inclusion in the DTP
>>project's code-base.
>>
>>I would also be interested in actively participating as a contributor to
>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>Server and Eclipse plugin development experience. Please let me know how I
>>should go about persuing becoming a contributor to the project.
>>
>>Simon Wilson
>>Objectnation GmbH
>>Zurich, Switzerland
>
>
>
|
|
|
| Re: Offer of Code Donation for DTP [message #94 is a reply to message #73] |
Fri, 11 March 2005 16:42 |
| Eclipse User |
|
|
|
Originally posted by: john.graham.sybase.com
Simon,
We are starting to look at existing code bases in the areas you mention,
with an eye toward eventual consolidation of best-of-breed,
community-supported components into DTP. As the discussion develops, regular
postings to this newsgroup and updates to the proposal will keep the
community informed. Since you have offered a code base, would like to talk
with us in more detail about its possible adoption into DTP?
Thanks,
--John Graham
john.graham@sybase.com
Eclipse DTP
"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
news:cviesd$amb$1@www.eclipse.org...
> John,
>
> I won't be making it to EclipseCon unfortunately, but look forward to
> discussing the matter with you in more detail in the near future.
>
> With best regards,
>
> Simon Wilson
> Objectnation GmbH
> Zurich, Switzerland
>
> John Graham wrote:
>> Simon,
>>
>> Thank you very much for the information and contribution offer. We are
>> definitely interested in talking with you further about these
>> possibilities. At this stage, we are collecting notices of interest, and
>> in the coming weeks we plan to discuss matters in more detail with
>> interested parties. (If you happen to be at EclipseCon next week, it
>> would a chance to meet in person as well.) We will definitely be back in
>> contact with you in the near future.
>>
>> Regards,
>> John Graham
>> john.graham@sybase.com
>> Eclipse DTP
>>
>> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
>> news:cvhqr8$q7j$1@www.eclipse.org...
>>
>>>I have spent the last 6 months working on a commercial-quality plugin for
>>>working with SQL RDBMS systems within the Eclipse IDE.
>>>
>>>The feature provides the following capabilities which correspond closely
>>>to the requirements described by the DTP proposal:
>>>
>>>* Definition of an extension point for JDBC drivers
>>>
>>> Each JDBC driver is published as a plugin. The plugin describes
>>> the database type it targets, the URL format, the driver's class name,
>>> vendor information, version information, etc.
>>>
>>> The plugin currently includes JDBC driver plugins for
>>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>>> and Connector-J driver for MySQL.
>>>
>>>* Definition of an extension point for database providers
>>>
>>> The plugin's provider concept is equivalent to the connection
>>> profile concept described in the DTP proposal. A provider is
>>> responsible for providing the contributing the following:
>>>
>>> 1) Meta-data provision for tables, functions, user-defined
>>> data-types, schemata, procedures, columns and views. Each
>>> provider can publish additional provider-specific meta-data.
>>>
>>> 2) Representation of database objects (tables, functions etc) as a
>>> model implementing interfaces defined by the core plugin. Services
>>> provided by this model include navigation through the database
>>> schema (enumeration of tables, etc.), finding of objects for
>>> content assist/auto completion, and the implementation of base
>>> services such as rename and drop.
>>>
>>> 3) Scripting of common statements such as SELECT (tables, views,
>>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>>> DROP (all objects) and EXEC (stored procedures, functions).
>>>
>>> 4) An optional provider-specific grammar class which describes
>>> the SQL grammar used by the provider. This grammar is then used
>>> by the UI plugin when rendering text with syntax highlighting
>>> for the user. It is also used when reformatting SQL (keyword
>>> identification for keyword case modification). Finally, the
>>> provider can customize dialect-specific operations such as keyword
>>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>>> and can be overridden/extended as required on a per-provider basis.
>>>
>>> 5) Contribute a UI for the configuration of database connections by
>>> the user.
>>>
>>> 6) Optional contribution of a class to parse SQL batches into
>>> statements for execution by the JDBC driver. This allows for
>>> provider-specific batch processing.
>>>
>>> 7) Create a registration object which represents a persistent
>>> database connection. This registration object is then used
>>> to obtain a database object (entry-point into the database's
>>> model) and a connection factory for the execution of ad-hoc
>>> queries.
>>>
>>> 8) A factory which can rehydrate a registration from
>>> connection configuration information.
>>>
>>> Note that providers are decoupled from JDBC drivers. This allows for
>>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>>> Server could be targetted by both jTDS and Microsoft's driver) and
>>> also for a single driver to target multiple providers (e.g. jTDS
>>> targetting both Microsoft SQL Server and Sybase).
>>>
>>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>>> Experimental support exists for MySQL v4.x.
>>>
>>>* A core plugin which defines:
>>>
>>> 1) The above extension points
>>>
>>> 2) A set of interfaces for the model.
>>>
>>> 3) Core classes such as a provider manager and JDBC driver manager.
>>>
>>> 4) A framework for the implementation of providers including
>>> a set of classes which implement a provider through the
>>> standard INFORMATION_SCHEMA views.
>>>
>>>* A UI plugin contributes the following:
>>>
>>> 1) A database perspective.
>>>
>>> 2) A schema explorer view for browsing database meta-data.
>>>
>>> 3) An SQL editor. This editor is used to edit SQL files and
>>> also ad-hoc queries. The queries can be executed against the
>>> selected registration. Several editors may be opened at once.
>>> The editor fully integrates with the Eclipse's resource model,
>>> correctly responding to events from the underlying file objects.
>>> The SQL editor also implements integration with the standard
>>> find/replace dialog and content assist.
>>>
>>> 4) A placeholder view. The user may use Ant-property-like
>>> placeholders in the SQL editor. These properties automatically
>>> appear in the placeholder view where the user may assign values
>>> to them. The placeholders are then substituted with the values
>>> prior to query execution.
>>>
>>> 5) A DDL definition view. This view displays a CREATE statement for
>>> the currently selected object in the schema explorer.
>>>
>>> 6) A script history view. This view displays a history of statements
>>> executed interactively by the user. The script history is full-text
>>> indexed (using Lucene) and can be searched by the user in
>>> real-time.
>>>
>>> The UI plugin makes use of Eclipse's adaptor facility to associate
>>> UI logic in an architecturally-clean and non-invasive fashion with
>>> model objects implemented by providers. A set of adapter factories
>>> is implemented as the basis for the hierarchy display in the
>>> schema explorer view. This allows providers to implement their
>>> own adaptor factories and tailor the schema explorer hierarchy to
>>> their own needs.
>>>
>>> The UI plugin also defines a set of action delegate object
>>> contributions for types defined by the core model, including the
>>> ability to drop, rename and script objects from the content menu.
>>>
>>> Providers may also provide additional contributions (for example, the
>>> PostgreSQL provider contributes an action delegate for a database
>>> vacuuming function).
>>>
>>> The UI plugin takes advantage of Eclipse's job framework. For example,
>>> the SQL editor implements a background SQL parser to extract
>>> placeholders from the editor's document as the user types. Also, the
>>> history manager updates the history's full-text index in the
>>> background as a job.
>>>
>>>* The plugin was developed on both the MacOS and Windows, and has been
>>> tested to run under Linux/GTK.
>>>
>>>* The plugin was developed for Eclipse 3.0 and has been tested with
>>> 3.1 M4.
>>>
>>>We believe that our set of plugins would provide a solid basis for the
>>>DTP project and that many of the requirements stated in the DTP proposal
>>>are met by the plugin. Please let me know whether the Eclipse Foundation
>>>would be interested in reviewing the code for possible inclusion in the
>>>DTP project's code-base.
>>>
>>>I would also be interested in actively participating as a contributor to
>>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>>Server and Eclipse plugin development experience. Please let me know how
>>>I should go about persuing becoming a contributor to the project.
>>>
>>>Simon Wilson
>>>Objectnation GmbH
>>>Zurich, Switzerland
>>
>>
|
|
|
| Re: Offer of Code Donation for DTP [message #112 is a reply to message #94] |
Tue, 15 March 2005 19:58 |
Simon Wilson
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Hi John,
I hope you had a great time at EclipseCon...
> would like to talk
> with us in more detail about its possible adoption into DTP?
Absolutely. Having not worked on an open-source project before, I need
some guidance from you as how to proceed...
I would be more than willing to write a short document to help you find
your way around the plugin. I would suggest a description of:
- Some information on me and my background
- Our motivations for developing our plugin in the first place
- The set of requirements it originally had to fulfill
- The conceptual basis of the current implementation
- An overview of the UI, with screenshots, descriptions etc.
- A design brief for plugin modularity, important classes, etc.
Would this be of use to you? oO would you rather just get your hands
dirty and dig into the code?
Please let me know which information/code etc you would need and which
channels I should use to get this information to you.
Cheers,
Simon
John Graham wrote:
> Simon,
>
> We are starting to look at existing code bases in the areas you mention,
> with an eye toward eventual consolidation of best-of-breed,
> community-supported components into DTP. As the discussion develops, regular
> postings to this newsgroup and updates to the proposal will keep the
> community informed. Since you have offered a code base, would like to talk
> with us in more detail about its possible adoption into DTP?
>
> Thanks,
> --John Graham
> john.graham@sybase.com
> Eclipse DTP
>
> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
> news:cviesd$amb$1@www.eclipse.org...
>
>>John,
>>
>>I won't be making it to EclipseCon unfortunately, but look forward to
>>discussing the matter with you in more detail in the near future.
>>
>>With best regards,
>>
>>Simon Wilson
>>Objectnation GmbH
>>Zurich, Switzerland
>>
>>John Graham wrote:
>>
>>>Simon,
>>>
>>>Thank you very much for the information and contribution offer. We are
>>>definitely interested in talking with you further about these
>>>possibilities. At this stage, we are collecting notices of interest, and
>>>in the coming weeks we plan to discuss matters in more detail with
>>>interested parties. (If you happen to be at EclipseCon next week, it
>>>would a chance to meet in person as well.) We will definitely be back in
>>>contact with you in the near future.
>>>
>>>Regards,
>>>John Graham
>>>john.graham@sybase.com
>>>Eclipse DTP
>>>
>>>"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
>>>news:cvhqr8$q7j$1@www.eclipse.org...
>>>
>>>
>>>>I have spent the last 6 months working on a commercial-quality plugin for
>>>>working with SQL RDBMS systems within the Eclipse IDE.
>>>>
>>>>The feature provides the following capabilities which correspond closely
>>>>to the requirements described by the DTP proposal:
>>>>
>>>>* Definition of an extension point for JDBC drivers
>>>>
>>>> Each JDBC driver is published as a plugin. The plugin describes
>>>> the database type it targets, the URL format, the driver's class name,
>>>> vendor information, version information, etc.
>>>>
>>>> The plugin currently includes JDBC driver plugins for
>>>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>>>> and Connector-J driver for MySQL.
>>>>
>>>>* Definition of an extension point for database providers
>>>>
>>>> The plugin's provider concept is equivalent to the connection
>>>> profile concept described in the DTP proposal. A provider is
>>>> responsible for providing the contributing the following:
>>>>
>>>> 1) Meta-data provision for tables, functions, user-defined
>>>> data-types, schemata, procedures, columns and views. Each
>>>> provider can publish additional provider-specific meta-data.
>>>>
>>>> 2) Representation of database objects (tables, functions etc) as a
>>>> model implementing interfaces defined by the core plugin. Services
>>>> provided by this model include navigation through the database
>>>> schema (enumeration of tables, etc.), finding of objects for
>>>> content assist/auto completion, and the implementation of base
>>>> services such as rename and drop.
>>>>
>>>> 3) Scripting of common statements such as SELECT (tables, views,
>>>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>>>> DROP (all objects) and EXEC (stored procedures, functions).
>>>>
>>>> 4) An optional provider-specific grammar class which describes
>>>> the SQL grammar used by the provider. This grammar is then used
>>>> by the UI plugin when rendering text with syntax highlighting
>>>> for the user. It is also used when reformatting SQL (keyword
>>>> identification for keyword case modification). Finally, the
>>>> provider can customize dialect-specific operations such as keyword
>>>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>>>> and can be overridden/extended as required on a per-provider basis.
>>>>
>>>> 5) Contribute a UI for the configuration of database connections by
>>>> the user.
>>>>
>>>> 6) Optional contribution of a class to parse SQL batches into
>>>> statements for execution by the JDBC driver. This allows for
>>>> provider-specific batch processing.
>>>>
>>>> 7) Create a registration object which represents a persistent
>>>> database connection. This registration object is then used
>>>> to obtain a database object (entry-point into the database's
>>>> model) and a connection factory for the execution of ad-hoc
>>>> queries.
>>>>
>>>> 8) A factory which can rehydrate a registration from
>>>> connection configuration information.
>>>>
>>>> Note that providers are decoupled from JDBC drivers. This allows for
>>>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>>>> Server could be targetted by both jTDS and Microsoft's driver) and
>>>> also for a single driver to target multiple providers (e.g. jTDS
>>>> targetting both Microsoft SQL Server and Sybase).
>>>>
>>>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>>>> Experimental support exists for MySQL v4.x.
>>>>
>>>>* A core plugin which defines:
>>>>
>>>> 1) The above extension points
>>>>
>>>> 2) A set of interfaces for the model.
>>>>
>>>> 3) Core classes such as a provider manager and JDBC driver manager.
>>>>
>>>> 4) A framework for the implementation of providers including
>>>> a set of classes which implement a provider through the
>>>> standard INFORMATION_SCHEMA views.
>>>>
>>>>* A UI plugin contributes the following:
>>>>
>>>> 1) A database perspective.
>>>>
>>>> 2) A schema explorer view for browsing database meta-data.
>>>>
>>>> 3) An SQL editor. This editor is used to edit SQL files and
>>>> also ad-hoc queries. The queries can be executed against the
>>>> selected registration. Several editors may be opened at once.
>>>> The editor fully integrates with the Eclipse's resource model,
>>>> correctly responding to events from the underlying file objects.
>>>> The SQL editor also implements integration with the standard
>>>> find/replace dialog and content assist.
>>>>
>>>> 4) A placeholder view. The user may use Ant-property-like
>>>> placeholders in the SQL editor. These properties automatically
>>>> appear in the placeholder view where the user may assign values
>>>> to them. The placeholders are then substituted with the values
>>>> prior to query execution.
>>>>
>>>> 5) A DDL definition view. This view displays a CREATE statement for
>>>> the currently selected object in the schema explorer.
>>>>
>>>> 6) A script history view. This view displays a history of statements
>>>> executed interactively by the user. The script history is full-text
>>>> indexed (using Lucene) and can be searched by the user in
>>>> real-time.
>>>>
>>>> The UI plugin makes use of Eclipse's adaptor facility to associate
>>>> UI logic in an architecturally-clean and non-invasive fashion with
>>>> model objects implemented by providers. A set of adapter factories
>>>> is implemented as the basis for the hierarchy display in the
>>>> schema explorer view. This allows providers to implement their
>>>> own adaptor factories and tailor the schema explorer hierarchy to
>>>> their own needs.
>>>>
>>>> The UI plugin also defines a set of action delegate object
>>>> contributions for types defined by the core model, including the
>>>> ability to drop, rename and script objects from the content menu.
>>>>
>>>> Providers may also provide additional contributions (for example, the
>>>> PostgreSQL provider contributes an action delegate for a database
>>>> vacuuming function).
>>>>
>>>> The UI plugin takes advantage of Eclipse's job framework. For example,
>>>> the SQL editor implements a background SQL parser to extract
>>>> placeholders from the editor's document as the user types. Also, the
>>>> history manager updates the history's full-text index in the
>>>> background as a job.
>>>>
>>>>* The plugin was developed on both the MacOS and Windows, and has been
>>>> tested to run under Linux/GTK.
>>>>
>>>>* The plugin was developed for Eclipse 3.0 and has been tested with
>>>> 3.1 M4.
>>>>
>>>>We believe that our set of plugins would provide a solid basis for the
>>>>DTP project and that many of the requirements stated in the DTP proposal
>>>>are met by the plugin. Please let me know whether the Eclipse Foundation
>>>>would be interested in reviewing the code for possible inclusion in the
>>>>DTP project's code-base.
>>>>
>>>>I would also be interested in actively participating as a contributor to
>>>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>>>Server and Eclipse plugin development experience. Please let me know how
>>>>I should go about persuing becoming a contributor to the project.
>>>>
>>>>Simon Wilson
>>>>Objectnation GmbH
>>>>Zurich, Switzerland
>>>
>>>
>
|
|
|
| Re: Offer of Code Donation for DTP [message #563670 is a reply to message #66] |
Wed, 23 February 2005 14:54 |
John Graham
Messages: 183
Registered: July 2009 |
Senior Member |
|
|
Simon,
Thank you very much for the information and contribution offer. We are
definitely interested in talking with you further about these possibilities.
At this stage, we are collecting notices of interest, and in the coming
weeks we plan to discuss matters in more detail with interested parties. (If
you happen to be at EclipseCon next week, it would a chance to meet in
person as well.) We will definitely be back in contact with you in the near
future.
Regards,
John Graham
john.graham@sybase.com
Eclipse DTP
"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
news:cvhqr8$q7j$1@www.eclipse.org...
>I have spent the last 6 months working on a commercial-quality plugin for
>working with SQL RDBMS systems within the Eclipse IDE.
>
> The feature provides the following capabilities which correspond closely
> to the requirements described by the DTP proposal:
>
> * Definition of an extension point for JDBC drivers
>
> Each JDBC driver is published as a plugin. The plugin describes
> the database type it targets, the URL format, the driver's class name,
> vendor information, version information, etc.
>
> The plugin currently includes JDBC driver plugins for
> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
> and Connector-J driver for MySQL.
>
> * Definition of an extension point for database providers
>
> The plugin's provider concept is equivalent to the connection
> profile concept described in the DTP proposal. A provider is
> responsible for providing the contributing the following:
>
> 1) Meta-data provision for tables, functions, user-defined
> data-types, schemata, procedures, columns and views. Each
> provider can publish additional provider-specific meta-data.
>
> 2) Representation of database objects (tables, functions etc) as a
> model implementing interfaces defined by the core plugin. Services
> provided by this model include navigation through the database
> schema (enumeration of tables, etc.), finding of objects for
> content assist/auto completion, and the implementation of base
> services such as rename and drop.
>
> 3) Scripting of common statements such as SELECT (tables, views,
> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
> DROP (all objects) and EXEC (stored procedures, functions).
>
> 4) An optional provider-specific grammar class which describes
> the SQL grammar used by the provider. This grammar is then used
> by the UI plugin when rendering text with syntax highlighting
> for the user. It is also used when reformatting SQL (keyword
> identification for keyword case modification). Finally, the
> provider can customize dialect-specific operations such as keyword
> escaping. A base grammar encapsulates the SQL 99 standard dialect
> and can be overridden/extended as required on a per-provider basis.
>
> 5) Contribute a UI for the configuration of database connections by
> the user.
>
> 6) Optional contribution of a class to parse SQL batches into
> statements for execution by the JDBC driver. This allows for
> provider-specific batch processing.
>
> 7) Create a registration object which represents a persistent
> database connection. This registration object is then used
> to obtain a database object (entry-point into the database's
> model) and a connection factory for the execution of ad-hoc
> queries.
>
> 8) A factory which can rehydrate a registration from
> connection configuration information.
>
> Note that providers are decoupled from JDBC drivers. This allows for
> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
> Server could be targetted by both jTDS and Microsoft's driver) and
> also for a single driver to target multiple providers (e.g. jTDS
> targetting both Microsoft SQL Server and Sybase).
>
> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
> Experimental support exists for MySQL v4.x.
>
> * A core plugin which defines:
>
> 1) The above extension points
>
> 2) A set of interfaces for the model.
>
> 3) Core classes such as a provider manager and JDBC driver manager.
>
> 4) A framework for the implementation of providers including
> a set of classes which implement a provider through the
> standard INFORMATION_SCHEMA views.
>
> * A UI plugin contributes the following:
>
> 1) A database perspective.
>
> 2) A schema explorer view for browsing database meta-data.
>
> 3) An SQL editor. This editor is used to edit SQL files and
> also ad-hoc queries. The queries can be executed against the
> selected registration. Several editors may be opened at once.
> The editor fully integrates with the Eclipse's resource model,
> correctly responding to events from the underlying file objects.
> The SQL editor also implements integration with the standard
> find/replace dialog and content assist.
>
> 4) A placeholder view. The user may use Ant-property-like
> placeholders in the SQL editor. These properties automatically
> appear in the placeholder view where the user may assign values
> to them. The placeholders are then substituted with the values
> prior to query execution.
>
> 5) A DDL definition view. This view displays a CREATE statement for
> the currently selected object in the schema explorer.
>
> 6) A script history view. This view displays a history of statements
> executed interactively by the user. The script history is full-text
> indexed (using Lucene) and can be searched by the user in
> real-time.
>
> The UI plugin makes use of Eclipse's adaptor facility to associate
> UI logic in an architecturally-clean and non-invasive fashion with
> model objects implemented by providers. A set of adapter factories
> is implemented as the basis for the hierarchy display in the
> schema explorer view. This allows providers to implement their
> own adaptor factories and tailor the schema explorer hierarchy to
> their own needs.
>
> The UI plugin also defines a set of action delegate object
> contributions for types defined by the core model, including the
> ability to drop, rename and script objects from the content menu.
>
> Providers may also provide additional contributions (for example, the
> PostgreSQL provider contributes an action delegate for a database
> vacuuming function).
>
> The UI plugin takes advantage of Eclipse's job framework. For example,
> the SQL editor implements a background SQL parser to extract
> placeholders from the editor's document as the user types. Also, the
> history manager updates the history's full-text index in the
> background as a job.
>
> * The plugin was developed on both the MacOS and Windows, and has been
> tested to run under Linux/GTK.
>
> * The plugin was developed for Eclipse 3.0 and has been tested with
> 3.1 M4.
>
> We believe that our set of plugins would provide a solid basis for the DTP
> project and that many of the requirements stated in the DTP proposal are
> met by the plugin. Please let me know whether the Eclipse Foundation would
> be interested in reviewing the code for possible inclusion in the DTP
> project's code-base.
>
> I would also be interested in actively participating as a contributor to
> the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
> Server and Eclipse plugin development experience. Please let me know how I
> should go about persuing becoming a contributor to the project.
>
> Simon Wilson
> Objectnation GmbH
> Zurich, Switzerland
|
|
|
| Re: Offer of Code Donation for DTP [message #563695 is a reply to message #71] |
Wed, 23 February 2005 17:34 |
Simon Wilson
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
John,
I won't be making it to EclipseCon unfortunately, but look forward to
discussing the matter with you in more detail in the near future.
With best regards,
Simon Wilson
Objectnation GmbH
Zurich, Switzerland
John Graham wrote:
> Simon,
>
> Thank you very much for the information and contribution offer. We are
> definitely interested in talking with you further about these possibilities.
> At this stage, we are collecting notices of interest, and in the coming
> weeks we plan to discuss matters in more detail with interested parties. (If
> you happen to be at EclipseCon next week, it would a chance to meet in
> person as well.) We will definitely be back in contact with you in the near
> future.
>
> Regards,
> John Graham
> john.graham@sybase.com
> Eclipse DTP
>
> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
> news:cvhqr8$q7j$1@www.eclipse.org...
>
>>I have spent the last 6 months working on a commercial-quality plugin for
>>working with SQL RDBMS systems within the Eclipse IDE.
>>
>>The feature provides the following capabilities which correspond closely
>>to the requirements described by the DTP proposal:
>>
>>* Definition of an extension point for JDBC drivers
>>
>> Each JDBC driver is published as a plugin. The plugin describes
>> the database type it targets, the URL format, the driver's class name,
>> vendor information, version information, etc.
>>
>> The plugin currently includes JDBC driver plugins for
>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>> and Connector-J driver for MySQL.
>>
>>* Definition of an extension point for database providers
>>
>> The plugin's provider concept is equivalent to the connection
>> profile concept described in the DTP proposal. A provider is
>> responsible for providing the contributing the following:
>>
>> 1) Meta-data provision for tables, functions, user-defined
>> data-types, schemata, procedures, columns and views. Each
>> provider can publish additional provider-specific meta-data.
>>
>> 2) Representation of database objects (tables, functions etc) as a
>> model implementing interfaces defined by the core plugin. Services
>> provided by this model include navigation through the database
>> schema (enumeration of tables, etc.), finding of objects for
>> content assist/auto completion, and the implementation of base
>> services such as rename and drop.
>>
>> 3) Scripting of common statements such as SELECT (tables, views,
>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>> DROP (all objects) and EXEC (stored procedures, functions).
>>
>> 4) An optional provider-specific grammar class which describes
>> the SQL grammar used by the provider. This grammar is then used
>> by the UI plugin when rendering text with syntax highlighting
>> for the user. It is also used when reformatting SQL (keyword
>> identification for keyword case modification). Finally, the
>> provider can customize dialect-specific operations such as keyword
>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>> and can be overridden/extended as required on a per-provider basis.
>>
>> 5) Contribute a UI for the configuration of database connections by
>> the user.
>>
>> 6) Optional contribution of a class to parse SQL batches into
>> statements for execution by the JDBC driver. This allows for
>> provider-specific batch processing.
>>
>> 7) Create a registration object which represents a persistent
>> database connection. This registration object is then used
>> to obtain a database object (entry-point into the database's
>> model) and a connection factory for the execution of ad-hoc
>> queries.
>>
>> 8) A factory which can rehydrate a registration from
>> connection configuration information.
>>
>> Note that providers are decoupled from JDBC drivers. This allows for
>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>> Server could be targetted by both jTDS and Microsoft's driver) and
>> also for a single driver to target multiple providers (e.g. jTDS
>> targetting both Microsoft SQL Server and Sybase).
>>
>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>> Experimental support exists for MySQL v4.x.
>>
>>* A core plugin which defines:
>>
>> 1) The above extension points
>>
>> 2) A set of interfaces for the model.
>>
>> 3) Core classes such as a provider manager and JDBC driver manager.
>>
>> 4) A framework for the implementation of providers including
>> a set of classes which implement a provider through the
>> standard INFORMATION_SCHEMA views.
>>
>>* A UI plugin contributes the following:
>>
>> 1) A database perspective.
>>
>> 2) A schema explorer view for browsing database meta-data.
>>
>> 3) An SQL editor. This editor is used to edit SQL files and
>> also ad-hoc queries. The queries can be executed against the
>> selected registration. Several editors may be opened at once.
>> The editor fully integrates with the Eclipse's resource model,
>> correctly responding to events from the underlying file objects.
>> The SQL editor also implements integration with the standard
>> find/replace dialog and content assist.
>>
>> 4) A placeholder view. The user may use Ant-property-like
>> placeholders in the SQL editor. These properties automatically
>> appear in the placeholder view where the user may assign values
>> to them. The placeholders are then substituted with the values
>> prior to query execution.
>>
>> 5) A DDL definition view. This view displays a CREATE statement for
>> the currently selected object in the schema explorer.
>>
>> 6) A script history view. This view displays a history of statements
>> executed interactively by the user. The script history is full-text
>> indexed (using Lucene) and can be searched by the user in
>> real-time.
>>
>> The UI plugin makes use of Eclipse's adaptor facility to associate
>> UI logic in an architecturally-clean and non-invasive fashion with
>> model objects implemented by providers. A set of adapter factories
>> is implemented as the basis for the hierarchy display in the
>> schema explorer view. This allows providers to implement their
>> own adaptor factories and tailor the schema explorer hierarchy to
>> their own needs.
>>
>> The UI plugin also defines a set of action delegate object
>> contributions for types defined by the core model, including the
>> ability to drop, rename and script objects from the content menu.
>>
>> Providers may also provide additional contributions (for example, the
>> PostgreSQL provider contributes an action delegate for a database
>> vacuuming function).
>>
>> The UI plugin takes advantage of Eclipse's job framework. For example,
>> the SQL editor implements a background SQL parser to extract
>> placeholders from the editor's document as the user types. Also, the
>> history manager updates the history's full-text index in the
>> background as a job.
>>
>>* The plugin was developed on both the MacOS and Windows, and has been
>> tested to run under Linux/GTK.
>>
>>* The plugin was developed for Eclipse 3.0 and has been tested with
>> 3.1 M4.
>>
>>We believe that our set of plugins would provide a solid basis for the DTP
>>project and that many of the requirements stated in the DTP proposal are
>>met by the plugin. Please let me know whether the Eclipse Foundation would
>>be interested in reviewing the code for possible inclusion in the DTP
>>project's code-base.
>>
>>I would also be interested in actively participating as a contributor to
>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>Server and Eclipse plugin development experience. Please let me know how I
>>should go about persuing becoming a contributor to the project.
>>
>>Simon Wilson
>>Objectnation GmbH
>>Zurich, Switzerland
>
>
>
|
|
|
| Re: Offer of Code Donation for DTP [message #563992 is a reply to message #73] |
Fri, 11 March 2005 16:42 |
John Graham
Messages: 183
Registered: July 2009 |
Senior Member |
|
|
Simon,
We are starting to look at existing code bases in the areas you mention,
with an eye toward eventual consolidation of best-of-breed,
community-supported components into DTP. As the discussion develops, regular
postings to this newsgroup and updates to the proposal will keep the
community informed. Since you have offered a code base, would like to talk
with us in more detail about its possible adoption into DTP?
Thanks,
--John Graham
john.graham@sybase.com
Eclipse DTP
"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
news:cviesd$amb$1@www.eclipse.org...
> John,
>
> I won't be making it to EclipseCon unfortunately, but look forward to
> discussing the matter with you in more detail in the near future.
>
> With best regards,
>
> Simon Wilson
> Objectnation GmbH
> Zurich, Switzerland
>
> John Graham wrote:
>> Simon,
>>
>> Thank you very much for the information and contribution offer. We are
>> definitely interested in talking with you further about these
>> possibilities. At this stage, we are collecting notices of interest, and
>> in the coming weeks we plan to discuss matters in more detail with
>> interested parties. (If you happen to be at EclipseCon next week, it
>> would a chance to meet in person as well.) We will definitely be back in
>> contact with you in the near future.
>>
>> Regards,
>> John Graham
>> john.graham@sybase.com
>> Eclipse DTP
>>
>> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
>> news:cvhqr8$q7j$1@www.eclipse.org...
>>
>>>I have spent the last 6 months working on a commercial-quality plugin for
>>>working with SQL RDBMS systems within the Eclipse IDE.
>>>
>>>The feature provides the following capabilities which correspond closely
>>>to the requirements described by the DTP proposal:
>>>
>>>* Definition of an extension point for JDBC drivers
>>>
>>> Each JDBC driver is published as a plugin. The plugin describes
>>> the database type it targets, the URL format, the driver's class name,
>>> vendor information, version information, etc.
>>>
>>> The plugin currently includes JDBC driver plugins for
>>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>>> and Connector-J driver for MySQL.
>>>
>>>* Definition of an extension point for database providers
>>>
>>> The plugin's provider concept is equivalent to the connection
>>> profile concept described in the DTP proposal. A provider is
>>> responsible for providing the contributing the following:
>>>
>>> 1) Meta-data provision for tables, functions, user-defined
>>> data-types, schemata, procedures, columns and views. Each
>>> provider can publish additional provider-specific meta-data.
>>>
>>> 2) Representation of database objects (tables, functions etc) as a
>>> model implementing interfaces defined by the core plugin. Services
>>> provided by this model include navigation through the database
>>> schema (enumeration of tables, etc.), finding of objects for
>>> content assist/auto completion, and the implementation of base
>>> services such as rename and drop.
>>>
>>> 3) Scripting of common statements such as SELECT (tables, views,
>>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>>> DROP (all objects) and EXEC (stored procedures, functions).
>>>
>>> 4) An optional provider-specific grammar class which describes
>>> the SQL grammar used by the provider. This grammar is then used
>>> by the UI plugin when rendering text with syntax highlighting
>>> for the user. It is also used when reformatting SQL (keyword
>>> identification for keyword case modification). Finally, the
>>> provider can customize dialect-specific operations such as keyword
>>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>>> and can be overridden/extended as required on a per-provider basis.
>>>
>>> 5) Contribute a UI for the configuration of database connections by
>>> the user.
>>>
>>> 6) Optional contribution of a class to parse SQL batches into
>>> statements for execution by the JDBC driver. This allows for
>>> provider-specific batch processing.
>>>
>>> 7) Create a registration object which represents a persistent
>>> database connection. This registration object is then used
>>> to obtain a database object (entry-point into the database's
>>> model) and a connection factory for the execution of ad-hoc
>>> queries.
>>>
>>> 8) A factory which can rehydrate a registration from
>>> connection configuration information.
>>>
>>> Note that providers are decoupled from JDBC drivers. This allows for
>>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>>> Server could be targetted by both jTDS and Microsoft's driver) and
>>> also for a single driver to target multiple providers (e.g. jTDS
>>> targetting both Microsoft SQL Server and Sybase).
>>>
>>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>>> Experimental support exists for MySQL v4.x.
>>>
>>>* A core plugin which defines:
>>>
>>> 1) The above extension points
>>>
>>> 2) A set of interfaces for the model.
>>>
>>> 3) Core classes such as a provider manager and JDBC driver manager.
>>>
>>> 4) A framework for the implementation of providers including
>>> a set of classes which implement a provider through the
>>> standard INFORMATION_SCHEMA views.
>>>
>>>* A UI plugin contributes the following:
>>>
>>> 1) A database perspective.
>>>
>>> 2) A schema explorer view for browsing database meta-data.
>>>
>>> 3) An SQL editor. This editor is used to edit SQL files and
>>> also ad-hoc queries. The queries can be executed against the
>>> selected registration. Several editors may be opened at once.
>>> The editor fully integrates with the Eclipse's resource model,
>>> correctly responding to events from the underlying file objects.
>>> The SQL editor also implements integration with the standard
>>> find/replace dialog and content assist.
>>>
>>> 4) A placeholder view. The user may use Ant-property-like
>>> placeholders in the SQL editor. These properties automatically
>>> appear in the placeholder view where the user may assign values
>>> to them. The placeholders are then substituted with the values
>>> prior to query execution.
>>>
>>> 5) A DDL definition view. This view displays a CREATE statement for
>>> the currently selected object in the schema explorer.
>>>
>>> 6) A script history view. This view displays a history of statements
>>> executed interactively by the user. The script history is full-text
>>> indexed (using Lucene) and can be searched by the user in
>>> real-time.
>>>
>>> The UI plugin makes use of Eclipse's adaptor facility to associate
>>> UI logic in an architecturally-clean and non-invasive fashion with
>>> model objects implemented by providers. A set of adapter factories
>>> is implemented as the basis for the hierarchy display in the
>>> schema explorer view. This allows providers to implement their
>>> own adaptor factories and tailor the schema explorer hierarchy to
>>> their own needs.
>>>
>>> The UI plugin also defines a set of action delegate object
>>> contributions for types defined by the core model, including the
>>> ability to drop, rename and script objects from the content menu.
>>>
>>> Providers may also provide additional contributions (for example, the
>>> PostgreSQL provider contributes an action delegate for a database
>>> vacuuming function).
>>>
>>> The UI plugin takes advantage of Eclipse's job framework. For example,
>>> the SQL editor implements a background SQL parser to extract
>>> placeholders from the editor's document as the user types. Also, the
>>> history manager updates the history's full-text index in the
>>> background as a job.
>>>
>>>* The plugin was developed on both the MacOS and Windows, and has been
>>> tested to run under Linux/GTK.
>>>
>>>* The plugin was developed for Eclipse 3.0 and has been tested with
>>> 3.1 M4.
>>>
>>>We believe that our set of plugins would provide a solid basis for the
>>>DTP project and that many of the requirements stated in the DTP proposal
>>>are met by the plugin. Please let me know whether the Eclipse Foundation
>>>would be interested in reviewing the code for possible inclusion in the
>>>DTP project's code-base.
>>>
>>>I would also be interested in actively participating as a contributor to
>>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>>Server and Eclipse plugin development experience. Please let me know how
>>>I should go about persuing becoming a contributor to the project.
>>>
>>>Simon Wilson
>>>Objectnation GmbH
>>>Zurich, Switzerland
>>
>>
|
|
|
| Re: Offer of Code Donation for DTP [message #564257 is a reply to message #94] |
Tue, 15 March 2005 19:58 |
Simon Wilson
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Hi John,
I hope you had a great time at EclipseCon...
> would like to talk
> with us in more detail about its possible adoption into DTP?
Absolutely. Having not worked on an open-source project before, I need
some guidance from you as how to proceed...
I would be more than willing to write a short document to help you find
your way around the plugin. I would suggest a description of:
- Some information on me and my background
- Our motivations for developing our plugin in the first place
- The set of requirements it originally had to fulfill
- The conceptual basis of the current implementation
- An overview of the UI, with screenshots, descriptions etc.
- A design brief for plugin modularity, important classes, etc.
Would this be of use to you? oO would you rather just get your hands
dirty and dig into the code?
Please let me know which information/code etc you would need and which
channels I should use to get this information to you.
Cheers,
Simon
John Graham wrote:
> Simon,
>
> We are starting to look at existing code bases in the areas you mention,
> with an eye toward eventual consolidation of best-of-breed,
> community-supported components into DTP. As the discussion develops, regular
> postings to this newsgroup and updates to the proposal will keep the
> community informed. Since you have offered a code base, would like to talk
> with us in more detail about its possible adoption into DTP?
>
> Thanks,
> --John Graham
> john.graham@sybase.com
> Eclipse DTP
>
> "Simon Wilson" <simon.wilson@objectnation.com> wrote in message
> news:cviesd$amb$1@www.eclipse.org...
>
>>John,
>>
>>I won't be making it to EclipseCon unfortunately, but look forward to
>>discussing the matter with you in more detail in the near future.
>>
>>With best regards,
>>
>>Simon Wilson
>>Objectnation GmbH
>>Zurich, Switzerland
>>
>>John Graham wrote:
>>
>>>Simon,
>>>
>>>Thank you very much for the information and contribution offer. We are
>>>definitely interested in talking with you further about these
>>>possibilities. At this stage, we are collecting notices of interest, and
>>>in the coming weeks we plan to discuss matters in more detail with
>>>interested parties. (If you happen to be at EclipseCon next week, it
>>>would a chance to meet in person as well.) We will definitely be back in
>>>contact with you in the near future.
>>>
>>>Regards,
>>>John Graham
>>>john.graham@sybase.com
>>>Eclipse DTP
>>>
>>>"Simon Wilson" <simon.wilson@objectnation.com> wrote in message
>>>news:cvhqr8$q7j$1@www.eclipse.org...
>>>
>>>
>>>>I have spent the last 6 months working on a commercial-quality plugin for
>>>>working with SQL RDBMS systems within the Eclipse IDE.
>>>>
>>>>The feature provides the following capabilities which correspond closely
>>>>to the requirements described by the DTP proposal:
>>>>
>>>>* Definition of an extension point for JDBC drivers
>>>>
>>>> Each JDBC driver is published as a plugin. The plugin describes
>>>> the database type it targets, the URL format, the driver's class name,
>>>> vendor information, version information, etc.
>>>>
>>>> The plugin currently includes JDBC driver plugins for
>>>> the PostgreSQL JDBC driver, jTDS driver for Sybase and MS SQL Server
>>>> and Connector-J driver for MySQL.
>>>>
>>>>* Definition of an extension point for database providers
>>>>
>>>> The plugin's provider concept is equivalent to the connection
>>>> profile concept described in the DTP proposal. A provider is
>>>> responsible for providing the contributing the following:
>>>>
>>>> 1) Meta-data provision for tables, functions, user-defined
>>>> data-types, schemata, procedures, columns and views. Each
>>>> provider can publish additional provider-specific meta-data.
>>>>
>>>> 2) Representation of database objects (tables, functions etc) as a
>>>> model implementing interfaces defined by the core plugin. Services
>>>> provided by this model include navigation through the database
>>>> schema (enumeration of tables, etc.), finding of objects for
>>>> content assist/auto completion, and the implementation of base
>>>> services such as rename and drop.
>>>>
>>>> 3) Scripting of common statements such as SELECT (tables, views,
>>>> sequences), INSERT, UPDATE and DELETE (tables), CREATE,
>>>> DROP (all objects) and EXEC (stored procedures, functions).
>>>>
>>>> 4) An optional provider-specific grammar class which describes
>>>> the SQL grammar used by the provider. This grammar is then used
>>>> by the UI plugin when rendering text with syntax highlighting
>>>> for the user. It is also used when reformatting SQL (keyword
>>>> identification for keyword case modification). Finally, the
>>>> provider can customize dialect-specific operations such as keyword
>>>> escaping. A base grammar encapsulates the SQL 99 standard dialect
>>>> and can be overridden/extended as required on a per-provider basis.
>>>>
>>>> 5) Contribute a UI for the configuration of database connections by
>>>> the user.
>>>>
>>>> 6) Optional contribution of a class to parse SQL batches into
>>>> statements for execution by the JDBC driver. This allows for
>>>> provider-specific batch processing.
>>>>
>>>> 7) Create a registration object which represents a persistent
>>>> database connection. This registration object is then used
>>>> to obtain a database object (entry-point into the database's
>>>> model) and a connection factory for the execution of ad-hoc
>>>> queries.
>>>>
>>>> 8) A factory which can rehydrate a registration from
>>>> connection configuration information.
>>>>
>>>> Note that providers are decoupled from JDBC drivers. This allows for
>>>> a provider to be targeted by multiple drivers (e.g. Microsoft SQL
>>>> Server could be targetted by both jTDS and Microsoft's driver) and
>>>> also for a single driver to target multiple providers (e.g. jTDS
>>>> targetting both Microsoft SQL Server and Sybase).
>>>>
>>>> Full-featured providers exist for PostgreSQL and Microsoft SQL Server.
>>>> Experimental support exists for MySQL v4.x.
>>>>
>>>>* A core plugin which defines:
>>>>
>>>> 1) The above extension points
>>>>
>>>> 2) A set of interfaces for the model.
>>>>
>>>> 3) Core classes such as a provider manager and JDBC driver manager.
>>>>
>>>> 4) A framework for the implementation of providers including
>>>> a set of classes which implement a provider through the
>>>> standard INFORMATION_SCHEMA views.
>>>>
>>>>* A UI plugin contributes the following:
>>>>
>>>> 1) A database perspective.
>>>>
>>>> 2) A schema explorer view for browsing database meta-data.
>>>>
>>>> 3) An SQL editor. This editor is used to edit SQL files and
>>>> also ad-hoc queries. The queries can be executed against the
>>>> selected registration. Several editors may be opened at once.
>>>> The editor fully integrates with the Eclipse's resource model,
>>>> correctly responding to events from the underlying file objects.
>>>> The SQL editor also implements integration with the standard
>>>> find/replace dialog and content assist.
>>>>
>>>> 4) A placeholder view. The user may use Ant-property-like
>>>> placeholders in the SQL editor. These properties automatically
>>>> appear in the placeholder view where the user may assign values
>>>> to them. The placeholders are then substituted with the values
>>>> prior to query execution.
>>>>
>>>> 5) A DDL definition view. This view displays a CREATE statement for
>>>> the currently selected object in the schema explorer.
>>>>
>>>> 6) A script history view. This view displays a history of statements
>>>> executed interactively by the user. The script history is full-text
>>>> indexed (using Lucene) and can be searched by the user in
>>>> real-time.
>>>>
>>>> The UI plugin makes use of Eclipse's adaptor facility to associate
>>>> UI logic in an architecturally-clean and non-invasive fashion with
>>>> model objects implemented by providers. A set of adapter factories
>>>> is implemented as the basis for the hierarchy display in the
>>>> schema explorer view. This allows providers to implement their
>>>> own adaptor factories and tailor the schema explorer hierarchy to
>>>> their own needs.
>>>>
>>>> The UI plugin also defines a set of action delegate object
>>>> contributions for types defined by the core model, including the
>>>> ability to drop, rename and script objects from the content menu.
>>>>
>>>> Providers may also provide additional contributions (for example, the
>>>> PostgreSQL provider contributes an action delegate for a database
>>>> vacuuming function).
>>>>
>>>> The UI plugin takes advantage of Eclipse's job framework. For example,
>>>> the SQL editor implements a background SQL parser to extract
>>>> placeholders from the editor's document as the user types. Also, the
>>>> history manager updates the history's full-text index in the
>>>> background as a job.
>>>>
>>>>* The plugin was developed on both the MacOS and Windows, and has been
>>>> tested to run under Linux/GTK.
>>>>
>>>>* The plugin was developed for Eclipse 3.0 and has been tested with
>>>> 3.1 M4.
>>>>
>>>>We believe that our set of plugins would provide a solid basis for the
>>>>DTP project and that many of the requirements stated in the DTP proposal
>>>>are met by the plugin. Please let me know whether the Eclipse Foundation
>>>>would be interested in reviewing the code for possible inclusion in the
>>>>DTP project's code-base.
>>>>
>>>>I would also be interested in actively participating as a contributor to
>>>>the DTP project, with a particular emphasis on PostgreSQL, Microsoft SQL
>>>>Server and Eclipse plugin development experience. Please let me know how
>>>>I should go about persuing becoming a contributor to the project.
>>>>
>>>>Simon Wilson
>>>>Objectnation GmbH
>>>>Zurich, Switzerland
>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Fri Aug 16 17:40:54 GMT 2024
Powered by FUDForum. Page generated in 0.04031 seconds |
] 
Search
Help
Register
Login
Home
