Sling build broken for me.

[Ian Boston <ie...@tfd.co.uk>]

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.

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.

Best Regards
Ian

Re: Sling build broken for me.

[Robert Munteanu <ro...@apache.org>]

On Wed, 2017-10-11 at 21:56 +0200, Karl Pauls wrote:
> > 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?

Well, run all ITs with bundles set to snapshots will only affect
bundles that are present in the launchpad - and not all of them are.

Not sure how hard that would be to do, last time I got lost in
dependency resolution in the plugin :-) I don't have any plans to look
into it in the short term.

Robert

Re: Sling build broken for me.

[Robert Munteanu <ro...@apache.org>]

On Thu, 2017-10-12 at 12:54 +0100, Ian Boston wrote:
> > 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

It would work in a limited manner. If a module that is a dependency for
other modules fails, the dependant modules would be banned from the
reactor.

Robert

Re: Sling build broken for me.

[Ian Boston <ie...@tfd.co.uk>]

Hi,



On 12 October 2017 at 11:52, Robert Munteanu <ro...@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 <ka...@gmail.com> wrote:
> >
> > > On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <rombert@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 <ie...@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
> > > karlpauls@gmail.com
> > >
>
>

Re: Sling build broken for me.

[Robert Munteanu <ro...@apache.org>]

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

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 <ka...@gmail.com> wrote:
> 
> > On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <rombert@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 <ie...@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
> > karlpauls@gmail.com
> > 

Re: Sling build broken for me.

[Ian Boston <ie...@tfd.co.uk>]

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 <ka...@gmail.com> wrote:

> On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <ro...@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 <ie...@tfd.co.uk> wrote:
> >> > Hi,
> >> >
> >> > On 11 October 2017 at 11:21, Robert Munteanu <ro...@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
> karlpauls@gmail.com
>

Re: Sling build broken for me.

[Karl Pauls <ka...@gmail.com>]

On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <ro...@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 <ie...@tfd.co.uk> wrote:
>> > Hi,
>> >
>> > On 11 October 2017 at 11:21, Robert Munteanu <ro...@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
karlpauls@gmail.com

Re: Sling build broken for me.

[Robert Munteanu <ro...@apache.org>]

On Wed, 2017-10-11 at 16:04 +0200, Karl Pauls wrote:
> On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > Hi,
> > 
> > On 11 October 2017 at 11:21, Robert Munteanu <ro...@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?

Robert

Re: Sling build broken for me.

[Karl Pauls <ka...@gmail.com>]

On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Hi,
>
> On 11 October 2017 at 11:21, Robert Munteanu <ro...@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=rev .
>>
>> >
>> > 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

>
>> - we are
>> building individual modules on Jenkins [1].
>>
>> commons.log builds fine for me as an individual module and I don't see
>> it failing on Jenkins either.
>>
>> If there's a consistent failure at your end, please file a bug.
>
>
>
> Both commons log and commons log webconsole fail performing PaxExam ITs,
> reliably. Normal Unit tests are Ok.
> JDK 1.8.0
> Maven 3.5.0
>
> I have disabled tests in those bundles to move on, assuming its something
> strange about my box.
>
> Best Regards
> Ian
>
>
>
>> But for
>> getting the launchpad up and running only need to build
>> launchpad/builder/ - all depenendencies are releases therefore the
>> reactor build is not used.
>>
>> Thanks,
>>
>> Robert
>>
>>
>> [1]: https://builds.apache.org/view/S-Z/view/Sling/
>>



-- 
Karl Pauls
karlpauls@gmail.com

Re: Sling build broken for me.

[Ian Boston <ie...@tfd.co.uk>]

Hi,

On 11 October 2017 at 11:21, Robert Munteanu <ro...@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=rev .
>
> >
> > 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 ?



> - we are
> building individual modules on Jenkins [1].
>
> commons.log builds fine for me as an individual module and I don't see
> it failing on Jenkins either.
>
> If there's a consistent failure at your end, please file a bug.



Both commons log and commons log webconsole fail performing PaxExam ITs,
reliably. Normal Unit tests are Ok.
JDK 1.8.0
Maven 3.5.0

I have disabled tests in those bundles to move on, assuming its something
strange about my box.

Best Regards
Ian



> But for
> getting the launchpad up and running only need to build
> launchpad/builder/ - all depenendencies are releases therefore the
> reactor build is not used.
>
> Thanks,
>
> Robert
>
>
> [1]: https://builds.apache.org/view/S-Z/view/Sling/
>

Re: Sling build broken for me.

[Robert Munteanu <ro...@apache.org>]

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=rev .

> 
> 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 - we are
building individual modules on Jenkins [1].

commons.log builds fine for me as an individual module and I don't see
it failing on Jenkins either.

If there's a consistent failure at your end, please file a bug. But for
getting the launchpad up and running only need to build
launchpad/builder/ - all depenendencies are releases therefore the
reactor build is not used.

Thanks,

Robert


[1]: https://builds.apache.org/view/S-Z/view/Sling/