| RCP standalone example [message #41895] |
Wed, 05 May 2004 18:28  |
Eclipse User |
|
|
|
Originally posted by: arturofalck.hotmail.com
I would like to create a stand alone application using RCP and am looking
for a simple example to use as guide.
I have built Nick Edgar's browser example
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org. eclipse.ui.examples.rcp.browser/readme.html
I have successfully ran the browser example from the debugger using
I20040428.
Now I would like to put it in a primary feature and "shrink wrap" it into an
application that can be launched like eclipse.
I am trying to follow "The Java Developer's Guide to Eclipse" example but I
don't believe that their example works with RCP (I also have a hard time
believing that all those steps are really necessary to deploy an
application).
Thanks,
Arturo.
|
|
|
|
|
| Re: RCP standalone example [message #44064 is a reply to message #42016] |
Mon, 28 June 2004 19:52  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
There is doc in the developers section on packaging a product that should
help you.
Jeff
"Arturo" <arturo@pragmafs.com> wrote in message
news:c7dcss$356$1@eclipse.org...
> Thanks to Ed Burnette for this answer:
>
> The primary feature stuff is not actually needed anymore. I have not seen
> any good doc on how this is supposed to work now, but the good news is
that
> an RCP export wizard is in the works that will take your plug-in(s) and
> produce a deployable directory with a startup program and all the pieces
> needed to run the application. For more info see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=49592
>
> Arturo.
>
>
> "Arturo" <arturofalck@hotmail.com> wrote in message
> news:c7bbaq$r7g$1@eclipse.org...
> > I would like to create a stand alone application using RCP and am
looking
> > for a simple example to use as guide.
> >
> > I have built Nick Edgar's browser example
> >
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org. eclipse.ui.examples.rcp.browser/readme.html
> >
> > I have successfully ran the browser example from the debugger using
> > I20040428.
> >
> > Now I would like to put it in a primary feature and "shrink wrap" it
into
> an
> > application that can be launched like eclipse.
> >
> > I am trying to follow "The Java Developer's Guide to Eclipse" example
but
> I
> > don't believe that their example works with RCP (I also have a hard time
> > believing that all those steps are really necessary to deploy an
> > application).
> >
> > Thanks,
> >
> > Arturo.
> >
> >
> >
>
>
|
|
|
| Re: RCP standalone example [message #44125 is a reply to message #44064] |
Tue, 29 June 2004 05:17 |
| Eclipse User |
|
|
|
Originally posted by: ed.burnette.REMOVE.THIS.sas.com
The doc is still a little confusing and/or incomplete. For example, there
are three places where you can put a product name: on the extension element,
the product element, and the property element (appName). It's not clear if
they're all meaningful (only the one on product is used as far as I can
tell). For example:
<extension
id="RcpProduct"
name="extension name"
point="org.eclipse.core.runtime.products">
<product
description="product description"
name="product name"
application="org.eclipse.ui.tutorials.rcp.part4.RcpApplication ">
<property
value="icons/windowImage.gif"
name="windowImage"/>
<property
value="aboutText property"
name="aboutText"/>
<property
value="appName property"
name="appName"/>
<property
value="plugin_customization.ini"
name="preferenceCustomization"/>
<property
value="icons/aboutImage.gif"
name="aboutImage"/>
</product>
The placement of the id attribute always a crap shoot. For the
o.e.c.r.product extension, here we see it on the top level element
(extension), not fully qualified. For the o.e.u.perspectives extension it is
fully qualified on the perspective sub-element. I guess the product
extension was modelled after the older applications extension instead of the
newer style that favors putting id on sub-elements.
It's unfortunate the splash gif can't be specified here too. I've been
strugling with getting osgi.splashPath or splashLocation set when using a
run-time workbench. PDE really really wants to create a configuration area
and config.ini file for you, and the launch configuration dialog lets you
specify a product and start levels but not most of the other config
settings. You can use a -config option to override or you can use the vm -D
option to override specific osgi settings but so far I've only had luck
getting the latter to work (maybe because when launching with PDE you get
two -config options which confuses it). I know about the
launch-using-features option but I don't want to use features for this
program.
Also I'm not sure how/if substitutions are done in the about text (the old
feature based about text was pretty clear on this). For example version
numbers, license keys, hyper links, etc.. I don't think the doc is
completely converted and it doesn't help that the IDE's packaging has old
bits hanging around (like a primary feature).
And what is it with paths? Some properties take relative names, some take
full drive paths, some psudo-paths like /plugins/org.eclipse.ui (where /
means the install directory), some take urls like platform:/base/ but it
doesn't pick up plug-ins in my workspace (maybe platform:/workspace/? saw a
mention but not doc'd where platform:/base/ was doc'd), and some may do
substitutions like ${ws} but I'm not sure. Since it seems to be inconsistent
it needs to be spelled out every place there is a path.
Right now I've almost got an example working with -configuration in a
run-time Workbench but inexplicably it is failing unless I provide it with a
directory in configuration called eclipse.update with a file called
feature.xml. The only reason I know that is that I copied the configuration
directory that PDE created for me (which worked) and started eliminating
things until it stopped working. If I read the doc right, it should just
work with a config.ini and nothing else in the configuration but it doesn't
look that way. Still investigating.
I know this is probably straying into Platform Update's area, but many
things in Update are intertwined with the Core Runtime. I think, in the
future, much of it should be moved into Core Runtime actually, for example
what's currently called the Update configurator, so that RCP apps can
discover their own plug-ins without a piece of Update.
--
Ed
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:cbpsto$mrn$1@eclipse.org...
> There is doc in the developers section on packaging a product that should
> help you.
>
> Jeff
>
> "Arturo" <arturo@pragmafs.com> wrote in message
> news:c7dcss$356$1@eclipse.org...
> > Thanks to Ed Burnette for this answer:
> >
> > The primary feature stuff is not actually needed anymore. I have not
seen
> > any good doc on how this is supposed to work now, but the good news is
> that
> > an RCP export wizard is in the works that will take your plug-in(s) and
> > produce a deployable directory with a startup program and all the pieces
> > needed to run the application. For more info see
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=49592
> >
> > Arturo.
|
|
|
| Re: RCP standalone example [message #44252 is a reply to message #44125] |
Wed, 30 June 2004 01:30 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Some embedded commnets...
"Ed Burnette" <ed.burnette@REMOVE.THIS.sas.com> wrote in message
news:cbqu04$h5u$1@eclipse.org...
> The doc is still a little confusing and/or incomplete. For example, there
> are three places where you can put a product name: on the extension
element,
> the product element, and the property element (appName). It's not clear if
> they're all meaningful (only the one on product is used as far as I can
> tell). For example:
appName is not the product ID. It is a tag that identifies the window
system configuration statements to use to personalize Eclipse. This comes
from the the world of X etc. See the Javado on IProductConstants.
The product name is the one on the product tag.
>
> <extension
> id="RcpProduct"
> name="extension name"
> point="org.eclipse.core.runtime.products">
> <product
> description="product description"
> name="product name"
>
application="org.eclipse.ui.tutorials.rcp.part4.RcpApplication ">
> <property
> value="icons/windowImage.gif"
> name="windowImage"/>
> <property
> value="aboutText property"
> name="aboutText"/>
> <property
> value="appName property"
> name="appName"/>
> <property
> value="plugin_customization.ini"
> name="preferenceCustomization"/>
> <property
> value="icons/aboutImage.gif"
> name="aboutImage"/>
> </product>
>
> The placement of the id attribute always a crap shoot. For the
> o.e.c.r.product extension, here we see it on the top level element
> (extension), not fully qualified. For the o.e.u.perspectives extension it
is
> fully qualified on the perspective sub-element. I guess the product
> extension was modelled after the older applications extension instead of
the
> newer style that favors putting id on sub-elements.
The location of an extension id is not a crap shoot. From the runtime point
of view, there is exactly one place to put the extension id, on the
<extension> tag. ALL other id attributes are attributes that *happen* to be
called "id" because that is what the extension point definers happened to
call it. The extensions without ids are thus anonymous. The UI has choosen
to use anonymous extensions and include multiple contributions per
extension. This is no newer/older, better/worse than the other technique.
> It's unfortunate the splash gif can't be specified here too. I've been
> strugling with getting osgi.splashPath or splashLocation set when using a
Yes, specifying the splash in the product would be ideal but it would also
mean that we would not be able to discover the splash location until
significant work had been done.
> run-time workbench. PDE really really wants to create a configuration area
> and config.ini file for you, and the launch configuration dialog lets you
> specify a product and start levels but not most of the other config
> settings. You can use a -config option to override or you can use the
vm -D
> option to override specific osgi settings but so far I've only had luck
> getting the latter to work (maybe because when launching with PDE you get
> two -config options which confuses it). I know about the
> launch-using-features option but I don't want to use features for this
> program.
Please enter or contribute to existing PDE bugs on this.
> Also I'm not sure how/if substitutions are done in the about text (the old
> feature based about text was pretty clear on this). For example version
> numbers, license keys, hyper links, etc.. I don't think the doc is
> completely converted and it doesn't help that the IDE's packaging has old
> bits hanging around (like a primary feature).
We reviewed against the 2.1 code and all the same substitutions are being
done. The presence of the primary feature tag in the o.e.platform feature
markup was a problem we found at the last minute (literally) and decided not
to correct since it was untested. This is documented in the feature.xml
itself.
> And what is it with paths? Some properties take relative names, some take
> full drive paths, some psudo-paths like /plugins/org.eclipse.ui (where /
> means the install directory), some take urls like platform:/base/ but it
> doesn't pick up plug-ins in my workspace (maybe platform:/workspace/? saw
a
> mention but not doc'd where platform:/base/ was doc'd), and some may do
> substitutions like ${ws} but I'm not sure. Since it seems to be
inconsistent
> it needs to be spelled out every place there is a path.
You'll have to be more specific on this. The form of the values of the
various product properties is detailed in IProductConstants.
> Right now I've almost got an example working with -configuration in a
> run-time Workbench but inexplicably it is failing unless I provide it with
a
> directory in configuration called eclipse.update with a file called
> feature.xml. The only reason I know that is that I copied the
configuration
> directory that PDE created for me (which worked) and started eliminating
> things until it stopped working. If I read the doc right, it should just
> work with a config.ini and nothing else in the configuration but it
doesn't
> look that way. Still investigating.
Yup, sounds like PDE and Update issues
> I know this is probably straying into Platform Update's area, but many
> things in Update are intertwined with the Core Runtime. I think, in the
> future, much of it should be moved into Core Runtime actually, for example
> what's currently called the Update configurator, so that RCP apps can
> discover their own plug-ins without a piece of Update.
If you think they are intertwined now (I disagree actually) you should look
at 2.1! Half of the Boot plugin was actually update code. Your first
suggestion is exactly opposite to the direction we are headed. For 3.0 we
explicitly separated update (feature etc) notions from the runtime. The
runtime now contains no update knowledge at all. It exposes as public API
all that is needed to manage an Eclipse install. This separation of
concerns now allows for alternative configurators to be used.
It is perfectly reasonable for someone to write a simple configurator which
just discovers plugins on the disk and "installs" them into the runtime (the
update configurator funciton you allude to). The wonder of the current
approach is that the product/installation designer now has the choice as
oppose to being locked into the Eclipse update mechanism.
Jeff
> "Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
> news:cbpsto$mrn$1@eclipse.org...
> > There is doc in the developers section on packaging a product that
should
> > help you.
> >
> > Jeff
> >
> > "Arturo" <arturo@pragmafs.com> wrote in message
> > news:c7dcss$356$1@eclipse.org...
> > > Thanks to Ed Burnette for this answer:
> > >
> > > The primary feature stuff is not actually needed anymore. I have not
> seen
> > > any good doc on how this is supposed to work now, but the good news is
> > that
> > > an RCP export wizard is in the works that will take your plug-in(s)
and
> > > produce a deployable directory with a startup program and all the
pieces
> > > needed to run the application. For more info see
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=49592
> > >
> > > Arturo.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03956 seconds
] 
Search
Help
Register
Login
Home
