You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "RJ Nowling (JIRA)" <ji...@apache.org> on 2015/02/18 21:05:12 UTC
[jira] [Commented] (BIGTOP-1682) Build BPS Spark against BigTop
Artifacts
[ https://issues.apache.org/jira/browse/BIGTOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326474#comment-14326474 ]
RJ Nowling commented on BIGTOP-1682:
------------------------------------
Some discussion on IRC about the issue:
{noformat}
<cos1> see, the situation with relying on Bigtop Spark binaries and Spark published maven artifacts is exactly what we are trying to avoid, right?
<rnowling> cos1, I agree. I see two challenges:
<cos1> it'd be more consistent if Spark artifacts are the ones that we use in the package?
<rnowling> 1. how do we guarantee compatibility with the versions in BigTop?
<rnowling> 2. how do we make it easy for users who want to use BPS outside of BigTop installs?
<rnowling> I think using BigTop artifacts instead of vanilla artifacts helps with #1
<rnowling> I see a few different options: 1. RPMs install local maven/ivy repos 2. Update BPS gradle to depend on BigTop gradle 3. BigTop publishes its JARs as a Maven repo somewhere
<rnowling> I like #2 best, especially if we users can set a flag for building against BigTop or maven artifacts
<rnowling> (which would solve the easy of use issuers for other deployment environments)
<rnowling> fourth option: I know that sbt allows for a directory of "user managed dependencies" (basically, you copy the JARs to that dir). maybe groovy lets you do something similar?
<rnowling> so then we can just build BigTop JARs, put them in a directory, and in the build system, we can just point to that?
<rnowling> or we ignore the whole issue and keep doing what we're doing :)
<cos1> hmm...
<cos1> lemme think for a sec
<cos1> I think in #4 you meant gradle not groovy, right?
<cos1> Maven has such an option, I believe. So I'd imagine Gradle would too....
<rnowling> cos1, yeah, sorry, yes, gradle
<cos1> I like 2 as well
<cos1> I think it is less intrusive and quite transparent. The only tie would be a need to clone the source repo, but one has to do it anyway ;)
<rnowling> cos1, I like #2 as well but I would want to make it user selectable between vanilla artifacts (via maven central) and BigTop components. in my particular case, I'm deploying BPS on Spark-only cluster as smoke tests
<rnowling> so I need to be able to build BPS spark using vanilla spark artifacts
{noformat}
> Build BPS Spark against BigTop Artifacts
> ----------------------------------------
>
> Key: BIGTOP-1682
> URL: https://issues.apache.org/jira/browse/BIGTOP-1682
> Project: Bigtop
> Issue Type: Improvement
> Components: blueprints
> Affects Versions: 0.9.0
> Reporter: RJ Nowling
>
> As a demo application in BigTop, BPS Spark should be deployable to BigTop. As a result, compatibility with the Spark artifact published by BigTop should be a priority.
> BPS Spark currently builds against upstream, vanilla artifacts published by upstream projects through Maven. This could lead to a situation where BPS Spark is incompatible with the BigTop artifacts or deployments.
> Whatever solution we decide on should consider the following use cases:
> 1. Building & deploying BPS Spark against specific BigTop versions
> 2. Building & deploying BPS Spark against non-BigTop (e.g., upstream) versions
> 3. Ease of building / testing for developers
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)