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]
*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
<mailto:o...@oflebbe.de>>寫道：
> Am 18.06.2015 um 23:57 schrieb jay vyas
<jayunit100.apa...@gmail.com <mailto: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
