Hi Konrad & all, sorry for being radio silent for almost half a year now but as you might have noticed I was quite busy in my dayjob and the stuff I committed before did just work and priorities didn't allow me to get back to the whole content-package stuff (which I hope to slowly change now).
Based on the last changes in the filevault plugin some of the setups that were in place are no longer working - this is specifically by enforcing to not embed osgi bundles and configs. My suggestion to make sure this is not breaking each and every existing setup would be 2fold a) make sure we can override those rules to run it in some kind of legacy mode b) we optimize the tooling to support a merging of container packages into one container or provide a nesting capability As an endresult it should be possible to slowly migrate existing structures (that currently are postprocessed by a converter) towards something that natively enables a suitable structure while the codestructures would not need to change beyond the pom definitions. Right now in most cases because of compatiblity reasons with the osgi installer the osgi configs and osgi bundles are part of the application packages. This is failing for almost everyone - and if we want them to be moved out into the container we must make sure that the structures can be reflected. As a first step I would suggest we establish some property to establish some legacy mode for application packages and as a next step make sure we get container packages that allow the same that is currently partially reflected by application packages with mutliple install folders (e.g. with runmode support). As long as we want to support the sling installer for a while the container structure itself would need be able to locate the binaries and packages in locations the installer is aware of (install and config folders) or we need to patch the sling installer to be able to process the new container packages accurately Cheers Dominik
