[
https://issues.apache.org/jira/browse/YETUS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15243350#comment-15243350
]
Allen Wittenauer edited comment on YETUS-369 at 4/15/16 6:19 PM:
-----------------------------------------------------------------
I've been rolling this around in my head.
I'm going to tentatively put this for 0.4.0. I want to revisit personalities
vs. projects and giving them more functionality as well as being able to be
used simultaneously. (e.g., given a JIRA issue of HBASE-1, Yetus should be
able to automatically load the settings from hbase without being told). It's
going to be a WILDLY incompatible change and I'd rather not hold back 0.3.0 to
get it in there.
One of the things I wanted to do as part of that was enable a per-branch build
tool setting, since many projects change tools in their lifetime. Having a JVM
setting per-branch fits right in line with that.
One of the trickier parts of this, however, is the difference between file
location vs. JVM version. As a result, this request will likely need to morph
into "compatible JVMs" per branch. In other words, the --multijdkdirs option
lists several JVMs and the per-branch setting would filter out the ones that
are known not to work/be compatible/whatever. For example, if
--multijdkdirs=oracle-6-jdk,oracle-7-jdk,oracle-8-jdk and 'master' is only
compatible with JVMs 1.7 and 1.8, yetus will filter out the oracle-6-jdk from
multijdkdirs (after giving a warning, ofc). How this interacts with JAVA_HOME
is unknown, but I could imagine it being similar to just force setting it to
the lowest version. (Then come the issues of "what if there are multiple
lowest".. *sigh*)
was (Author: aw):
I've been rolling this around in my head.
I'm going to tentatively put this for 0.4.0. I want to revisit personalities
vs. projects and giving them more functionality as well as being able to be
used simultaneously. (e.g., given a JIRA issue of HBASE-1, Yetus should be
able to automatically load the settings from hbase without being told).
One of the things I wanted to do as part of that was enable a per-branch build
tool setting, since many projects change tools in their lifetime. Having a JVM
setting per-branch fits right in line with that.
One of the trickier parts of this, however, is the difference between file
location vs. JVM version. As a result, this request will likely need to morph
into "compatible JVMs" per branch. In other words, the --multijdkdirs option
lists several JVMs and the per-branch setting would filter out the ones that
are known not to work/be compatible/whatever. For example, if
--multijdkdirs=oracle-6-jdk,oracle-7-jdk,oracle-8-jdk and 'master' is only
compatible with JVMs 1.7 and 1.8, yetus will filter out the oracle-6-jdk from
multijdkdirs (after giving a warning, ofc). How this interacts with JAVA_HOME
is unknown, but I could imagine it being similar to just force setting it to
the lowest version. (Then come the issues of "what if there are multiple
lowest".. *sigh*)
> Allow setting multijdk by branch; e.g. jdk8 for master branch but jdk7 for
> older branches
> ------------------------------------------------------------------------------------------
>
> Key: YETUS-369
> URL: https://issues.apache.org/jira/browse/YETUS-369
> Project: Yetus
> Issue Type: Improvement
> Reporter: stack
> Fix For: 0.4.0
>
>
> Over in hbase, we'd like to have our master branch be jdk8 only but for older
> branches from which we are still making releases, we'd like to default jdk7.
> Mighty [~busbey] notes that this is not possible currently in yetus so am
> filing that I foresee projects needing this facility of yovely yetus.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
