Hi
I see that maven filters have been added to the repository as a way to have different configurations for different target platforms which is the only way to do control certain types of changes, but it is a dangerous solution because it moves the configuration from the original configuration files and actually duplicates the configuration.
What I mean is that the filters tend to start out as the commonly configured configuration options but overtime, as more people find these option and find configuration options that are common to their particular situation, the filters grow until they contain a surprising number of configuration options.
While they are great for reducing duplication in the configuration files they should be used with great care and restricted to those options that really can only be done before the JVM is started.
I speak from experience on this. Maven filters is how I managed configuration for different target deployments on several different projects and I found that it simply did not work well. That is the exact reason I introduced overrides. Most of the things I see in the maven filters are things that can be controlled by specifying an overrides file.
http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/trunk/jeeves/src/main/java/jeeves/server/ConfigurationOverrides.java?view=markup
is the overrides class in the SVN, the javadocs explains how it is used. Things that overrides cannot be used for is configuring web.xml and the transformer used (and never will) but it could be used to configure the config-*.xml files right now and with only a little modifications to the code base it could be used to configure the database setup sql as well.
The benefit of overrides is you can do one build (in most cases) and then just choose the override files to use when you start the server. There are several methods for controlling what overrides is used from system preferences to servlet configuration options.
Jesse
Hi Jesse
Thanks about sharing your experience with maven filters. For sure seem some duplication between maven filters and overrides feature and should be better in my oppinion to keep the option that we consider is better and easy to maintain.
I think is interesting if you can join in next IRC meeting (next tuesday i hope) to discuss this also with Francois that have being working in the maven filters.
Thanks and regards,
Jose García
On Thu, Aug 4, 2011 at 3:37 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:
Hi
I see that maven filters have been added to the repository as a way to have different configurations for different target platforms which is the only way to do control certain types of changes, but it is a dangerous solution because it moves the configuration from the original configuration files and actually duplicates the configuration.
What I mean is that the filters tend to start out as the commonly configured configuration options but overtime, as more people find these option and find configuration options that are common to their particular situation, the filters grow until they contain a surprising number of configuration options.
While they are great for reducing duplication in the configuration files they should be used with great care and restricted to those options that really can only be done before the JVM is started.
I speak from experience on this. Maven filters is how I managed configuration for different target deployments on several different projects and I found that it simply did not work well. That is the exact reason I introduced overrides. Most of the things I see in the maven filters are things that can be controlled by specifying an overrides file.
http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/trunk/jeeves/src/main/java/jeeves/server/ConfigurationOverrides.java?view=markup
is the overrides class in the SVN, the javadocs explains how it is used. Things that overrides cannot be used for is configuring web.xml and the transformer used (and never will) but it could be used to configure the config-*.xml files right now and with only a little modifications to the code base it could be used to configure the database setup sql as well.
The benefit of overrides is you can do one build (in most cases) and then just choose the override files to use when you start the server. There are several methods for controlling what overrides is used from system preferences to servlet configuration options.
Jesse
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hello Jesse,
2011/8/4 Jesse Eichar <jesse.eichar@anonymised.com>:
Hi
I see that maven filters have been added to the repository as a way to have
different configurations for different target platforms which is the only
way to do control certain types of changes, but it is a dangerous solution
because it moves the configuration from the original configuration files and
actually duplicates the configuration.
It moves all options to one place in order to make a custom GeoNetwork build.
At least from my side, I was thinking that filters will be useful for
the following needs :
* to remove the shell script for updating docs and installer
properties (eg. version number)
* be able to build custom geonetwork version easily (including the
installer pack and setting SQL file default values)
What I mean is that the filters tend to start out as the commonly configured
configuration options but overtime, as more people find these option and
find configuration options that are common to their particular situation,
the filters grow until they contain a surprising number of configuration
options.
Probably true !
While they are great for reducing duplication in the configuration files
they should be used with great care and restricted to those options that
really can only be done before the JVM is started.
One option could be to remove all properties that could be set by the
overrides mechanism and set the jeeves.configuration.overrides.file
properties using filter ?
... but that will not apply to :
* other (non-jeeves based) modules (eg. web-client and probably GAAP
when it will come) and
* not servlet based GeoNetwork (eg. Jeevlet which use Restlet event if
it could probably be adapted to use the overrides).
I speak from experience on this. Maven filters is how I managed
configuration for different target deployments on several different projects
and I found that it simply did not work well. That is the exact reason I
introduced overrides.
It's two complementary things, filters is for build time and overrides
when the app start ... so maybe we should improve what is set by
filters and what is set by overrides.
To be discussed on next IRC as suggested by Jose.
Cheers.
Francois
Most of the things I see in the maven filters are
things that can be controlled by specifying an overrides file.
http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/trunk/jeeves/src/main/java/jeeves/server/ConfigurationOverrides.java?view=markup
is the overrides class in the SVN, the javadocs explains how it is used.
Things that overrides cannot be used for is configuring web.xml and the
transformer used (and never will) but it could be used to configure the
config-*.xml files right now and with only a little modifications to the
code base it could be used to configure the database setup sql as well.
The benefit of overrides is you can do one build (in most cases) and then
just choose the override files to use when you start the server. There are
several methods for controlling what overrides is used from system
preferences to servlet configuration options.
Jesse
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
To be clear, maven filters can play a valuable role, just care is required when managing them. I would be happy to be at the IRC meeting next week. What time is it at?
Jesse
On Thu, Aug 4, 2011 at 7:42 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hello Jesse,
2011/8/4 Jesse Eichar <jesse.eichar@anonymised.com>:
Hi
I see that maven filters have been added to the repository as a way to have
different configurations for different target platforms which is the only
way to do control certain types of changes, but it is a dangerous solution
because it moves the configuration from the original configuration files and
actually duplicates the configuration.
It moves all options to one place in order to make a custom GeoNetwork build.
At least from my side, I was thinking that filters will be useful for
the following needs :
- to remove the shell script for updating docs and installer
properties (eg. version number)
- be able to build custom geonetwork version easily (including the
installer pack and setting SQL file default values)
What I mean is that the filters tend to start out as the commonly configured
configuration options but overtime, as more people find these option and
find configuration options that are common to their particular situation,
the filters grow until they contain a surprising number of configuration
options.
Probably true !
While they are great for reducing duplication in the configuration files
they should be used with great care and restricted to those options that
really can only be done before the JVM is started.
One option could be to remove all properties that could be set by the
overrides mechanism and set the jeeves.configuration.overrides.file
properties using filter ?
… but that will not apply to :
- other (non-jeeves based) modules (eg. web-client and probably GAAP
when it will come) and
- not servlet based GeoNetwork (eg. Jeevlet which use Restlet event if
it could probably be adapted to use the overrides).
I speak from experience on this. Maven filters is how I managed
configuration for different target deployments on several different projects
and I found that it simply did not work well. That is the exact reason I
introduced overrides.
It’s two complementary things, filters is for build time and overrides
when the app start … so maybe we should improve what is set by
filters and what is set by overrides.
To be discussed on next IRC as suggested by Jose.
Cheers.
Francois
Most of the things I see in the maven filters are
things that can be controlled by specifying an overrides file.
http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/trunk/jeeves/src/main/java/jeeves/server/ConfigurationOverrides.java?view=markup
is the overrides class in the SVN, the javadocs explains how it is used.
Things that overrides cannot be used for is configuring web.xml and the
transformer used (and never will) but it could be used to configure the
config-*.xml files right now and with only a little modifications to the
code base it could be used to configure the database setup sql as well.
The benefit of overrides is you can do one build (in most cases) and then
just choose the override files to use when you start the server. There are
several methods for controlling what overrides is used from system
preferences to servlet configuration options.
Jesse
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
2011/8/5 Jesse Eichar <jesse.eichar@anonymised.com>
To be clear, maven filters can play a valuable role, just care is required when managing them. I would be happy to be at the IRC meeting next week. What time is it at?
Tomorrow 11h.
Francois
Jesse
On Thu, Aug 4, 2011 at 7:42 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hello Jesse,
2011/8/4 Jesse Eichar <jesse.eichar@anonymised.com>:
Hi
I see that maven filters have been added to the repository as a way to have
different configurations for different target platforms which is the only
way to do control certain types of changes, but it is a dangerous solution
because it moves the configuration from the original configuration files and
actually duplicates the configuration.
It moves all options to one place in order to make a custom GeoNetwork build.
At least from my side, I was thinking that filters will be useful for
the following needs :
- to remove the shell script for updating docs and installer
properties (eg. version number)
- be able to build custom geonetwork version easily (including the
installer pack and setting SQL file default values)
What I mean is that the filters tend to start out as the commonly configured
configuration options but overtime, as more people find these option and
find configuration options that are common to their particular situation,
the filters grow until they contain a surprising number of configuration
options.
Probably true !
While they are great for reducing duplication in the configuration files
they should be used with great care and restricted to those options that
really can only be done before the JVM is started.
One option could be to remove all properties that could be set by the
overrides mechanism and set the jeeves.configuration.overrides.file
properties using filter ?
… but that will not apply to :
- other (non-jeeves based) modules (eg. web-client and probably GAAP
when it will come) and
- not servlet based GeoNetwork (eg. Jeevlet which use Restlet event if
it could probably be adapted to use the overrides).
I speak from experience on this. Maven filters is how I managed
configuration for different target deployments on several different projects
and I found that it simply did not work well. That is the exact reason I
introduced overrides.
It’s two complementary things, filters is for build time and overrides
when the app start … so maybe we should improve what is set by
filters and what is set by overrides.
To be discussed on next IRC as suggested by Jose.
Cheers.
Francois
Most of the things I see in the maven filters are
things that can be controlled by specifying an overrides file.
http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/trunk/jeeves/src/main/java/jeeves/server/ConfigurationOverrides.java?view=markup
is the overrides class in the SVN, the javadocs explains how it is used.
Things that overrides cannot be used for is configuring web.xml and the
transformer used (and never will) but it could be used to configure the
config-*.xml files right now and with only a little modifications to the
code base it could be used to configure the database setup sql as well.
The benefit of overrides is you can do one build (in most cases) and then
just choose the override files to use when you start the server. There are
several methods for controlling what overrides is used from system
preferences to servlet configuration options.
Jesse
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork