Corey Nolet 2013-04-26, 03:01
Christopher 2013-04-26, 11:27
Corey Nolet 2013-04-26, 14:18
Keith Turner 2013-04-26, 15:40
Christopher 2013-04-28, 05:45
Keith Turner 2013-04-29, 14:58
Christopher 2013-04-29, 16:27
Corey Nolet 2013-04-29, 17:00
Josh Elser 2013-04-29, 17:11
It seems there was a consensus that MAC should be moved to server. Is
anyone going to do this for 1.5?
One more advantage of this move would be putting MAC in its one package.
Currently it shares a package with a lot of unrelated test code.
On Mon, Apr 29, 2013 at 1:11 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> I think I like the idea of moving it to server and working towards MAC and
> the "regular" processes being equal citizens. Whether or not we make a
> convenient option to auto-start a proxy is more of a discussion about how
> easy we want to make startup for a new person.
> As much as I think we need to get 1.5 out the door, I think this may be
> best to nip right away rather than create confusion about "where did MAC
> go!" immediately after 1.5.0 is released.
> The server module seems like the most painless and correct home for
> On 4/28/13 1:45 AM, Christopher wrote:
>> I agree that accumulo-test is the best place, but I think we should
>> make it a point that no other modules should depend on accumulo-test
>> for precisely this reason... to provide a place for end-to-end tests
>> of other modules (the assembly module notwithstanding).
>> This is actually a good reason to move MiniAccumuloCluster from test,
>> because the proxy currently has a dependency on it just for
>> MiniAccumuloCluster. That way, end-to-end integration testing that
>> includes even testing of the proxy would make sense to exist in
>> accumulo-test, and we'd avoid a circular dependency. It could be moved
>> to server instead, as it seems to me that it is essentially an
>> alternate server implementation (from the proxy's perspective,
>> anyway). Though, I'm not sure I like the idea that the proxy is
>> dependent on anything other than client code (accumulo-core).
>> Alternatively, the proxy's dependency could be reversed, so that
>> instead of the proxy having an option to start up a
>> MiniAccumuloCluster, the MiniAccumuloCluster could have an option to
>> start up the proxy. This reversal actually makes more sense to me
>> anyway. I never understood why the proxy should have the option to
>> start up Accumulo, Mini or otherwise, as the natural operation, as it
>> seems to me to be a bit backwards: an interface launching the service,
>> rather than a service exposing an interface. I suppose it's not
>> unprecedented, but it seems backwards to me.
>> A third option is to move MiniAccumuloCluster to another module
>> entirely, but I'm not so sure that's necessary or desirable.
>> Any of these options removes the circular dependency, if we're going
>> to make the accumulo-test the place to put end-to-end integration
>> My preference is a combination of the first two options: to put
>> MiniAccumuloCluster in the server module and reverse the dependency,
>> so that proxy only depends on core, and none depend on test.
>> Christopher L Tubbs II
>> On Fri, Apr 26, 2013 at 11:40 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
>>> On Fri, Apr 26, 2013 at 10:18 AM, Corey Nolet <[EMAIL PROTECTED]>
>>> So the accumulo-test would be the best place to start putting end to end
>>>> integration tests?
>>>> For test against code in modules that can not depend on accumulo-test I
>>> think this is a good place.
>>>> Sent from my Verizon Wireless 4G LTE Smartphone
>>>> -------- Original message --------
>>>> From: Christopher <[EMAIL PROTECTED]>
>>>> Date: 04/26/2013 7:27 AM (GMT-05:00)
>>>> To: Accumulo Dev List <[EMAIL PROTECTED]>
>>>> Subject: Re: Integration Tests
>>>> The maven-failsafe-plugin is already configured to execute integration
>>>> tests in the 1.5 branch and trunk. Simply name your JUnit classes to
>>>> execute with the pattern of "*IT" (vs. "*Test" for unit tests), and
>>>> they'll execute during the integration test phase of the build
>>>> lifecycle. That way, they won't slow down a "mvn package" build, but
Corey Nolet 2013-05-03, 16:17
Keith Turner 2013-05-03, 16:30
Corey Nolet 2013-05-03, 16:43
Corey Nolet 2013-04-28, 11:45
Michael Berman 2013-09-13, 21:15