Hi Konrad, I get your point yet that was not really the origin. Probably we can split this off in another way. Let's introduce a PackageType.Collection - basically this would supposed to be never installed but is just a shipping unit holding a set of other packages. These could either be in a flat list or for compat reasons also be placed in an /etc/packages structure. This packageType would be excluded of evaluation and is supposed to never be installed directly. It basically is a zip file acting as a wrapper around a collection of other packages. No further semantics beside the fact that it has no vault identity on its own and won't be visible after being installed - it's a pure shipping unit.
Cheers Dominik On Thu, Jan 16, 2020 at 5:21 PM Konrad Windszus <[email protected]> wrote: > 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]> 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]> 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 >> 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 >> > >
