[
https://issues.apache.org/jira/browse/BIGTOP-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated BIGTOP-1201:
---------------------------------------
Attachment: BIGTOP-1201.patch
the answers in the same order:
# fixed
# I don't think so, really. I will dig deeper, but I believe this is one of the
fixed things in Gradle
# I kept current format - and have wrote some of the parsing code - to have
both solutions next to each other, so we can gradually phase out make stuff.
Once it happens, we surely can change the format of the BOM. In fact, we can
totally use Groovy DSL for that, which is a way reacher than JSON or XML; and
it will be a way more straight forward to work with. Wadda think?
# removed. I still have a comment for a TODO - will fill it in a consequent
JIRA is this one is a low priority
# Yes, the replacement of Maven has been planned to be done separately. This
ticket is for packages only. Do you think it is sensible?
> Enhance (gradleize) the build to ease development, deployment; abstract
> implementation
> --------------------------------------------------------------------------------------
>
> Key: BIGTOP-1201
> URL: https://issues.apache.org/jira/browse/BIGTOP-1201
> Project: Bigtop
> Issue Type: Improvement
> Components: Build
> Affects Versions: 0.7.0
> Reporter: Konstantin Boudnik
> Assignee: Konstantin Boudnik
> Fix For: 0.8.0
>
> Attachments: BIGTOP-1201.patch, BIGTOP-1201.patch, BIGTOP-1201.patch,
> BIGTOP-1201.patch, BIGTOP-1201.patch, BIGTOP-1201.patch, BIGTOP-1201.patch,
> BIGTOP-1201.patch, BIGTOP-1201.patch, BIGTOP-1201.patch, BIGTOP-1201.patch,
> BIGTOP-1201.patch, BIGTOP-1201.patch
>
>
> As has been discussed on the multiple occasions different parts of the Bigtop
> framework aren't really well stitched together. It requires a certain level
> of understanding of the project or/and digging across different sources of
> documentation to be able to:
> - build Bigtop framework
> - build and install target artifacts (packages, jars)
> - prepared to develop or test targeted stack
> - enforce all per-requisites consistently
> - coordinate version updates
> - produce documentation
> - <add more here>
> There are isolated attempts to patch the flaw with small pieces of scripting
> band-aids. However, the problem requires more systematic approach, in my
> opinion. What we need to have is a declarative yet flexible build system that
> can
> - short to medium term: wrap isolated pieces of the framework and provide a
> single entry point to building, developing, deployment, and testing
> - long term: consolidate all bits of the framework in one comprehensive
> build management system
> An apparent requirements of the solution:
> - it needs to play well with JVM stack
> - it needs to be expressive and declarative to give us flexibility to
> incorporate a number of currently used frameworks (maven, make, puppet) in
> one focal point
> - don't limit our ability to replace (if needed) various bits of current
> framework with something more uniform.
> Behold, I propose Gradle.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
