[jira] [Reopened] (HBASE-10653) Incorrect table status in HBase shell Describe
[ https://issues.apache.org/jira/browse/HBASE-10653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rekha Joshi reopened HBASE-10653: - Incorrect table status in HBase shell Describe -- Key: HBASE-10653 URL: https://issues.apache.org/jira/browse/HBASE-10653 Project: HBase Issue Type: Bug Components: shell Affects Versions: 0.94.17 Reporter: Biju Nair Assignee: Rekha Joshi Labels: HbaseShell, describe Fix For: 0.98.0 Attachments: HBASE-10653.1.patch, HBASE-10653.2.patch Describe output of table which is disabled shows as enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11095) Add ip restriction in user permissions
Liu Shaohui created HBASE-11095:
---
Summary: Add ip restriction in user permissions
Key: HBASE-11095
URL: https://issues.apache.org/jira/browse/HBASE-11095
Project: HBase
Issue Type: New Feature
Components: security
Reporter: Liu Shaohui
Priority: Minor
For some sensitive data, users want to restrict the from ips of hbase users
like mysql access control.
One direct solution is to add the candidated ips when granting user permisions.
{quote}
grant user|@group\[@ip-regular expression\] [ table [ column family [
column qualifier ] ] ]
{quote}
Any comments and suggestions are welcomed.
[~apurtell]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (HBASE-11096) stop method of Master and RegionServer coprocessor is not invoked
Qiang Tian created HBASE-11096: -- Summary: stop method of Master and RegionServer coprocessor is not invoked Key: HBASE-11096 URL: https://issues.apache.org/jira/browse/HBASE-11096 Project: HBase Issue Type: Bug Reporter: Qiang Tian Assignee: Qiang Tian the stop method of coprocessor specified by hbase.coprocessor.master.classes and hbase.coprocessor.regionserver.classes is not invoked. If coprocessor allocates OS resources, it could cause master/regionserver resource leak or hang during exit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-5697) Audit HBase for usage of deprecated hadoop 0.20.x property names.
[ https://issues.apache.org/jira/browse/HBASE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh resolved HBASE-5697. --- Resolution: Fixed Hadoop Flags: Incompatible change,Reviewed (was: Incompatible change) Thanks Srikanth and thanks Enis for taking a look. I've commited this to trunk. Audit HBase for usage of deprecated hadoop 0.20.x property names. - Key: HBASE-5697 URL: https://issues.apache.org/jira/browse/HBASE-5697 Project: HBase Issue Type: Task Reporter: Jonathan Hsieh Assignee: Srikanth Srungarapu Labels: noob Fix For: 0.99.0 Attachments: HBASE-5697.patch, HBASE-5697_v2.patch, HBASE-5697_v3.patch, deprecated_properties, hbase-5697.v3.patch Many xml config properties in Hadoop have changed in 0.23. We should audit hbase to insulate it from hadoop property name changes. Here is a list of the hadoop property name changes: hadoop.native.lib - io.native.lib.available mapred.job.classpath.archives - mapreduce.job.classpath.archives mapred.map.tasks.speculative.execution - mapreduce.map.speculative mapred.task.id - mapreduce.task.attempt.id mapred.output.compress - mapreduce.output.fileoutputformat.compress mapred.output.compression.codec - mapreduce.output.fileoutputformat.compress.codec mapred.output.compression.type - mapreduce.output.fileoutputformat.compress.type mapred.reduce.tasks.speculative.execution - mapreduce.reduce.speculative mapred.input.dir - mapreduce.input.fileinputformat.inputdir mapred.job.name - mapreduce.job.name mapred.local.dir - mapreduce.cluster.local.dir mapred.temp.dir - mapreduce.cluster.temp.dir mapred.system.dir - mapreduce.jobtracker.system.dir mapred.working.dir - mapreduce.job.working.dir mapred.job.tracker - mapreduce.jobtracker.address heartbeat.recheck.interval - dfs.namenode.heartbeat.recheck-interval dfs.socket.timeout - dfs.client.socket-timeout dfs.block.size - dfs.blocksize io.sort.mb - mapreduce.task.io.sort.mb mapred.input.dir - mapreduce.input.fileinputformat.inputdir mapred.input.dir - mapreduce.input.fileinputformat.inputdir min.num.spills.for.combine - mapreduce.map.combine.minspills mapred.map.max.attempts - mapreduce.map.max.attempts dfs.socket.timeout - dfs.client.socket-timeout dfs.datanode.max.xcievers - dfs.datanode.max.transfer.threads -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6096) AccessController v2
[ https://issues.apache.org/jira/browse/HBASE-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6096. --- Resolution: Fixed This umbrella has seen it's day. Resolving and spinning out still relevant subtasks to top level issues. AccessController v2 --- Key: HBASE-6096 URL: https://issues.apache.org/jira/browse/HBASE-6096 Project: HBase Issue Type: Umbrella Components: security Affects Versions: 0.94.1, 0.95.2 Reporter: Andrew Purtell Attachments: Security-ACL Matrix.pdf Umbrella issue for iteration on the initial AccessController drop. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6098) ACL design changes
[ https://issues.apache.org/jira/browse/HBASE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6098. --- Resolution: Invalid Invalid sub-umbrella. I should have just linked the issues here to the parent. ACL design changes -- Key: HBASE-6098 URL: https://issues.apache.org/jira/browse/HBASE-6098 Project: HBase Issue Type: Sub-task Components: security Affects Versions: 0.94.1, 0.95.2 Reporter: Andrew Purtell -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-5352) ACL improvements
[ https://issues.apache.org/jira/browse/HBASE-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-5352. --- Resolution: Fixed Assignee: (was: Enis Soztutar) This umbrella has seen it's day. Will spin out still relevant unfinished subtasks to top level issues. ACL improvements Key: HBASE-5352 URL: https://issues.apache.org/jira/browse/HBASE-5352 Project: HBase Issue Type: Improvement Components: security Affects Versions: 0.92.1, 0.94.0 Reporter: Enis Soztutar In this issue I would like to open discussion for a few minor ACL related improvements. The proposed changes are as follows: 1. Introduce something like AccessControllerProtocol.checkPermissions(Permission[] permissions) API, so that clients can check access rights before carrying out the operations. We need this kind of operation for HCATALOG-245, which introduces authorization providers for hbase over hcat. We cannot use getUserPermissions() since it requires ADMIN permissions on the global/table level. 2. getUserPermissions(tableName)/grant/revoke and drop/modify table operations should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights. The reasoning is that if a user is able to admin or read from a table, she should be able to read the table's permissions. We can choose whether we want only READ or ADMIN permissions for getUserPermission(). Since we check for global permissions first for table permissions, configuring table access using global permissions will continue to work. 3. Grant/Revoke global permissions - HBASE-5342 (included for completeness) From all 3, we may want to backport the first one to 0.92 since without it, Hive/Hcatalog cannot use Hbase's authorization mechanism effectively. I will create subissues and convert HBASE-5342 to a subtask when we get some feedback, and opinions for going further. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6101) Insure Observers cover all relevant RPC and lifecycle code paths
[ https://issues.apache.org/jira/browse/HBASE-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6101. --- Resolution: Fixed Insure Observers cover all relevant RPC and lifecycle code paths Key: HBASE-6101 URL: https://issues.apache.org/jira/browse/HBASE-6101 Project: HBase Issue Type: Sub-task Components: Coprocessors, master, regionserver, security Affects Versions: 0.94.1, 0.95.2 Reporter: Andrew Purtell -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-5343) Access control API in HBaseAdmin.java
[ https://issues.apache.org/jira/browse/HBASE-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-5343. --- Resolution: Invalid Assignee: (was: Enis Soztutar) Access control API in HBaseAdmin.java --- Key: HBASE-5343 URL: https://issues.apache.org/jira/browse/HBASE-5343 Project: HBase Issue Type: Improvement Components: Client, Coprocessors, security Affects Versions: 0.92.1, 0.94.0 Reporter: Enis Soztutar To use the access control mechanism added in HBASE-3025, users should either use the shell interface, or use the coprocessor API directly, which is not very user friendly. We can add grant/revoke/user_permission commands similar to the shell interface to HBaseAdmin assuming HBASE-5341 is in. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6030) Log AccessDeniedExceptions at INFO level
[ https://issues.apache.org/jira/browse/HBASE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6030. --- Resolution: Not a Problem Assignee: (was: Andrew Purtell) Log AccessDeniedExceptions at INFO level Key: HBASE-6030 URL: https://issues.apache.org/jira/browse/HBASE-6030 Project: HBase Issue Type: Improvement Components: Coprocessors, security Affects Versions: 0.92.2, 0.94.1, 0.95.2 Environment: AccessController coprocessor Reporter: Andrew Purtell Priority: Minor The HBase AccessController can emit a detailed trace of every action, and whether it succeeded or failed, but this is expected to be used only for debugging an application in a staging environment. In production a RegionServer may have thousands of requests per second, logging the audit trace just isn't viable. However, we might want to log the AccessDeniedExceptions which result from access failures in the daemon logs like Hadoop does, e.g. the NameNode log. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-7333) Improve the security shell commands
[ https://issues.apache.org/jira/browse/HBASE-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-7333. --- Resolution: Not a Problem Assignee: (was: Andrew Purtell) Superseded by a lot of commits. Improve the security shell commands --- Key: HBASE-7333 URL: https://issues.apache.org/jira/browse/HBASE-7333 Project: HBase Issue Type: Sub-task Components: Coprocessors, security, shell Affects Versions: 0.94.4, 0.95.2 Reporter: Andrew Purtell The shell commands for security are rudimentary and should be improved. The commands we have need to be updated for the AccessController v2 changes. The distinction between the shell and the Java (admin) API is blurry because our shell is JRuby but it makes sense to provide some convenient shortcuts for common actions. At a minimum the current set of commands should validate their arguments. 'revoke' should be improved so all access for a given user can be conveniently revoked with one command, as opposed to requiring a specific revoke for every previous grant. This may involve interaction with a master mediated transaction or barrier framework. Once HBASE-6222 is in, it should be possible to conveniently construct ACLs and add them to DML ops like put and delete; and there should be support for dumping ACLs at the cell level too. Also, I observed 'user_permission' fail with NPEs on a colleague's workstation recently. It could have been the local environment, but I suspect there may be some rot here. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6186) Assure thread safety
[ https://issues.apache.org/jira/browse/HBASE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6186. --- Resolution: Invalid Assure thread safety Key: HBASE-6186 URL: https://issues.apache.org/jira/browse/HBASE-6186 Project: HBase Issue Type: Sub-task Components: security Affects Versions: 0.94.0, 0.94.1, 0.95.2 Reporter: Andrew Purtell Labels: security Check data structures for necessary thread safety. One known issue is as follows: In TableAuthManager, we need to deal with concurrent grants and revokes now that ADMIN permission can be delegated to perhaps multiple users. Consider using a ReadWriteLock to protect for update. The current data structure is an array multimap. It is also possible to obtain a synchronized multimap from Guava with Multimaps#synchronizedListMultimap but by far the most common access is read access, and concurrent read access is fine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6106) Update documentation to reflect design and interface changes
[ https://issues.apache.org/jira/browse/HBASE-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-6106. --- Resolution: Fixed Superseded by subsequent documentation updates. Retired with parent. Update documentation to reflect design and interface changes Key: HBASE-6106 URL: https://issues.apache.org/jira/browse/HBASE-6106 Project: HBase Issue Type: Sub-task Components: Coprocessors, documentation, security Affects Versions: 0.94.1, 0.95.2 Reporter: Andrew Purtell -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-3045) Extend HBASE-3025 into a role based access control model using HBase groups
[ https://issues.apache.org/jira/browse/HBASE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-3045. --- Resolution: Later Assignee: (was: Eugene Koontz) Hadoop group mapping seems good enough for now. Resolving as Later. Extend HBASE-3025 into a role based access control model using HBase groups - Key: HBASE-3045 URL: https://issues.apache.org/jira/browse/HBASE-3045 Project: HBase Issue Type: Sub-task Components: security Reporter: Andrew Purtell -- This message was sent by Atlassian JIRA (v6.2#6252)
0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.orgwrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
Thank you guys - this is the most responsive community I've seen around! On Tue, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.orgwrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
[jira] [Created] (HBASE-11097) Allow 0.89-fb to work with ipv6 addresses
Amitanand Aiyer created HBASE-11097: --- Summary: Allow 0.89-fb to work with ipv6 addresses Key: HBASE-11097 URL: https://issues.apache.org/jira/browse/HBASE-11097 Project: HBase Issue Type: New Feature Affects Versions: 0.89-fb Reporter: Amitanand Aiyer -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
Do you guys think it'd make sense to find site:run to install phase? This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. Cos On Tue, Apr 29, 2014 at 02:54PM, Konstantin Boudnik wrote: Thank you guys - this is the most responsive community I've seen around! On Tue, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.orgwrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
On Tue, Apr 29, 2014 at 04:27PM, Stack wrote: On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Yeah, you right. it also won't fly for another reason - the install won't engage other needed steps such as compile, test-compile, etc. It seems that for the purpose of Bigtop packaging there's no other way but to really execute two septate mvn process one after another. Thanks, Cos Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release (https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary assembly in 0.98? When we were building bigtop releases out of 0.94.x we were expecting target/hbase*tar.gz to be present. It seems the things have changes somewhat 'cause not assembly:assembly nor package targets create the tarballs anymore. Am I doing something wrong? Sorry if it has been answered elsewhere... -- Regards, Cos -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom
[jira] [Created] (HBASE-11098) Improve documentation around our blockcache options
stack created HBASE-11098: - Summary: Improve documentation around our blockcache options Key: HBASE-11098 URL: https://issues.apache.org/jira/browse/HBASE-11098 Project: HBase Issue Type: Sub-task Components: documentation Reporter: stack Assignee: stack Adding as a subtask on [~ndimiduk] necessary cleanup. Trying to make sense of this stuff I started adding doc (package-info files, javadoc). I see this as complementary to the parent task work. -- This message was sent by Atlassian JIRA (v6.2#6252)
Rolling the 0.98.2 RC0 tomorrow
/eom -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: Rolling the 0.98.2 RC0 tomorrow
Do you expect a go/nogo before HBaseCon? Or after? Might be tight, no? 2014-04-29 21:26 GMT-04:00 Andrew Purtell apurt...@apache.org: /eom -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
We have a 'release' Maven profile. Right now it just runs Apache RAT. I wonder if some kind of hairy Maven-foo can reattach site into the right place if this profile is enabled. RAT is pretty quick, and Javadoc is going to dominate build time anyhow, so should be ok for Bigtop packaging. The question is if it's possible. My Maven is weak. Anyone have any idea? On Tue, Apr 29, 2014 at 4:37 PM, Konstantin Boudnik c...@apache.org wrote: On Tue, Apr 29, 2014 at 04:27PM, Stack wrote: On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Yeah, you right. it also won't fly for another reason - the install won't engage other needed steps such as compile, test-compile, etc. It seems that for the purpose of Bigtop packaging there's no other way but to really execute two septate mvn process one after another. Thanks, Cos Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release ( https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone point me to the right direction about the tar.gz binary
[jira] [Created] (HBASE-11099) Two situations where we could open a region with smaller sequence number
Jeffrey Zhong created HBASE-11099:
-
Summary: Two situations where we could open a region with smaller
sequence number
Key: HBASE-11099
URL: https://issues.apache.org/jira/browse/HBASE-11099
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.99.0
Reporter: Jeffrey Zhong
Recently I happened to run into code where we potentially could open region
with smaller sequence number:
1) Inside function: HRegion#internalFlushcache. This is due to we change the
way WAL Sync where we use late binding(assign sequence number right before wal
sync).
The flushSeqId may less than the change sequence number included in the flush
which may cause later region opening code to use a smaller than expected
sequence number when we reopen the region.
{code}
flushSeqId = this.sequenceId.incrementAndGet();
...
mvcc.waitForRead(w);
{code}
2) HRegion#replayRecoveredEdits where we have following code:
{code}
...
if (coprocessorHost != null) {
status.setStatus(Running pre-WAL-restore hook in coprocessors);
if (coprocessorHost.preWALRestore(this.getRegionInfo(), key, val)) {
// if bypass this log entry, ignore it ...
continue;
}
}
...
currentEditSeqId = key.getLogSeqNum();
{code}
If coprocessor skip some tail WALEdits, then the function will return smaller
currentEditSeqId. In the end, a region may also open with a smaller sequence
number. This may cause data loss because Master may record a larger flushed
sequence Id and some WALEdits maybe skipped during recovery if the region fail
again.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
On Tue, Apr 29, 2014 at 6:45 PM, Andrew Purtell apurt...@apache.org wrote: We have a 'release' Maven profile. Right now it just runs Apache RAT. I wonder if some kind of hairy Maven-foo can reattach site into the right place if this profile is enabled. RAT is pretty quick, and Javadoc is going to dominate build time anyhow, so should be ok for Bigtop packaging. The question is if it's possible. My Maven is weak. Anyone have any idea? Seems like site is a lifecycle of its own apart from the maven 'default' lifecycle: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Getting the site lifecycle to run inside a goal of the 'default' lifecycle could be tough (I'm no expert). We make use of the pre-site building docbook. St.Ack On Tue, Apr 29, 2014 at 4:37 PM, Konstantin Boudnik c...@apache.org wrote: On Tue, Apr 29, 2014 at 04:27PM, Stack wrote: On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Yeah, you right. it also won't fly for another reason - the install won't engage other needed steps such as compile, test-compile, etc. It seems that for the purpose of Bigtop packaging there's no other way but to really execute two septate mvn process one after another. Thanks, Cos Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release ( https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
Right, I'm probably not using correct maven terminology. On Apr 29, 2014, at 10:35 PM, Stack st...@duboce.net wrote: On Tue, Apr 29, 2014 at 6:45 PM, Andrew Purtell apurt...@apache.org wrote: We have a 'release' Maven profile. Right now it just runs Apache RAT. I wonder if some kind of hairy Maven-foo can reattach site into the right place if this profile is enabled. RAT is pretty quick, and Javadoc is going to dominate build time anyhow, so should be ok for Bigtop packaging. The question is if it's possible. My Maven is weak. Anyone have any idea? Seems like site is a lifecycle of its own apart from the maven 'default' lifecycle: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Getting the site lifecycle to run inside a goal of the 'default' lifecycle could be tough (I'm no expert). We make use of the pre-site building docbook. St.Ack On Tue, Apr 29, 2014 at 4:37 PM, Konstantin Boudnik c...@apache.org wrote: On Tue, Apr 29, 2014 at 04:27PM, Stack wrote: On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Yeah, you right. it also won't fly for another reason - the install won't engage other needed steps such as compile, test-compile, etc. It seems that for the purpose of Bigtop packaging there's no other way but to really execute two septate mvn process one after another. Thanks, Cos Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not find artifact org.apache.hbase:hbase-common:jar:0.98.1 in apache release ( https://repository.apache.org/content/repositories/releases/) - [Help 1] Naturally, such artifacts aren't available in the aforementioned repo, because only *-hadoop1 and *-hadoop2 versions are there. I am using the same maven command as before. But even the standard release command mvn clean install -DskipTests site assembly:single -Prelease doesn't work anymore. I am building with clean ~/.m2, if it makes any difference. Anyone here has a similar experience? Thanks in advance, Cos On Tue, Apr 22, 2014 at 07:26PM, Konstantin Boudnik wrote: Right, thanks! Also, it moved + plus set of artifacts got changed. No matter - I got the packaging working again, so once HBase has 0.98.2 out of the door it will be right there in Bigtop 0.8.0. Appreciate the help, guys! Cos On Tue, Apr 22, 2014 at 04:20PM, Ted Yu wrote: Please use assembly:single See http://hbase.apache.org/book.html#maven.release Cheers On Tue, Apr 22, 2014 at 4:17 PM, Konstantin Boudnik c...@apache.org wrote: Guys, can anyone
Re: Rolling the 0.98.2 RC0 tomorrow
Would be happy to give it a spin with upcoming Bigtop 0.8.0! Thanks much, mate! On Tue, Apr 29, 2014 at 06:26PM, Andrew Purtell wrote: /eom -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: 0.98.1 has stopped building [Was: What happened to tar.gz assembly in 0.98?]
+1 on what Stack said - 'site' stands apart from the other targets. In the midst of this conversation I have tried to tight it up with default-install phase but it basically has two consequences: - not working as riding install's coat-tails don't do much good as its own bound life-cycles steps aren't getting called. Hence, no compilation, etc. will be happening - increasing the time of the build (potentially) I would ask a slightly different question: why site needs the installed artifacts in the first place? And if you guys feel like we need to dig into this issue - please let me know I will be happy to play with it: I have a bit of knowledge in Maven. However, ~2K of a build file scares the hell out of me ;) Regards, Cos On Tue, Apr 29, 2014 at 10:35PM, Stack wrote: On Tue, Apr 29, 2014 at 6:45 PM, Andrew Purtell apurt...@apache.org wrote: We have a 'release' Maven profile. Right now it just runs Apache RAT. I wonder if some kind of hairy Maven-foo can reattach site into the right place if this profile is enabled. RAT is pretty quick, and Javadoc is going to dominate build time anyhow, so should be ok for Bigtop packaging. The question is if it's possible. My Maven is weak. Anyone have any idea? Seems like site is a lifecycle of its own apart from the maven 'default' lifecycle: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Getting the site lifecycle to run inside a goal of the 'default' lifecycle could be tough (I'm no expert). We make use of the pre-site building docbook. St.Ack On Tue, Apr 29, 2014 at 4:37 PM, Konstantin Boudnik c...@apache.org wrote: On Tue, Apr 29, 2014 at 04:27PM, Stack wrote: On Tue, Apr 29, 2014 at 4:18 PM, Konstantin Boudnik c...@apache.org wrote: Do you guys think it'd make sense to find site:run to install phase? It wouldn't fly. You'd piss off everyone as they wait on javadoc and doc targets every time they make small change. Yeah, you right. it also won't fly for another reason - the install won't engage other needed steps such as compile, test-compile, etc. It seems that for the purpose of Bigtop packaging there's no other way but to really execute two septate mvn process one after another. Thanks, Cos Site is intentionally broken off an explicit goal unhooked from maven lifecycle for this reason. Ditto assembly for similar but also more convoluted reasons. St.Ack This way - in theory at least - site will always be executing install first? It might be too small of an issue though which might be totally workarounded with two sequential maven runs. e, Apr 29, 2014 at 02:48PM, Andrew Purtell wrote: Ah, and if I read to the end ( sorry - sometimes don't do that when annoyed - unrelated to this :-) ), then indeed you did clean ~/.m2 and then attempted a list of targets including site. Install jars to the local Maven cache before invoking javadoc or site targets. On Tue, Apr 29, 2014 at 2:44 PM, Andrew Purtell apurt...@apache.org wrote: Is this because we frob the Maven versions after rolling the source tarball? See https://hbase.apache.org/book/releasing.html Do 'mvn -DskipTests clean install' first, then something that pulls in javadoc or site targets and you should be fine. My guess is you did that at one point, then moved to a different box or somehow wiped out local 0.98.1 artifacts in your ~/.m2. On Tue, Apr 29, 2014 at 2:38 PM, Konstantin Boudnik c...@apache.org wrote: This is a bit weird, but since last night I can't build 0.98.1 anymore because of the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project hbase: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal on project hbase-server: Could not resolve dependencies for project org.apache.hbase:hbase-server:jar:0.98.1: The following artifacts could not be resolved: org.apache.hbase:hbase-common:jar:0.98.1, org.apache.hbase:hbase-protocol:jar:0.98.1, org.apache.hbase:hbase-client:jar:0.98.1, org.apache.hbase:hbase-prefix-tree:jar:0.98.1, org.apache.hbase:hbase-common:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop-compat:jar:tests:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:0.98.1, org.apache.hbase:hbase-hadoop2-compat:jar:tests:0.98.1: Could not
