Hi Dominik, better late feedback than no feedback at all. Let me comment on your points
> On 16. Jan 2020, at 15:09, Dominik Süß <[email protected]> wrote: > > 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. IMHO not if one explicitly sets the packageType to 'mixed' > > 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 That is implicitly done by setting the packageType to 'mixed'. But maybe I just don't understand correctly. I would help a lot to discuss on a concrete example. Can you share one which is no longer working? > b) we optimize the tooling to support a merging of container packages into > one container or provide a nesting capability There was a question just raised today on what a container is supposed to support. According to https://issues.apache.org/jira/browse/JCRVLT-170 <https://issues.apache.org/jira/browse/JCRVLT-170> neither nested container packages nor content packages. What exactly do you propose? Can you formulate your proposal in a dedicated JIRA ticket for FileVault? > > 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. With 'mixed' this is already the case IMHO, other changes might need further refactorings.... > > 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. Not necessarily. Even the OSGi installer can deal with container packages containing both app subpackages and bundles/configs. > > 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). What exactly is wrong about 'mixed'? > > 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 Container packages allow exactly that IMHO > > Cheers > Dominik > Konrad
