has anyone heard about an 'Apache Projects Testing Program'?
I recently heard this phrase but I don't see any responses to my web search. Has anyone else heard about this program?
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
Corey, It seems these move were not done is such a way that history was preserved. 'svn move' should be used, it preserves history. Although I never use this. When I move things around in eclipse it automatically does 'svn move'. I looked into how to fix this. There does not seem to be an easy way other than reverting the changes and doing a move. Keith On Mon, May 20, 2013 at 10:12 PM, wrote: > Author: cjnolet > Date: Tue May 21 02:12:28 2013 > New Revision: 1484644 > > URL: http://svn.apache.org/r1484644 > Log: > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
BTW revision can be reverted w/ a negative. For example to revert revision 9 and 4 could do the following svn merge -c -9 . svn merge -c -4 . On Tue, May 21, 2013 at 10:23 AM, Keith Turner wrote: > Corey, > > It seems these move were not done is such a way that history was > preserved. 'svn move' should be used, it preserves history. Although I > never use this. When I move things around in eclipse it automatically does > 'svn move'. > > I looked into how to fix this. There does not seem to be an easy way > other than reverting the changes and doing a move. > > Keith > > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > >> Author: cjnolet >> Date: Tue May 21 02:12:28 2013 >> New Revision: 1484644 >> >> URL: http://svn.apache.org/r1484644 >> Log: >> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module >> >>
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
Ill revert this and redo. Still getting used to svn. Corey, It seems these move were not done is such a way that history was preserved. 'svn move' should be used, it preserves history. Although I never use this. When I move things around in eclipse it automatically does 'svn move'. I looked into how to fix this. There does not seem to be an easy way other than reverting the changes and doing a move. Keith On Mon, May 20, 2013 at 10:12 PM, wrote: > Author: cjnolet > Date: Tue May 21 02:12:28 2013 > New Revision: 1484644 > > URL: http://svn.apache.org/r1484644 > Log: > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > >
hadoop-2.0 incompatibility
Ugh. While running the continuous ingest verify, yarn spit this out: Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was expected This is preventing the reduce step from completing. -Eric
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
Corey, You should try git-svn. That should give you an interface that you are used to. On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > Ill revert this and redo. Still getting used to svn. > Corey, > > It seems these move were not done is such a way that history was preserved. > 'svn move' should be used, it preserves history. Although I never use > this. When I move things around in eclipse it automatically does 'svn > move'. > > I looked into how to fix this. There does not seem to be an easy way other > than reverting the changes and doing a move. > > Keith > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > >> Author: cjnolet >> Date: Tue May 21 02:12:28 2013 >> New Revision: 1484644 >> >> URL: http://svn.apache.org/r1484644 >> Log: >> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module >> >>
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > Ill revert this and redo. Still getting used to svn. > Yeah, svn is quirky w/ this type of stuff, I am still learning too when it comes to these corner cases. I just did an experiment on my local 1.5 I did the following.. svn merge -c -1484792 . svn merge -c -1484644 . resolve --accept=working mini svn status shows the following. I looked at the docs, the '+' means that history changes are scheduled. So I think this means the history will come back, but not positive. Not completely sure I resolved the tree conflict correctly. svn status M test/compat/japi-compliance/japi-accumulo-1.4.xml M test/system/upgrade_test.sh M test/src/test/java/org/apache/accumulo/fate/zookeeper/ZooLockTest.java M test/src/test/java/org/apache/accumulo/test/MetaSplitTest.java M test/src/test/java/org/apache/accumulo/test/TestAccumuloSplitRecovery.java M test/src/test/java/org/apache/accumulo/test/ShellServerTest.java M test/pom.xml M proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java M proxy/src/main/java/org/apache/accumulo/proxy/Proxy.java M proxy/pom.xml M pom.xml M assemble/pom.xml M mini/pom.xml M README A +server/src/test/java/org/apache/accumulo/server/mini A + server/src/test/java/org/apache/accumulo/server/mini/MiniAccumuloClusterTest.java A +server/src/test/resources/FooFilter.jar M server/src/test/resources/log4j.properties A +server/src/main/java/org/apache/accumulo/server/mini A + server/src/main/java/org/apache/accumulo/server/mini/MiniAccumuloCluster.java A + server/src/main/java/org/apache/accumulo/server/mini/MiniAccumuloConfig.java I am thinking it would be best to revert in each branch. Then merge from 1.5 to 1.6 w/o making changes, and just commit the props that mark the merge as done. > Corey, > > It seems these move were not done is such a way that history was preserved. > 'svn move' should be used, it preserves history. Although I never use > this. When I move things around in eclipse it automatically does 'svn > move'. > > I looked into how to fix this. There does not seem to be an easy way other > than reverting the changes and doing a move. > > Keith > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > > > Author: cjnolet > > Date: Tue May 21 02:12:28 2013 > > New Revision: 1484644 > > > > URL: http://svn.apache.org/r1484644 > > Log: > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > Ill revert this and redo. Still getting used to svn. > let me know if you want me to do the revert. > Corey, > > It seems these move were not done is such a way that history was preserved. > 'svn move' should be used, it preserves history. Although I never use > this. When I move things around in eclipse it automatically does 'svn > move'. > > I looked into how to fix this. There does not seem to be an easy way other > than reverting the changes and doing a move. > > Keith > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > > > Author: cjnolet > > Date: Tue May 21 02:12:28 2013 > > New Revision: 1484644 > > > > URL: http://svn.apache.org/r1484644 > > Log: > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
I'd like to try it if you don't mind. The only way to learn is to do. I'll hold on committing the change until i'm 100% confident that I'm not going to make the problem worse. On Tue, May 21, 2013 at 11:13 AM, Keith Turner wrote: > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > > > Ill revert this and redo. Still getting used to svn. > > > > let me know if you want me to do the revert. > > > > Corey, > > > > It seems these move were not done is such a way that history was > preserved. > > 'svn move' should be used, it preserves history. Although I never use > > this. When I move things around in eclipse it automatically does 'svn > > move'. > > > > I looked into how to fix this. There does not seem to be an easy way > other > > than reverting the changes and doing a move. > > > > Keith > > > > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > > > > > Author: cjnolet > > > Date: Tue May 21 02:12:28 2013 > > > New Revision: 1484644 > > > > > > URL: http://svn.apache.org/r1484644 > > > Log: > > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > > > > > > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
I just did a revert locally. In your svn status above, was there a reason for not doing an "svn delete mini" to get rid of the mini directory that was created? On Tue, May 21, 2013 at 11:19 AM, Corey Nolet wrote: > I'd like to try it if you don't mind. The only way to learn is to do. > > I'll hold on committing the change until i'm 100% confident that I'm not > going to make the problem worse. > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner wrote: > >> On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: >> >> > Ill revert this and redo. Still getting used to svn. >> > >> >> let me know if you want me to do the revert. >> >> >> > Corey, >> > >> > It seems these move were not done is such a way that history was >> preserved. >> > 'svn move' should be used, it preserves history. Although I never >> use >> > this. When I move things around in eclipse it automatically does 'svn >> > move'. >> > >> > I looked into how to fix this. There does not seem to be an easy way >> other >> > than reverting the changes and doing a move. >> > >> > Keith >> > >> > >> > On Mon, May 20, 2013 at 10:12 PM, wrote: >> > >> > > Author: cjnolet >> > > Date: Tue May 21 02:12:28 2013 >> > > New Revision: 1484644 >> > > >> > > URL: http://svn.apache.org/r1484644 >> > > Log: >> > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module >> > > >> > > >> > >> > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 11:19 AM, Corey Nolet wrote: > I'd like to try it if you don't mind. The only way to learn is to do. > go for it > > I'll hold on committing the change until i'm 100% confident that I'm not > going to make the problem worse. > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner wrote: > > > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > > > > > Ill revert this and redo. Still getting used to svn. > > > > > > > let me know if you want me to do the revert. > > > > > > > Corey, > > > > > > It seems these move were not done is such a way that history was > > preserved. > > > 'svn move' should be used, it preserves history. Although I never > use > > > this. When I move things around in eclipse it automatically does 'svn > > > move'. > > > > > > I looked into how to fix this. There does not seem to be an easy way > > other > > > than reverting the changes and doing a move. > > > > > > Keith > > > > > > > > > On Mon, May 20, 2013 at 10:12 PM, wrote: > > > > > > > Author: cjnolet > > > > Date: Tue May 21 02:12:28 2013 > > > > New Revision: 1484644 > > > > > > > > URL: http://svn.apache.org/r1484644 > > > > Log: > > > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > > > > > > > > > > > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 11:37 AM, Corey Nolet wrote: > I just did a revert locally. In your svn status above, was there a reason > for not doing an "svn delete mini" to get rid of the mini directory that > was created? > No, I was not sure what was going on w/ that directory. I knew there was something screwy, but I did not want to bother figuring out what I should do if you were going to work on it. If you get this to work.. I would be interested in seeing what svn commands you used. > > > On Tue, May 21, 2013 at 11:19 AM, Corey Nolet wrote: > > > I'd like to try it if you don't mind. The only way to learn is to do. > > > > I'll hold on committing the change until i'm 100% confident that I'm not > > going to make the problem worse. > > > > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner wrote: > > > >> On Tue, May 21, 2013 at 10:53 AM, Corey Nolet > wrote: > >> > >> > Ill revert this and redo. Still getting used to svn. > >> > > >> > >> let me know if you want me to do the revert. > >> > >> > >> > Corey, > >> > > >> > It seems these move were not done is such a way that history was > >> preserved. > >> > 'svn move' should be used, it preserves history. Although I never > >> use > >> > this. When I move things around in eclipse it automatically does 'svn > >> > move'. > >> > > >> > I looked into how to fix this. There does not seem to be an easy way > >> other > >> > than reverting the changes and doing a move. > >> > > >> > Keith > >> > > >> > > >> > On Mon, May 20, 2013 at 10:12 PM, wrote: > >> > > >> > > Author: cjnolet > >> > > Date: Tue May 21 02:12:28 2013 > >> > > New Revision: 1484644 > >> > > > >> > > URL: http://svn.apache.org/r1484644 > >> > > Log: > >> > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > >> > > > >> > > > >> > > >> > > > > >
Re: hadoop-2.0 incompatibility
Is this something else we can resolve via reflection or are we back to square 1? On Tue, May 21, 2013 at 11:02 AM, Eric Newton wrote: > Ugh. While running the continuous ingest verify, yarn spit this out: > > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was > expected > > This is preventing the reduce step from completing. > > -Eric >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
Doing "svn merge -r 1484792:1484643 ." seemed to reverse the two commits correctly without any conflicts (it correctly removed the mini/ directory as well). I think this worked. On Tue, May 21, 2013 at 11:40 AM, Keith Turner wrote: > On Tue, May 21, 2013 at 11:37 AM, Corey Nolet wrote: > > > I just did a revert locally. In your svn status above, was there a reason > > for not doing an "svn delete mini" to get rid of the mini directory that > > was created? > > > > No, I was not sure what was going on w/ that directory. I knew there was > something screwy, but I did not want to bother figuring out what I should > do if you were going to work on it. > > If you get this to work.. I would be interested in seeing what svn commands > you used. > > > > > > > > On Tue, May 21, 2013 at 11:19 AM, Corey Nolet wrote: > > > > > I'd like to try it if you don't mind. The only way to learn is to do. > > > > > > I'll hold on committing the change until i'm 100% confident that I'm > not > > > going to make the problem worse. > > > > > > > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner > wrote: > > > > > >> On Tue, May 21, 2013 at 10:53 AM, Corey Nolet > > wrote: > > >> > > >> > Ill revert this and redo. Still getting used to svn. > > >> > > > >> > > >> let me know if you want me to do the revert. > > >> > > >> > > >> > Corey, > > >> > > > >> > It seems these move were not done is such a way that history was > > >> preserved. > > >> > 'svn move' should be used, it preserves history. Although I > never > > >> use > > >> > this. When I move things around in eclipse it automatically does > 'svn > > >> > move'. > > >> > > > >> > I looked into how to fix this. There does not seem to be an easy > way > > >> other > > >> > than reverting the changes and doing a move. > > >> > > > >> > Keith > > >> > > > >> > > > >> > On Mon, May 20, 2013 at 10:12 PM, wrote: > > >> > > > >> > > Author: cjnolet > > >> > > Date: Tue May 21 02:12:28 2013 > > >> > > New Revision: 1484644 > > >> > > > > >> > > URL: http://svn.apache.org/r1484644 > > >> > > Log: > > >> > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > >> > > > > >> > > > > >> > > > >> > > > > > > > > >
Re: hadoop-2.0 incompatibility
On Tue, May 21, 2013 at 11:02 AM, Eric Newton wrote: > Ugh. While running the continuous ingest verify, yarn spit this out: > > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was > expected > > This is preventing the reduce step from completing. > Could fix it in 1.5.1 I am starting to think that hadoop compat was so important, it should have been mostly completed before the feature freeze. > > -Eric >
Re: hadoop-2.0 incompatibility
I'm testing a fix, but I'm not for holding up the release for this. First, calling a method by reflection is quite a bit slower, so even if we fix it, it might not be appropriate. On Tue, May 21, 2013 at 11:49 AM, John Vines wrote: > Is this something else we can resolve via reflection or are we back to > square 1? > > > On Tue, May 21, 2013 at 11:02 AM, Eric Newton > wrote: > > > Ugh. While running the continuous ingest verify, yarn spit this out: > > > > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was > > expected > > > > This is preventing the reduce step from completing. > > > > -Eric > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 11:54 AM, Corey Nolet wrote: > Doing "svn merge -r 1484792:1484643 ." seemed to reverse the two commits > correctly without any conflicts (it correctly removed the mini/ directory > as well). I think this worked. > I suppose only the mini move commits fall in that range? > > > On Tue, May 21, 2013 at 11:40 AM, Keith Turner wrote: > > > On Tue, May 21, 2013 at 11:37 AM, Corey Nolet wrote: > > > > > I just did a revert locally. In your svn status above, was there a > reason > > > for not doing an "svn delete mini" to get rid of the mini directory > that > > > was created? > > > > > > > No, I was not sure what was going on w/ that directory. I knew there was > > something screwy, but I did not want to bother figuring out what I should > > do if you were going to work on it. > > > > If you get this to work.. I would be interested in seeing what svn > commands > > you used. > > > > > > > > > > > > > On Tue, May 21, 2013 at 11:19 AM, Corey Nolet > wrote: > > > > > > > I'd like to try it if you don't mind. The only way to learn is to do. > > > > > > > > I'll hold on committing the change until i'm 100% confident that I'm > > not > > > > going to make the problem worse. > > > > > > > > > > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner > > wrote: > > > > > > > >> On Tue, May 21, 2013 at 10:53 AM, Corey Nolet > > > wrote: > > > >> > > > >> > Ill revert this and redo. Still getting used to svn. > > > >> > > > > >> > > > >> let me know if you want me to do the revert. > > > >> > > > >> > > > >> > Corey, > > > >> > > > > >> > It seems these move were not done is such a way that history was > > > >> preserved. > > > >> > 'svn move' should be used, it preserves history. Although I > > never > > > >> use > > > >> > this. When I move things around in eclipse it automatically does > > 'svn > > > >> > move'. > > > >> > > > > >> > I looked into how to fix this. There does not seem to be an easy > > way > > > >> other > > > >> > than reverting the changes and doing a move. > > > >> > > > > >> > Keith > > > >> > > > > >> > > > > >> > On Mon, May 20, 2013 at 10:12 PM, wrote: > > > >> > > > > >> > > Author: cjnolet > > > >> > > Date: Tue May 21 02:12:28 2013 > > > >> > > New Revision: 1484644 > > > >> > > > > > >> > > URL: http://svn.apache.org/r1484644 > > > >> > > Log: > > > >> > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
Re: hadoop-2.0 incompatibility
We still have the option of putting out a separate build for 1.5.0 compatibility with hadoop 2. Should we vote on that release separately? Seems like it should be easy to add more binary packages that correspond to the same source release, even after the initial vote. Adam On Tue, May 21, 2013 at 11:55 AM, Keith Turner wrote: > On Tue, May 21, 2013 at 11:02 AM, Eric Newton > wrote: > > > Ugh. While running the continuous ingest verify, yarn spit this out: > > > > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was > > expected > > > > This is preventing the reduce step from completing. > > > > Could fix it in 1.5.1 > > I am starting to think that hadoop compat was so important, it should have > been mostly completed before the feature freeze. > > > > > > -Eric > > >
Re: hadoop-2.0 incompatibility
I agree that 1.5.1 is a reasonable target, if it's fixed at all (we don't have Counters in our input/output formats, so the problem would be exclusive to tests/examples anyway). If hadoop compat is a 1.5 feature, this is a minor bug. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 11:55 AM, Keith Turner wrote: > On Tue, May 21, 2013 at 11:02 AM, Eric Newton wrote: > >> Ugh. While running the continuous ingest verify, yarn spit this out: >> >> Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was >> expected >> >> This is preventing the reduce step from completing. >> > > Could fix it in 1.5.1 > > I am starting to think that hadoop compat was so important, it should have > been mostly completed before the feature freeze. > > >> >> -Eric >>
Re: hadoop-2.0 incompatibility
Sure, that's still an option, but I don't think this particular incompatibility makes it necessary, does it? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 12:00 PM, Adam Fuchs wrote: > We still have the option of putting out a separate build for 1.5.0 > compatibility with hadoop 2. Should we vote on that release separately? > Seems like it should be easy to add more binary packages that correspond to > the same source release, even after the initial vote. > > Adam > > > > On Tue, May 21, 2013 at 11:55 AM, Keith Turner wrote: > >> On Tue, May 21, 2013 at 11:02 AM, Eric Newton >> wrote: >> >> > Ugh. While running the continuous ingest verify, yarn spit this out: >> > >> > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class was >> > expected >> > >> > This is preventing the reduce step from completing. >> > >> >> Could fix it in 1.5.1 >> >> I am starting to think that hadoop compat was so important, it should have >> been mostly completed before the feature freeze. >> >> >> > >> > -Eric >> > >>
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
git-svn is likely to do worse with preserving svn history. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 11:05 AM, Vincent Russell wrote: > Corey, > > You should try git-svn. That should give you an interface that you are used > to. > > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: >> Ill revert this and redo. Still getting used to svn. >> Corey, >> >> It seems these move were not done is such a way that history was preserved. >> 'svn move' should be used, it preserves history. Although I never use >> this. When I move things around in eclipse it automatically does 'svn >> move'. >> >> I looked into how to fix this. There does not seem to be an easy way other >> than reverting the changes and doing a move. >> >> Keith >> >> >> On Mon, May 20, 2013 at 10:12 PM, wrote: >> >>> Author: cjnolet >>> Date: Tue May 21 02:12:28 2013 >>> New Revision: 1484644 >>> >>> URL: http://svn.apache.org/r1484644 >>> Log: >>> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module >>> >>>
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
Keith: Correct. If you specify the revisions in reverse order, it reverses those commits. I'm comfortable with this change and ready to push up. Here's what I'll do: Revert changes in 1.4.4 Revert changes in 1.5 Revert changes in 1.6 Merge 1.5 to 1.6 Is this what you were describing above Keith? On Tue, May 21, 2013 at 12:03 PM, Christopher wrote: > git-svn is likely to do worse with preserving svn history. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, May 21, 2013 at 11:05 AM, Vincent Russell > wrote: > > Corey, > > > > You should try git-svn. That should give you an interface that you are > used to. > > > > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet wrote: > >> Ill revert this and redo. Still getting used to svn. > >> Corey, > >> > >> It seems these move were not done is such a way that history was > preserved. > >> 'svn move' should be used, it preserves history. Although I never > use > >> this. When I move things around in eclipse it automatically does 'svn > >> move'. > >> > >> I looked into how to fix this. There does not seem to be an easy way > other > >> than reverting the changes and doing a move. > >> > >> Keith > >> > >> > >> On Mon, May 20, 2013 at 10:12 PM, wrote: > >> > >>> Author: cjnolet > >>> Date: Tue May 21 02:12:28 2013 > >>> New Revision: 1484644 > >>> > >>> URL: http://svn.apache.org/r1484644 > >>> Log: > >>> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > >>> > >>> >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 11:58 AM, Keith Turner wrote: > On Tue, May 21, 2013 at 11:54 AM, Corey Nolet wrote: > >> Doing "svn merge -r 1484792:1484643 ." seemed to reverse the two commits >> correctly without any conflicts (it correctly removed the mini/ directory >> as well). I think this worked. >> > > I suppose only the mini move commits fall in that range? Hopefully... otherwise, the alternative to reverse a merge is to do: svn merge -c -ZZ,-YY,-XX (note the dash prior to each rev, and that the revs are in descending order... or ascending towards zero, if you treat the dash as a negative sign) >> >> >> On Tue, May 21, 2013 at 11:40 AM, Keith Turner wrote: >> >> > On Tue, May 21, 2013 at 11:37 AM, Corey Nolet wrote: >> > >> > > I just did a revert locally. In your svn status above, was there a >> reason >> > > for not doing an "svn delete mini" to get rid of the mini directory >> that >> > > was created? >> > > >> > >> > No, I was not sure what was going on w/ that directory. I knew there was >> > something screwy, but I did not want to bother figuring out what I should >> > do if you were going to work on it. >> > >> > If you get this to work.. I would be interested in seeing what svn >> commands >> > you used. >> > >> > >> > > >> > > >> > > On Tue, May 21, 2013 at 11:19 AM, Corey Nolet >> wrote: >> > > >> > > > I'd like to try it if you don't mind. The only way to learn is to do. >> > > > >> > > > I'll hold on committing the change until i'm 100% confident that I'm >> > not >> > > > going to make the problem worse. >> > > > >> > > > >> > > > On Tue, May 21, 2013 at 11:13 AM, Keith Turner >> > wrote: >> > > > >> > > >> On Tue, May 21, 2013 at 10:53 AM, Corey Nolet >> > > wrote: >> > > >> >> > > >> > Ill revert this and redo. Still getting used to svn. >> > > >> > >> > > >> >> > > >> let me know if you want me to do the revert. >> > > >> >> > > >> >> > > >> > Corey, >> > > >> > >> > > >> > It seems these move were not done is such a way that history was >> > > >> preserved. >> > > >> > 'svn move' should be used, it preserves history. Although I >> > never >> > > >> use >> > > >> > this. When I move things around in eclipse it automatically does >> > 'svn >> > > >> > move'. >> > > >> > >> > > >> > I looked into how to fix this. There does not seem to be an easy >> > way >> > > >> other >> > > >> > than reverting the changes and doing a move. >> > > >> > >> > > >> > Keith >> > > >> > >> > > >> > >> > > >> > On Mon, May 20, 2013 at 10:12 PM, wrote: >> > > >> > >> > > >> > > Author: cjnolet >> > > >> > > Date: Tue May 21 02:12:28 2013 >> > > >> > > New Revision: 1484644 >> > > >> > > >> > > >> > > URL: http://svn.apache.org/r1484644 >> > > >> > > Log: >> > > >> > > ACCUMULO-1438 Moving MiniAccumuloCluster into mini module >> > > >> > > >> > > >> > > >> > > >> > >> > > >> >> > > > >> > > > >> > > >> > >>
Re: dependencies within 1.5
I think it's worth asking because a few people expressed interest in moving the mini cluster to it's own module. Do we want this for 1.5 or do we wait until 1.6 and provide a deprecation strategy? On Mon, May 20, 2013 at 2:10 PM, Corey Nolet wrote: > Agreed, they also slow down the build. > > > On Mon, May 20, 2013 at 2:09 PM, Christopher wrote: > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, >> might be useful. >> I'd probably argue for it to be in a de-activated profile, by default, >> though. Shaded jars can become problematic if people start using them >> as dependencies. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet wrote: >> > This may be far out into space- but how would you guys feel about >> providing >> > a shaded jar in the pom for a new mini module? This may make it easier >> for >> > users to run the mini accumulo cluster without hadoop/zookeeper >> installed. >> > >> > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher >> wrote: >> > >> >> ACCUMULO-1436 for fixing "provided" dependencies. >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> >> >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher >> wrote: >> >> > You're right. I'm not sure why our internal dependencies would be >> >> > marked as provided... except maybe I made that mistake to try to deal >> >> > with the mess of the 'copy-dependencies' stuff. That should be fixed. >> >> > >> >> > -- >> >> > Christopher L Tubbs II >> >> > http://gravatar.com/ctubbsii >> >> > >> >> > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines >> wrote: >> >> >> Jim, accumulo-start is a provided dependency for all of the other >> >> versions. >> >> >> So when you list accumulo-server as a dependency, it does not pull >> in >> >> the >> >> >> provided dependencies. >> >> >> >> >> >> This is sort of what I was getting at before, Chris. The provided >> jars >> >> >> don't get pulled in/referenced when they are marked as provided. For >> >> >> external dependencies, that totally makes sense. But I don't know >> why we >> >> >> need to mark other accumulo parts as provided. I find it difficult >> to >> >> >> believe that that is a standard maven configuration. It is extremely >> >> >> painful for downstream clients. >> >> >> >> >> >> >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar >> wrote: >> >> >> >> >> >>> The question mark was in my statement because I didn't actually >> know >> >> if it >> >> >>> created a circular dependency. It appears that Corey found it >> doesn't >> >> have >> >> >>> one. All I did was put a dependency on accumulo-master and saw that >> >> when I >> >> >>> did so, Maven didn't pull accumulo-start for me. From my >> understanding, >> >> >>> that is the whole point of Maven, to handle the sub-dependencies of >> >> what >> >> >>> I'm trying to use and when I tried to use MiniAccumuloCluster, it >> >> didn't >> >> >>> pull all the right dependencies. >> >> >>> >> >> >>> >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet >> >> wrote: >> >> >>> >> >> >>> > I take that back- the start module does not have an explicit >> >> dependency >> >> >>> on >> >> >>> > accumulo-server. As long as the Main.class is used from the >> assembly >> >> >>> > artifact's classpath, everything should work fine. >> >> >>> > >> >> >>> > >> >> >>> > On Mon, May 20, 2013 at 8:21 AM, Corey Nolet >> >> wrote: >> >> >>> > >> >> >>> > > The only part that makes a circular dependency is including the >> >> >>> > > MiniAccumuloRunner in the Main.class. I'm not sure if that >> warrants >> >> >>> > needing >> >> >>> > > to rearchitect the runner, since it was made to give users the >> >> ability >> >> >>> to >> >> >>> > > interact with the Miniaccumulocluster as a single node >> accumulo. >> >> It was >> >> >>> > > also made to make the maven plugin much easier and standardize >> the >> >> >>> > > interface. Seems like two options are to remove the runner >> option >> >> from >> >> >>> > the >> >> >>> > > Main.class or move it to the start module. >> >> >>> > > >> >> >>> > > Personally, I'd opt for moving the runner to the start module. >> >> >>> > > On May 20, 2013 8:12 AM, "David Medinets" < >> >> david.medin...@gmail.com> >> >> >>> > > wrote: >> >> >>> > > >> >> >>> > >> Combine this work with Dave Marion's work and put >> >> MiniAccumuloRunner >> >> >>> > into >> >> >>> > >> an add-on script? >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> On Mon, May 20, 2013 at 7:49 AM, Corey Nolet < >> cjno...@gmail.com> >> >> >>> wrote: >> >> >>> > >> >> >> >>> > >> > I think the ability to run "./bin/accumulo mini" may have >> >> introduced >> >> >>> > >> this >> >> >>> > >> > circular dependency. Perhaps the MiniAccumuloRunner should >> be >> >> moved >> >> >>> > >> > somewhere else. >> >> >>> > >> > On May 20, 2013 12:07 AM, "Christopher" < >> ctubb...@apache.org> >> >> >>> wrote: >> >> >>> > >> > >> >> >>> > >> > > What do yo
Re: dependencies within 1.5
On Tue, May 21, 2013 at 12:16 PM, Corey Nolet wrote: > I think it's worth asking because a few people expressed interest in moving > the mini cluster to it's own module. Do we want this for 1.5 or do we wait > until 1.6 and provide a deprecation strategy? > I think we should move it in 1.5 XOR leave the package name the same in 1.6, but move it to another module. Either way avoids API changes for users. > > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet wrote: > > > Agreed, they also slow down the build. > > > > > > On Mon, May 20, 2013 at 2:09 PM, Christopher > wrote: > > > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, > >> might be useful. > >> I'd probably argue for it to be in a de-activated profile, by default, > >> though. Shaded jars can become problematic if people start using them > >> as dependencies. > >> > >> -- > >> Christopher L Tubbs II > >> http://gravatar.com/ctubbsii > >> > >> > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet wrote: > >> > This may be far out into space- but how would you guys feel about > >> providing > >> > a shaded jar in the pom for a new mini module? This may make it easier > >> for > >> > users to run the mini accumulo cluster without hadoop/zookeeper > >> installed. > >> > > >> > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher > >> wrote: > >> > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > >> >> > >> >> -- > >> >> Christopher L Tubbs II > >> >> http://gravatar.com/ctubbsii > >> >> > >> >> > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher > >> wrote: > >> >> > You're right. I'm not sure why our internal dependencies would be > >> >> > marked as provided... except maybe I made that mistake to try to > deal > >> >> > with the mess of the 'copy-dependencies' stuff. That should be > fixed. > >> >> > > >> >> > -- > >> >> > Christopher L Tubbs II > >> >> > http://gravatar.com/ctubbsii > >> >> > > >> >> > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines > >> wrote: > >> >> >> Jim, accumulo-start is a provided dependency for all of the other > >> >> versions. > >> >> >> So when you list accumulo-server as a dependency, it does not pull > >> in > >> >> the > >> >> >> provided dependencies. > >> >> >> > >> >> >> This is sort of what I was getting at before, Chris. The provided > >> jars > >> >> >> don't get pulled in/referenced when they are marked as provided. > For > >> >> >> external dependencies, that totally makes sense. But I don't know > >> why we > >> >> >> need to mark other accumulo parts as provided. I find it difficult > >> to > >> >> >> believe that that is a standard maven configuration. It is > extremely > >> >> >> painful for downstream clients. > >> >> >> > >> >> >> > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar > >> wrote: > >> >> >> > >> >> >>> The question mark was in my statement because I didn't actually > >> know > >> >> if it > >> >> >>> created a circular dependency. It appears that Corey found it > >> doesn't > >> >> have > >> >> >>> one. All I did was put a dependency on accumulo-master and saw > that > >> >> when I > >> >> >>> did so, Maven didn't pull accumulo-start for me. From my > >> understanding, > >> >> >>> that is the whole point of Maven, to handle the sub-dependencies > of > >> >> what > >> >> >>> I'm trying to use and when I tried to use MiniAccumuloCluster, it > >> >> didn't > >> >> >>> pull all the right dependencies. > >> >> >>> > >> >> >>> > >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet > >> >> wrote: > >> >> >>> > >> >> >>> > I take that back- the start module does not have an explicit > >> >> dependency > >> >> >>> on > >> >> >>> > accumulo-server. As long as the Main.class is used from the > >> assembly > >> >> >>> > artifact's classpath, everything should work fine. > >> >> >>> > > >> >> >>> > > >> >> >>> > On Mon, May 20, 2013 at 8:21 AM, Corey Nolet < > cjno...@gmail.com> > >> >> wrote: > >> >> >>> > > >> >> >>> > > The only part that makes a circular dependency is including > the > >> >> >>> > > MiniAccumuloRunner in the Main.class. I'm not sure if that > >> warrants > >> >> >>> > needing > >> >> >>> > > to rearchitect the runner, since it was made to give users > the > >> >> ability > >> >> >>> to > >> >> >>> > > interact with the Miniaccumulocluster as a single node > >> accumulo. > >> >> It was > >> >> >>> > > also made to make the maven plugin much easier and > standardize > >> the > >> >> >>> > > interface. Seems like two options are to remove the runner > >> option > >> >> from > >> >> >>> > the > >> >> >>> > > Main.class or move it to the start module. > >> >> >>> > > > >> >> >>> > > Personally, I'd opt for moving the runner to the start > module. > >> >> >>> > > On May 20, 2013 8:12 AM, "David Medinets" < > >> >> david.medin...@gmail.com> > >> >> >>> > > wrote: > >> >> >>> > > > >> >> >>> > >> Combine this work with Dave Marion's work and put > >> >> MiniAccumuloRunner > >> >> >>> > into > >> >> >>> > >> an add-on script? > >> >> >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 12:09 PM, Corey Nolet wrote: > Keith: Correct. If you specify the revisions in reverse order, it reverses > those commits. > > I'm comfortable with this change and ready to push up. Here's what I'll do: > > Revert changes in 1.4.4 > Revert changes in 1.5 > Revert changes in 1.6 > Merge 1.5 to 1.6 > > Is this what you were describing above Keith? > That is what I was thinking. > > > On Tue, May 21, 2013 at 12:03 PM, Christopher wrote: > > > git-svn is likely to do worse with preserving svn history. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, May 21, 2013 at 11:05 AM, Vincent Russell > > wrote: > > > Corey, > > > > > > You should try git-svn. That should give you an interface that you are > > used to. > > > > > > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet > wrote: > > >> Ill revert this and redo. Still getting used to svn. > > >> Corey, > > >> > > >> It seems these move were not done is such a way that history was > > preserved. > > >> 'svn move' should be used, it preserves history. Although I never > > use > > >> this. When I move things around in eclipse it automatically does 'svn > > >> move'. > > >> > > >> I looked into how to fix this. There does not seem to be an easy way > > other > > >> than reverting the changes and doing a move. > > >> > > >> Keith > > >> > > >> > > >> On Mon, May 20, 2013 at 10:12 PM, wrote: > > >> > > >>> Author: cjnolet > > >>> Date: Tue May 21 02:12:28 2013 > > >>> New Revision: 1484644 > > >>> > > >>> URL: http://svn.apache.org/r1484644 > > >>> Log: > > >>> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > >>> > > >>> > > >
Re: svn commit: r1484644 - in /accumulo/branches/1.5: ./ mini/ mini/src/ mini/src/main/ mini/src/main/java/ mini/src/main/java/org/ mini/src/main/java/org/apache/ mini/src/main/java/org/apache/accumul
On Tue, May 21, 2013 at 12:09 PM, Corey Nolet wrote: > Keith: Correct. If you specify the revisions in reverse order, it reverses > those commits. > > I'm comfortable with this change and ready to push up. Here's what I'll do: > > Revert changes in 1.4.4 > Revert changes in 1.5 > Revert changes in 1.6 > Merge 1.5 to 1.6 > > Is this what you were describing above Keith? > slightly unrelated. We are trying to keep 1.5 and 1.6 in a state such that "svn merge -r 1:HEAD 1.5 1.6" will work nicely. The point of this is to ensure that bug fixes made in 1.5 are also made in 1.6. > > > On Tue, May 21, 2013 at 12:03 PM, Christopher wrote: > > > git-svn is likely to do worse with preserving svn history. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, May 21, 2013 at 11:05 AM, Vincent Russell > > wrote: > > > Corey, > > > > > > You should try git-svn. That should give you an interface that you are > > used to. > > > > > > On Tue, May 21, 2013 at 10:53 AM, Corey Nolet > wrote: > > >> Ill revert this and redo. Still getting used to svn. > > >> Corey, > > >> > > >> It seems these move were not done is such a way that history was > > preserved. > > >> 'svn move' should be used, it preserves history. Although I never > > use > > >> this. When I move things around in eclipse it automatically does 'svn > > >> move'. > > >> > > >> I looked into how to fix this. There does not seem to be an easy way > > other > > >> than reverting the changes and doing a move. > > >> > > >> Keith > > >> > > >> > > >> On Mon, May 20, 2013 at 10:12 PM, wrote: > > >> > > >>> Author: cjnolet > > >>> Date: Tue May 21 02:12:28 2013 > > >>> New Revision: 1484644 > > >>> > > >>> URL: http://svn.apache.org/r1484644 > > >>> Log: > > >>> ACCUMULO-1438 Moving MiniAccumuloCluster into mini module > > >>> > > >>> > > >
Re: dependencies within 1.5
I think we should move it in 1.5. The bug Eric found this morning, along with the laundry list of non-breakers, are enough for an RC5 to be cut. This should be pulled in. Having packages not align with modules causes nothing must frustration and confusion when trying to debug things. On Tue, May 21, 2013 at 12:27 PM, Keith Turner wrote: > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet wrote: > > > I think it's worth asking because a few people expressed interest in > moving > > the mini cluster to it's own module. Do we want this for 1.5 or do we > wait > > until 1.6 and provide a deprecation strategy? > > > > I think we should move it in 1.5 XOR leave the package name the same in > 1.6, but move it to another module. Either way avoids API changes for > users. > > > > > > > > > > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet wrote: > > > > > Agreed, they also slow down the build. > > > > > > > > > On Mon, May 20, 2013 at 2:09 PM, Christopher > > wrote: > > > > > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, > > >> might be useful. > > >> I'd probably argue for it to be in a de-activated profile, by default, > > >> though. Shaded jars can become problematic if people start using them > > >> as dependencies. > > >> > > >> -- > > >> Christopher L Tubbs II > > >> http://gravatar.com/ctubbsii > > >> > > >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet > wrote: > > >> > This may be far out into space- but how would you guys feel about > > >> providing > > >> > a shaded jar in the pom for a new mini module? This may make it > easier > > >> for > > >> > users to run the mini accumulo cluster without hadoop/zookeeper > > >> installed. > > >> > > > >> > > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher > > >> wrote: > > >> > > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > > >> >> > > >> >> -- > > >> >> Christopher L Tubbs II > > >> >> http://gravatar.com/ctubbsii > > >> >> > > >> >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher > > > >> wrote: > > >> >> > You're right. I'm not sure why our internal dependencies would be > > >> >> > marked as provided... except maybe I made that mistake to try to > > deal > > >> >> > with the mess of the 'copy-dependencies' stuff. That should be > > fixed. > > >> >> > > > >> >> > -- > > >> >> > Christopher L Tubbs II > > >> >> > http://gravatar.com/ctubbsii > > >> >> > > > >> >> > > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines > > >> wrote: > > >> >> >> Jim, accumulo-start is a provided dependency for all of the > other > > >> >> versions. > > >> >> >> So when you list accumulo-server as a dependency, it does not > pull > > >> in > > >> >> the > > >> >> >> provided dependencies. > > >> >> >> > > >> >> >> This is sort of what I was getting at before, Chris. The > provided > > >> jars > > >> >> >> don't get pulled in/referenced when they are marked as provided. > > For > > >> >> >> external dependencies, that totally makes sense. But I don't > know > > >> why we > > >> >> >> need to mark other accumulo parts as provided. I find it > difficult > > >> to > > >> >> >> believe that that is a standard maven configuration. It is > > extremely > > >> >> >> painful for downstream clients. > > >> >> >> > > >> >> >> > > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar > > >> wrote: > > >> >> >> > > >> >> >>> The question mark was in my statement because I didn't actually > > >> know > > >> >> if it > > >> >> >>> created a circular dependency. It appears that Corey found it > > >> doesn't > > >> >> have > > >> >> >>> one. All I did was put a dependency on accumulo-master and saw > > that > > >> >> when I > > >> >> >>> did so, Maven didn't pull accumulo-start for me. From my > > >> understanding, > > >> >> >>> that is the whole point of Maven, to handle the > sub-dependencies > > of > > >> >> what > > >> >> >>> I'm trying to use and when I tried to use MiniAccumuloCluster, > it > > >> >> didn't > > >> >> >>> pull all the right dependencies. > > >> >> >>> > > >> >> >>> > > >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet < > cjno...@gmail.com> > > >> >> wrote: > > >> >> >>> > > >> >> >>> > I take that back- the start module does not have an explicit > > >> >> dependency > > >> >> >>> on > > >> >> >>> > accumulo-server. As long as the Main.class is used from the > > >> assembly > > >> >> >>> > artifact's classpath, everything should work fine. > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > On Mon, May 20, 2013 at 8:21 AM, Corey Nolet < > > cjno...@gmail.com> > > >> >> wrote: > > >> >> >>> > > > >> >> >>> > > The only part that makes a circular dependency is including > > the > > >> >> >>> > > MiniAccumuloRunner in the Main.class. I'm not sure if that > > >> warrants > > >> >> >>> > needing > > >> >> >>> > > to rearchitect the runner, since it was made to give users > > the > > >> >> ability > > >> >> >>> to > > >> >> >>> > > interact with the Miniaccumulocluster as a single node > > >> accumulo. > > >> >> I
Re: dependencies within 1.5
I know it's not a requirement to support OSGi environments but past experience has led me to try to maintain like packages within jars and not split them across jars if at all possible. I've had grueling problems trying to integrate Accumulo into Apache Karaf containers and spend hours troubleshooting to find that the cause was packages being split between jars. That being said- we could simply make note of it to users who are planning on integrating with OSGi environments because they can easily create uber-jars containing everything... but if we can fix that now in 1.5, I'd be more apt to do that. On Tue, May 21, 2013 at 12:27 PM, Keith Turner wrote: > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet wrote: > > > I think it's worth asking because a few people expressed interest in > moving > > the mini cluster to it's own module. Do we want this for 1.5 or do we > wait > > until 1.6 and provide a deprecation strategy? > > > > I think we should move it in 1.5 XOR leave the package name the same in > 1.6, but move it to another module. Either way avoids API changes for > users. > > > > > > > > > > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet wrote: > > > > > Agreed, they also slow down the build. > > > > > > > > > On Mon, May 20, 2013 at 2:09 PM, Christopher > > wrote: > > > > > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, > > >> might be useful. > > >> I'd probably argue for it to be in a de-activated profile, by default, > > >> though. Shaded jars can become problematic if people start using them > > >> as dependencies. > > >> > > >> -- > > >> Christopher L Tubbs II > > >> http://gravatar.com/ctubbsii > > >> > > >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet > wrote: > > >> > This may be far out into space- but how would you guys feel about > > >> providing > > >> > a shaded jar in the pom for a new mini module? This may make it > easier > > >> for > > >> > users to run the mini accumulo cluster without hadoop/zookeeper > > >> installed. > > >> > > > >> > > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher > > >> wrote: > > >> > > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > > >> >> > > >> >> -- > > >> >> Christopher L Tubbs II > > >> >> http://gravatar.com/ctubbsii > > >> >> > > >> >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher > > > >> wrote: > > >> >> > You're right. I'm not sure why our internal dependencies would be > > >> >> > marked as provided... except maybe I made that mistake to try to > > deal > > >> >> > with the mess of the 'copy-dependencies' stuff. That should be > > fixed. > > >> >> > > > >> >> > -- > > >> >> > Christopher L Tubbs II > > >> >> > http://gravatar.com/ctubbsii > > >> >> > > > >> >> > > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines > > >> wrote: > > >> >> >> Jim, accumulo-start is a provided dependency for all of the > other > > >> >> versions. > > >> >> >> So when you list accumulo-server as a dependency, it does not > pull > > >> in > > >> >> the > > >> >> >> provided dependencies. > > >> >> >> > > >> >> >> This is sort of what I was getting at before, Chris. The > provided > > >> jars > > >> >> >> don't get pulled in/referenced when they are marked as provided. > > For > > >> >> >> external dependencies, that totally makes sense. But I don't > know > > >> why we > > >> >> >> need to mark other accumulo parts as provided. I find it > difficult > > >> to > > >> >> >> believe that that is a standard maven configuration. It is > > extremely > > >> >> >> painful for downstream clients. > > >> >> >> > > >> >> >> > > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar > > >> wrote: > > >> >> >> > > >> >> >>> The question mark was in my statement because I didn't actually > > >> know > > >> >> if it > > >> >> >>> created a circular dependency. It appears that Corey found it > > >> doesn't > > >> >> have > > >> >> >>> one. All I did was put a dependency on accumulo-master and saw > > that > > >> >> when I > > >> >> >>> did so, Maven didn't pull accumulo-start for me. From my > > >> understanding, > > >> >> >>> that is the whole point of Maven, to handle the > sub-dependencies > > of > > >> >> what > > >> >> >>> I'm trying to use and when I tried to use MiniAccumuloCluster, > it > > >> >> didn't > > >> >> >>> pull all the right dependencies. > > >> >> >>> > > >> >> >>> > > >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet < > cjno...@gmail.com> > > >> >> wrote: > > >> >> >>> > > >> >> >>> > I take that back- the start module does not have an explicit > > >> >> dependency > > >> >> >>> on > > >> >> >>> > accumulo-server. As long as the Main.class is used from the > > >> assembly > > >> >> >>> > artifact's classpath, everything should work fine. > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > On Mon, May 20, 2013 at 8:21 AM, Corey Nolet < > > cjno...@gmail.com> > > >> >> wrote: > > >> >> >>> > > > >> >> >>> > > The only part that makes a circular dependency is including > > the > > >> >> >>> >
Re: dependencies within 1.5
On Tue, May 21, 2013 at 12:34 PM, John Vines wrote: > I think we should move it in 1.5. The bug Eric found this morning, along > Thats ok w/ me. I mostly want to avoid the deprecation route. > with the laundry list of non-breakers, are enough for an RC5 to be cut. > This should be pulled in. Having packages not align with modules causes > nothing must frustration and confusion when trying to debug things. > > > On Tue, May 21, 2013 at 12:27 PM, Keith Turner wrote: > > > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet wrote: > > > > > I think it's worth asking because a few people expressed interest in > > moving > > > the mini cluster to it's own module. Do we want this for 1.5 or do we > > wait > > > until 1.6 and provide a deprecation strategy? > > > > > > > I think we should move it in 1.5 XOR leave the package name the same in > > 1.6, but move it to another module. Either way avoids API changes for > > users. > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet > wrote: > > > > > > > Agreed, they also slow down the build. > > > > > > > > > > > > On Mon, May 20, 2013 at 2:09 PM, Christopher > > > wrote: > > > > > > > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, > > > >> might be useful. > > > >> I'd probably argue for it to be in a de-activated profile, by > default, > > > >> though. Shaded jars can become problematic if people start using > them > > > >> as dependencies. > > > >> > > > >> -- > > > >> Christopher L Tubbs II > > > >> http://gravatar.com/ctubbsii > > > >> > > > >> > > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet > > wrote: > > > >> > This may be far out into space- but how would you guys feel about > > > >> providing > > > >> > a shaded jar in the pom for a new mini module? This may make it > > easier > > > >> for > > > >> > users to run the mini accumulo cluster without hadoop/zookeeper > > > >> installed. > > > >> > > > > >> > > > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher > > > > >> wrote: > > > >> > > > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > > > >> >> > > > >> >> -- > > > >> >> Christopher L Tubbs II > > > >> >> http://gravatar.com/ctubbsii > > > >> >> > > > >> >> > > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher < > ctubb...@apache.org > > > > > > >> wrote: > > > >> >> > You're right. I'm not sure why our internal dependencies would > be > > > >> >> > marked as provided... except maybe I made that mistake to try > to > > > deal > > > >> >> > with the mess of the 'copy-dependencies' stuff. That should be > > > fixed. > > > >> >> > > > > >> >> > -- > > > >> >> > Christopher L Tubbs II > > > >> >> > http://gravatar.com/ctubbsii > > > >> >> > > > > >> >> > > > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines > > > > >> wrote: > > > >> >> >> Jim, accumulo-start is a provided dependency for all of the > > other > > > >> >> versions. > > > >> >> >> So when you list accumulo-server as a dependency, it does not > > pull > > > >> in > > > >> >> the > > > >> >> >> provided dependencies. > > > >> >> >> > > > >> >> >> This is sort of what I was getting at before, Chris. The > > provided > > > >> jars > > > >> >> >> don't get pulled in/referenced when they are marked as > provided. > > > For > > > >> >> >> external dependencies, that totally makes sense. But I don't > > know > > > >> why we > > > >> >> >> need to mark other accumulo parts as provided. I find it > > difficult > > > >> to > > > >> >> >> believe that that is a standard maven configuration. It is > > > extremely > > > >> >> >> painful for downstream clients. > > > >> >> >> > > > >> >> >> > > > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar > > > > >> wrote: > > > >> >> >> > > > >> >> >>> The question mark was in my statement because I didn't > actually > > > >> know > > > >> >> if it > > > >> >> >>> created a circular dependency. It appears that Corey found it > > > >> doesn't > > > >> >> have > > > >> >> >>> one. All I did was put a dependency on accumulo-master and > saw > > > that > > > >> >> when I > > > >> >> >>> did so, Maven didn't pull accumulo-start for me. From my > > > >> understanding, > > > >> >> >>> that is the whole point of Maven, to handle the > > sub-dependencies > > > of > > > >> >> what > > > >> >> >>> I'm trying to use and when I tried to use > MiniAccumuloCluster, > > it > > > >> >> didn't > > > >> >> >>> pull all the right dependencies. > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet < > > cjno...@gmail.com> > > > >> >> wrote: > > > >> >> >>> > > > >> >> >>> > I take that back- the start module does not have an > explicit > > > >> >> dependency > > > >> >> >>> on > > > >> >> >>> > accumulo-server. As long as the Main.class is used from the > > > >> assembly > > > >> >> >>> > artifact's classpath, everything should work fine. > > > >> >> >>> > > > > >> >> >>> > > > > >> >> >>> > On Mon, May 20, 2013 at 8:21 AM, Corey Nolet < > > > cjno...@gmail
Re: dependencies within 1.5
+1 for moving it in 1.5 for all the previous reasons specified. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 12:36 PM, Keith Turner wrote: > On Tue, May 21, 2013 at 12:34 PM, John Vines wrote: > >> I think we should move it in 1.5. The bug Eric found this morning, along >> > > Thats ok w/ me. I mostly want to avoid the deprecation route. > > > >> with the laundry list of non-breakers, are enough for an RC5 to be cut. >> This should be pulled in. Having packages not align with modules causes >> nothing must frustration and confusion when trying to debug things. >> >> >> On Tue, May 21, 2013 at 12:27 PM, Keith Turner wrote: >> >> > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet wrote: >> > >> > > I think it's worth asking because a few people expressed interest in >> > moving >> > > the mini cluster to it's own module. Do we want this for 1.5 or do we >> > wait >> > > until 1.6 and provide a deprecation strategy? >> > > >> > >> > I think we should move it in 1.5 XOR leave the package name the same in >> > 1.6, but move it to another module. Either way avoids API changes for >> > users. >> > >> > >> > >> > >> > >> > > >> > > >> > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet >> wrote: >> > > >> > > > Agreed, they also slow down the build. >> > > > >> > > > >> > > > On Mon, May 20, 2013 at 2:09 PM, Christopher >> > > wrote: >> > > > >> > > >> Maybe... or 'jar-with-dependencies' assembly, or something similar, >> > > >> might be useful. >> > > >> I'd probably argue for it to be in a de-activated profile, by >> default, >> > > >> though. Shaded jars can become problematic if people start using >> them >> > > >> as dependencies. >> > > >> >> > > >> -- >> > > >> Christopher L Tubbs II >> > > >> http://gravatar.com/ctubbsii >> > > >> >> > > >> >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet >> > wrote: >> > > >> > This may be far out into space- but how would you guys feel about >> > > >> providing >> > > >> > a shaded jar in the pom for a new mini module? This may make it >> > easier >> > > >> for >> > > >> > users to run the mini accumulo cluster without hadoop/zookeeper >> > > >> installed. >> > > >> > >> > > >> > >> > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher > > >> > > >> wrote: >> > > >> > >> > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. >> > > >> >> >> > > >> >> -- >> > > >> >> Christopher L Tubbs II >> > > >> >> http://gravatar.com/ctubbsii >> > > >> >> >> > > >> >> >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher < >> ctubb...@apache.org >> > > >> > > >> wrote: >> > > >> >> > You're right. I'm not sure why our internal dependencies would >> be >> > > >> >> > marked as provided... except maybe I made that mistake to try >> to >> > > deal >> > > >> >> > with the mess of the 'copy-dependencies' stuff. That should be >> > > fixed. >> > > >> >> > >> > > >> >> > -- >> > > >> >> > Christopher L Tubbs II >> > > >> >> > http://gravatar.com/ctubbsii >> > > >> >> > >> > > >> >> > >> > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines > > >> > > >> wrote: >> > > >> >> >> Jim, accumulo-start is a provided dependency for all of the >> > other >> > > >> >> versions. >> > > >> >> >> So when you list accumulo-server as a dependency, it does not >> > pull >> > > >> in >> > > >> >> the >> > > >> >> >> provided dependencies. >> > > >> >> >> >> > > >> >> >> This is sort of what I was getting at before, Chris. The >> > provided >> > > >> jars >> > > >> >> >> don't get pulled in/referenced when they are marked as >> provided. >> > > For >> > > >> >> >> external dependencies, that totally makes sense. But I don't >> > know >> > > >> why we >> > > >> >> >> need to mark other accumulo parts as provided. I find it >> > difficult >> > > >> to >> > > >> >> >> believe that that is a standard maven configuration. It is >> > > extremely >> > > >> >> >> painful for downstream clients. >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar > > >> > > >> wrote: >> > > >> >> >> >> > > >> >> >>> The question mark was in my statement because I didn't >> actually >> > > >> know >> > > >> >> if it >> > > >> >> >>> created a circular dependency. It appears that Corey found it >> > > >> doesn't >> > > >> >> have >> > > >> >> >>> one. All I did was put a dependency on accumulo-master and >> saw >> > > that >> > > >> >> when I >> > > >> >> >>> did so, Maven didn't pull accumulo-start for me. From my >> > > >> understanding, >> > > >> >> >>> that is the whole point of Maven, to handle the >> > sub-dependencies >> > > of >> > > >> >> what >> > > >> >> >>> I'm trying to use and when I tried to use >> MiniAccumuloCluster, >> > it >> > > >> >> didn't >> > > >> >> >>> pull all the right dependencies. >> > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> On Mon, May 20, 2013 at 8:44 AM, Corey Nolet < >> > cjno...@gmail.com> >> > > >> >> wrote: >> > > >> >> >>> >> > > >> >> >>> > I take that back- the start module does not have an >
Re: dependencies within 1.5
Hadoop's module is "hadoop-minicluster" so I'm thinking of making "accumulo-minicluster". I'm also thinking the package should be "o.a.a.minicluster" Any objections? On Tue, May 21, 2013 at 12:50 PM, Christopher wrote: > +1 for moving it in 1.5 for all the previous reasons specified. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, May 21, 2013 at 12:36 PM, Keith Turner wrote: > > On Tue, May 21, 2013 at 12:34 PM, John Vines wrote: > > > >> I think we should move it in 1.5. The bug Eric found this morning, along > >> > > > > Thats ok w/ me. I mostly want to avoid the deprecation route. > > > > > > > >> with the laundry list of non-breakers, are enough for an RC5 to be cut. > >> This should be pulled in. Having packages not align with modules causes > >> nothing must frustration and confusion when trying to debug things. > >> > >> > >> On Tue, May 21, 2013 at 12:27 PM, Keith Turner > wrote: > >> > >> > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet > wrote: > >> > > >> > > I think it's worth asking because a few people expressed interest in > >> > moving > >> > > the mini cluster to it's own module. Do we want this for 1.5 or do > we > >> > wait > >> > > until 1.6 and provide a deprecation strategy? > >> > > > >> > > >> > I think we should move it in 1.5 XOR leave the package name the same > in > >> > 1.6, but move it to another module. Either way avoids API changes for > >> > users. > >> > > >> > > >> > > >> > > >> > > >> > > > >> > > > >> > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet > >> wrote: > >> > > > >> > > > Agreed, they also slow down the build. > >> > > > > >> > > > > >> > > > On Mon, May 20, 2013 at 2:09 PM, Christopher > > >> > > wrote: > >> > > > > >> > > >> Maybe... or 'jar-with-dependencies' assembly, or something > similar, > >> > > >> might be useful. > >> > > >> I'd probably argue for it to be in a de-activated profile, by > >> default, > >> > > >> though. Shaded jars can become problematic if people start using > >> them > >> > > >> as dependencies. > >> > > >> > >> > > >> -- > >> > > >> Christopher L Tubbs II > >> > > >> http://gravatar.com/ctubbsii > >> > > >> > >> > > >> > >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet > >> > wrote: > >> > > >> > This may be far out into space- but how would you guys feel > about > >> > > >> providing > >> > > >> > a shaded jar in the pom for a new mini module? This may make it > >> > easier > >> > > >> for > >> > > >> > users to run the mini accumulo cluster without hadoop/zookeeper > >> > > >> installed. > >> > > >> > > >> > > >> > > >> > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher < > ctubb...@apache.org > >> > > >> > > >> wrote: > >> > > >> > > >> > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > >> > > >> >> > >> > > >> >> -- > >> > > >> >> Christopher L Tubbs II > >> > > >> >> http://gravatar.com/ctubbsii > >> > > >> >> > >> > > >> >> > >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher < > >> ctubb...@apache.org > >> > > > >> > > >> wrote: > >> > > >> >> > You're right. I'm not sure why our internal dependencies > would > >> be > >> > > >> >> > marked as provided... except maybe I made that mistake to > try > >> to > >> > > deal > >> > > >> >> > with the mess of the 'copy-dependencies' stuff. That should > be > >> > > fixed. > >> > > >> >> > > >> > > >> >> > -- > >> > > >> >> > Christopher L Tubbs II > >> > > >> >> > http://gravatar.com/ctubbsii > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines < > vi...@apache.org > >> > > >> > > >> wrote: > >> > > >> >> >> Jim, accumulo-start is a provided dependency for all of the > >> > other > >> > > >> >> versions. > >> > > >> >> >> So when you list accumulo-server as a dependency, it does > not > >> > pull > >> > > >> in > >> > > >> >> the > >> > > >> >> >> provided dependencies. > >> > > >> >> >> > >> > > >> >> >> This is sort of what I was getting at before, Chris. The > >> > provided > >> > > >> jars > >> > > >> >> >> don't get pulled in/referenced when they are marked as > >> provided. > >> > > For > >> > > >> >> >> external dependencies, that totally makes sense. But I > don't > >> > know > >> > > >> why we > >> > > >> >> >> need to mark other accumulo parts as provided. I find it > >> > difficult > >> > > >> to > >> > > >> >> >> believe that that is a standard maven configuration. It is > >> > > extremely > >> > > >> >> >> painful for downstream clients. > >> > > >> >> >> > >> > > >> >> >> > >> > > >> >> >> On Mon, May 20, 2013 at 9:10 AM, Jim Klucar < > klu...@gmail.com > >> > > >> > > >> wrote: > >> > > >> >> >> > >> > > >> >> >>> The question mark was in my statement because I didn't > >> actually > >> > > >> know > >> > > >> >> if it > >> > > >> >> >>> created a circular dependency. It appears that Corey > found it > >> > > >> doesn't > >> > > >> >> have > >> > > >> >> >>> one. All I did was put a dependency on accumulo-master and > >> saw > >> > > that > >> > > >> >> wh
Re: dependencies within 1.5
Sounds good to me On Tue, May 21, 2013 at 1:30 PM, Corey Nolet wrote: > Hadoop's module is "hadoop-minicluster" so I'm thinking of making > "accumulo-minicluster". I'm also thinking the package should be > "o.a.a.minicluster" Any objections? > > > On Tue, May 21, 2013 at 12:50 PM, Christopher wrote: > > > +1 for moving it in 1.5 for all the previous reasons specified. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, May 21, 2013 at 12:36 PM, Keith Turner wrote: > > > On Tue, May 21, 2013 at 12:34 PM, John Vines wrote: > > > > > >> I think we should move it in 1.5. The bug Eric found this morning, > along > > >> > > > > > > Thats ok w/ me. I mostly want to avoid the deprecation route. > > > > > > > > > > > >> with the laundry list of non-breakers, are enough for an RC5 to be > cut. > > >> This should be pulled in. Having packages not align with modules > causes > > >> nothing must frustration and confusion when trying to debug things. > > >> > > >> > > >> On Tue, May 21, 2013 at 12:27 PM, Keith Turner > > wrote: > > >> > > >> > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet > > wrote: > > >> > > > >> > > I think it's worth asking because a few people expressed interest > in > > >> > moving > > >> > > the mini cluster to it's own module. Do we want this for 1.5 or do > > we > > >> > wait > > >> > > until 1.6 and provide a deprecation strategy? > > >> > > > > >> > > > >> > I think we should move it in 1.5 XOR leave the package name the same > > in > > >> > 1.6, but move it to another module. Either way avoids API changes > for > > >> > users. > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > > >> > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet > > >> wrote: > > >> > > > > >> > > > Agreed, they also slow down the build. > > >> > > > > > >> > > > > > >> > > > On Mon, May 20, 2013 at 2:09 PM, Christopher < > ctubb...@apache.org > > > > > >> > > wrote: > > >> > > > > > >> > > >> Maybe... or 'jar-with-dependencies' assembly, or something > > similar, > > >> > > >> might be useful. > > >> > > >> I'd probably argue for it to be in a de-activated profile, by > > >> default, > > >> > > >> though. Shaded jars can become problematic if people start > using > > >> them > > >> > > >> as dependencies. > > >> > > >> > > >> > > >> -- > > >> > > >> Christopher L Tubbs II > > >> > > >> http://gravatar.com/ctubbsii > > >> > > >> > > >> > > >> > > >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet < > cjno...@gmail.com> > > >> > wrote: > > >> > > >> > This may be far out into space- but how would you guys feel > > about > > >> > > >> providing > > >> > > >> > a shaded jar in the pom for a new mini module? This may make > it > > >> > easier > > >> > > >> for > > >> > > >> > users to run the mini accumulo cluster without > hadoop/zookeeper > > >> > > >> installed. > > >> > > >> > > > >> > > >> > > > >> > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher < > > ctubb...@apache.org > > >> > > > >> > > >> wrote: > > >> > > >> > > > >> > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. > > >> > > >> >> > > >> > > >> >> -- > > >> > > >> >> Christopher L Tubbs II > > >> > > >> >> http://gravatar.com/ctubbsii > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher < > > >> ctubb...@apache.org > > >> > > > > >> > > >> wrote: > > >> > > >> >> > You're right. I'm not sure why our internal dependencies > > would > > >> be > > >> > > >> >> > marked as provided... except maybe I made that mistake to > > try > > >> to > > >> > > deal > > >> > > >> >> > with the mess of the 'copy-dependencies' stuff. That > should > > be > > >> > > fixed. > > >> > > >> >> > > > >> > > >> >> > -- > > >> > > >> >> > Christopher L Tubbs II > > >> > > >> >> > http://gravatar.com/ctubbsii > > >> > > >> >> > > > >> > > >> >> > > > >> > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines < > > vi...@apache.org > > >> > > > >> > > >> wrote: > > >> > > >> >> >> Jim, accumulo-start is a provided dependency for all of > the > > >> > other > > >> > > >> >> versions. > > >> > > >> >> >> So when you list accumulo-server as a dependency, it does > > not > > >> > pull > > >> > > >> in > > >> > > >> >> the > > >> > > >> >> >> provided dependencies. > > >> > > >> >> >> > > >> > > >> >> >> This is sort of what I was getting at before, Chris. The > > >> > provided > > >> > > >> jars > > >> > > >> >> >> don't get pulled in/referenced when they are marked as > > >> provided. > > >> > > For > > >> > > >> >> >> external dependencies, that totally makes sense. But I > > don't > > >> > know > > >> > > >> why we > > >> > > >> >> >> need to mark other accumulo parts as provided. I find it > > >> > difficult > > >> > > >> to > > >> > > >> >> >> believe that that is a standard maven configuration. It > is > > >> > > extremely > > >> > > >> >> >> painful for downstream clients. > > >> > > >> >> >> > > >> > > >> >> >> > > >> > > >> >> >> On Mon, May 20, 2013 at 9:
Re: hadoop-2.0 incompatibility
Yes, that's correct. It looks like we only need to exercise the two builds option if we find a need later on. Adam On Tue, May 21, 2013 at 12:02 PM, Christopher wrote: > Sure, that's still an option, but I don't think this particular > incompatibility makes it necessary, does it? > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, May 21, 2013 at 12:00 PM, Adam Fuchs wrote: > > We still have the option of putting out a separate build for 1.5.0 > > compatibility with hadoop 2. Should we vote on that release separately? > > Seems like it should be easy to add more binary packages that correspond > to > > the same source release, even after the initial vote. > > > > Adam > > > > > > > > On Tue, May 21, 2013 at 11:55 AM, Keith Turner wrote: > > > >> On Tue, May 21, 2013 at 11:02 AM, Eric Newton > >> wrote: > >> > >> > Ugh. While running the continuous ingest verify, yarn spit this out: > >> > > >> > Error: Found interface org.apache.hadoop.mapreduce.Counter, but class > was > >> > expected > >> > > >> > This is preventing the reduce step from completing. > >> > > >> > >> Could fix it in 1.5.1 > >> > >> I am starting to think that hadoop compat was so important, it should > have > >> been mostly completed before the feature freeze. > >> > >> > >> > > >> > -Eric > >> > > >> >
Re: dependencies within 1.5
Seems fine to me as well. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 1:35 PM, John Vines wrote: > Sounds good to me > > > On Tue, May 21, 2013 at 1:30 PM, Corey Nolet wrote: > >> Hadoop's module is "hadoop-minicluster" so I'm thinking of making >> "accumulo-minicluster". I'm also thinking the package should be >> "o.a.a.minicluster" Any objections? >> >> >> On Tue, May 21, 2013 at 12:50 PM, Christopher wrote: >> >> > +1 for moving it in 1.5 for all the previous reasons specified. >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Tue, May 21, 2013 at 12:36 PM, Keith Turner wrote: >> > > On Tue, May 21, 2013 at 12:34 PM, John Vines wrote: >> > > >> > >> I think we should move it in 1.5. The bug Eric found this morning, >> along >> > >> >> > > >> > > Thats ok w/ me. I mostly want to avoid the deprecation route. >> > > >> > > >> > > >> > >> with the laundry list of non-breakers, are enough for an RC5 to be >> cut. >> > >> This should be pulled in. Having packages not align with modules >> causes >> > >> nothing must frustration and confusion when trying to debug things. >> > >> >> > >> >> > >> On Tue, May 21, 2013 at 12:27 PM, Keith Turner >> > wrote: >> > >> >> > >> > On Tue, May 21, 2013 at 12:16 PM, Corey Nolet >> > wrote: >> > >> > >> > >> > > I think it's worth asking because a few people expressed interest >> in >> > >> > moving >> > >> > > the mini cluster to it's own module. Do we want this for 1.5 or do >> > we >> > >> > wait >> > >> > > until 1.6 and provide a deprecation strategy? >> > >> > > >> > >> > >> > >> > I think we should move it in 1.5 XOR leave the package name the same >> > in >> > >> > 1.6, but move it to another module. Either way avoids API changes >> for >> > >> > users. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > >> > > >> > >> > > On Mon, May 20, 2013 at 2:10 PM, Corey Nolet >> > >> wrote: >> > >> > > >> > >> > > > Agreed, they also slow down the build. >> > >> > > > >> > >> > > > >> > >> > > > On Mon, May 20, 2013 at 2:09 PM, Christopher < >> ctubb...@apache.org >> > > >> > >> > > wrote: >> > >> > > > >> > >> > > >> Maybe... or 'jar-with-dependencies' assembly, or something >> > similar, >> > >> > > >> might be useful. >> > >> > > >> I'd probably argue for it to be in a de-activated profile, by >> > >> default, >> > >> > > >> though. Shaded jars can become problematic if people start >> using >> > >> them >> > >> > > >> as dependencies. >> > >> > > >> >> > >> > > >> -- >> > >> > > >> Christopher L Tubbs II >> > >> > > >> http://gravatar.com/ctubbsii >> > >> > > >> >> > >> > > >> >> > >> > > >> On Mon, May 20, 2013 at 2:00 PM, Corey Nolet < >> cjno...@gmail.com> >> > >> > wrote: >> > >> > > >> > This may be far out into space- but how would you guys feel >> > about >> > >> > > >> providing >> > >> > > >> > a shaded jar in the pom for a new mini module? This may make >> it >> > >> > easier >> > >> > > >> for >> > >> > > >> > users to run the mini accumulo cluster without >> hadoop/zookeeper >> > >> > > >> installed. >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > On Mon, May 20, 2013 at 1:56 PM, Christopher < >> > ctubb...@apache.org >> > >> > >> > >> > > >> wrote: >> > >> > > >> > >> > >> > > >> >> ACCUMULO-1436 for fixing "provided" dependencies. >> > >> > > >> >> >> > >> > > >> >> -- >> > >> > > >> >> Christopher L Tubbs II >> > >> > > >> >> http://gravatar.com/ctubbsii >> > >> > > >> >> >> > >> > > >> >> >> > >> > > >> >> On Mon, May 20, 2013 at 12:52 PM, Christopher < >> > >> ctubb...@apache.org >> > >> > > >> > >> > > >> wrote: >> > >> > > >> >> > You're right. I'm not sure why our internal dependencies >> > would >> > >> be >> > >> > > >> >> > marked as provided... except maybe I made that mistake to >> > try >> > >> to >> > >> > > deal >> > >> > > >> >> > with the mess of the 'copy-dependencies' stuff. That >> should >> > be >> > >> > > fixed. >> > >> > > >> >> > >> > >> > > >> >> > -- >> > >> > > >> >> > Christopher L Tubbs II >> > >> > > >> >> > http://gravatar.com/ctubbsii >> > >> > > >> >> > >> > >> > > >> >> > >> > >> > > >> >> > On Mon, May 20, 2013 at 10:24 AM, John Vines < >> > vi...@apache.org >> > >> > >> > >> > > >> wrote: >> > >> > > >> >> >> Jim, accumulo-start is a provided dependency for all of >> the >> > >> > other >> > >> > > >> >> versions. >> > >> > > >> >> >> So when you list accumulo-server as a dependency, it does >> > not >> > >> > pull >> > >> > > >> in >> > >> > > >> >> the >> > >> > > >> >> >> provided dependencies. >> > >> > > >> >> >> >> > >> > > >> >> >> This is sort of what I was getting at before, Chris. The >> > >> > provided >> > >> > > >> jars >> > >> > > >> >> >> don't get pulled in/referenced when they are marked as >> > >> provided. >> > >> > > For >> > >> > > >> >> >> external dependencies, that totally makes sense. But I >> > don't >> > >> > know >> > >> > > >> why we >> > >> > > >> >> >> need to mark other accumulo par
fixVersion recommendation for JIRA
To reduce ambiguity for users when one is trying to determine whether a bug has been fixed in any given version, I propose it be common practice to specify the next major release version, in addition to the next bugfix version, for the "fixVersion" field in JIRA. Example: Accumulo 1.6.0 may be released before Accumulo 1.5.1, so a ticket marked only with a fixVersion of 1.5.1 is ambiguous. One cannot easily determine if the bug still affects 1.6.0. If one specifies both 1.5.1 and 1.6.0, it is not ambiguous. One does not need to continue to specify future major releases, because major releases only occur in chronological order. So, it would not be necessary to put something like: 1.5.6, 1.6.0, 1.7.0 I can easily infer that the bug was fixed in 1.7.0 if it is marked as fixed for 1.6.0. Further, I can tell that it was either backported or initially fixed in 1.5.6. But it would be helpful if, I saw something like: 1.5.6, 1.6.2, 1.7.0 This would clarify that the earliest version of 1.5 with the fix was 1.5.6, and the earliest version of 1.6 that had the fix was 1.6.2, and that all versions 1.7.0 and later were either fixed or it doesn't apply to those versions. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
GIT
I'm sure this has been entertained before, I'm starting to think that we should seriously consider switching to git, maybe sooner (during 1.6 development cycle?). -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: GIT
+1 On Tue, May 21, 2013 at 5:44 PM, Christopher wrote: > I'm sure this has been entertained before, I'm starting to think that > we should seriously consider switching to git, maybe sooner (during > 1.6 development cycle?). > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii >
Re: GIT
I thought we were constrained by apache's subversion repo? On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: > +1 > > > On Tue, May 21, 2013 at 5:44 PM, Christopher wrote: > > > I'm sure this has been entertained before, I'm starting to think that > > we should seriously consider switching to git, maybe sooner (during > > 1.6 development cycle?). > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > >
Re: GIT
+1 On May 21, 2013 5:52 PM, "John Vines" wrote: > +1 > > > On Tue, May 21, 2013 at 5:44 PM, Christopher wrote: > > > I'm sure this has been entertained before, I'm starting to think that > > we should seriously consider switching to git, maybe sooner (during > > 1.6 development cycle?). > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > >
Re: GIT
On Tue, May 21, 2013 at 6:05 PM, David Medinets wrote: > I thought we were constrained by apache's subversion repo? I'm not sure what we are constrained by. > > On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: > >> +1 >> >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher wrote: >> >> > I'm sure this has been entertained before, I'm starting to think that >> > we should seriously consider switching to git, maybe sooner (during >> > 1.6 development cycle?). >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >>
Re: GIT
No constraint. git is now a first-class citizen of ASF infrastructure. We can switch if we like. On Tue, May 21, 2013 at 6:12 PM, Christopher wrote: > On Tue, May 21, 2013 at 6:05 PM, David Medinets > wrote: >> I thought we were constrained by apache's subversion repo? > > I'm not sure what we are constrained by. > >> >> On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: >> >>> +1 >>> >>> >>> On Tue, May 21, 2013 at 5:44 PM, Christopher wrote: >>> >>> > I'm sure this has been entertained before, I'm starting to think that >>> > we should seriously consider switching to git, maybe sooner (during >>> > 1.6 development cycle?). >>> > >>> > -- >>> > Christopher L Tubbs II >>> > http://gravatar.com/ctubbsii >>> > >>>
Re: GIT
Looks like git support is available, but still a work in progress. See https://git-wip-us.apache.org/ On Tue, May 21, 2013 at 6:12 PM, Christopher wrote: > On Tue, May 21, 2013 at 6:05 PM, David Medinets > wrote: > > I thought we were constrained by apache's subversion repo? > > I'm not sure what we are constrained by. > > > > > On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: > > > >> +1 > >> > >> > >> On Tue, May 21, 2013 at 5:44 PM, Christopher > wrote: > >> > >> > I'm sure this has been entertained before, I'm starting to think that > >> > we should seriously consider switching to git, maybe sooner (during > >> > 1.6 development cycle?). > >> > > >> > -- > >> > Christopher L Tubbs II > >> > http://gravatar.com/ctubbsii > >> > > >> >
Re: GIT
+1 Yay, git. On 05/21/2013 05:44 PM, Christopher wrote: I'm sure this has been entertained before, I'm starting to think that we should seriously consider switching to git, maybe sooner (during 1.6 development cycle?). -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: GIT
Hi Guys, ASF infra fully supports Git now, independent of the actual host name which indicates a 'work in progress or WP" :) You simply need to file an INFRA ticket [1] and request a writeable Git repo. You cannot have SVN and Git at the same time, so your SVN will be disabled to be read only at some point during the transition. If the community wants to do this, I would call a VOTE of the PMC, or simply DISCUSS thread and look for consensus. If all is well proceed with the ticket and you're good to go. Cheers, Chris [1] http://issues.apache.org/jira/browse/INFRA ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Mike Drob Reply-To: "dev@accumulo.apache.org" Date: Tuesday, May 21, 2013 3:25 PM To: "dev@accumulo.apache.org" Subject: Re: GIT >Looks like git support is available, but still a work in progress. See >https://git-wip-us.apache.org/ > > >On Tue, May 21, 2013 at 6:12 PM, Christopher wrote: > >> On Tue, May 21, 2013 at 6:05 PM, David Medinets >> wrote: >> > I thought we were constrained by apache's subversion repo? >> >> I'm not sure what we are constrained by. >> >> > >> > On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: >> > >> >> +1 >> >> >> >> >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher >> wrote: >> >> >> >> > I'm sure this has been entertained before, I'm starting to think >>that >> >> > we should seriously consider switching to git, maybe sooner (during >> >> > 1.6 development cycle?). >> >> > >> >> > -- >> >> > Christopher L Tubbs II >> >> > http://gravatar.com/ctubbsii >> >> > >> >> >>
Re: GIT
Everything at Apache is a work in progress. Plenty of projects are using it. On Tue, May 21, 2013 at 6:25 PM, Mike Drob wrote: > Looks like git support is available, but still a work in progress. See > https://git-wip-us.apache.org/ > > > On Tue, May 21, 2013 at 6:12 PM, Christopher wrote: > >> On Tue, May 21, 2013 at 6:05 PM, David Medinets >> wrote: >> > I thought we were constrained by apache's subversion repo? >> >> I'm not sure what we are constrained by. >> >> > >> > On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: >> > >> >> +1 >> >> >> >> >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher >> wrote: >> >> >> >> > I'm sure this has been entertained before, I'm starting to think that >> >> > we should seriously consider switching to git, maybe sooner (during >> >> > 1.6 development cycle?). >> >> > >> >> > -- >> >> > Christopher L Tubbs II >> >> > http://gravatar.com/ctubbsii >> >> > >> >> >>
MapR compatability
So I finally got around to testing MapR (well, finally got it running). Gave RC4 a test run and, after seeing the stack trace, not surprised it broke in HadoopLogCloser.close(). IllegalStateException gest thrown from line 54 due to the filesystem being of type com.mapr.fs.MapRFileSystem. At this point, I think this should be considered an acceptable break and something we shoudl try to resolve first thing for 1.5.1. Thoughts?
Re: MapR compatability
Sounds good to me. On 05/21/2013 06:36 PM, John Vines wrote: So I finally got around to testing MapR (well, finally got it running). Gave RC4 a test run and, after seeing the stack trace, not surprised it broke in HadoopLogCloser.close(). IllegalStateException gest thrown from line 54 due to the filesystem being of type com.mapr.fs.MapRFileSystem. At this point, I think this should be considered an acceptable break and something we shoudl try to resolve first thing for 1.5.1. Thoughts?
Re: MapR compatability
Or you could configure the MapR log closer. On Tue, May 21, 2013 at 6:36 PM, John Vines wrote: > So I finally got around to testing MapR (well, finally got it running). > Gave RC4 a test run and, after seeing the stack trace, not surprised it > broke in HadoopLogCloser.close(). IllegalStateException gest thrown from > line 54 due to the filesystem being of type com.mapr.fs.MapRFileSystem. At > this point, I think this should be considered an acceptable break and > something we shoudl try to resolve first thing for 1.5.1. Thoughts? >
Re: MapR compatability
Sigh, I guess I could do that. I was rushing out the door, but I'll try that. Sent from my phone, please pardon the typos and brevity. Or you could configure the MapR log closer. On Tue, May 21, 2013 at 6:36 PM, John Vines wrote: > So I finally got around to testing MapR (well, finally got it running). > Gave RC4 a test run and, after seeing the stack trace, not surprised it > broke in HadoopLogCloser.close(). IllegalStateException gest thrown from > line 54 due to the filesystem being of type com.mapr.fs.MapRFileSystem. At > this point, I think this should be considered an acceptable break and > something we shoudl try to resolve first thing for 1.5.1. Thoughts? >
Re: GIT
+1 but it is more than just changing tools. Have a discussion about a git workflow and branching model. I have seen that be a point of frustration for many projects making the switch. On May 21, 2013 6:29 PM, "Benson Margulies" wrote: > Everything at Apache is a work in progress. Plenty of projects are using > it. > > On Tue, May 21, 2013 at 6:25 PM, Mike Drob wrote: > > Looks like git support is available, but still a work in progress. See > > https://git-wip-us.apache.org/ > > > > > > On Tue, May 21, 2013 at 6:12 PM, Christopher > wrote: > > > >> On Tue, May 21, 2013 at 6:05 PM, David Medinets > >> wrote: > >> > I thought we were constrained by apache's subversion repo? > >> > >> I'm not sure what we are constrained by. > >> > >> > > >> > On Tue, May 21, 2013 at 5:51 PM, John Vines wrote: > >> > > >> >> +1 > >> >> > >> >> > >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher > >> wrote: > >> >> > >> >> > I'm sure this has been entertained before, I'm starting to think > that > >> >> > we should seriously consider switching to git, maybe sooner (during > >> >> > 1.6 development cycle?). > >> >> > > >> >> > -- > >> >> > Christopher L Tubbs II > >> >> > http://gravatar.com/ctubbsii > >> >> > > >> >> > >> >
Re: GIT
+1 with a big caveat that a branching strategy needs to be discussed. On Tue, May 21, 2013 at 7:32 PM, Michael Wall wrote: > +1 but it is more than just changing tools. Have a discussion about a git > workflow and branching model. I have seen that be a point of frustration > for many projects making the switch. > On May 21, 2013 6:29 PM, "Benson Margulies" wrote: > > > Everything at Apache is a work in progress. Plenty of projects are using > > it. > > > > On Tue, May 21, 2013 at 6:25 PM, Mike Drob wrote: > > > Looks like git support is available, but still a work in progress. See > > > https://git-wip-us.apache.org/ > > > > > > > > > On Tue, May 21, 2013 at 6:12 PM, Christopher > > wrote: > > > > > >> On Tue, May 21, 2013 at 6:05 PM, David Medinets > > >> wrote: > > >> > I thought we were constrained by apache's subversion repo? > > >> > > >> I'm not sure what we are constrained by. > > >> > > >> > > > >> > On Tue, May 21, 2013 at 5:51 PM, John Vines > wrote: > > >> > > > >> >> +1 > > >> >> > > >> >> > > >> >> On Tue, May 21, 2013 at 5:44 PM, Christopher > > >> wrote: > > >> >> > > >> >> > I'm sure this has been entertained before, I'm starting to think > > that > > >> >> > we should seriously consider switching to git, maybe sooner > (during > > >> >> > 1.6 development cycle?). > > >> >> > > > >> >> > -- > > >> >> > Christopher L Tubbs II > > >> >> > http://gravatar.com/ctubbsii > > >> >> > > > >> >> > > >> > > >
Backporting features
Not sure if this has been decided already or not. Is there an official position on whether the 1.5 branch is feature frozen (and bug fixes only) when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been writing and testing against 1.6. I'd like to also backport to a 1.5.1. Thoughts? -- Dave
Re: Backporting features
IMO, if it can be backported without disrupting anything big from that major release line, I'm ok with it. Given what it I understand of what you have going in ACCUMULO-1399, I think that lines up. With that said, I'd also encourage you to pull it back to 1.4 too, just in case we have a reason to release a 1.4.4. On 05/21/2013 09:52 PM, dlmar...@comcast.net wrote: Not sure if this has been decided already or not. Is there an official position on whether the 1.5 branch is feature frozen (and bug fixes only) when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been writing and testing against 1.6. I'd like to also backport to a 1.5.1. Thoughts? -- Dave
Re: Backporting features
Maybe this is opening a can of worms- but if the proxy was backported to 1.4.4, I can't see why your new work shouldn't be.
Re: Backporting features
I was using my issue as an example and was looking for a general policy from the community. Sounds like it has already been talked about and there is a precedent. - Original Message - From: "Corey Nolet" To: dev@accumulo.apache.org Sent: Tuesday, May 21, 2013 10:02:14 PM Subject: Re: Backporting features Maybe this is opening a can of worms- but if the proxy was backported to 1.4.4, I can't see why your new work shouldn't be.
Re: Backporting features
I don't know about precedent, but... My general opinion is that new features shouldn't be back-ported to the main branch of older release lines, unless there's a compelling reason. Instead, they should be supported as separate add-on that one can compile in (perhaps as a patch in the contrib area?), or as a forked branch. The reason for this opinion is that it can be surprising and disruptive for users if they end up relying on new features in a bugfix'd version, and for whatever reason, have to switch to an earlier version of the same release line (perhaps a bug was found in a bug-fix, and they were forced to roll back, or they move to a system that hasn't yet been upgraded). A second reason for this is that back-ported features can often behave in ways that are different from the way they behave in the branch in which they were introduced, and this can also introduce confusion. Of course, this is just a general opinion... any specific opinion about a particular feature, I'd have to form on a case-by-case basis. I think MiniAccumuloCluster, for instance, was a great thing to backport, because of it's ability to enable testing of the core functionality, rather than it actually modifying any core functionality. I'm less enthusiastic about backporting the proxy, but I can see how it could be useful, especially if it helped people transition seamlessly to newer versions of Accumulo without re-writing lots of utility code. I should also mention that one of the reasons I was thinking about git, and initiated a discussion about that today on this list, was because I was thinking about the convenience it might provide enabling the creation of forked branches with backported features (rather than include them in the "official" release line)... though that particular application of git might need further discussion (because it can be annoying to have an excessive number of branches for backported features). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 21, 2013 at 10:04 PM, wrote: > I was using my issue as an example and was looking for a general policy from > the community. Sounds like it has already been talked about and there is a > precedent. > > - Original Message - > From: "Corey Nolet" > To: dev@accumulo.apache.org > Sent: Tuesday, May 21, 2013 10:02:14 PM > Subject: Re: Backporting features > > Maybe this is opening a can of worms- but if the proxy was backported to > 1.4.4, I can't see why your new work shouldn't be.
