Hi Dominik, For me container was always immutable by only embedding immutable content (bundles, config, app-packages, as indicated in JCRVLT-170) Especially when we allow nesting of containers, we should probably think of two different container types: - container (immutable), with the current restrictions, but in addition allows nested containers (immutable) - content-container (mutable), only allows content and content-container sub packages
That way we have a clean separation even on the container level. Whether we need one container which allows embedding both container (immutable) and content-container (mutable), I am not sure about. WDYT? Also not very sure about the naming of such a construct... Konrad > On 16. Jan 2020, at 16:40, Dominik Süß <[email protected]> wrote: > > Hi Konrad, > > mixed is a legacy structure that basically allows all kinds of things. What > we would want to avoid is mixing content and application content in the same > package - building a container that allow application and content package to > be grouped together (as installable entities) but making sure they are not > mashed together helps to install both at distinct times. If you check setups > working with the composite nodestore you would have 2 different times at > which the application and the content packages would be installed. Crucial is > that containers basically don't really define an own identity that you would > be depending on - you should only define dependencies on the actual > installables . The problem of a mixed package is that people start to add > content to it and therefore you have to define dependencies on it, if they > then also contain application on content there is ambiguity when this package > actually is in an installed state as the application part would need to be > installed when preparing the immutable part of the repository while the > content only can be installed at runtime with the mutable content being > accessible. > Containers would be the tool to declare a grouping of entities that are > supposed to be installed while (optimally - not sure if we should enforce) > not playing a role in the dependency handling at all. > > Cheers > Dominik > > On Thu, Jan 16, 2020 at 3:33 PM Konrad Windszus <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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
