Hello, I belive we can safely drom sling-karaf-configs because it does not bring any real value. My solution is to drop the project and inline the confgurations inside the features.
I've been working on this and publishing an internal release (publicly
available [1]) of the artifacts so we can deploy them internally .
I've been fixing the issues one by one with Karaf features and I came to
the conclusion that having a separate configs project and also separate
configs creates more work without any real benefits.
A karaf feature is declared as follows:
<feature name="sling-caconfig" version="${project.version}">
<config external="true"
name="org.apache.sling.jcr.repoinit.RepositoryInitializer-sling_caconfig">mvn:org.apache.sling/org.apache.sling.karaf-configs/${sling-karaf-configs.version}/config/org.apache.sling.jcr.repoinit.RepositoryInitializer-sling_caconfig</config>
<bundle>mvn:org.apache.sling/org.apache.sling.caconfig.api/1.1.0</bundle>
<!-- dependencies REDACTED for brevity -->
</feature>
Now if you analyze the feature you will notice that the config is
defined as external and has a link to a *versioned* maven artifact.
Looking at the following potential use cases you can see what I mean:
1. Configuration needs to be updated to match new bundle artifact:
- I need to update the sling-karaf-configs project and make a release
- I need to update the sling-karaf-features to use the new version of
the configs and make a release
- Optional - release sling-karaf-distribution
2. I need make an internal release with custom configurations
- I need to release and publish my custom configuration to an internal repo
- I need to copy-paste the features.xml file and update the configs to
my custom configurations
So no matter what I do, I cannot avoid releasing both artifacts. To me
that means that we can safely inline the configs inside as there is no
real reason why they should live outside. I believe that the only reason
why you would wish to put them outside is if you used un-versioned
config files. Without the version you could get only the LATEST and that
can make sense in some situations.
Am I missing something here?
Eugen,
p.s. Considering that my reasoning is flawed, right now
sling-karaf-features uses "project.version" for configs - that means it
expects sling-karaf-configs to have same version as sling-karaf-features.
[1] https://bintray.com/netdava/maven/sling-karaf
signature.asc
Description: OpenPGP digital signature
