Mailing-List: contact dev-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sling.apache.org
Message-ID: <1507805576.28700.27.camel@apache.org>
Subject: Re: Sling build broken for me.
From: Robert Munteanu <rombert@apache.org>
To: dev@sling.apache.org
Date: Thu, 12 Oct 2017 13:52:56 +0300
In-Reply-To: <CAH=Gj-kCs4Vsg0_v53RWLbX8harnk_7E0bvt6GroxhGff8cjOQ@mail.gmail.com>
References: 
	<CAH=Gj-=Gs=nLV3CK0Rbab4zk2VAek63G7SfEoimfhnUurS9Hcw@mail.gmail.com>
	 <1507717290.28700.2.camel@apache.org>
	 <CAH=Gj-mMgZvFqY2nVgBeDvkA9tkp9iAb9L=Y3QEwV3ozB2W9Fw@mail.gmail.com>
	 <CAJnwQNhd232zOLASJZfa+TGouAmJCXS+peUWhvZa4F2DMVRnmA@mail.gmail.com>
	 <1507738042.28700.12.camel@apache.org>
	 <CAJnwQNg7h8ub=roiC7tzNfeEmpK2K9-zwdSv1mfpeG=c48kCbg@mail.gmail.com>
	 <CAH=Gj-kCs4Vsg0_v53RWLbX8harnk_7E0bvt6GroxhGff8cjOQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
archived-at: Thu, 12 Oct 2017 10:53:03 -0000

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 <karlpauls@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 <ieb@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
> >