On Monday 18 June 2018 16:07:16 Eugen Stan wrote:
> Hello,
Hi,
> 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">mv
> n:org.apache.sling/org.apache.sling.karaf-configs/${sling-karaf-configs.vers
> ion}/config/org.apache.sling.jcr.repoinit.RepositoryInitializer-sling_caconf
> ig</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?
yes, see SLING-6043.
Additional benefit is the reusability of configurations.
Regards,
O.
> 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.
Will be changed once configs are released.
>
> [1] https://bintray.com/netdava/maven/sling-karaf
