I take that back. I've been using an outdated version of svn.
On Fri, May 3, 2013 at 12:30 PM, Keith Turner <[email protected]> wrote: > I can move it. Eclipse should make it fairly simple > > > On Fri, May 3, 2013 at 12:17 PM, Corey Nolet <[email protected]> wrote: > > > I was wondering about that on a recent patch... I'd have done it in the > > patch but i can't delete files... > > > > > > On Fri, May 3, 2013 at 12:04 PM, Keith Turner <[email protected]> wrote: > > > > > 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 > > > > MiniAccumuloCluster. > > > > > > > > > > > > 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 > > > >> tests. > > > >> > > > >> 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 > > > >> http://gravatar.com/ctubbsii > > > >> > > > >> > > > >> 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] > > > > > >>> wrote: > > > >>> > > > >>> 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 > > > >>>> they'll still get executed for a full build "mvn verify". > > > >>>> > > > >>>> -- > > > >>>> Christopher L Tubbs II > > > >>>> http://gravatar.com/ctubbsii > > > >>>> > > > >>>> > > > >>>> On Thu, Apr 25, 2013 at 11:01 PM, Corey Nolet < > [email protected]> > > > >>>> wrote: > > > >>>> > > > >>>>> Would it make sense to start putting more integration tests for > > > tablet > > > >>>>> > > > >>>> servers, master, connector, etc… inside of the accumulo-test > module > > > (or > > > >>>> some other module)? Seems like it'd be useful to have tests at the > > > >>>> various > > > >>>> layers. Until we have a plugin to start up the mini acc cluster > once > > > and > > > >>>> only once, I don't want to drastically slow down the build. I > would, > > > >>>> however, like to have some integration tests for a current ticket > > I'm > > > >>>> working on. > > > >>>> > > > >>>> > > > > > > > > > > > > > > > -- > > Corey Nolet > > Senior Software Engineer > > TexelTek, inc. > > [Office] 301.880.7123 > > [Cell] 410-903-2110 > > > -- Corey Nolet Senior Software Engineer TexelTek, inc. [Office] 301.880.7123 [Cell] 410-903-2110
