Hi Dominik, I am not getting exactly what you propose here: Which types should be allowed in "container"? a) If there is already a support for "content" type packages I don't see the need for another type within "container" b) If there is no support for nested content type packages, the question is how to aggregate multiple content type packages together so that they are actually installed via one big content-package?
As I already said, I am not too much worried about a mixture of mutable and immutable packages (that can still be done via 'mixed') but if we support that in FileVault via a dedicated type, this should be installable as well (i.e. be a regular content package). Having a pure package format without supporting installation sounds like a unnecessary limitation (even having AEM as a Cloud Service in mind) because a lot of consumers right now don't care about mutable/immutable (i.e. old AEM instances not leveraging the Composite Node Store). As I already said, I would like to see a clarification ticket for JCRVLT-170, because that clearly does neither mention nested containers nor content type packages within containers (therefore everyone assumes, those are forbidden) Thanks, Konrad > On 21. Jan 2020, at 08:34, Dominik Süß <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >
