Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Making platform bundles more reuseable - A Mars target?

Hi Dani,

The problem as I see it moving some of the stuff I'm interested in into
e.g. jdt.core is not an option because it has UI meaning and e.g.
depends on jface.preferences, ... .

For the rules example I agree - we don't need an extra bundle for that
because it can be simply moved to o.e.text.

I'll file a bugzilla so that we can continue strategies there.

Tom

On 18.05.14 18:08, Daniel Megert wrote:
> Hi Tom
> 
> I'm not sure we need to split bundles. Looks like we need to move some
> types to other components (o.e.text, o.e.jdt.core) and then deprecate
> the current types. For sure this is not a Mars target for JDT, but if
> you do the work and propose high quality patches along with test cases,
> I have no objections.
> 
> Dani
> 
> 
> 
> From:        Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
> To:        eclipse-dev@xxxxxxxxxxx
> Date:        17.05.2014 14:22
> Subject:        [eclipse-dev] Making platform bundles more reuseable - A
> Mars        target?
> Sent by:        eclipse-dev-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------
> 
> 
> 
> Hi,
> 
> I know you are all busy working to get Luna out of the door but I'm
> already looking at Mars ;-)
> 
> When looking into the codebase of the platform you find out that we
> already have a nice seperation between core and ui but if you start to
> dig deeper you find out that even the bundles who contain UI have a lot
> of code in it that does not need SWT/JFace at all.
> 
> Of main interest to me are:
> * org.eclipse.jface
> * org.eclipse.jface.text
> * org.eclipse.jdt.ui
> 
> I'd like to start a discussion how to break those bundles into a common
> and an SWT specific part while maintain API compability.
> 
> Let's start with
> 
> jface.text:
> -----------
> As it looks like refactorings like this have already happened to some
> extend because some of the code has the org.eclipse.jface.text prefix,
> the first and most important package I looked into
> org.eclipse.jface.text.rules which has only one class which does depend
> on SWT DefaultDamagerRepairer, all other parts can be moved to
> org.eclipse.text. Are we fine with split-packages?
> 
> org.eclipse.jdt.ui:
> -------------------
> In this bundle there's a lot of code that does depend on SWT but a good
> other part is not and can be used nicely outside an SWT environment. The
> first stuff I looked into is FastJavaPartitionScanner.
> 
> Before I proceed with this I'd like to hear from the people involved
> (Dani, Markus, ...) if they would accept such a bundle split in Mars.
> 
> If not I need to copy over code and to e(fx)clipse which I'm fine as
> well but it would be a lot nicer if I could simply reuse the stuff from
> upstream. For the time being and to work on my proof of concept I've
> forked the code so that I can proceed with my proof of concept.
> 
> Tom
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> 
> 
> 
> 
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> 



Back to the top