+1 (non-binding)
here is a workaround when using the slingstart-maven-plugin for generating the
files if you do not want the multilines in config files:
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>slingstart-maven-plugin</artifactId>
<extensions>true</extensions>
<version>1.2.0</version>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.configadmin</artifactId>
<version>1.8.4</version>
</dependency>
</dependencies>
</plugin>
worked for me.
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:[email protected]]
>Sent: Thursday, June 11, 2015 8:07 AM
>To: [email protected]
>Subject: Re: [VOTE] Release Apache Sling Provisioning Model 1.2.0 and Apache
>Sling Slingstart Maven Plugin 1.2.0
>
>Am 10.06.15 um 22:41 schrieb Stefan Seifert:
>> i've a problem with this new release.
>>
>> in rev. 1684389 you updated the dependency on org.apache.felix.configadmin
>from 1.2.8 to 1.8.6.
>>
>> the problem is that this version always writes osgi config files with arrays
>in multiple lines - and if such a version is deployed to a felix instance with
>an older version org.apache.felix.configadmin 1.8.4 or below the configuration
>cannot be read and is ignored.
>>
>> thus this slingstart plugin version only supports instances with the very
>latest configadmin - is this intended?
>>
>Yes, this is really unfortunate. However, you don't need the latest
>configadmin but the lastest OSGi installer core (I've started a vote for
>that because of exactly this reason).
>I don't think this is a blocker for this release, we can decide whether
>we're fine with this and if not find a solution and release updated
>versions.
>I agree that this coupling is not nice and is usually not what we do.
>However, I don't see a good solution for this. The new format is really
>very handy for making a diff with multi value properties, so I really
>want this :) If we want to stay 100% compatible, it would mean, we only
>support reading the new format but always write out the old format - and
>in that case we'll never take advantage of it.
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>[email protected]
