My main worry is that in case you build a custom distribution with a
smaller set of features, you end up with lots of files that you don't care.
I think the easiest way is simply that at build time, all files from
startup and boot features are extracted. The features that are only
installed at run
>
> I was able to modify above files, because I saw them being present.
That was exactly my point regarding documentation. I'd imagine a lot of
people would not be even aware something is configurable and can waste time
digging or what's worse, reinvent the wheel. For someone who is been
playing
Hi Guillaume,
We are building a distribution, and we modify these files:
-rw-r--r-- 1 fabian staff 0 Sep 6 16:13 blacklisted.properties
-rw-r--r-- 1 fabian staff 977 Dec 11 2015 branding.properties
-rw-r--r-- 1 fabian staff 2414 Oct 28 17:35 custom.properties
-rw-r--r-- 1 fabi
I agree we should not remove any documentation on those configurations.
So the features inside the configuration will contain all the documentation
that exist currently in the config files.
When installing a feature using the feature service, the configuration are
always written to the etc/ dir, s
yeah, metatype could really help.
All of the properties of Pax Web are already available. But do we use those
already with the config commands?
Should be easy to use?
regards, Achim
2016-11-25 11:13 GMT+01:00 Christian Schneider :
> +1
>
> It is really important that we do such house keeping in
+1
It is really important that we do such house keeping in karaf as without
that the distro tends to grow over time.
The only small issue I see is that it is more difficult for people to
understand the defaults if a config file is not present but maybe we can
find another
way to solve this.
+1 on slimming down the configs.
regarding Milens comments.
It's possible already and called config:edit pid.
All those configurations are stored directly with config-admin service so
there isn't a proprietary config in Karaf.
I only have one comment about it.
Would be great to have a little togl
I like the idea of reducing the number of files in etc folder.
However I would vote against it until there is a good documentation of how
to configure everything that's in those removed files. That is what can be
configured, where, how it differs in clustered env, ...
Once that is place that is eas
The slimmer, the better, nice to have in 4.1
regards
Grzegorz
2016-11-25 8:22 GMT+01:00 Jean-Baptiste Onofré :
> +1 to do it on master.
>
> Regards
> JB
>
> On Nov 25, 2016, 08:19, at 08:19, Guillaume Nodet
> wrote:
> >I'd like to trim down a bit the number of files in the etc/ directory.
> >
+1 to do it on master.
Regards
JB
On Nov 25, 2016, 08:19, at 08:19, Guillaume Nodet wrote:
>I'd like to trim down a bit the number of files in the etc/ directory.
>The distribution contains a bunch of config files for the ACLs, but I'm
>not
>sure people usually modify those. I think this may
I'd like to trim down a bit the number of files in the etc/ directory.
The distribution contains a bunch of config files for the ACLs, but I'm not
sure people usually modify those. I think this may be the same for various
configuration.
What I'm proposing is the following:
* make sure all those
11 matches
Mail list logo
