[
https://issues.apache.org/jira/browse/BIGTOP-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138031#comment-14138031
]
Mark Grover commented on BIGTOP-1373:
-------------------------------------
Thanks, Roman.
Here are my thoughts:
{quote}
we already agree that Makefile-based builds are getting removed in 0.9.0. No
point in massaging that functionality.
{quote}
That'd be fine by me but since we have the change made to Makefile as well, I
can't see it hurting if we commit that.
{quote}
in our current Gradle-based infrastructure everything is keyed-off of the URL
and hence is trivial to add custom logic to handle different types of protocols
(even imaginary ones).
{quote}
The reason I have favored a separate makefile from day 1 is because of my
personal desire to make Apache Bigtop a better integration platform for the
ecosystem. I think given that we currently bundle released apache components
prevents us from catching Integration issues in other projects before they are
released.
Here is what I am thinking and may be there are other ways of achieving the
same and if you have alternatives, I'd love to hear.
I personally would like to see this change being done in a backwards compatible
manner which means nothing in the way we build or test our Bigtop stack should
change. If we were to use the same properties from existing bigtop.mk then we
can either do the regular Bigtop build that downloads the existing releases of
Apache projects and packages/tests them, or we can do a Bigtop build of
projects pulled down from the trunk of their github repos. But, more
importantly, to switch between the two, one would have to make code changes to
bigtop.mk. I think it would be great to have the ability to build both the
status quo builds and the component trunk based builds using the exact same
code in the repo. I can think of 2 ways we can possibly do that:
1. We can introduce new properties in the existing bigtop.mk file but that's
more than just an extra _SITE variable because we would also need to update the
PKG_VERSION etc. based on what the trunk is pointing to.
2. We can introduce a separately bigtop.mk file and add functionality in our
Makefile/Gradle scripts to override which makefile gets used. That way we could
have a jenkins job that would build every night off of component trunks and
nothing in the existing workflow changes.
So, I preferred #2, which is what I think this JIRA intends to do. Does that
make sense?
> Add a mechanism of obtaining source for components from SCM
> -----------------------------------------------------------
>
> Key: BIGTOP-1373
> URL: https://issues.apache.org/jira/browse/BIGTOP-1373
> Project: Bigtop
> Issue Type: Improvement
> Reporter: Julien Eid
> Attachments: BIGTOP-1373-extrafile.patch,
> BIGTOP-1373-noextrafile.patch, BIGTOP-1373.patch
>
>
> This was brought up here (https://issues.apache.org/jira/browse/BIGTOP-1363)
> as a much wanted feature for our build system so we can build against
> branches. I have two approaches to doing this that I'll be posting up Patch
> files for and seeing which approach everyone likes better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
