On Thu, 2016-07-21 at 13:59 +0200, Oliver Lietz wrote: > On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote: > [...] > > > Sure, the templates used to generate both Java files from > > > Launchpad > > > Karaf > > > Features are already in SVN under resources. > > > > > > The code (some Java classes running from my IDE) reading the > > > feature.xml and > > > generating the Java sources needs some cleanup and optimization. > > > The > > > same code > > > is also used to query Maven Central and to update dependencies in > > > feature.xml > > > – the paths to features and templates are hard-coded and guava is > > > "fixed". > > > I will come up with some kind of "application", fatjar or similar > > > for > > > easy > > > usage. > > > > OK. > > > > IMO it does not have to be fully automated and fool-proof, but it > > should be possible for anyone to perform a version update. > > That can be done always by editing SlingVersionResolver.java > directly. > Using feature.xml should ensure (tests in bootstrap) that all bundles > are > compatible (form a runnable Sling instance) and updates don't have to > be done > twice.
Right, I think that's the toughest part - making sure the bundle versions are in sync. Also, a couple of suggestions related to further reducing the boilerplate. 1. Simpler HTTP port detection If no http port is specified we can just pick a random one and log it, or otherwise we have withHttpPort(int port); method which takes a specified HTTP port. 2. Automatic management of the working directory In the event ITs we manually manage: - the working directory - sling.home - repository.home ( or alternatively the OSGi configs for the segment node store and the lucene index provider ) Could we also move these inside the module? I don't think we even need a config option here, just auto-manage them. If you agree, I'll file enhancement requests. Thanks, Robert > > O. > > [...] >
