Home » Eclipse Projects » Equinox » Equinox Goals - Abstracting Libraries for External Use
| Equinox Goals - Abstracting Libraries for External Use [message #4699] |
Fri, 28 February 2003 05:59  |
Eclipse User |
|
|
|
Originally posted by: joetoth.comcast.net
Equinox caught my eye because recently I needed a source code generation
library and I remembered eclipse has a great library for AST, compiling,
etc. So, I decided to rip out one of the libs that included this
functionality. This lib wanted another, then another.
Then when I wanted to create a CompilationUnit, it complained about
wanting IPlugin something. So unfortunately I couldn't use this.
(I was able to use IDOMCompilationUnit, but this had very limited
functionality - Next I need to support minor scripting, eclipse libs for
syntax highlighting autocompletion, etc would be great!)
My point being, eclipse, an open source project has many great apis. If
equinox can expand the scope of these APIs beyond the IDE environment,
these APIs will be used in alot more applications and inherintly via the
open source model they'll become more versatile, stable and faster.
It would be good if each plugin had 2 level.
1 being core functionality
2 using that functionality to interoperate between each plugin
Or maybe something like apache's commons project where they create
libraries separate from the projects that use them.
To play with eclipse, I wrote a sql plugin
http://easysql.sourceforge.net/ a while back.
I remember SWT was written so that it can be used how I'm describing.
Will a goal of Equinox be abstracting out libraries for external use?
Example being the source code generation and compilation.
Thanks,
Joseph Toth
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #4768 is a reply to message #4699] |
Fri, 28 February 2003 15:49  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Joseph,
This is not a stated goal of Equinox. Can you outline what you think could
be done in Equinox to solve the problem?
Jeff
"Joseph Toth" <joetoth@comcast.net> wrote in message
news:b3ms3q$mjo$1@rogue.oti.com...
> Equinox caught my eye because recently I needed a source code generation
> library and I remembered eclipse has a great library for AST, compiling,
> etc. So, I decided to rip out one of the libs that included this
> functionality. This lib wanted another, then another.
> Then when I wanted to create a CompilationUnit, it complained about
> wanting IPlugin something. So unfortunately I couldn't use this.
> (I was able to use IDOMCompilationUnit, but this had very limited
> functionality - Next I need to support minor scripting, eclipse libs for
> syntax highlighting autocompletion, etc would be great!)
>
> My point being, eclipse, an open source project has many great apis. If
> equinox can expand the scope of these APIs beyond the IDE environment,
> these APIs will be used in alot more applications and inherintly via the
> open source model they'll become more versatile, stable and faster.
>
> It would be good if each plugin had 2 level.
> 1 being core functionality
> 2 using that functionality to interoperate between each plugin
>
> Or maybe something like apache's commons project where they create
> libraries separate from the projects that use them.
>
> To play with eclipse, I wrote a sql plugin
> http://easysql.sourceforge.net/ a while back.
> I remember SWT was written so that it can be used how I'm describing.
>
> Will a goal of Equinox be abstracting out libraries for external use?
> Example being the source code generation and compilation.
>
> Thanks,
> Joseph Toth
>
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #4974 is a reply to message #4768] |
Fri, 28 February 2003 20:13 |
| Eclipse User |
|
|
|
Originally posted by: joetoth.comcast.net
Jeff McAffer wrote:
> Joseph,
>
> This is not a stated goal of Equinox. Can you outline what you think could
> be done in Equinox to solve the problem?
>
> Jeff
>
> "Joseph Toth" <joetoth@comcast.net> wrote in message
> news:b3ms3q$mjo$1@rogue.oti.com...
>
>>Equinox caught my eye because recently I needed a source code generation
>>library and I remembered eclipse has a great library for AST, compiling,
>>etc. So, I decided to rip out one of the libs that included this
>>functionality. This lib wanted another, then another.
>>Then when I wanted to create a CompilationUnit, it complained about
>>wanting IPlugin something. So unfortunately I couldn't use this.
>>(I was able to use IDOMCompilationUnit, but this had very limited
>>functionality - Next I need to support minor scripting, eclipse libs for
>>syntax highlighting autocompletion, etc would be great!)
>>
>>My point being, eclipse, an open source project has many great apis. If
>>equinox can expand the scope of these APIs beyond the IDE environment,
>>these APIs will be used in alot more applications and inherintly via the
>>open source model they'll become more versatile, stable and faster.
>>
>>It would be good if each plugin had 2 level.
>>1 being core functionality
>>2 using that functionality to interoperate between each plugin
>>
>>Or maybe something like apache's commons project where they create
>>libraries separate from the projects that use them.
>>
>>To play with eclipse, I wrote a sql plugin
>>http://easysql.sourceforge.net/ a while back.
>>I remember SWT was written so that it can be used how I'm describing.
>>
>>Will a goal of Equinox be abstracting out libraries for external use?
>>Example being the source code generation and compilation.
>>
>>Thanks,
>>Joseph Toth
>>
>
>
>
Off the top of my head, here are 2 things that can be done in Equinox:
1. Plugin doesn't have to depend on any static variables,
eg. Plugin doesn't take Workbench as a parameter but, it would take only
the components required to interface with.
2. Plugin would need documentation on how to use outside of eclipse.
a. What interfaces need to be implemented for the other libraries
you are using. - eg. How CompilationUnit will interact with Swing.
Taking an approach like this would give the most flexibility to "broaden
the range of Eclipse platform runtime configurations", plus incorporate
my goal of using eclipse libraries externally. But of course, this
means more intelligent abstracting and more coding.
I'm just throwing this out there since this is an early stage in the
Equinox project. Even though external libraries are out of the scope,
the work that will be done here seems like external libraries can become
an inherent benefit of Equinox, if the approach is correct.
Thanks,
Joseph Toth
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #5315 is a reply to message #4974] |
Sun, 02 March 2003 20:53 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
I was chatting about this with some folks around here and other than best
practices or raising awareness, there does not seem to be much one could do
to the architecture/implementation of Eclipse platform to resolve this
issue.
Basically you are trying to use a library in a scenario for which it was not
designed. Separating out the parts of Eclipse that don't really need
Eclipse is a good idea but it is work and the plugin authors need to see a
reason to do it. Some will, some won't.
Jeff
p.s., the part about broadening the scope of Eclipse means broadening the
places where the *eclipse platform* is run/used. Your scenario seeks to use
random parts of Eclipse and explicitly not run the platform. That is
somewhat at odds with Equinox and Eclipse in general. Note also that SWT is
a special case. It has (and always has had) a life outside of Eclipse. The
Eclipse IU is based on SWT. SWT has never been based on Eclipse.
"Joseph Toth" <joetoth@comcast.net> wrote in message
news:3E5FC2FA.8000504@comcast.net...
> Off the top of my head, here are 2 things that can be done in Equinox:
>
> 1. Plugin doesn't have to depend on any static variables,
> eg. Plugin doesn't take Workbench as a parameter but, it would take only
> the components required to interface with.
>
> 2. Plugin would need documentation on how to use outside of eclipse.
> a. What interfaces need to be implemented for the other libraries
> you are using. - eg. How CompilationUnit will interact with Swing.
>
> Taking an approach like this would give the most flexibility to "broaden
> the range of Eclipse platform runtime configurations", plus incorporate
> my goal of using eclipse libraries externally. But of course, this
> means more intelligent abstracting and more coding.
>
> I'm just throwing this out there since this is an early stage in the
> Equinox project. Even though external libraries are out of the scope,
> the work that will be done here seems like external libraries can become
> an inherent benefit of Equinox, if the approach is correct.
>
>
> Thanks,
> Joseph Toth
>
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #6045 is a reply to message #5315] |
Mon, 03 March 2003 16:12 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
True that the desire does not match what Eclipse was designed for...
but it demonstrates a deceptively strong limitation of the current Eclipse
architecture and design. While Eclipse seems to promote modularity
through plug-ins, I would argue that its modularity is very much limited
in terms of alternate grouping of functionality or alternate
implementations.
I would argue that this is due to three original design mistakes:
1) Everything is a plug-in, even libraries which know nothing about
extensions
2) Dependencies are on plug-ins, not APIs
3) APIs are packaged with their implementation
Point (1) results in Eclipse being a bit monolithic. The platform considers
everything
a plug-in, even what is really just a library. So this does not promote the
idea
that some library could be developed, deployed, and used as Java library
independently of Eclipse, at least workspace and worbench.
Point (2) and (3) make things worse by making plug-ins dependent on
plug-ins,
and combining APIs and implementation. This does not help controlling
dependencies and the overall feeling that the entire download from
eclipse.org is necessary to run. Many plug-ins do a great job at defining a
clean API, but the implementation drags in dependencies... so because
I require the entire plug-in, I am requiring the transitive closure...
For instance, someone may want to promote its on Java compiler, but
reuse all the interfaces of Eclipse JDT compiler. Or someone may want
to propose an alternate workbench, maybe for smaller devices, leveraging
not only different layout options but also allowing different widget
toolkits...
but this is impossible although the workbench UI does a great job at
defining interfaces for its extension points (such as interfaces in
org.eclipse.ui).
So you are technically right about best practices... and the limitations of
a
platform to enforce modularity... but the current approach for dependencies
and packaging, as well as the monolithic platform for libraries and
plug-ins,
is just neither promoting nor helping modular design as Joseph is talking
about.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3trak$ql3$1@rogue.oti.com...
> I was chatting about this with some folks around here and other than best
> practices or raising awareness, there does not seem to be much one could
do
> to the architecture/implementation of Eclipse platform to resolve this
> issue.
>
> Basically you are trying to use a library in a scenario for which it was
not
> designed. Separating out the parts of Eclipse that don't really need
> Eclipse is a good idea but it is work and the plugin authors need to see a
> reason to do it. Some will, some won't.
>
> Jeff
>
> p.s., the part about broadening the scope of Eclipse means broadening the
> places where the *eclipse platform* is run/used. Your scenario seeks to
use
> random parts of Eclipse and explicitly not run the platform. That is
> somewhat at odds with Equinox and Eclipse in general. Note also that SWT
is
> a special case. It has (and always has had) a life outside of Eclipse. The
> Eclipse IU is based on SWT. SWT has never been based on Eclipse.
>
>
> "Joseph Toth" <joetoth@comcast.net> wrote in message
> news:3E5FC2FA.8000504@comcast.net...
> > Off the top of my head, here are 2 things that can be done in Equinox:
> >
> > 1. Plugin doesn't have to depend on any static variables,
> > eg. Plugin doesn't take Workbench as a parameter but, it would take only
> > the components required to interface with.
> >
> > 2. Plugin would need documentation on how to use outside of eclipse.
> > a. What interfaces need to be implemented for the other libraries
> > you are using. - eg. How CompilationUnit will interact with Swing.
> >
> > Taking an approach like this would give the most flexibility to "broaden
> > the range of Eclipse platform runtime configurations", plus incorporate
> > my goal of using eclipse libraries externally. But of course, this
> > means more intelligent abstracting and more coding.
> >
> > I'm just throwing this out there since this is an early stage in the
> > Equinox project. Even though external libraries are out of the scope,
> > the work that will be done here seems like external libraries can become
> > an inherent benefit of Equinox, if the approach is correct.
> >
> >
> > Thanks,
> > Joseph Toth
> >
>
>
|
|
| |
| Re: Equinox Goals - Abstracting Libraries for External Use [message #13370 is a reply to message #6045] |
Sun, 16 March 2003 01:26 |
| Eclipse User |
|
|
|
Originally posted by: cagatayk.stop.acm.org
....
Olivier Gruber wrote:
> True that the desire does not match what Eclipse was designed for...
> but it demonstrates a deceptively strong limitation of the current Eclipse
> architecture and design. While Eclipse seems to promote modularity
> through plug-ins, I would argue that its modularity is very much limited
> in terms of alternate grouping of functionality or alternate
> implementations.
> I would argue that this is due to three original design mistakes:
>
> 1) Everything is a plug-in, even libraries which know nothing about
> extensions
> 2) Dependencies are on plug-ins, not APIs
> 3) APIs are packaged with their implementation
>
> Point (1) results in Eclipse being a bit monolithic. The platform considers
> everything
> a plug-in, even what is really just a library. So this does not promote the
> idea
> that some library could be developed, deployed, and used as Java library
> independently of Eclipse, at least workspace and worbench.
This is not so much an issue for the platform itself as it is an issue
for JDT. Java Core itself is developed with the basic assumption that
the platform and core resources are available for its use. Whether it
comes as a plugin or a single JAR file (or whatever basic unit of
packaging that ends up being adopted as a result of Equinox work) does
not change the fact that at runtime it requires a builder infrastructure
to plug into and java projects existing in a workspace. In this respect,
I agree with Jeff that it is completely up to the plugin authors to
decide what their prerequisites are.
--
CK.
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #13389 is a reply to message #5315] |
Sun, 16 March 2003 02:10 |
| Eclipse User |
|
|
|
Originally posted by: cagatayk.stop.acm.org
Jeff McAffer wrote:
> p.s., the part about broadening the scope of Eclipse means broadening the
> places where the *eclipse platform* is run/used.
>
One of things I'm particularly interested in seeing as a result of
Equinox work is to be able to use the core platform to develop J2EE
applications that can be deployed on compliant application servers.
Eclipse provides a very attractive way of developing software components
that integrate with each other in well defined ways. In contrast, J2EE
standards by themselves provide a set of technologies but not a fully
functional framework to develop J2EE applications. It would be so great
if we could use the core platform to develop J2EE applications that can
be extended using an extension mechanism and do this dynamically, by
deploying a standard EAR for instance. Ideally, you would deploy a new
feature on the server and the application would pick up the additional
functionality automatically without a need for restart. When you
undeploy the feature, the application would again adjust by removing the
extensions the feature provided.
Obviously, I don't expect the Eclipse platform itself to provide any
kind of J2EE integration but making this possible would definitely
broaden the places where the platform is run/used, as you state. A
combination of a flexible service framework, dynamic plugins (and maybe
an interceptor architecture?) would go a long way toward this.
--
CK.
|
|
|
| Re: Equinox Goals - Abstracting Libraries for External Use [message #15298 is a reply to message #4974] |
Mon, 24 March 2003 13:27 |
 Calum MacLean
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Just to say that I would echo what Joseph says below.
I also recently thought it would be useful to use some of the JDT
functionality, e.g. code completion, in another context outside of Eclipse.
In doing it, I too found that it pulled in the Resources plugin, I had to
have the Eclipse platform running etc.
In order to try to make use of it, I had to muck about with how I loaded the
plugins (can't remember exactly how now).
The basic problem I encountered was that you needed the Eclipse Core
platform to be running in order to load any plugins. Then in order to use a
loaded plugin you had to define your own code in a plugin too. So, in order
to use functionality from a plugin, you had to operate within the bounds of
the Eclipse application. This made it pretty difficult to use any
functionality from your own (non-Eclipse) program.
My basic thing is, that there seems to be loads of useful functionality
defined within Eclipse, but you can't actually use it anywhere other than
within Eclipse itself - which seems a bit of a shame...
Of course, I do recognise that getting to this point would be rather
difficult, involving a lot of refactoring of plugins, and in particular the
interface between them.
Calum
"Joseph Toth" <joetoth@comcast.net> wrote in message
news:3E5FC2FA.8000504@comcast.net...
> Jeff McAffer wrote:
> > Joseph,
> >
> > This is not a stated goal of Equinox. Can you outline what you think
could
> > be done in Equinox to solve the problem?
> >
> > Jeff
> >
> > "Joseph Toth" <joetoth@comcast.net> wrote in message
> > news:b3ms3q$mjo$1@rogue.oti.com...
> >
> >>Equinox caught my eye because recently I needed a source code generation
> >>library and I remembered eclipse has a great library for AST, compiling,
> >>etc. So, I decided to rip out one of the libs that included this
> >>functionality. This lib wanted another, then another.
> >>Then when I wanted to create a CompilationUnit, it complained about
> >>wanting IPlugin something. So unfortunately I couldn't use this.
> >>(I was able to use IDOMCompilationUnit, but this had very limited
> >>functionality - Next I need to support minor scripting, eclipse libs for
> >>syntax highlighting autocompletion, etc would be great!)
> >>
> >>My point being, eclipse, an open source project has many great apis. If
> >>equinox can expand the scope of these APIs beyond the IDE environment,
> >>these APIs will be used in alot more applications and inherintly via the
> >>open source model they'll become more versatile, stable and faster.
> >>
> >>It would be good if each plugin had 2 level.
> >>1 being core functionality
> >>2 using that functionality to interoperate between each plugin
> >>
> >>Or maybe something like apache's commons project where they create
> >>libraries separate from the projects that use them.
> >>
> >>To play with eclipse, I wrote a sql plugin
> >>http://easysql.sourceforge.net/ a while back.
> >>I remember SWT was written so that it can be used how I'm describing.
> >>
> >>Will a goal of Equinox be abstracting out libraries for external use?
> >>Example being the source code generation and compilation.
> >>
> >>Thanks,
> >>Joseph Toth
> >>
> >
> >
> >
>
> Off the top of my head, here are 2 things that can be done in Equinox:
>
> 1. Plugin doesn't have to depend on any static variables,
> eg. Plugin doesn't take Workbench as a parameter but, it would take only
> the components required to interface with.
>
> 2. Plugin would need documentation on how to use outside of eclipse.
> a. What interfaces need to be implemented for the other libraries
> you are using. - eg. How CompilationUnit will interact with Swing.
>
> Taking an approach like this would give the most flexibility to "broaden
> the range of Eclipse platform runtime configurations", plus incorporate
> my goal of using eclipse libraries externally. But of course, this
> means more intelligent abstracting and more coding.
>
> I'm just throwing this out there since this is an early stage in the
> Equinox project. Even though external libraries are out of the scope,
> the work that will be done here seems like external libraries can become
> an inherent benefit of Equinox, if the approach is correct.
>
>
> Thanks,
> Joseph Toth
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:30:13 GMT 2024
Powered by FUDForum. Page generated in 0.03529 seconds |
] 
Search
Help
Register
Login
Home
