[ 
https://issues.apache.org/jira/browse/BIGTOP-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974446#comment-13974446
 ] 

jay vyas edited comment on BIGTOP-1201 at 4/18/14 8:30 PM:
-----------------------------------------------------------

Hi Cos:  Okay finally got to play with this. 

- it works ! I can do "gradle" and it prints all build options.  AWESOME !
- I did a basic test "gradle mahout-download", and it also worked : I saw the 
mahout tarfile downloaded into the .dl/ directory. 

So 4 initial thoughts :

- I think now with both "bigtop.mk" "packages.gradle" and "build.gradle" all 
floating around in the top level, the README definetly needs an update. 

- I see your calling "mvn ..." inside of build.gradle.  Is there a non-command 
line way to invoke maven from gradle?  more just a curiosity than anything 
else.  Seems like it would be nice to just require gradle and nothing else, if 
thats possible.

- What other things should i do to test this patch?  Im just now learning about 
the bigtop packaging stuff and so don't really know where i should poke at it 
.... 

- Shall we create a follow up JIRA of next steps which follow this, (i.e. the 
DEB stuff)  as part of pushing this one in?


was (Author: jayunit100):
Hi Cos:  Okay finally got to play with this. 

- it works ! I can do "gradle" and it prints all build options.  AWESOME !
- I did a basic test "gradle mahout-download", and it also worked : I saw the 
mahout tarfile downloaded into the .dl/ directory. 

So three initial thoughts : 

- I think now with both "bigtop.mk" "packages.gradle" and "build.gradle" all 
floating around in the top level, the README definetly needs an update. 

- I see your calling "mvn ..." inside of build.gradle.  Is there a non-command 
line way to invoke maven from gradle?  more just a curiosity than anything 
else.  Seems like it would be nice to just require gradle and nothing else, if 
thats possible.

- What other things should i do to test this patch?  Im just now learning about 
the bigtop packaging stuff and so don't really know where i should poke at it 
.... 

- Shall we create a follow up JIRA of next steps which follow this, (i.e. the 
DEB stuff)  as part of pushing this one in?

> Enchance 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
>
>
> 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)

Reply via email to