Hi,
On 12 October 2017 at 11:52, Robert Munteanu <romb...@apache.org> wrote: > Hi Ian, > > On Thu, 2017-10-12 at 11:26 +0100, Ian Boston wrote: > > 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. > > I'll set the Jenkins jobs to also build regularly. Note that a full > reactor build is not something I am keen on doing since: > > - it takes a long time > - if one module in the reactor fails the build is aborted > Would --fail-at-end work ? Best Regards Ian > > Therefore I think it's best to keep the individual builds, but > configure them to build periodically as well as on changes. > > https://issues.apache.org/jira/browse/SLING-7191 > > If you think this is not enough or we find scenarios that it does not > cover we can revisit the change. > > Thanks, > > Robert > > > > > 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.or > > > g> > > > 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 <rombert@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=reve > > > > > > > v . > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > >
