Hi, 2 observations going through the upgrade process from Oak 1.6 to Oak 1.7/1.8 using the full build to verify.
Most of the build breakages are due to a bundle being release but its reference not being updated, some are subtle. The 9-SNAPSHOT that started this thread is obvious but hard to find. I just fixed the Healthcare IT build because the a bundle included in the Pax exam now needed a different set of imports so the PaxExam startup failed. That indicates the last release of HC might have been done without running the ITs. Oak Server also uses PaxExam, for ITs but it includes the version of Oak using the org.apache.sling.testing.paxexam bundle. Once updated, any bundle that builds using an older version of that bundle wont be testing against the current version of Oak being used by Sling. You could argue, so what, its behind an API, but the point of an IT is to catch the out of band issues not represented in the API. I am tempted to upgrade everything to perform ITs against the current version of Oak (1.7/1.8) in the work I am doing. To recap: IMHO, Sling should be running full builds with all ITs at regular intervals. Ideally anyone doing a release should do the same before and after the release to ensure the released bundle isn't broken and the build is buildable after the release. Best Regards Ian On 11 October 2017 at 20:56, Karl Pauls <karlpa...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <romb...@apache.org> > wrote: > > On Wed, 2017-10-11 at 16:04 +0200, Karl Pauls wrote: > >> On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston <i...@tfd.co.uk> wrote: > >> > Hi, > >> > > >> > On 11 October 2017 at 11:21, Robert Munteanu <romb...@apache.org> > >> > wrote: > >> > > >> > > Hi Ian, > >> > > > >> > > On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote: > >> > > > Hi, > >> > > > Could be me. > >> > > > I do mvn clean install on a clean Sling checkout with a clean > >> > > > maven > >> > > > repo > >> > > > and I get failiures to download slingfeature:9-SNAPSHOT > >> > > > required by > >> > > > an IT > >> > > > test sample. This happens before the reactor starts. > >> > > > >> > > Fixed in http://svn.apache.org/viewvc?rev=1811803&view=revev . > >> > > > >> > > > > >> > > > If I fix that by using slingfeature:9 I then get 11 test > >> > > > failures in > >> > > > commons.log related to the format of the logging output. > >> > > > > >> > > > Is this just me ? > >> > > > > >> > > > If it is just me, I can disable tests there to move on. > >> > > > >> > > I am not sure anyone is building the full reactor anymore > >> > > >> > > >> > > >> > Isnt that a bit dangerous ? > >> > Not being able to reliably build Sling could allow a failure to go > >> > for > >> > months without being noticed using old snapshot builds from other > >> > modules. > >> > > >> > I assume no one is building all of Sling because it takes too long > >> > now ? > >> > >> > >> Carsten and I did sit down semi-regularly and got it back building. > >> Not sure when we did that last but it can't be more than a month or > >> two. > >> > >> I agree that this is not a good state to be in. > >> > >> regards, > >> > >> Karl > > > > Would it help if we added weekly builds for all modules, irrespective > > if any changes are present? > > Yes, I think that would be a good start. Ultimately, I still think we > should get this "run integration tests with all bundles set to > SNAPSHOT build" working but until we have that we might as well make > sure we run the reactor every once in a while. Would that be hard to > do? > > regards, > > Karl > > > Robert > > > > -- > Karl Pauls > karlpa...@gmail.com >
