Eclipse Community Forums: EMF » Refactor URI to separate bundle?

Help

Home

Home » Modeling » EMF » Refactor URI to separate bundle?

Show: Today's Messages :: Show Polls :: Message Navigator

Refactor URI to separate bundle? [message #1077286]

Thu, 01 August 2013 13:43

Bryan Hunt

Messages: 366
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

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077293 is a reply to message #1077286]

Thu, 01 August 2013 13:53

Ed Merks

Messages: 33142
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

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077297 is a reply to message #1077293]

Thu, 01 August 2013 13:59

Bryan Hunt

Messages: 366
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.

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077305 is a reply to message #1077297]

Thu, 01 August 2013 14:10

Bryan Hunt

Messages: 366
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.

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077309 is a reply to message #1077297]

Thu, 01 August 2013 14:12

Ed Merks

Messages: 33142
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.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077314 is a reply to message #1077309]

Thu, 01 August 2013 14:21

Bryan Hunt

Messages: 366
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.

Report message to a moderator

Re: Refactor URI to separate bundle? [message #1077336 is a reply to message #1077314]

Thu, 01 August 2013 14:55

Ed Merks

Messages: 33142
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.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO - MySQL] java.util.concurrent.TimeoutException
Next Topic:	Strange behavior with substitution groups

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 20:48:31 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter