Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Refactor URI to separate bundle?
Refactor URI to separate bundle? [message #1077286] Thu, 01 August 2013 09:43 Go to next message
Bryan Hunt is currently offline Bryan Hunt
Messages: 346
Registered: July 2009
Senior Member
Hi Ed,

What do you think about the possibility of refactoring URI into it's own bundle? The features of URI are so nice that I'd like to use it in projects that do not depend on EMF. I know that I can just use the emf.common bundle without the rest of EMF, but it drags in the runtime bundle which in turn drags in lots of other unnecessary stuff.

I might be willing to do the work if you think this is even possible. I had two initial thoughts on this: a split package which I know is not the best, or turning the existing URI code into a facade on top of the real implementation in another bundle.

Bryan
Re: Refactor URI to separate bundle? [message #1077293 is a reply to message #1077286] Thu, 01 August 2013 09:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Bryan,

Comments below.

On 01/08/2013 3:43 PM, Bryan Hunt wrote:
> Hi Ed,
>
> What do you think about the possibility of refactoring URI into it's
> own bundle? The features of URI are so nice that I'd like to use it
> in projects that do not depend on EMF. I know that I can just use the
> emf.common bundle without the rest of EMF, but it drags in the runtime
> bundle which in turn drags in lots of other unnecessary stuff.
You're wanting to use this outside of an Eclipse environment? In that
case, the org.eclipse.core.runtime isn't needed for it to work stand
alone and the 350K jar size is irrelevant except perhaps for micro
devices. If not, org.eclipse.core.runtime seems like a minimal
dependency already...
>
> I might be willing to do the work if you think this is even possible.
In the 2.9 release, there are a number of other dependencies, e.g., the
data structures used for interning the instances and interning the
strings used by the instances...
> I had two initial thoughts on this: a split package which I know is
> not the best, or turning the existing URI code into a facade on top of
> the real implementation in another bundle.
Both sound kind of horrible!
>
> Bryan
Re: Refactor URI to separate bundle? [message #1077297 is a reply to message #1077293] Thu, 01 August 2013 09:59 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan Hunt
Messages: 346
Registered: July 2009
Senior Member
Ed Merks wrote on Thu, 01 August 2013 08:53


You're wanting to use this outside of an Eclipse environment? In that
case, the org.eclipse.core.runtime isn't needed for it to work stand
alone and the 350K jar size is irrelevant except perhaps for micro
devices. If not, org.eclipse.core.runtime seems like a minimal
dependency already...


I want to use it in an OSGi environment, so the dependency on runtime is a big deal especially if you are working on an embedded device such as a RaspberryPI or are working with another runtime such as Felix.

Another thought I had is to move all of the things that depend on runtime to a fragment.
Re: Refactor URI to separate bundle? [message #1077305 is a reply to message #1077297] Thu, 01 August 2013 10:10 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan Hunt
Messages: 346
Registered: July 2009
Senior Member
Bryan Hunt wrote on Thu, 01 August 2013 08:59

Another thought I had is to move all of the things that depend on runtime to a fragment.


I had another look at the code and see that CommonPlugin$Implementation extends EclipsePlugin which ties the activator to the runtime bundle. Fragments don't have an activator, so that Idea won't work. I guess I'll just stick with doing things the hard way.
Re: Refactor URI to separate bundle? [message #1077309 is a reply to message #1077297] Thu, 01 August 2013 10:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Bryan,

So another approach is to rebundle the jar itself so that it's treated
as a non-OSGi jar such that any Equinox dependencies are irrelevant.
Then it just comes down to the 350K jar size. So is that in and of
itself a concern? If so, even the .class files themselves could be
selectively extracted and rejarred...


On 01/08/2013 3:59 PM, Bryan Hunt wrote:
> Ed Merks wrote on Thu, 01 August 2013 08:53
>> You're wanting to use this outside of an Eclipse environment? In
>> that case, the org.eclipse.core.runtime isn't needed for it to work
>> stand alone and the 350K jar size is irrelevant except perhaps for
>> micro devices. If not, org.eclipse.core.runtime seems like a minimal
>> dependency already...
>
>
> I want to use it in an OSGi environment, so the dependency on runtime
> is a big deal especially if you are working on an embedded device such
> as a RaspberryPI or are working with another runtime such as Felix.
>
> Another thought I had is to move all of the things that depend on
> runtime to a fragment.
Re: Refactor URI to separate bundle? [message #1077314 is a reply to message #1077309] Thu, 01 August 2013 10:21 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan Hunt
Messages: 346
Registered: July 2009
Senior Member
Ed Merks wrote on Thu, 01 August 2013 09:12

So another approach is to rebundle the jar itself so that it's treated
as a non-OSGi jar such that any Equinox dependencies are irrelevant.
Then it just comes down to the 350K jar size. So is that in and of
itself a concern? If so, even the .class files themselves could be
selectively extracted and rejarred...


The jar size is not currently a concern. The concern is strictly:

Require-Bundle: org.eclipse.core.runtime
Bundle-Activator: org.eclipse.emf.common.CommonPlugin$Implementation

Repackaging the .class file into it's own OSGi bundle would work until you wanted to use it with EMF. You could possibly get away with changing the package version on the new bundle, but I think there's still a risk of a runtime linkage error.
Re: Refactor URI to separate bundle? [message #1077336 is a reply to message #1077314] Thu, 01 August 2013 10:55 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Bryan,

Comments below.

On 01/08/2013 4:21 PM, Bryan Hunt wrote:
> Ed Merks wrote on Thu, 01 August 2013 09:12
>> So another approach is to rebundle the jar itself so that it's
>> treated as a non-OSGi jar such that any Equinox dependencies are
>> irrelevant. Then it just comes down to the 350K jar size. So is
>> that in and of itself a concern? If so, even the .class files
>> themselves could be selectively extracted and rejarred...
>
>
> The jar size is not currently a concern. The concern is strictly:
>
> Require-Bundle: org.eclipse.core.runtime
> Bundle-Activator: org.eclipse.emf.common.CommonPlugin$Implementation
So repacking helps with that.
>
> Repackaging the .class file into it's own OSGi bundle would work until
> you wanted to use it with EMF.
Yes, and depending on which parts of EMF you use, you really start to
need things like the plugin.xml registrations, and access to resources
via the activator...
> You could possibly get away with changing the package version on the
> new bundle, but I think there's still a risk of a runtime linkage error.
Yes.
Previous Topic:setting default value of derived propertyi in ecore
Next Topic:Strange behavior with substitution groups
Goto Forum:
  


Current Time: Fri Jul 25 16:43:13 EDT 2014

Powered by FUDForum. Page generated in 0.01969 seconds