Some more questions about that: The subpackages are a) just packages in /etc/packages/.... which are contained in the original package or b) some packages which are themselves being picked up by the JCR Installer (something in /apps/.../install/somepackage.zip)?
Are you using the latest snapshot of the according sling bundle to treat content-packages (https://github.com/apache/sling/tree/trunk/installer/factories/packages) or the one from Adobe? Thanks, Konrad > On 17 Feb 2017, at 13:11, Dominik Süß <dominik.su...@gmail.com> wrote: > > @kwin - sorry I cannot add logs as this is confidential information - yet I > could trace back this to the case where packages contain subpackages which > within the resource tranformer cause subsequent InstallTasks having the > same URL. - This migth be a bug but needs to fixed along for this to be > applicable. > > Cheers > Dominik > > On Fri, Feb 17, 2017 at 1:08 PM, Konrad Windszus <konra...@gmx.de> wrote: > >> Can you provide the logs? The change in SLING-6392 will always log in case >> it changes something (see https://svn.apache.org/viewvc/ >> sling/trunk/installer/core/src/main/java/org/apache/ >> sling/installer/core/impl/PersistentResourceList.java? >> r1=1765129&r2=1783196&pathrev=1783196). So I am wondering which package >> is actually detected as stale? >> The according log entry should start with "Removing stale resource ..." >> Thanks, >> Konrad >> >>> On 17 Feb 2017, at 13:04, Dominik Süß <dominik.su...@gmail.com> wrote: >>> >>> Reverting to -1. Subsequential integration testing on product on top of >>> this did show that SLING-6392 does fail with content-packages that >>> partially end up uninstalled instead of installed. >>> >>> Reverting SLING-6392 only including SLING-5457 succeeds. >>> >>> On Fri, Feb 17, 2017 at 1:00 PM, Stefan Seifert <sseif...@pro-vision.de> >>> wrote: >>> >>>> +1 >>>> >>>> >> >>
