[jira] [Updated] (HBASE-3361) Modularize Maven Structure for Tests
[ https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-3361: -- Resolution: Won't Fix Status: Resolved (was: Patch Available) > Modularize Maven Structure for Tests > > > Key: HBASE-3361 > URL: https://issues.apache.org/jira/browse/HBASE-3361 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Ed Kohlwey >Assignee: Misty Stanley-Jones > Attachments: HBASE-3361.patch > > > There's a few reasons to break tests out into their own module: > 1. Allowing maven users to easily re-consume test utilities as part of a > "test" package which doesn't pollute the runtime classpath > 2. Putting integration tests (tests that create or require a cluster) in > their own module allows users to easily rebuild and test the core of HBase > without running long-running tests, reducing the developer iteration loop > After some discussions with Stack on IRC, it sounds like there was some > historic investigation of this which was abandoned because the module system > was becoming too complex. I'd suggest that rather than trying to break out > components all at once into their modules, evaluate creation of modules on a > case-by-case basis and only create them when there's a significant use case > justification. > I created a sample of what I'm thinking about (based on the current trunk) > and posted it on github > git://github.com/ekohlwey/modularized-hbase.git -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-3361) Modularize Maven Structure for Tests
[ https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-3361: --- Status: Patch Available (was: Reopened) > Modularize Maven Structure for Tests > > > Key: HBASE-3361 > URL: https://issues.apache.org/jira/browse/HBASE-3361 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Ed Kohlwey >Assignee: Misty Stanley-Jones > Attachments: HBASE-3361.patch > > > There's a few reasons to break tests out into their own module: > 1. Allowing maven users to easily re-consume test utilities as part of a > "test" package which doesn't pollute the runtime classpath > 2. Putting integration tests (tests that create or require a cluster) in > their own module allows users to easily rebuild and test the core of HBase > without running long-running tests, reducing the developer iteration loop > After some discussions with Stack on IRC, it sounds like there was some > historic investigation of this which was abandoned because the module system > was becoming too complex. I'd suggest that rather than trying to break out > components all at once into their modules, evaluate creation of modules on a > case-by-case basis and only create them when there's a significant use case > justification. > I created a sample of what I'm thinking about (based on the current trunk) > and posted it on github > git://github.com/ekohlwey/modularized-hbase.git -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-3361) Modularize Maven Structure for Tests
[ https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-3361: --- Attachment: HBASE-3361.patch > Modularize Maven Structure for Tests > > > Key: HBASE-3361 > URL: https://issues.apache.org/jira/browse/HBASE-3361 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Ed Kohlwey >Assignee: Misty Stanley-Jones > Attachments: HBASE-3361.patch > > > There's a few reasons to break tests out into their own module: > 1. Allowing maven users to easily re-consume test utilities as part of a > "test" package which doesn't pollute the runtime classpath > 2. Putting integration tests (tests that create or require a cluster) in > their own module allows users to easily rebuild and test the core of HBase > without running long-running tests, reducing the developer iteration loop > After some discussions with Stack on IRC, it sounds like there was some > historic investigation of this which was abandoned because the module system > was becoming too complex. I'd suggest that rather than trying to break out > components all at once into their modules, evaluate creation of modules on a > case-by-case basis and only create them when there's a significant use case > justification. > I created a sample of what I'm thinking about (based on the current trunk) > and posted it on github > git://github.com/ekohlwey/modularized-hbase.git -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Updated: (HBASE-3361) Modularize Maven Structure for Tests
[ https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-3361: - Component/s: (was: test) documentation I made this a documentation issue. We need a maven section in the book. Move the wiki page content in and add this config. that Lars and Ed figured. > Modularize Maven Structure for Tests > > > Key: HBASE-3361 > URL: https://issues.apache.org/jira/browse/HBASE-3361 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Ed Kohlwey >Assignee: Ed Kohlwey > > There's a few reasons to break tests out into their own module: > 1. Allowing maven users to easily re-consume test utilities as part of a > "test" package which doesn't pollute the runtime classpath > 2. Putting integration tests (tests that create or require a cluster) in > their own module allows users to easily rebuild and test the core of HBase > without running long-running tests, reducing the developer iteration loop > After some discussions with Stack on IRC, it sounds like there was some > historic investigation of this which was abandoned because the module system > was becoming too complex. I'd suggest that rather than trying to break out > components all at once into their modules, evaluate creation of modules on a > case-by-case basis and only create them when there's a significant use case > justification. > I created a sample of what I'm thinking about (based on the current trunk) > and posted it on github > git://github.com/ekohlwey/modularized-hbase.git -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
