Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » best pratice on where to store property strings?
best pratice on where to store property strings? [message #26839] Sun, 24 August 2003 20:55 Go to next message
Dave Carlson is currently offline Dave Carlson
Messages: 34
Registered: July 2009
Member
A recent message from Ed Merks contained a comment about property message
strings, which raises a question for me. The comment:

-------------------
All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
They typically have names based on keys in the spec's html, e.g., the
message:
cvc-complex-type.3 = The attribute ''{0}'' is not permitted
-------------------

It seems that EMF plugins keep all translation strings in the
plugin.properties file, whereas the Wizard generated plugins from non-EMF
always specify a separate resource file for properties. Outside of EMF and
XSD, the plugin.properties is only used for variable replacement in the
plugin.xsd definitions. Other plugins as part of Eclipse core contain
several properties files that are distributed across different packages
within the plugin (the JDT plugin comes to mind here).

I'm looking for a best practice (or at least a common convention for my own
code) about where to keep message properties. Any reason not to centralize
all property strings in the plugin.properties files as done with EMF?

Thanks!
Dave Carlson
Re: best pratice on where to store property strings? [message #27081 is a reply to message #26839] Tue, 02 September 2003 11:39 Go to previous messageGo to next message
Randall Hauch is currently offline Randall Hauch
Messages: 79
Registered: July 2009
Member
Yes, there is one very good reason not to, if you wish to reuse your
plugins' jar files outside of Eclipse Platform:

If each plugin has a "plugin.properties" file, this filename is
unqualified and therefore most classloaders
will not be able to distinguish between the "plugin.properties" files
from different plugins
(they'll constantly use the first "plugin.properties" file on the
classpath).

We've found it simply much easier to put a property file in the package of
the plugin (i.e., the packaged named the same as the plugin unique
identifier - so, the "com.xyz.myplugin" package in a plugin named
"com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's just
as easy (if not slightly easier) to create as a ResourceBundle. For us,
this has worked smashingly well. ;-)

This is one of the reasons why EMF has to be packaged differently for
running inside and outside the Eclipse Platform - all of the
"plugin.properties" files need to be combined into a single file. You'll
have to do the same for your multiple plugins.

"Dave Carlson" <dcarlson@ontogenics.com> wrote in message
news:bibmpd$m3j$1@eclipse.org...
> A recent message from Ed Merks contained a comment about property message
> strings, which raises a question for me. The comment:
>
> -------------------
> All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> They typically have names based on keys in the spec's html, e.g., the
> message:
> cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> -------------------
>
> It seems that EMF plugins keep all translation strings in the
> plugin.properties file, whereas the Wizard generated plugins from non-EMF
> always specify a separate resource file for properties. Outside of EMF
and
> XSD, the plugin.properties is only used for variable replacement in the
> plugin.xsd definitions. Other plugins as part of Eclipse core contain
> several properties files that are distributed across different packages
> within the plugin (the JDT plugin comes to mind here).
>
> I'm looking for a best practice (or at least a common convention for my
own
> code) about where to keep message properties. Any reason not to
centralize
> all property strings in the plugin.properties files as done with EMF?
>
> Thanks!
> Dave Carlson
>
>
Re: best pratice on where to store property strings? [message #27120 is a reply to message #27081] Tue, 02 September 2003 13:39 Go to previous messageGo to next message
Dave Carlson is currently offline Dave Carlson
Messages: 34
Registered: July 2009
Member
Great, this is the kind of practical feedback I was looking for. The
approach you are suggesting is the same as that used by the Eclipse PDE new
project wizard.

I wonder why the EMF framework opted for a different approach, using the
plugin.properties file? This seems to be integral to the resource string
lookup methods used by EMF edit and editor projects.

Thanks,
Dave

"Randall Hauch" <rhauch@metamatrix.com> wrote in message
news:bj2dkr$3rk$1@eclipse.org...
> Yes, there is one very good reason not to, if you wish to reuse your
> plugins' jar files outside of Eclipse Platform:
>
> If each plugin has a "plugin.properties" file, this filename is
> unqualified and therefore most classloaders
> will not be able to distinguish between the "plugin.properties" files
> from different plugins
> (they'll constantly use the first "plugin.properties" file on the
> classpath).
>
> We've found it simply much easier to put a property file in the package of
> the plugin (i.e., the packaged named the same as the plugin unique
> identifier - so, the "com.xyz.myplugin" package in a plugin named
> "com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's
just
> as easy (if not slightly easier) to create as a ResourceBundle. For us,
> this has worked smashingly well. ;-)
>
> This is one of the reasons why EMF has to be packaged differently for
> running inside and outside the Eclipse Platform - all of the
> "plugin.properties" files need to be combined into a single file. You'll
> have to do the same for your multiple plugins.
>
> "Dave Carlson" <dcarlson@ontogenics.com> wrote in message
> news:bibmpd$m3j$1@eclipse.org...
> > A recent message from Ed Merks contained a comment about property
message
> > strings, which raises a question for me. The comment:
> >
> > -------------------
> > All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> > They typically have names based on keys in the spec's html, e.g., the
> > message:
> > cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> > -------------------
> >
> > It seems that EMF plugins keep all translation strings in the
> > plugin.properties file, whereas the Wizard generated plugins from
non-EMF
> > always specify a separate resource file for properties. Outside of EMF
> and
> > XSD, the plugin.properties is only used for variable replacement in the
> > plugin.xsd definitions. Other plugins as part of Eclipse core contain
> > several properties files that are distributed across different packages
> > within the plugin (the JDT plugin comes to mind here).
> >
> > I'm looking for a best practice (or at least a common convention for my
> own
> > code) about where to keep message properties. Any reason not to
> centralize
> > all property strings in the plugin.properties files as done with EMF?
> >
> > Thanks!
> > Dave Carlson
> >
> >
>
>
Re: best pratice on where to store property strings? [message #27160 is a reply to message #27120] Tue, 02 September 2003 13:49 Go to previous message
Eclipse User
Originally posted by: merks.ca.ibm.com

Dave,

One reason is that the same string may be needed in the plugin.xml and in the
code and the same is true for image resources.

To get a standalone package, copying the plugin.properties and the icons
directory to the directory of the XyzPlugin class will produce a result the
works...


Dave Carlson wrote:

> Great, this is the kind of practical feedback I was looking for. The
> approach you are suggesting is the same as that used by the Eclipse PDE new
> project wizard.
>
> I wonder why the EMF framework opted for a different approach, using the
> plugin.properties file? This seems to be integral to the resource string
> lookup methods used by EMF edit and editor projects.
>
> Thanks,
> Dave
>
> "Randall Hauch" <rhauch@metamatrix.com> wrote in message
> news:bj2dkr$3rk$1@eclipse.org...
> > Yes, there is one very good reason not to, if you wish to reuse your
> > plugins' jar files outside of Eclipse Platform:
> >
> > If each plugin has a "plugin.properties" file, this filename is
> > unqualified and therefore most classloaders
> > will not be able to distinguish between the "plugin.properties" files
> > from different plugins
> > (they'll constantly use the first "plugin.properties" file on the
> > classpath).
> >
> > We've found it simply much easier to put a property file in the package of
> > the plugin (i.e., the packaged named the same as the plugin unique
> > identifier - so, the "com.xyz.myplugin" package in a plugin named
> > "com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's
> just
> > as easy (if not slightly easier) to create as a ResourceBundle. For us,
> > this has worked smashingly well. ;-)
> >
> > This is one of the reasons why EMF has to be packaged differently for
> > running inside and outside the Eclipse Platform - all of the
> > "plugin.properties" files need to be combined into a single file. You'll
> > have to do the same for your multiple plugins.
> >
> > "Dave Carlson" <dcarlson@ontogenics.com> wrote in message
> > news:bibmpd$m3j$1@eclipse.org...
> > > A recent message from Ed Merks contained a comment about property
> message
> > > strings, which raises a question for me. The comment:
> > >
> > > -------------------
> > > All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> > > They typically have names based on keys in the spec's html, e.g., the
> > > message:
> > > cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> > > -------------------
> > >
> > > It seems that EMF plugins keep all translation strings in the
> > > plugin.properties file, whereas the Wizard generated plugins from
> non-EMF
> > > always specify a separate resource file for properties. Outside of EMF
> > and
> > > XSD, the plugin.properties is only used for variable replacement in the
> > > plugin.xsd definitions. Other plugins as part of Eclipse core contain
> > > several properties files that are distributed across different packages
> > > within the plugin (the JDT plugin comes to mind here).
> > >
> > > I'm looking for a best practice (or at least a common convention for my
> > own
> > > code) about where to keep message properties. Any reason not to
> > centralize
> > > all property strings in the plugin.properties files as done with EMF?
> > >
> > > Thanks!
> > > Dave Carlson
> > >
> > >
> >
> >
Re: best pratice on where to store property strings? [message #576598 is a reply to message #26839] Tue, 02 September 2003 11:39 Go to previous message
Randall Hauch is currently offline Randall Hauch
Messages: 79
Registered: July 2009
Member
Yes, there is one very good reason not to, if you wish to reuse your
plugins' jar files outside of Eclipse Platform:

If each plugin has a "plugin.properties" file, this filename is
unqualified and therefore most classloaders
will not be able to distinguish between the "plugin.properties" files
from different plugins
(they'll constantly use the first "plugin.properties" file on the
classpath).

We've found it simply much easier to put a property file in the package of
the plugin (i.e., the packaged named the same as the plugin unique
identifier - so, the "com.xyz.myplugin" package in a plugin named
"com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's just
as easy (if not slightly easier) to create as a ResourceBundle. For us,
this has worked smashingly well. ;-)

This is one of the reasons why EMF has to be packaged differently for
running inside and outside the Eclipse Platform - all of the
"plugin.properties" files need to be combined into a single file. You'll
have to do the same for your multiple plugins.

"Dave Carlson" <dcarlson@ontogenics.com> wrote in message
news:bibmpd$m3j$1@eclipse.org...
> A recent message from Ed Merks contained a comment about property message
> strings, which raises a question for me. The comment:
>
> -------------------
> All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> They typically have names based on keys in the spec's html, e.g., the
> message:
> cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> -------------------
>
> It seems that EMF plugins keep all translation strings in the
> plugin.properties file, whereas the Wizard generated plugins from non-EMF
> always specify a separate resource file for properties. Outside of EMF
and
> XSD, the plugin.properties is only used for variable replacement in the
> plugin.xsd definitions. Other plugins as part of Eclipse core contain
> several properties files that are distributed across different packages
> within the plugin (the JDT plugin comes to mind here).
>
> I'm looking for a best practice (or at least a common convention for my
own
> code) about where to keep message properties. Any reason not to
centralize
> all property strings in the plugin.properties files as done with EMF?
>
> Thanks!
> Dave Carlson
>
>
Re: best pratice on where to store property strings? [message #576616 is a reply to message #27081] Tue, 02 September 2003 13:39 Go to previous message
Dave Carlson is currently offline Dave Carlson
Messages: 34
Registered: July 2009
Member
Great, this is the kind of practical feedback I was looking for. The
approach you are suggesting is the same as that used by the Eclipse PDE new
project wizard.

I wonder why the EMF framework opted for a different approach, using the
plugin.properties file? This seems to be integral to the resource string
lookup methods used by EMF edit and editor projects.

Thanks,
Dave

"Randall Hauch" <rhauch@metamatrix.com> wrote in message
news:bj2dkr$3rk$1@eclipse.org...
> Yes, there is one very good reason not to, if you wish to reuse your
> plugins' jar files outside of Eclipse Platform:
>
> If each plugin has a "plugin.properties" file, this filename is
> unqualified and therefore most classloaders
> will not be able to distinguish between the "plugin.properties" files
> from different plugins
> (they'll constantly use the first "plugin.properties" file on the
> classpath).
>
> We've found it simply much easier to put a property file in the package of
> the plugin (i.e., the packaged named the same as the plugin unique
> identifier - so, the "com.xyz.myplugin" package in a plugin named
> "com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's
just
> as easy (if not slightly easier) to create as a ResourceBundle. For us,
> this has worked smashingly well. ;-)
>
> This is one of the reasons why EMF has to be packaged differently for
> running inside and outside the Eclipse Platform - all of the
> "plugin.properties" files need to be combined into a single file. You'll
> have to do the same for your multiple plugins.
>
> "Dave Carlson" <dcarlson@ontogenics.com> wrote in message
> news:bibmpd$m3j$1@eclipse.org...
> > A recent message from Ed Merks contained a comment about property
message
> > strings, which raises a question for me. The comment:
> >
> > -------------------
> > All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> > They typically have names based on keys in the spec's html, e.g., the
> > message:
> > cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> > -------------------
> >
> > It seems that EMF plugins keep all translation strings in the
> > plugin.properties file, whereas the Wizard generated plugins from
non-EMF
> > always specify a separate resource file for properties. Outside of EMF
> and
> > XSD, the plugin.properties is only used for variable replacement in the
> > plugin.xsd definitions. Other plugins as part of Eclipse core contain
> > several properties files that are distributed across different packages
> > within the plugin (the JDT plugin comes to mind here).
> >
> > I'm looking for a best practice (or at least a common convention for my
> own
> > code) about where to keep message properties. Any reason not to
> centralize
> > all property strings in the plugin.properties files as done with EMF?
> >
> > Thanks!
> > Dave Carlson
> >
> >
>
>
Re: best pratice on where to store property strings? [message #576672 is a reply to message #27120] Tue, 02 September 2003 13:49 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Dave,

One reason is that the same string may be needed in the plugin.xml and in the
code and the same is true for image resources.

To get a standalone package, copying the plugin.properties and the icons
directory to the directory of the XyzPlugin class will produce a result the
works...


Dave Carlson wrote:

> Great, this is the kind of practical feedback I was looking for. The
> approach you are suggesting is the same as that used by the Eclipse PDE new
> project wizard.
>
> I wonder why the EMF framework opted for a different approach, using the
> plugin.properties file? This seems to be integral to the resource string
> lookup methods used by EMF edit and editor projects.
>
> Thanks,
> Dave
>
> "Randall Hauch" <rhauch@metamatrix.com> wrote in message
> news:bj2dkr$3rk$1@eclipse.org...
> > Yes, there is one very good reason not to, if you wish to reuse your
> > plugins' jar files outside of Eclipse Platform:
> >
> > If each plugin has a "plugin.properties" file, this filename is
> > unqualified and therefore most classloaders
> > will not be able to distinguish between the "plugin.properties" files
> > from different plugins
> > (they'll constantly use the first "plugin.properties" file on the
> > classpath).
> >
> > We've found it simply much easier to put a property file in the package of
> > the plugin (i.e., the packaged named the same as the plugin unique
> > identifier - so, the "com.xyz.myplugin" package in a plugin named
> > "com.xyx.myplugin"). This works with the Eclipse i18n wizard, and it's
> just
> > as easy (if not slightly easier) to create as a ResourceBundle. For us,
> > this has worked smashingly well. ;-)
> >
> > This is one of the reasons why EMF has to be packaged differently for
> > running inside and outside the Eclipse Platform - all of the
> > "plugin.properties" files need to be combined into a single file. You'll
> > have to do the same for your multiple plugins.
> >
> > "Dave Carlson" <dcarlson@ontogenics.com> wrote in message
> > news:bibmpd$m3j$1@eclipse.org...
> > > A recent message from Ed Merks contained a comment about property
> message
> > > strings, which raises a question for me. The comment:
> > >
> > > -------------------
> > > All the error messages are in plugins/org.eclipse.xsd/plugin.properties.
> > > They typically have names based on keys in the spec's html, e.g., the
> > > message:
> > > cvc-complex-type.3 = The attribute ''{0}'' is not permitted
> > > -------------------
> > >
> > > It seems that EMF plugins keep all translation strings in the
> > > plugin.properties file, whereas the Wizard generated plugins from
> non-EMF
> > > always specify a separate resource file for properties. Outside of EMF
> > and
> > > XSD, the plugin.properties is only used for variable replacement in the
> > > plugin.xsd definitions. Other plugins as part of Eclipse core contain
> > > several properties files that are distributed across different packages
> > > within the plugin (the JDT plugin comes to mind here).
> > >
> > > I'm looking for a best practice (or at least a common convention for my
> > own
> > > code) about where to keep message properties. Any reason not to
> > centralize
> > > all property strings in the plugin.properties files as done with EMF?
> > >
> > > Thanks!
> > > Dave Carlson
> > >
> > >
> >
> >
Previous Topic:JBuilder to Eclipse Migration
Next Topic:Specific failure in XSDEcoreBuilder
Goto Forum:
  


Current Time: Thu Aug 21 04:20:33 EDT 2014

Powered by FUDForum. Page generated in 0.02824 seconds