For as long as we support building components from GitHub repository by SHA, we must support the local install steps in do-component-build scripts. Otherwise the result cannot be transitively consistent.
We should not assume a Bigtop user will be building with a BOM full of conveniently already released artifacts in public Maven repos (see above), or even with direct access to public networks. It would be inconvenient but I could see an extra 'getting started' step of setting up a local Nexus or similar. However, when building from SHAs on a dev workstation the local Maven cache seems actually the best option. Alternatively, we can declare this use case is no longer supported. That would make me sad. Would also be great if we can continue supporting Bigtop package builds on build servers and developer workstations without requiring any specific containerization technology (or any containerization at all). Giving people an option to use Docker specific techniques is fine as long as it is totally optional. On Fri, Jun 19, 2015 at 11:26 PM, Bruno Mahé <bm...@apache.org> wrote: > Echoing both Nate and Evans, I would not limit ourselves based on the > technology used for the build. > > However, I am not sure to completely follow option 3. We are doing that > already for packages. For instance if package A depends on Apache > Zookeeper., then the package A does depend on Apache Zookeeper and includes > symlinks to the Apache Zookeeper library provided by the Apache Zookeeper > package. > > > Thanks, > Bruno > > > > On 06/19/2015 12:47 PM, n...@reactor8.com wrote: > > Echoing Evans, think we should not be worried about stateless vs > non-stateless containers.., seems core idea and need to is optimize the > build process and maximize re-use whether on host or container machines or > build environments. > > > > Added sub-task with Olaf’s idea to Evans umbrella CI task, currently > marked it for 1.1: > > > > https://issues.apache.org/jira/browse/BIGTOP-1906 > > > > > > > > *From:* Evans Ye [mailto:evan...@apache.org <evan...@apache.org>] > *Sent:* Friday, June 19, 2015 7:16 AM > *To:* user@bigtop.apache.org > *Subject:* Re: Rebooting the conversation on the Future of bigtop: > Abstracting the backplane ? Containers? > > > > I thnk it's not a problem that container is not stateless. No matter how > we should have CI jobs that builds all the artifacts and store them as > official repos. > You point out an important thing that is the mvn install is the key > feature to propergate self patched components around. If we disable this > than there's no reason to build jars by ourselves. I'm +1 to option 2. > > 2015年6月19日 上午5:59於 "Olaf Flebbe" <o...@oflebbe.de>寫道： > > > > Am 18.06.2015 um 23:57 schrieb jay vyas <jayunit100.apa...@gmail.com>: > > > > You can easily share the artifacts with a docker shared volume > > > > in the container "EXPORT M2_HOME=/container/m2/" > > > > follwed by > > > > "docker build -v ~/.m2/ /container/m2/ ........ " > > > > This will put the mvn jars into the host rather than the guest > conatainer, so that they persist. > > > > > > Thats not the point. Containers are not stateless any more. > > Olaf > > >
