[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999251#comment-15999251 ] Xiang Li edited comment on HBASE-15199 at 5/9/17 4:18 AM: -- Hi [~busbey] I uploaded a new patch based on the current master branch. I never worked for a patch as "addendum" before, but if it means a patch to contain the diff based on the current status, and does not contain the already committed changes for HBASE-15199, then it is as uploaded. Would you please review? The logic is updated as : (1) for the commands which need jruby (currently shell and org.jruby.Main) A. when JRUBY_HOME is specified explicitly, eg. export JRUBY_HOME=/usr/local/share/jruby CLASSPATH and HBASE_OPTS are updated according to JRUBY_HOME specified B. when JRUBY_HOME is not specified explicitly add jruby packaged with HBase to CLASSPATH (2) for other commands, do nothing was (Author: water): Hi [~busbey] I uploaded a new patch based on the current master branch. I never worked for a patch as "addendum" before, but it means a patch to contain the diff based on the current status, and does not contain the already committed changes for HBASE-15199, then it is as uploaded. Would you please review? The logic is updated as : (1) for the commands which need jruby (currently shell and org.jruby.Main) A. when JRUBY_HOME is specified explicitly, eg. export JRUBY_HOME=/usr/local/share/jruby CLASSPATH and HBASE_OPTS are updated according to JRUBY_HOME specified B. when JRUBY_HOME is not specified explicitly add jruby packaged with HBase to CLASSPATH (2) for other commands, do nothing > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001935#comment-16001935 ] Xiang Li edited comment on HBASE-15199 at 5/9/17 4:17 AM: -- [~busbey] Would you please let me know if I need to do something else for this JIRA? was (Author: water): [~busbey] Would you please let me know if I need to something else for this JIRA? > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999255#comment-15999255 ] Xiang Li edited comment on HBASE-15199 at 5/6/17 3:51 AM: -- I tested it on both Linux and Windows. it took some time 8-) was (Author: water): I tested it on both Linux and Windows. it took some time ^_^ > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199-addendum.master.000.patch, > HBASE-15199.master.001.patch, HBASE-15199.master.002.patch, > HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998488#comment-15998488 ] Sean Busbey edited comment on HBASE-15199 at 5/5/17 3:49 PM: - I think more experienced operators can already manually change things such that JRuby stuff ends up in the server environment. We should stay focused on the path everyone ends up walking down by default. [~water], would you mind putting together the change? An addendum is fine, but if it looks like things will take until sometime next week, then let's do a new JIRA instead. was (Author: busbey): I think more experience operators can already manually change things such that JRuby stuff ends up in the server environment. We should stay focused on the path everyone ends up walking down by default. [~water], would you mind putting together the change? An addendum is fine, but if it looks like things will take until sometime next week, then let's do a new JIRA instead. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch, > HBASE-15199.master.002.patch, HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998483#comment-15998483 ] Xiang Li edited comment on HBASE-15199 at 5/5/17 3:45 PM: -- Hi Sean, the proposed change also change makes sense to me. The only reason for me to keep the logic as it is now is we might need to leave a way for (senior) operators to control JRUBY_HOME if they really want and be aware of the consequence, even for server. But I am just wondering if it is really needed. was (Author: water): Hi Sean, the proposed also change makes sense to me. The only reason for me to keep the logic as it is now is we might need to leave a way for (senior) operators to control JRUBY_HOME if they really want and be aware of the consequence, even for server. But I am just wondering if it is really needed. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch, > HBASE-15199.master.002.patch, HBASE-15199.master.003.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[
https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997606#comment-15997606
]
Ted Yu edited comment on HBASE-15199 at 5/5/17 12:09 AM:
-
The above procedure allows shell to work.
However, there is a catch - if JRUBY_HOME is set as environment variable and
you use bin/start-hbase.sh, the jruby jar would appear in the classpath:
java.class.path=/a/jruby-1.6.8/lib/jruby.jar
leading to the following exception when rootdir is on s3(a):
{code}
2017-05-04 23:53:48,192 FATAL [cn012:46854.activeMasterManager] master.HMaster:
Failed to become active master
java.nio.file.AccessDeniedException: : getFileStatus on :
com.amazonaws.services.s3.model.AmazonS3Exception: AWS authentication requires
a valid Date or x-amz-date header (Service: Amazon S3; Status Code: 403; Error
Code: AccessDenied; Request ID: B1725B25836D2604), S3 Extended Request ID:
f8+vQ1XvtF3iCC9RBCtOnsQrMdQTvWSJb930LTkS4BJxRqZHuUNoI/fFELMV8ndMBnYgRp4x91g=
at org.apache.hadoop.fs.s3a.S3AUtils.translateException(S3AUtils.java:158)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:1635)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:117)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1447)
at org.apache.hadoop.fs.s3a.S3AFileSystem.exists(S3AFileSystem.java:2040)
at
org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:462)
at
org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:162)
at
org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:142)
at
org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:724)
{code}
Should we document this ?
If so, I can open a JIRA.
was (Author: yuzhih...@gmail.com):
The above procedure allows shell to work.
However, there is a catch - if JRUBY_HOME is set as environment variable and
you use bin/start-hbase.sh, the jruby jar would appear in the classpath:
java.class.path=/a/jruby-1.6.8/lib/jruby.jar
leading to the following exception:
{code}
2017-05-04 23:53:48,192 FATAL [cn012:46854.activeMasterManager] master.HMaster:
Failed to become active master
java.nio.file.AccessDeniedException: : getFileStatus on :
com.amazonaws.services.s3.model.AmazonS3Exception: AWS authentication requires
a valid Date or x-amz-date header (Service: Amazon S3; Status Code: 403; Error
Code: AccessDenied; Request ID: B1725B25836D2604), S3 Extended Request ID:
f8+vQ1XvtF3iCC9RBCtOnsQrMdQTvWSJb930LTkS4BJxRqZHuUNoI/fFELMV8ndMBnYgRp4x91g=
at org.apache.hadoop.fs.s3a.S3AUtils.translateException(S3AUtils.java:158)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:1635)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:117)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1447)
at org.apache.hadoop.fs.s3a.S3AFileSystem.exists(S3AFileSystem.java:2040)
at
org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:462)
at
org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:162)
at
org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:142)
at
org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:724)
{code}
Should we document this ?
If so, I can open a JIRA.
> Move jruby jar so only on hbase-shell module classpath; currently globally
> available
>
>
> Key: HBASE-15199
> URL: https://issues.apache.org/jira/browse/HBASE-15199
> Project: HBase
> Issue Type: Task
> Components: dependencies, jruby, shell
>Reporter: stack
>Assignee: Xiang Li
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 15199.txt, HBASE-15199.master.001.patch,
> HBASE-15199.master.002.patch, HBASE-15199.master.003.patch
>
>
> A suggestion that came up out of internal issue (filed by Mr Jan Van Besien)
> was to move the scope of the jruby include down so it is only a dependency
> for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time
> for example) which can clash with the includes of others. Our Sean suggests
> that could be good to shut down exploit possibilities if jruby was not
> globally available. Only downside I can think is that it may no longer be
> available to our bin/*rb scripts if we move the jar but perhaps these can be
> changed so they can find the ruby jar in new location.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990735#comment-15990735 ] Xiang Li edited comment on HBASE-15199 at 5/1/17 1:47 PM: -- Updated patch 002 for master branch to address [~busbey]'s comments. The logic with the patch is (1) if JRUBY_HOME is defined, CLASSPATH is updated according to JRUBY_HOME defined (2) if JRUBY_HOME is not defined, check if the command issued belongs to a pre-defined command set (currently it contains shell and org.jruby.Main). A. if yes, add jruby jar packaged with HBase into CLASSPATH B. if no, do nothing There is a behavior change when comparing with original logic(without the patch) (1) without the patch, JRUBY_HOME and JRUBY_OPTS only takes effect when "hbase shell", that is, it does not take effect when "hbase org.jruby.Main xxx.rb“. It is a bug I believe (2) with the patch, JRUBY_HOME takes effect, for all commands, as long as it is specified. When JRUBY_HOME is specified, the jruby-complete jar packaged with HBase will be ignored. Make any sense to you? [~busbey], [~stack], [~jinghe] was (Author: water): Updated patch 002 for master branch to address [~busbey]'s comments! The logic with the patch is (1) if JRUBY_HOME is defined, CLASSPATH is updated according to JRUBY_HOME defined (2) if JRUBY_HOME is not defined, check if the command issued belongs to a pre-defined command set (currently it contains shell and org.jruby.Main). A. if yes, add jruby jar packaged with HBase into CLASSPATH B. if no, do nothing There is a behavior change when comparing with original logic(without the patch) (1) without the patch, JRUBY_HOME and JRUBY_OPTS only takes effect when "hbase shell", that is, it does not take effect when "hbase org.jruby.Main xxx.rb“. It is a bug I believe (2) with the patch, JRUBY_HOME takes effect, for all commands, as long as it is specified. When JRUBY_HOME is specified, the jruby-complete jar packaged with HBase will be ignored. Make any sense to you? [~busbey], [~stack], [~jinghe] > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch, > HBASE-15199.master.002.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15985044#comment-15985044 ] Xiang Li edited comment on HBASE-15199 at 4/26/17 4:10 PM: --- Updated patch 001 (considering Stack's patch as 000) for master, in accordance with Stack's idea, by moving jruby-complete from lib to lib/ruby. 3 files are updated: (1) hadoop-two-compat.xml in assembly is updated to move jruby-complete from lib to lib/ruby when doing assembly. (2) hbase(for Linux) and hbase.cmd(for Windows) are updated to add jruby-complete to classpath only when hbase shell. I tested the patch on Linux (not on Windows), by using HBase 1.2.4. HBase shell worked well, while master and region server could be launched correctly without jruby-complete in the classpath. [~stack] and [~busbey], make sense to you? My only concern is that if only hbase shell needs jruby-complete when runtime. Seems yes, as the output of dependency tree of maven shows only hbase shell and assembly use jruby-complete as a dependency. was (Author: water): Updated patch 001 (considering Stack's patch as 000) for master, in accordance with Stack's idea, by moving jruby-complete from lib to lib/ruby. 3 files are updated: (1) hadoop-two-compat.xml in assembly is updated to move jruby-complete from lib to lib/ruby when doing assembly. (2) hbase(for Linux) and hbase.cmd(for Windows) are updated to add jruby-complete to classpath only when hbase shell. I tested the patch on Linux (not on Windows), by using HBase 1.2.4. HBase shell worked well, while master and region server could be launched correctly without jruby-complete in the classpath. [~stack] and [~busbey], make sense to you? My only concern is that if only hbase shell needs jruby-complete when runtime. Seem yes, as the output of dependency tree of maven shows only hbase shell and assembly use jruby-complete as a dependency. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15985044#comment-15985044 ] Xiang Li edited comment on HBASE-15199 at 4/26/17 4:09 PM: --- Updated patch 001 (considering Stack's patch as 000) for master, in accordance with Stack's idea, by moving jruby-complete from lib to lib/ruby. 3 files are updated: (1) hadoop-two-compat.xml in assembly is updated to move jruby-complete from lib to lib/ruby when doing assembly. (2) hbase(for Linux) and hbase.cmd(for Windows) are updated to add jruby-complete to classpath only when hbase shell. I tested the patch on Linux (not on Windows), by using HBase 1.2.4. HBase shell worked well, while master and region server could be launched correctly without jruby-complete in the classpath. [~stack] and [~busbey], make sense to you? My only concern is that if only hbase shell needs jruby-complete when runtime. Seem yes, as the output of dependency tree of maven shows only hbase shell and assembly use jruby-complete as a dependency. was (Author: water): Updated patch 001 (considering Stack's patch as 000) for master, in accordance with Stack's idea, by moving jruby-complete from lib to lib/ruby. 3 files are updated: (1) hadoop-two-compat.xml in assembly is updated to move jruby-complete from lib to lib/ruby when doing assembly. (2) hbase(for Linux) and hbase.cmd(for Windows) are updated to add jruby-complete to classpath only when hbase shell. I tested the patch on Linux (not on Windows), by using HBase 1.2.4. HBase shell worked well, while master and region server could be launched correctly without jruby-complete in the classpath. [~stack] and [~busbey], make sense to you? > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Assignee: Xiang Li >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt, HBASE-15199.master.001.patch > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15199) Move jruby jar so only on hbase-shell module classpath; currently globally available
[ https://issues.apache.org/jira/browse/HBASE-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976032#comment-15976032 ] Xiang Li edited comment on HBASE-15199 at 4/20/17 4:08 AM: --- Hi [~stack] Agree with Sean. Your patch removes jruby-complete from of hbase parent pom, which can not move it down to hbase-shell. Currently, it is already scoped to hbase-shell. If an artifact is only declared in , it will not be actually included. Only when it is added to (the same level as , not the one under ), it is added as a dependency. can be used to control the version, scope or exclusion.., so that you do not have to specify those in every pom of child modules which needs that dependency. was (Author: water): Hi [~stack] Agree with Sean. Your patch removes jruby-complete from of hbase parent pom, which can not move it down to hbase-shell. Currently, it is already scoped to hbase-shell. If an artifact is only declared in , it will not be actually included. Only when it is added to (the same level as , not the one under ), it is added as a dependency. can be used to control the version, scope or exclusion.., so that you do not have to specify those in every pom of child modules. > Move jruby jar so only on hbase-shell module classpath; currently globally > available > > > Key: HBASE-15199 > URL: https://issues.apache.org/jira/browse/HBASE-15199 > Project: HBase > Issue Type: Task > Components: dependencies, jruby, shell >Reporter: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: 15199.txt > > > A suggestion that came up out of internal issue (filed by Mr Jan Van Besien) > was to move the scope of the jruby include down so it is only a dependency > for the hbase-shell. jruby jar brings in a bunch of dependencies (joda time > for example) which can clash with the includes of others. Our Sean suggests > that could be good to shut down exploit possibilities if jruby was not > globally available. Only downside I can think is that it may no longer be > available to our bin/*rb scripts if we move the jar but perhaps these can be > changed so they can find the ruby jar in new location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
