Home » Eclipse Projects » Equinox » How do you handle library classes via dependencies?
| |
| Re: How do you handle library classes via dependencies? [message #22427 is a reply to message #22318] |
Thu, 10 April 2003 18:45   |
Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
Normally there should be a way for A to say which interface it wants from
xerces. And that should ultimately come from a central repository of ids.
Ala com class ids or corba ior. A central key to component management is the
idea of mapping an interface with a certain Id. This way if A wants
IXerces[020] then it does not matter where it gets it from. Does the idea of
interface id apeal to you guys ? This would be a minimal reinvention of the
wheel but !
"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
news:b7493v$9o0$1@rogue.oti.com...
> I am curious, if plugin A depends on B that has xerces.jar 1.0 and also
> depends on C that has xerces 2.0, and A uses xerces, first of all which
one
> does A use? Second, is there any issue like runtime ambiguous names or
> something? How does A know to go to B for 1.0 as opposed to C for 2.0 or
> vice versa OR even not use either because they aren't the version A needs?
>
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #22469 is a reply to message #22427] |
Thu, 10 April 2003 19:45 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
That sounds similar to my engine where I have a "shared" classpath that any
plugin can stick something into and all other plugins can use it. Sort of
like every plugin depending on one plugin. It is the parent loader to ALL
plugin classloaders. That way, if a given requires class the JVM is asking
any plugin class is not found within its classpath, it goes to the dependent
loaders classpaths, and wont find it there, so then it goes to the parent
loader, which its immediate parent is the "global" plugin classpath that all
plugins share and it can find it there. If not, it then moves on to the
engine class loader, system loader, etc.
"dominic" <dominic@nospam.com> wrote in message
news:b74dne$dr4$1@rogue.oti.com...
> Normally there should be a way for A to say which interface it wants from
> xerces. And that should ultimately come from a central repository of ids.
> Ala com class ids or corba ior. A central key to component management is
the
> idea of mapping an interface with a certain Id. This way if A wants
> IXerces[020] then it does not matter where it gets it from. Does the idea
of
> interface id apeal to you guys ? This would be a minimal reinvention of
the
> wheel but !
>
> "Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
> news:b7493v$9o0$1@rogue.oti.com...
> > I am curious, if plugin A depends on B that has xerces.jar 1.0 and also
> > depends on C that has xerces 2.0, and A uses xerces, first of all which
> one
> > does A use? Second, is there any issue like runtime ambiguous names or
> > something? How does A know to go to B for 1.0 as opposed to C for 2.0 or
> > vice versa OR even not use either because they aren't the version A
needs?
> >
> >
> >
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #22513 is a reply to message #22469] |
Thu, 10 April 2003 20:16 |
| Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
What identifies the interface ? a string or guid type id. Also can a plugin
specify that it provides more than one interface when it is registering with
shared classpath? Maybe for bacward compatibility reasons a plugin may
decide to provide both interfaces.
"Kevin" <kduffey@marketron.com> wrote in message
news:b74h76$h16$1@rogue.oti.com...
> That sounds similar to my engine where I have a "shared" classpath that
any
> plugin can stick something into and all other plugins can use it. Sort of
> like every plugin depending on one plugin. It is the parent loader to ALL
> plugin classloaders. That way, if a given requires class the JVM is asking
> any plugin class is not found within its classpath, it goes to the
dependent
> loaders classpaths, and wont find it there, so then it goes to the parent
> loader, which its immediate parent is the "global" plugin classpath that
all
> plugins share and it can find it there. If not, it then moves on to the
> engine class loader, system loader, etc.
>
>
> "dominic" <dominic@nospam.com> wrote in message
> news:b74dne$dr4$1@rogue.oti.com...
> > Normally there should be a way for A to say which interface it wants
from
> > xerces. And that should ultimately come from a central repository of
ids.
> > Ala com class ids or corba ior. A central key to component management is
> the
> > idea of mapping an interface with a certain Id. This way if A wants
> > IXerces[020] then it does not matter where it gets it from. Does the
idea
> of
> > interface id apeal to you guys ? This would be a minimal reinvention of
> the
> > wheel but !
> >
> > "Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
> > news:b7493v$9o0$1@rogue.oti.com...
> > > I am curious, if plugin A depends on B that has xerces.jar 1.0 and
also
> > > depends on C that has xerces 2.0, and A uses xerces, first of all
which
> > one
> > > does A use? Second, is there any issue like runtime ambiguous names or
> > > something? How does A know to go to B for 1.0 as opposed to C for 2.0
or
> > > vice versa OR even not use either because they aren't the version A
> needs?
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #22600 is a reply to message #22513] |
Fri, 11 April 2003 06:44 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
This relates back to an earlier posting I did.
MANY problems would be circumvented if plugins were delivered including
libraries like XML parsers they are dependent on (the reused libraries).
The runtime could be optimized to check for equivalence and (maybe on
class level) and only load the same library once.
The GUID approach is a nice approach technically, but in practice it
will be a lot of configuration, which I guess we all know is error prone.
Kind regards,
Peter Kriens
dominic wrote:
> What identifies the interface ? a string or guid type id. Also can a plugin
> specify that it provides more than one interface when it is registering with
> shared classpath? Maybe for bacward compatibility reasons a plugin may
> decide to provide both interfaces.
>
>
> "Kevin" <kduffey@marketron.com> wrote in message
> news:b74h76$h16$1@rogue.oti.com...
>
>>That sounds similar to my engine where I have a "shared" classpath that
>>
> any
>
>>plugin can stick something into and all other plugins can use it. Sort of
>>like every plugin depending on one plugin. It is the parent loader to ALL
>>plugin classloaders. That way, if a given requires class the JVM is asking
>>any plugin class is not found within its classpath, it goes to the
>>
> dependent
>
>>loaders classpaths, and wont find it there, so then it goes to the parent
>>loader, which its immediate parent is the "global" plugin classpath that
>>
> all
>
>>plugins share and it can find it there. If not, it then moves on to the
>>engine class loader, system loader, etc.
>>
>>
>>"dominic" <dominic@nospam.com> wrote in message
>>news:b74dne$dr4$1@rogue.oti.com...
>>
>>>Normally there should be a way for A to say which interface it wants
>>>
> from
>
>>>xerces. And that should ultimately come from a central repository of
>>>
> ids.
>
>>>Ala com class ids or corba ior. A central key to component management is
>>>
>>the
>>
>>>idea of mapping an interface with a certain Id. This way if A wants
>>>IXerces[020] then it does not matter where it gets it from. Does the
>>>
> idea
>
>>of
>>
>>>interface id apeal to you guys ? This would be a minimal reinvention of
>>>
>>the
>>
>>>wheel but !
>>>
>>>"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
>>>news:b7493v$9o0$1@rogue.oti.com...
>>>
>>>>I am curious, if plugin A depends on B that has xerces.jar 1.0 and
>>>>
> also
>
>>>>depends on C that has xerces 2.0, and A uses xerces, first of all
>>>>
> which
>
>>>one
>>>
>>>>does A use? Second, is there any issue like runtime ambiguous names or
>>>>something? How does A know to go to B for 1.0 as opposed to C for 2.0
>>>>
> or
>
>>>>vice versa OR even not use either because they aren't the version A
>>>>
>>needs?
>>
>>>>
>>>>
>>>
>>
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #22643 is a reply to message #22600] |
Fri, 11 April 2003 13:54 |
| Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
I can see how this would lead to a clumbered repository of libraries.
Imagine doenloading the same library two or three times for every plugin !
This is the other extreme of the table. Com and Corba have been dealing with
these issues for a long while now.
The simplest thing i see is a core engine that at start up reads all the
plugins and registers what interfaces they provide/need. At run/start time
this engine would return the *exact* interface requested by a plugin.
The dependency *should* only be used when the user starts to load/unload
certain plugins. For example if the user decides to turn off the jdt plugin
then the engine would remove all the interfaces provided by the jdt plugin
from its registry and also inform those interfaces that they are no longer
supposed to run ! of course if the user restarts his system then he would
only get the plugins he allowed to run.
So coming back to the subject packaging (static linking) together plugin
specific libraries does not look apealing to me. Heck this is why we need a
plugin framework in the first place.
Furthermore right now i do not think there is a provision for the platform
to support 2 versions of the jdt at the same time. Unless the plugin
framework becomes so much granular we will never be able to provide the
"capability a la carte" that we need here.
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E966438.4040002@aQute.se...
> This relates back to an earlier posting I did.
>
> MANY problems would be circumvented if plugins were delivered including
> libraries like XML parsers they are dependent on (the reused libraries).
> The runtime could be optimized to check for equivalence and (maybe on
> class level) and only load the same library once.
>
> The GUID approach is a nice approach technically, but in practice it
> will be a lot of configuration, which I guess we all know is error prone.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
> dominic wrote:
>
> > What identifies the interface ? a string or guid type id. Also can a
plugin
> > specify that it provides more than one interface when it is registering
with
> > shared classpath? Maybe for bacward compatibility reasons a plugin may
> > decide to provide both interfaces.
> >
> >
> > "Kevin" <kduffey@marketron.com> wrote in message
> > news:b74h76$h16$1@rogue.oti.com...
> >
> >>That sounds similar to my engine where I have a "shared" classpath that
> >>
> > any
> >
> >>plugin can stick something into and all other plugins can use it. Sort
of
> >>like every plugin depending on one plugin. It is the parent loader to
ALL
> >>plugin classloaders. That way, if a given requires class the JVM is
asking
> >>any plugin class is not found within its classpath, it goes to the
> >>
> > dependent
> >
> >>loaders classpaths, and wont find it there, so then it goes to the
parent
> >>loader, which its immediate parent is the "global" plugin classpath that
> >>
> > all
> >
> >>plugins share and it can find it there. If not, it then moves on to the
> >>engine class loader, system loader, etc.
> >>
> >>
> >>"dominic" <dominic@nospam.com> wrote in message
> >>news:b74dne$dr4$1@rogue.oti.com...
> >>
> >>>Normally there should be a way for A to say which interface it wants
> >>>
> > from
> >
> >>>xerces. And that should ultimately come from a central repository of
> >>>
> > ids.
> >
> >>>Ala com class ids or corba ior. A central key to component management
is
> >>>
> >>the
> >>
> >>>idea of mapping an interface with a certain Id. This way if A wants
> >>>IXerces[020] then it does not matter where it gets it from. Does the
> >>>
> > idea
> >
> >>of
> >>
> >>>interface id apeal to you guys ? This would be a minimal reinvention of
> >>>
> >>the
> >>
> >>>wheel but !
> >>>
> >>>"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
> >>>news:b7493v$9o0$1@rogue.oti.com...
> >>>
> >>>>I am curious, if plugin A depends on B that has xerces.jar 1.0 and
> >>>>
> > also
> >
> >>>>depends on C that has xerces 2.0, and A uses xerces, first of all
> >>>>
> > which
> >
> >>>one
> >>>
> >>>>does A use? Second, is there any issue like runtime ambiguous names or
> >>>>something? How does A know to go to B for 1.0 as opposed to C for 2.0
> >>>>
> > or
> >
> >>>>vice versa OR even not use either because they aren't the version A
> >>>>
> >>needs?
> >>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #22994 is a reply to message #22643] |
Tue, 15 April 2003 07:22 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
dominic wrote:
> I can see how this would lead to a clumbered repository of libraries.
> Imagine doenloading the same library two or three times for every plugin !
You are sure your estethic feelings are not in the way of your view of
reality? :-)
The real problem I see is that managing libraries by reference is not
working very well in practice. Go and download libs from apache and see
how many have version numbers. DLL hell was caused by the fact that
people did not follow Microsoft's guidelines for versioning. Most
versioning schemes require a discipline that is beyond what can be
expected from most developers.
Lets face it, download time and disk space are no real issues nowadays.
Knowing exactly what a plugin was compiled against (and having that
actual code) seems an enormous boon to reliability imho.
Keeping the repository well managed seems to be very straightforward imho.
Kind regards,
Peter Kriens
> This is the other extreme of the table. Com and Corba have been dealing with
> these issues for a long while now.
> The simplest thing i see is a core engine that at start up reads all the
> plugins and registers what interfaces they provide/need. At run/start time
> this engine would return the *exact* interface requested by a plugin.
> The dependency *should* only be used when the user starts to load/unload
> certain plugins. For example if the user decides to turn off the jdt plugin
> then the engine would remove all the interfaces provided by the jdt plugin
> from its registry and also inform those interfaces that they are no longer
> supposed to run ! of course if the user restarts his system then he would
> only get the plugins he allowed to run.
> So coming back to the subject packaging (static linking) together plugin
> specific libraries does not look apealing to me. Heck this is why we need a
> plugin framework in the first place.
> Furthermore right now i do not think there is a provision for the platform
> to support 2 versions of the jdt at the same time. Unless the plugin
> framework becomes so much granular we will never be able to provide the
> "capability a la carte" that we need here.
>
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E966438.4040002@aQute.se...
>
>>This relates back to an earlier posting I did.
>>
>>MANY problems would be circumvented if plugins were delivered including
>>libraries like XML parsers they are dependent on (the reused libraries).
>> The runtime could be optimized to check for equivalence and (maybe on
>>class level) and only load the same library once.
>>
>>The GUID approach is a nice approach technically, but in practice it
>>will be a lot of configuration, which I guess we all know is error prone.
>>
>>Kind regards,
>>
>>Peter Kriens
>>
>>
>>
>>
>>dominic wrote:
>>
>>
>>>What identifies the interface ? a string or guid type id. Also can a
>>>
> plugin
>
>>>specify that it provides more than one interface when it is registering
>>>
> with
>
>>>shared classpath? Maybe for bacward compatibility reasons a plugin may
>>>decide to provide both interfaces.
>>>
>>>
>>>"Kevin" <kduffey@marketron.com> wrote in message
>>>news:b74h76$h16$1@rogue.oti.com...
>>>
>>>
>>>>That sounds similar to my engine where I have a "shared" classpath that
>>>>
>>>>
>>>any
>>>
>>>
>>>>plugin can stick something into and all other plugins can use it. Sort
>>>>
> of
>
>>>>like every plugin depending on one plugin. It is the parent loader to
>>>>
> ALL
>
>>>>plugin classloaders. That way, if a given requires class the JVM is
>>>>
> asking
>
>>>>any plugin class is not found within its classpath, it goes to the
>>>>
>>>>
>>>dependent
>>>
>>>
>>>>loaders classpaths, and wont find it there, so then it goes to the
>>>>
> parent
>
>>>>loader, which its immediate parent is the "global" plugin classpath that
>>>>
>>>>
>>>all
>>>
>>>
>>>>plugins share and it can find it there. If not, it then moves on to the
>>>>engine class loader, system loader, etc.
>>>>
>>>>
>>>>"dominic" <dominic@nospam.com> wrote in message
>>>>news:b74dne$dr4$1@rogue.oti.com...
>>>>
>>>>
>>>>>Normally there should be a way for A to say which interface it wants
>>>>>
>>>>>
>>>from
>>>
>>>
>>>>>xerces. And that should ultimately come from a central repository of
>>>>>
>>>>>
>>>ids.
>>>
>>>
>>>>>Ala com class ids or corba ior. A central key to component management
>>>>>
> is
>
>>>>the
>>>>
>>>>
>>>>>idea of mapping an interface with a certain Id. This way if A wants
>>>>>IXerces[020] then it does not matter where it gets it from. Does the
>>>>>
>>>>>
>>>idea
>>>
>>>
>>>>of
>>>>
>>>>
>>>>>interface id apeal to you guys ? This would be a minimal reinvention of
>>>>>
>>>>>
>>>>the
>>>>
>>>>
>>>>>wheel but !
>>>>>
>>>>>"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
>>>>>news:b7493v$9o0$1@rogue.oti.com...
>>>>>
>>>>>
>>>>>>I am curious, if plugin A depends on B that has xerces.jar 1.0 and
>>>>>>
>>>>>>
>>>also
>>>
>>>
>>>>>>depends on C that has xerces 2.0, and A uses xerces, first of all
>>>>>>
>>>>>>
>>>which
>>>
>>>
>>>>>one
>>>>>
>>>>>
>>>>>>does A use? Second, is there any issue like runtime ambiguous names or
>>>>>>something? How does A know to go to B for 1.0 as opposed to C for 2.0
>>>>>>
>>>>>>
>>>or
>>>
>>>
>>>>>>vice versa OR even not use either because they aren't the version A
>>>>>>
>>>>>>
>>>>needs?
>>>>
>>>>
>>>>>>
>>>
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #23037 is a reply to message #22994] |
Tue, 15 April 2003 10:34 |
| Eclipse User |
|
|
|
Originally posted by: d3l3t3-heavy-n0sp4m.ungoverned.org
pkriens wrote:
> Lets face it, download time and disk space are no real issues nowadays.
> Knowing exactly what a plugin was compiled against (and having that
> actual code) seems an enormous boon to reliability imho.
Which is probably precisely why Microsoft chose a variant of the
approach in .NET. Essentially, in .NET, a component is guaranteed to get
the exact versions of other components it was compiled against (modulo
policy filed). It certainly does make sense for a variety of scenarios.
Despite this, I do understand the hesitation to forcing every component
to always include its dependent libraries. It would be nice if there was
a way to get the best of both worlds. To do this, would require
something else that .NET has, a global cache of libraries. In such a
solution, we could just shove every library into the global cache and
use reference counting. Thus, when a duplicate library is entered into
the cache (determined with a content hash or something), it is not saved
to the disk, but just reference counted.
This would require that we come up with some sort of standard way to
package Java packages so that we could determine the identity...and not
to forget, their substitutability.
-> richard
|
|
|
| Re: How do you handle library classes via dependencies? [message #23121 is a reply to message #22994] |
Wed, 16 April 2003 19:00 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E9BB332.2010500@aQute.se...
>
>
> The real problem I see is that managing libraries by reference is not
> working very well in practice. Go and download libs from apache and see
> how many have version numbers. DLL hell was caused by the fact that
> people did not follow Microsoft's guidelines for versioning. Most
> versioning schemes require a discipline that is beyond what can be
> expected from most developers.
>
> Lets face it, download time and disk space are no real issues nowadays.
> Knowing exactly what a plugin was compiled against (and having that
> actual code) seems an enormous boon to reliability imho.
>
I agree that this is a real problem deserving a solution. Some issue:
- disk space and download bandwidth are very cheap but not universal and
product team are continually under pressure to minimize their resource
usage. eclipse.org has a 45Mb pipe which is saturated 24/7 and Eclipse is
only 60MB.
- the requires graph for a given product can be quite large. Some Eclipse
based products today barely fit on a CD. These products form the basis of
other products or *optionally* work in conjunciton with them. In addition
to the scaling issues, we should also consider how the optional prereq'ing
fits in.
- as eclipse is used more in generic application scenarios, size does
matter. For example, you would be disappointed if IE took 10 minutes to
download the Flash plugin the first time you encountered Flash content.
Note that this sort of scenario is precisely what is driving the dynamic
plugins work.
So, I don't know the answer. Perhaps a hybrid approach. It is definitely
worth looking for an answer.
Jeff
|
|
|
| Re: How do you handle library classes via dependencies? [message #23162 is a reply to message #23121] |
Thu, 17 April 2003 02:25 |
 Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Honestly guys, this along with my own interest in a plugin engine and not
knowing of eclipse before starting is why I built my own engine. My engine
with XMLPull parser is about 30K in size. It isn't near as robust as
Eclipse, but it works in a similar fashion: plugin repository, each plugin
dynamically loaded with its own classloader, plugin dependencies resolved
all while no plugin code is loaded, extension points and extensions, and so
forth. I'll be working on a generic UI framework similar to what Eclipse and
others are like, where by plugins can build the UI without any plugin code
running, and a proxy is used by the engine to listen for various events of
buttons/menu items that then create the plugin they are being sent to as
needed, and so forth.
Don't get me wrong, Eclipse IDE rocks, and Equinox will prove even better
once it can do all that is on its plate. But the bottom line to me is size.
I want a very small footprint, and the size of the runtime plus the
complexity is more than I personally care to have in my own applications.
However, that said, I do think Eclipse/Equinox have a very solid foundation
and with so many on board to support it, I too am along for the ride! If I
can figure out how to get testing of the core runtime code I am working on,
I am hoping to contribute to Equinox/Eclipse as well! So, while I do like
what I have built and it works well, I also want to contribute to the
Eclipse/Equinox products because of what they offer as well.
Still, despite that these days 100GB hds, 1GB of memory, DVD-R drives and
3+Ghz computers are "almost" the norm, I still believe writing code for the
smallest possible denominator is a good way to go. The code usually ends up
will refined, optimized (eventually) and easy to work with as opposed to
100's of classes to do something similar.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b7k8nm$ol0$1@rogue.oti.com...
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E9BB332.2010500@aQute.se...
> >
> >
> > The real problem I see is that managing libraries by reference is not
> > working very well in practice. Go and download libs from apache and see
> > how many have version numbers. DLL hell was caused by the fact that
> > people did not follow Microsoft's guidelines for versioning. Most
> > versioning schemes require a discipline that is beyond what can be
> > expected from most developers.
> >
> > Lets face it, download time and disk space are no real issues nowadays.
> > Knowing exactly what a plugin was compiled against (and having that
> > actual code) seems an enormous boon to reliability imho.
> >
>
> I agree that this is a real problem deserving a solution. Some issue:
>
> - disk space and download bandwidth are very cheap but not universal and
> product team are continually under pressure to minimize their resource
> usage. eclipse.org has a 45Mb pipe which is saturated 24/7 and Eclipse is
> only 60MB.
>
> - the requires graph for a given product can be quite large. Some Eclipse
> based products today barely fit on a CD. These products form the basis of
> other products or *optionally* work in conjunciton with them. In addition
> to the scaling issues, we should also consider how the optional prereq'ing
> fits in.
>
> - as eclipse is used more in generic application scenarios, size does
> matter. For example, you would be disappointed if IE took 10 minutes to
> download the Flash plugin the first time you encountered Flash content.
> Note that this sort of scenario is precisely what is driving the dynamic
> plugins work.
>
> So, I don't know the answer. Perhaps a hybrid approach. It is definitely
> worth looking for an answer.
>
> Jeff
>
>
|
|
|
| Re: How do you handle library classes via dependencies? [message #23555 is a reply to message #23162] |
Sat, 26 April 2003 14:21 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I REALLY think you should take a good look at OSGi. Your sentiments to
make things small and beautifull are shared with most of the designers
of the specifications.
Kind regards,
Peter Kriens
Kevin wrote:
> Honestly guys, this along with my own interest in a plugin engine and not
> knowing of eclipse before starting is why I built my own engine. My engine
> with XMLPull parser is about 30K in size. It isn't near as robust as
> Eclipse, but it works in a similar fashion: plugin repository, each plugin
> dynamically loaded with its own classloader, plugin dependencies resolved
> all while no plugin code is loaded, extension points and extensions, and so
> forth. I'll be working on a generic UI framework similar to what Eclipse and
> others are like, where by plugins can build the UI without any plugin code
> running, and a proxy is used by the engine to listen for various events of
> buttons/menu items that then create the plugin they are being sent to as
> needed, and so forth.
>
> Don't get me wrong, Eclipse IDE rocks, and Equinox will prove even better
> once it can do all that is on its plate. But the bottom line to me is size.
> I want a very small footprint, and the size of the runtime plus the
> complexity is more than I personally care to have in my own applications.
> However, that said, I do think Eclipse/Equinox have a very solid foundation
> and with so many on board to support it, I too am along for the ride! If I
> can figure out how to get testing of the core runtime code I am working on,
> I am hoping to contribute to Equinox/Eclipse as well! So, while I do like
> what I have built and it works well, I also want to contribute to the
> Eclipse/Equinox products because of what they offer as well.
>
> Still, despite that these days 100GB hds, 1GB of memory, DVD-R drives and
> 3+Ghz computers are "almost" the norm, I still believe writing code for the
> smallest possible denominator is a good way to go. The code usually ends up
> will refined, optimized (eventually) and easy to work with as opposed to
> 100's of classes to do something similar.
>
>
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b7k8nm$ol0$1@rogue.oti.com...
>
>>"pkriens" <Peter.Kriens@aQute.se> wrote in message
>>news:3E9BB332.2010500@aQute.se...
>>
>>>
>>>The real problem I see is that managing libraries by reference is not
>>>working very well in practice. Go and download libs from apache and see
>>>how many have version numbers. DLL hell was caused by the fact that
>>>people did not follow Microsoft's guidelines for versioning. Most
>>>versioning schemes require a discipline that is beyond what can be
>>>expected from most developers.
>>>
>>>Lets face it, download time and disk space are no real issues nowadays.
>>>Knowing exactly what a plugin was compiled against (and having that
>>>actual code) seems an enormous boon to reliability imho.
>>>
>>>
>>I agree that this is a real problem deserving a solution. Some issue:
>>
>>- disk space and download bandwidth are very cheap but not universal and
>>product team are continually under pressure to minimize their resource
>>usage. eclipse.org has a 45Mb pipe which is saturated 24/7 and Eclipse is
>>only 60MB.
>>
>>- the requires graph for a given product can be quite large. Some Eclipse
>>based products today barely fit on a CD. These products form the basis of
>>other products or *optionally* work in conjunciton with them. In addition
>>to the scaling issues, we should also consider how the optional prereq'ing
>>fits in.
>>
>>- as eclipse is used more in generic application scenarios, size does
>>matter. For example, you would be disappointed if IE took 10 minutes to
>>download the Flash plugin the first time you encountered Flash content.
>>Note that this sort of scenario is precisely what is driving the dynamic
>>plugins work.
>>
>>So, I don't know the answer. Perhaps a hybrid approach. It is definitely
>>worth looking for an answer.
>>
>>Jeff
>>
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Fri Dec 27 00:31:41 GMT 2024
Powered by FUDForum. Page generated in 0.03917 seconds |
] 
Search
Help
Register
Login
Home
