You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Shinichiro Abe <sh...@gmail.com> on 2012/04/02 13:07:20 UTC
[VOTE] Release ManifoldCF 0.5-incubating, RC3
Hi,
You can download the release candidate from
http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC3/
and there is also a tag in svn
under https://svn.apache.org/repos/asf/incubator/lcf/tags.
RC3 fixed the following issues:
CONNECTORS-440: Build should exclude integration content from external
sources.
Thank you,
Shinichiro Abe
[WITHDRAW][VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Shinichiro Abe <sh...@gmail.com>.
I'll create RC4 tomorrow.
Shinichiro Abe
On 2012/04/03, at 23:38, Karl Wright wrote:
> Update: I'm just about ready to ask for a new RC that contains the following:
>
> - No checked-in binaries at all
> - A new "XXX-lib" target just containing license files and binaries
> - Patched jars built on the fly from patch files included in the
> source distribution
>
> In order to make all this work, the ant build has been extended with
> the following targets, which replace download-dependencies:
>
> make-core-deps (downloads and/or builds dependent jars and puts them in lib)
> make-deps (downloads proprietary jars)
>
> Thus, to build from source, you need to either:
>
> (1) Unpack source tar, unpack lib tar, and run "ant build", or
> optionally "ant make-deps build"
> (2) Unpack source tar, run "ant make-core-deps", and then either "ant
> build" or "ant make-deps build"
>
> If the make-core-deps target is objectionable, I can of course remove
> it from ant help so it is hidden. It's essential, though, for release
> engineering purposes.
>
> Karl
>
> On Mon, Apr 2, 2012 at 5:25 PM, Karl Wright <da...@gmail.com> wrote:
>> If this is the next thing the community wants to try, I won't stand in
>> the way. I just got the impression that there's more wrong with our
>> build than just including dependent binaries - we also have problems
>> with the dependent binaries themselves in some cases.
>>
>> Nevertheless, should I call a vote on (say) reverting to RC1 and
>> applying the stated shell commands to the resulting artifacts? The
>> commands should also include .wsp files as well as jars, but that is a
>> minor issue.
>>
>> Karl
>>
>>
>> On Mon, Apr 2, 2012 at 3:42 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Mon, Apr 2, 2012 at 8:15 PM, Karl Wright <da...@gmail.com> wrote:
>>>> Possible solutions include:
>>>
>>> There's also the alternative that I brought up earlier:
>>>
>>> (5) Extract all dependencies from the existing pre-CONNECTORS-437
>>> source tree to a separate -lib package like this:
>>>
>>> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
>>> $ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt
>>> $ echo apache-manifoldcf-0.5-incubating/LICENSE.txt >> lib.txt
>>> $ echo apache-manifoldcf-0.5-incubating/NOTICE.txt >> lib.txt
>>> $ tar zcf apache-manifoldcf-0.5-incubating-lib.tar.gz -T lib.txt
>>>
>>> We can then publish that -lib package along with the official source
>>> release and include build instructions like the following:
>>>
>>> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
>>> $ tar zxf apache-manifoldcf-0.5-incubating-lib.tar.gz
>>> $ cd apache-manifoldcf-0.5-incubating
>>> $ ant build
>>>
>>> That gives us something that's immediately releasable even with the
>>> newly reinterpreted Apache rules. And it gives us more time and
>>> breathing room for following up on the various improvement ideas that
>>> in terms of simplifying the build and the way dependencies are handled
>>> would make sense even regardless of policy requirements.
>>>
>>> BR,
>>>
>>> Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
Update: I'm just about ready to ask for a new RC that contains the following:
- No checked-in binaries at all
- A new "XXX-lib" target just containing license files and binaries
- Patched jars built on the fly from patch files included in the
source distribution
In order to make all this work, the ant build has been extended with
the following targets, which replace download-dependencies:
make-core-deps (downloads and/or builds dependent jars and puts them in lib)
make-deps (downloads proprietary jars)
Thus, to build from source, you need to either:
(1) Unpack source tar, unpack lib tar, and run "ant build", or
optionally "ant make-deps build"
(2) Unpack source tar, run "ant make-core-deps", and then either "ant
build" or "ant make-deps build"
If the make-core-deps target is objectionable, I can of course remove
it from ant help so it is hidden. It's essential, though, for release
engineering purposes.
Karl
On Mon, Apr 2, 2012 at 5:25 PM, Karl Wright <da...@gmail.com> wrote:
> If this is the next thing the community wants to try, I won't stand in
> the way. I just got the impression that there's more wrong with our
> build than just including dependent binaries - we also have problems
> with the dependent binaries themselves in some cases.
>
> Nevertheless, should I call a vote on (say) reverting to RC1 and
> applying the stated shell commands to the resulting artifacts? The
> commands should also include .wsp files as well as jars, but that is a
> minor issue.
>
> Karl
>
>
> On Mon, Apr 2, 2012 at 3:42 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Apr 2, 2012 at 8:15 PM, Karl Wright <da...@gmail.com> wrote:
>>> Possible solutions include:
>>
>> There's also the alternative that I brought up earlier:
>>
>> (5) Extract all dependencies from the existing pre-CONNECTORS-437
>> source tree to a separate -lib package like this:
>>
>> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
>> $ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt
>> $ echo apache-manifoldcf-0.5-incubating/LICENSE.txt >> lib.txt
>> $ echo apache-manifoldcf-0.5-incubating/NOTICE.txt >> lib.txt
>> $ tar zcf apache-manifoldcf-0.5-incubating-lib.tar.gz -T lib.txt
>>
>> We can then publish that -lib package along with the official source
>> release and include build instructions like the following:
>>
>> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
>> $ tar zxf apache-manifoldcf-0.5-incubating-lib.tar.gz
>> $ cd apache-manifoldcf-0.5-incubating
>> $ ant build
>>
>> That gives us something that's immediately releasable even with the
>> newly reinterpreted Apache rules. And it gives us more time and
>> breathing room for following up on the various improvement ideas that
>> in terms of simplifying the build and the way dependencies are handled
>> would make sense even regardless of policy requirements.
>>
>> BR,
>>
>> Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
If this is the next thing the community wants to try, I won't stand in
the way. I just got the impression that there's more wrong with our
build than just including dependent binaries - we also have problems
with the dependent binaries themselves in some cases.
Nevertheless, should I call a vote on (say) reverting to RC1 and
applying the stated shell commands to the resulting artifacts? The
commands should also include .wsp files as well as jars, but that is a
minor issue.
Karl
On Mon, Apr 2, 2012 at 3:42 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Mon, Apr 2, 2012 at 8:15 PM, Karl Wright <da...@gmail.com> wrote:
>> Possible solutions include:
>
> There's also the alternative that I brought up earlier:
>
> (5) Extract all dependencies from the existing pre-CONNECTORS-437
> source tree to a separate -lib package like this:
>
> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
> $ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt
> $ echo apache-manifoldcf-0.5-incubating/LICENSE.txt >> lib.txt
> $ echo apache-manifoldcf-0.5-incubating/NOTICE.txt >> lib.txt
> $ tar zcf apache-manifoldcf-0.5-incubating-lib.tar.gz -T lib.txt
>
> We can then publish that -lib package along with the official source
> release and include build instructions like the following:
>
> $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
> $ tar zxf apache-manifoldcf-0.5-incubating-lib.tar.gz
> $ cd apache-manifoldcf-0.5-incubating
> $ ant build
>
> That gives us something that's immediately releasable even with the
> newly reinterpreted Apache rules. And it gives us more time and
> breathing room for following up on the various improvement ideas that
> in terms of simplifying the build and the way dependencies are handled
> would make sense even regardless of policy requirements.
>
> BR,
>
> Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Apr 2, 2012 at 8:15 PM, Karl Wright <da...@gmail.com> wrote:
> Possible solutions include:
There's also the alternative that I brought up earlier:
(5) Extract all dependencies from the existing pre-CONNECTORS-437
source tree to a separate -lib package like this:
$ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
$ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt
$ echo apache-manifoldcf-0.5-incubating/LICENSE.txt >> lib.txt
$ echo apache-manifoldcf-0.5-incubating/NOTICE.txt >> lib.txt
$ tar zcf apache-manifoldcf-0.5-incubating-lib.tar.gz -T lib.txt
We can then publish that -lib package along with the official source
release and include build instructions like the following:
$ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz
$ tar zxf apache-manifoldcf-0.5-incubating-lib.tar.gz
$ cd apache-manifoldcf-0.5-incubating
$ ant build
That gives us something that's immediately releasable even with the
newly reinterpreted Apache rules. And it gives us more time and
breathing room for following up on the various improvement ideas that
in terms of simplifying the build and the way dependencies are handled
would make sense even regardless of policy requirements.
BR,
Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
Hi folks,
As for the last pile of revisions, which download dependencies from
Maven or SVN depending, Jukka and I agreed that we'll also need either
a dependencies artifact or a source + dependencies artifact. How we
get the dependencies in the first place, though, is still unclear, so
we decided to put the question to infrastructure@apache.org to find
out their opinion of whether downloading binaries from svn was
acceptable. I did not get a clear answer to that, but I can say the
following:
(1) There is a clear level of discomfort about storing ANY binaries in
apache infrastructure.
(2) For patched dependent releases, the recommended process is to
download source tar/zip, unpack it, apply patches, and build it, all
as part of the build process for the main release.
(3) For those releases that simply do not exist at all in Maven, the
ideal process is to download the sources and build them.
The problems, then, are as follows:
(1) ManifoldCF binary distributions include packages which can only be
built on specific architectures. For example, the SharePoint 3.0 mcf
plugin.
(2) Patching of source cannot be done in a standard way on both
Windows and Linux, other than within an SVN checkout (via svn patch).
(3) There may be some binary dependencies whose sources are hard to
get hold of, e.g. jdbcpool-0.99.jar, which are also not found in
Maven.
Possible solutions include:
(1) Only patch sources that we can check out via svn. This implies
that, during the build process, instead of checking out a single
binary, we check out an entire source tree. Then we can apply the
patch. Downside: svn access required during build.
(2) Remove the dependency on anything we find we can't get the sources
for, such as jdbcpool-0.99. Downside: requires significant code
changes.
(3) Check in the binaries for all platform-dependent builds into
googlecode. Downside: Not clear whether the Incubator will consider
this reasonable.
(4) Require that builds only take place on Windows machines with
appropriate Windows tools and upstream dependencies installed.
Downside: Essentially a non-starter.
Obviously all of this will greatly complicate the build and release
process for ManifoldCF, if indeed there is exists an "acceptable"
solution at all. I honestly don't have a workable answer in mind at
this point for all of the new constraints we're dealing with.
Karl
On Mon, Apr 2, 2012 at 10:02 AM, Karl Wright <da...@gmail.com> wrote:
> My major concern with the release of binaries through the standard
> Apache channel is that we then effectively have another release that
> must be synchronized with the main release, since the non-maven
> binaries are not, by definition, part of the main release.
>
> I set bin-dist up with that in mind, so that it can effectively remain
> unversioned, and be "add only".
>
> If there is no other choice than parallel releases of binaries and
> source, with a separation of binaries and source in the svn tree, then
> I will have to think through the best solution. Certainly we will
> have to treat binaries from different sources differently. For
> example, all of the following would potentially need a different
> solution:
>
> (1) Stuff that's available from maven that is license-compatible with Apache
> (2) Stuff that's available from maven that is NOT license-compatible with Apache
> (3) Stuff that's not available from maven that is license-compatible with Apache
> (4) Stuff that's not available from maven that is not
> license-compatible with Apache
>
> We could not package dependencies that are (2) or (4). We would
> *have* to package (3), but not necessarily (1).
>
> Is this making your head spin yet? Mine is...
>
> An svn-based download is technically little different than a source
> checkout, seems to me, which is why I wonder why we would make a
> distinction at all.
>
> Karl
>
>
>
>
>
> On Mon, Apr 2, 2012 at 9:49 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Apr 2, 2012 at 2:31 PM, Karl Wright <da...@gmail.com> wrote:
>>> The only other potential problem is that the
>>> license/notice/dependencies files may not conform strictly to
>>> incubator guidelines. Specifically, we are not including a different
>>> set of files with a bin release vs. a source release, and also it was
>>> unclear whether our format (which was once again based on Lucene/Solr)
>>> is still acceptable or not. The thread in general@i.a.o provided some
>>> examples, but it is not clear whether those were the ONLY acceptable
>>> formats. I am hoping for Jukka and Tommaso's feedback here before we
>>> present this artifact to the incubator.
>>
>> Ideally the licensing metadata (i.e. the LICENSE and NOTICE files)
>> should only cover material contained in that specific package. See [1]
>> for a related discussion from a few years ago. At least back then it
>> seemed acceptable for a project to also only maintain a single set of
>> license metadata that covers the contents of both source and binary
>> distributions. AFAIUI that approach is in use by many Apache projects.
>>
>> About the RC more generally, I find the download-via-svn target a bit
>> troublesome as it makes the release depend on content in svn. That
>> essentially turns the svn server into a release distribution channel,
>> which it definitely shouldn't be.
>>
>> I think it's fine to manage the set of binary dependencies (that
>> aren't available in a stable third party location like Maven Central)
>> in svn, but a release should not try to access them from there.
>> Instead we should for example package them up in a separate -lib or
>> -deps archive and make it available for download along with the source
>> release through the standard Apache mirroring network. That archive
>> should also come with appropriate licensing metadata that's currently
>> lacking in bin-dist.
>>
>> [1] http://markmail.org/message/bttmkavpicxxg7gl
>>
>> BR,
>>
>> Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
My major concern with the release of binaries through the standard
Apache channel is that we then effectively have another release that
must be synchronized with the main release, since the non-maven
binaries are not, by definition, part of the main release.
I set bin-dist up with that in mind, so that it can effectively remain
unversioned, and be "add only".
If there is no other choice than parallel releases of binaries and
source, with a separation of binaries and source in the svn tree, then
I will have to think through the best solution. Certainly we will
have to treat binaries from different sources differently. For
example, all of the following would potentially need a different
solution:
(1) Stuff that's available from maven that is license-compatible with Apache
(2) Stuff that's available from maven that is NOT license-compatible with Apache
(3) Stuff that's not available from maven that is license-compatible with Apache
(4) Stuff that's not available from maven that is not
license-compatible with Apache
We could not package dependencies that are (2) or (4). We would
*have* to package (3), but not necessarily (1).
Is this making your head spin yet? Mine is...
An svn-based download is technically little different than a source
checkout, seems to me, which is why I wonder why we would make a
distinction at all.
Karl
On Mon, Apr 2, 2012 at 9:49 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Mon, Apr 2, 2012 at 2:31 PM, Karl Wright <da...@gmail.com> wrote:
>> The only other potential problem is that the
>> license/notice/dependencies files may not conform strictly to
>> incubator guidelines. Specifically, we are not including a different
>> set of files with a bin release vs. a source release, and also it was
>> unclear whether our format (which was once again based on Lucene/Solr)
>> is still acceptable or not. The thread in general@i.a.o provided some
>> examples, but it is not clear whether those were the ONLY acceptable
>> formats. I am hoping for Jukka and Tommaso's feedback here before we
>> present this artifact to the incubator.
>
> Ideally the licensing metadata (i.e. the LICENSE and NOTICE files)
> should only cover material contained in that specific package. See [1]
> for a related discussion from a few years ago. At least back then it
> seemed acceptable for a project to also only maintain a single set of
> license metadata that covers the contents of both source and binary
> distributions. AFAIUI that approach is in use by many Apache projects.
>
> About the RC more generally, I find the download-via-svn target a bit
> troublesome as it makes the release depend on content in svn. That
> essentially turns the svn server into a release distribution channel,
> which it definitely shouldn't be.
>
> I think it's fine to manage the set of binary dependencies (that
> aren't available in a stable third party location like Maven Central)
> in svn, but a release should not try to access them from there.
> Instead we should for example package them up in a separate -lib or
> -deps archive and make it available for download along with the source
> release through the standard Apache mirroring network. That archive
> should also come with appropriate licensing metadata that's currently
> lacking in bin-dist.
>
> [1] http://markmail.org/message/bttmkavpicxxg7gl
>
> BR,
>
> Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Apr 2, 2012 at 2:31 PM, Karl Wright <da...@gmail.com> wrote:
> The only other potential problem is that the
> license/notice/dependencies files may not conform strictly to
> incubator guidelines. Specifically, we are not including a different
> set of files with a bin release vs. a source release, and also it was
> unclear whether our format (which was once again based on Lucene/Solr)
> is still acceptable or not. The thread in general@i.a.o provided some
> examples, but it is not clear whether those were the ONLY acceptable
> formats. I am hoping for Jukka and Tommaso's feedback here before we
> present this artifact to the incubator.
Ideally the licensing metadata (i.e. the LICENSE and NOTICE files)
should only cover material contained in that specific package. See [1]
for a related discussion from a few years ago. At least back then it
seemed acceptable for a project to also only maintain a single set of
license metadata that covers the contents of both source and binary
distributions. AFAIUI that approach is in use by many Apache projects.
About the RC more generally, I find the download-via-svn target a bit
troublesome as it makes the release depend on content in svn. That
essentially turns the svn server into a release distribution channel,
which it definitely shouldn't be.
I think it's fine to manage the set of binary dependencies (that
aren't available in a stable third party location like Maven Central)
in svn, but a release should not try to access them from there.
Instead we should for example package them up in a separate -lib or
-deps archive and make it available for download along with the source
release through the standard Apache mirroring network. That archive
should also come with appropriate licensing metadata that's currently
lacking in bin-dist.
[1] http://markmail.org/message/bttmkavpicxxg7gl
BR,
Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
I checked out the bin.zip package; all looked good. I opened one
ticket about a minor problem (CONNECTORS-442) which is that the bin
packages include ant and maven build scripts, but that's not enough to
block release.
The only other potential problem is that the
license/notice/dependencies files may not conform strictly to
incubator guidelines. Specifically, we are not including a different
set of files with a bin release vs. a source release, and also it was
unclear whether our format (which was once again based on Lucene/Solr)
is still acceptable or not. The thread in general@i.a.o provided some
examples, but it is not clear whether those were the ONLY acceptable
formats. I am hoping for Jukka and Tommaso's feedback here before we
present this artifact to the incubator.
Otherwise, +1 from me.
Karl
On Mon, Apr 2, 2012 at 8:12 AM, Karl Wright <da...@gmail.com> wrote:
> At first glance it looks like the bin packages are complete;
> apparently I must have inadvertantly included something else in my bin
> packages when I built them (they were 175M each). Trying it out
> now...
>
> Karl
>
>
> On Mon, Apr 2, 2012 at 8:05 AM, Karl Wright <da...@gmail.com> wrote:
>> Hi Abe-san,
>>
>> The bin packages look much smaller than the ones I built here when I
>> was testing things out. Did you remember to include the proprietary
>> materials before you built the RC?
>>
>> I'm about to unpack the bin.zip to see if my suspicion is warranted...
>>
>> Karl
>>
>> On Mon, Apr 2, 2012 at 7:07 AM, Shinichiro Abe
>> <sh...@gmail.com> wrote:
>>> Hi,
>>>
>>> You can download the release candidate from
>>> http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC3/
>>> and there is also a tag in svn
>>> under https://svn.apache.org/repos/asf/incubator/lcf/tags.
>>>
>>> RC3 fixed the following issues:
>>> CONNECTORS-440: Build should exclude integration content from external
>>> sources.
>>>
>>> Thank you,
>>> Shinichiro Abe
>>>
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
At first glance it looks like the bin packages are complete;
apparently I must have inadvertantly included something else in my bin
packages when I built them (they were 175M each). Trying it out
now...
Karl
On Mon, Apr 2, 2012 at 8:05 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Abe-san,
>
> The bin packages look much smaller than the ones I built here when I
> was testing things out. Did you remember to include the proprietary
> materials before you built the RC?
>
> I'm about to unpack the bin.zip to see if my suspicion is warranted...
>
> Karl
>
> On Mon, Apr 2, 2012 at 7:07 AM, Shinichiro Abe
> <sh...@gmail.com> wrote:
>> Hi,
>>
>> You can download the release candidate from
>> http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC3/
>> and there is also a tag in svn
>> under https://svn.apache.org/repos/asf/incubator/lcf/tags.
>>
>> RC3 fixed the following issues:
>> CONNECTORS-440: Build should exclude integration content from external
>> sources.
>>
>> Thank you,
>> Shinichiro Abe
>>
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Karl Wright <da...@gmail.com>.
Hi Abe-san,
The bin packages look much smaller than the ones I built here when I
was testing things out. Did you remember to include the proprietary
materials before you built the RC?
I'm about to unpack the bin.zip to see if my suspicion is warranted...
Karl
On Mon, Apr 2, 2012 at 7:07 AM, Shinichiro Abe
<sh...@gmail.com> wrote:
> Hi,
>
> You can download the release candidate from
> http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC3/
> and there is also a tag in svn
> under https://svn.apache.org/repos/asf/incubator/lcf/tags.
>
> RC3 fixed the following issues:
> CONNECTORS-440: Build should exclude integration content from external
> sources.
>
> Thank you,
> Shinichiro Abe
>
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Posted by Shinichiro Abe <sh...@gmail.com>.
+1 from me
I've already checked signatures.
Shinichiro Abe
On 2012/04/02, at 20:07, Shinichiro Abe wrote:
> Hi,
>
> You can download the release candidate from
> http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC3/
> and there is also a tag in svn
> under https://svn.apache.org/repos/asf/incubator/lcf/tags.
>
> RC3 fixed the following issues:
> CONNECTORS-440: Build should exclude integration content from external
> sources.
>
> Thank you,
> Shinichiro Abe
>