Re: [e4-dev] API and package structure

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Simon, thanks for the input.. The use
of 'internals' in your 'copy' of the addons is something that I should
look at before giving my talk at EclipseCon...;-). It must be possible
to write the addons using only public API...

Eric

From:	Simon Chemouil <eclipse@xxxxxxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	02/18/2011 06:06 AM
Subject:	Re: [e4-dev] API and package structure
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Hi there,

As promised, here's the full list of classes in org.eclipse.e4.** we 
explicitly import in our application. I hope that will be useful.

$ grep -R "import org.eclipse.e4" bundles/ | cut -d ':' -f 2
| cut -d 
';' -f 1 | sort | uniq
import org.eclipse.e4.core.commands.ECommandService
import org.eclipse.e4.core.commands.EHandlerService
import org.eclipse.e4.core.contexts.ContextFunction
import org.eclipse.e4.core.contexts.ContextInjectionFactory
import org.eclipse.e4.core.contexts.EclipseContextFactory
import org.eclipse.e4.core.contexts.IContextFunction
import org.eclipse.e4.core.contexts.IEclipseContext
import org.eclipse.e4.core.contexts.RunAndTrack
import org.eclipse.e4.core.di.annotations.CanExecute
import org.eclipse.e4.core.di.annotations.Execute
import org.eclipse.e4.core.di.annotations.Optional
import org.eclipse.e4.core.di.IInjector
import org.eclipse.e4.core.di.suppliers.ExtendedObjectSupplier
import org.eclipse.e4.core.di.suppliers.IObjectDescriptor
import org.eclipse.e4.core.di.suppliers.IRequestor
import org.eclipse.e4.core.services.events.IEventBroker
import org.eclipse.e4.ui.di.Focus
import org.eclipse.e4.ui.di.Persist
import org.eclipse.e4.ui.internal.workbench.swt.AbstractPartRenderer
import org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener
import org.eclipse.e4.ui.model.application.commands.impl.CommandsPackageImpl
import org.eclipse.e4.ui.model.application.commands.MBindings
import org.eclipse.e4.ui.model.application.commands.MBindingTableContainer
import org.eclipse.e4.ui.model.application.commands.MHandler
import org.eclipse.e4.ui.model.application.commands.MHandlerContainer
import 
org.eclipse.e4.ui.model.application.descriptor.basic.MPartDescriptorContainer
import org.eclipse.e4.ui.model.application.impl.ApplicationImpl
import org.eclipse.e4.ui.model.application.impl.ApplicationPackageImpl
import org.eclipse.e4.ui.model.application.MApplication
import org.eclipse.e4.ui.model.application.MApplicationElement
import org.eclipse.e4.ui.model.application.ui.advanced.MPerspective
import org.eclipse.e4.ui.model.application.ui.advanced.MPerspectiveStack
import org.eclipse.e4.ui.model.application.ui.advanced.MPlaceholder
import org.eclipse.e4.ui.model.application.ui.basic.impl.BasicFactoryImpl
import org.eclipse.e4.ui.model.application.ui.basic.MBasicFactory
import org.eclipse.e4.ui.model.application.ui.basic.MInputPart
import org.eclipse.e4.ui.model.application.ui.basic.MPart
import org.eclipse.e4.ui.model.application.ui.basic.MPartSashContainer
import 
org.eclipse.e4.ui.model.application.ui.basic.MPartSashContainerElement
import org.eclipse.e4.ui.model.application.ui.basic.MPartStack
import org.eclipse.e4.ui.model.application.ui.basic.MStackElement
import org.eclipse.e4.ui.model.application.ui.basic.MTrimBar
import org.eclipse.e4.ui.model.application.ui.basic.MTrimmedWindow
import org.eclipse.e4.ui.model.application.ui.basic.MWindow
import org.eclipse.e4.ui.model.application.ui.impl.UILabelImpl
import org.eclipse.e4.ui.model.application.ui.impl.UiPackageImpl
import org.eclipse.e4.ui.model.application.ui.MContext
import org.eclipse.e4.ui.model.application.ui.MDirtyable
import org.eclipse.e4.ui.model.application.ui.MElementContainer
import org.eclipse.e4.ui.model.application.ui.menu.impl.MenuFactoryImpl
import org.eclipse.e4.ui.model.application.ui.menu.MMenuContributions
import org.eclipse.e4.ui.model.application.ui.menu.MMenuElement
import org.eclipse.e4.ui.model.application.ui.menu.MToolBarContributions
import org.eclipse.e4.ui.model.application.ui.menu.MToolControl
import org.eclipse.e4.ui.model.application.ui.menu.MTrimContributions
import org.eclipse.e4.ui.model.application.ui.MInput
import org.eclipse.e4.ui.model.application.ui.MUIElement
import org.eclipse.e4.ui.model.application.ui.MUILabel
import org.eclipse.e4.ui.model.application.ui.SideValue
import org.eclipse.e4.ui.services.IServiceConstants
import org.eclipse.e4.ui.widgets.CTabFolder
import org.eclipse.e4.ui.widgets.CTabFolder2Adapter
import org.eclipse.e4.ui.widgets.CTabFolderEvent
import org.eclipse.e4.ui.widgets.CTabItem
import org.eclipse.e4.ui.workbench.IPresentationEngine
import org.eclipse.e4.ui.workbench.modeling.EModelService
import org.eclipse.e4.ui.workbench.modeling.EPartService
import org.eclipse.e4.ui.workbench.modeling.EPartService.PartState
import org.eclipse.e4.ui.workbench.modeling.ESelectionService
import org.eclipse.e4.ui.workbench.modeling.IPartListener
import org.eclipse.e4.ui.workbench.modeling.ISaveHandler
import org.eclipse.e4.ui.workbench.modeling.IWindowCloseHandler
import org.eclipse.e4.ui.workbench.renderers.swt.TrimmedPartLayout
import org.eclipse.e4.ui.workbench.UIEvents
import org.eclipse.e4.ui.workbench.UIEvents.EventTags


The e4.ui.internal imports are done by the drag and drop/minmax/clean 
addons that we imported with our code (and appropriately changed to 
match the name of our model workbench objects).

Hope this helps :)

-- 
Simon


Eric Moffatt wrote:
> 
> Hi Simon, thanks for the input...I'll see if I can answer some of
your 
> questions below (might help with other's responses as well..;-).
> 
> 1) Having an e4 BOF at EclipseCon is an excellent idea !! I'll see
> what's entailed in setting one up, stay tuned...
> 
> 2) As far as provisional vs 'real' API goes this note was to get 
> responses on the 'real' API but most certainly input as to whether
we 
> want to 'lock in' to a particular context value or have it be 
> provisional are valid. In order to keep the API as simple as possible
we 
> should only be making those things that we are *sure* we need to do
> valid RCP apps should be marked API (i.e. feedback requesting that
a 
> particular element be *removed* from the API list is even better than
> that which adds more...;-).
> 
> 3) Only once we have the definitive list of what's 'in', what's 'out'
> and what's 'provisional' can we begin to determine how to expose it;
> including defining the appropriate package structure(s) as well as
> settling on naming conventions (i.e. the what to do with the 
>  "E"nterfaces.like 'EModelService...;-).
> 
> Eric
> 
> 
> From:                
 Simon Chemouil <eclipse@xxxxxxxxxxxxxx>
> To:                
 E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> Date:                
 02/11/2011 02:48 PM
> Subject:              
   Re: [e4-dev] API and package structure
> Sent by:              
   e4-dev-bounces@xxxxxxxxxxx
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Eric Moffatt racontait le 11/02/2011 20:22:
> [snip]
>  > *_Lazy Consensus Warning:_**Input will be accepted to modify
this list
>  > until March 1st, then this /_is_ / the API that we present
at 
> EclipseCon.*
>  >
>  > *NOTE:* Most of you have more experience using the base
E4 API's than I
>  > do so please go over this list thoroughly to ensure that
it includes at
>  > least those elements that you have need in your RCP development...
Once
>  > we determine what's 'in' we can then decide on how to best
expose the
>  > api (and where to put the internals).
> [snip]
> 
> Hi there,
> 
> I've been wanting to reply to this thread for some time but I have
my
> hands more than full...  And this message is not really my reply
:).
> I'll double check the API you propose and get back soon.
> 
> My current understanding is that we're keeping a lot of the API
> *provisional*. That's what I interpret from John's "This does
not have
> to be an "all or nothing" effort. I.e., we don't need to
end up in 4.1
> with no provisional API" and the lack of discussion about "The
other
> approach would be to maintain a strong separate between 3.x and 4.x
> package names, by calling all 4.x packages something like
> org.eclipse.platform.*." (by the way, yes, please, a different
> namespace!).  So do we agree that this list does not mean "provisional"
> API, just "EclipseCon API" (which is nice to get right,
but not the same
> deal)?
> 
> Regarding API usage, our RCP app is using the "July" release.
We did not
> upgrade the target mostly because we got it working and because there's
> only so much purely technical stuff we can do with our client's money
> (we're focussed on the functional/business side of the app...).
> Switching to a more recent E4 build could trigger a lot of unexpected
> surprises so we can't afford it right now. However, I'd like to do
what
> Brian did for his application and report all the e4 API stuff we're
> using. I will do it next week because I have set some free time to
> prepare the EclipseCon.
> 
> I was also thinking that it would be nice to meet different E4
> contributors and discuss the API and general architecture, the good
and
> the less good :). Mostly about the platform ("E4 Application
Platform"),
> there are still some open points imo. Is anyone else interested? This
> will be my first EclipseCon, so I don't know the ins and outs of
> organizing this, but how about an E4 platform BoF?
> 
> Regards,
> 
> Simon
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev