Home » Archived » XML Schema Definition (XSD) » best pratice on where to store property strings?
|
| Re: best pratice on where to store property strings? [message #27081 is a reply to message #26839] |
Tue, 02 September 2003 15:39   |
 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 17:39 |
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 17:49 |
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 15:39 |
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 17:39 |
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 17:49 |
Ed Merks
Messages: 33137
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
> > >
> > >
> >
> >
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:12:55 GMT 2024
Powered by FUDForum. Page generated in 0.04081 seconds |
] 
Search
Help
Register
Login
Home
