Please remove me as a mailing list moderator

[Benson Margulies]

I'm still getting mod email, could you all please take me off the mod list?

Re: [OT] Can no longer obtain JDK6/JDK7 tarballs

[Benson Margulies]

On Wed, Jul 20, 2016 at 10:41 AM, Keith Turner <ke...@deenlo.com> wrote:
> On Wed, Jul 20, 2016 at 9:34 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> Add the use of the animal sniffer plugin and/or the bootclasspath
>> option to the maven-compiler-plugin to force the use of only 1.7 apis.
>>
>>
> Thanks for the tip!  Animal sniffer seems like it will solve the problem of
> building using JDK8.

The bootclasspath is stronger, but takes more arrangements. You need a
way to get the 1.7 rt.jar in the picture without getting tangled up in
IP issues.



>
>
>>
>> On Wed, Jul 20, 2016 at 9:13 AM, Keith Turner <ke...@deenlo.com> wrote:
>> > On Wed, Jul 20, 2016 at 7:41 AM, <dlmar...@comcast.net> wrote:
>> >
>> >> Can't you use JDK8 and keep the source and target at 1.7?
>> >>
>> >
>> > Yes, but I think developers can accidentally use methods introduced in
>> > 1.8.   If TreeMap.foo() only exists in Java 1.8 and someone uses it (in a
>> > 1.7 source compatible way), then the code will compile to 1.7 class
>> files.
>> > However, it will not actually run in 1.7 jre.
>> >
>> > I suspect most developers are using JDK8.  So unless someone does a build
>> > with JDK 1.7 before release, these problems will go undetected.
>> > Christopher is trying to setup jenkins with multiple JDKs to do these
>> > builds.
>> >
>> > Is running jenkins on Centos 6 an option?  Then maybe Centos6 has
>> OpenJDK6
>> > and 7??  And can download Sun JDK8 for Centos 6.
>> >
>> >
>> >> - Original Message -
>> >>
>> >> From: "Christopher" <ctubb...@apache.org>
>> >> To: "Accumulo Dev List" <dev@accumulo.apache.org>
>> >> Sent: Tuesday, July 19, 2016 6:22:58 PM
>> >> Subject: [OT] Can no longer obtain JDK6/JDK7 tarballs
>> >>
>> >> I know we've discussed moving to JDK8 before, and we've moved the master
>> >> branch, which is expected to be 2.0.0.
>> >>
>> >> However, I'm trying to get the tarball for JDK7, so I can do
>> development on
>> >> older Accumulo branches while guaranteeing I don't do anything which
>> will
>> >> only work in JDK8.
>> >>
>> >> Unfortunately, OpenJDK does not provide tarballs to download, as far as
>> I
>> >> can tell. They work with downstream systems for packaging, but my OS
>> does
>> >> not package end-of-life (EOL) JDKs.
>> >>
>> >> So, I have to use the Oracle JDK tarball for JDK7. Unfortunately, Oracle
>> >> requires users to register to download EOL packages, and registration
>> >> requires users to provide a lot of details about themselves, their home
>> >> address, and their employment (required as part of the
>> registration/terms
>> >> of use). I'm unhappy and reluctant to disclose all that to Oracle (I'm
>> not
>> >> confident about their privacy practices).
>> >>
>> >> The alternative is to use an RPM for OpenJDK from another Linux distro,
>> but
>> >> that will probably not work outside the system it was designed for, and
>> >> would probably conflict with my installed JDK8 rpm.
>> >>
>> >> So, now it seems I'm screwed a bit, and can't do development in a "pure"
>> >> JDK7 JAVA_HOME on my modern OS. This is frustrating. Has anybody else
>> run
>> >> into this yet? What's your solution?
>> >>
>> >> I'm half tempted to suggest we require Java 8 for all future releases,
>> >> because of the difficulty of trying to guarantee support for older
>> versions
>> >> of Java when the EOL java versions are so increasingly difficult to
>> >> obtain... but I know that probably wouldn't go over very well.
>> >>
>> >>
>>

Re: [OT] Can no longer obtain JDK6/JDK7 tarballs

[Benson Margulies]

Add the use of the animal sniffer plugin and/or the bootclasspath
option to the maven-compiler-plugin to force the use of only 1.7 apis.


On Wed, Jul 20, 2016 at 9:13 AM, Keith Turner  wrote:
> On Wed, Jul 20, 2016 at 7:41 AM,  wrote:
>
>> Can't you use JDK8 and keep the source and target at 1.7?
>>
>
> Yes, but I think developers can accidentally use methods introduced in
> 1.8.   If TreeMap.foo() only exists in Java 1.8 and someone uses it (in a
> 1.7 source compatible way), then the code will compile to 1.7 class files.
> However, it will not actually run in 1.7 jre.
>
> I suspect most developers are using JDK8.  So unless someone does a build
> with JDK 1.7 before release, these problems will go undetected.
> Christopher is trying to setup jenkins with multiple JDKs to do these
> builds.
>
> Is running jenkins on Centos 6 an option?  Then maybe Centos6 has OpenJDK6
> and 7??  And can download Sun JDK8 for Centos 6.
>
>
>> - Original Message -
>>
>> From: "Christopher" 
>> To: "Accumulo Dev List" 
>> Sent: Tuesday, July 19, 2016 6:22:58 PM
>> Subject: [OT] Can no longer obtain JDK6/JDK7 tarballs
>>
>> I know we've discussed moving to JDK8 before, and we've moved the master
>> branch, which is expected to be 2.0.0.
>>
>> However, I'm trying to get the tarball for JDK7, so I can do development on
>> older Accumulo branches while guaranteeing I don't do anything which will
>> only work in JDK8.
>>
>> Unfortunately, OpenJDK does not provide tarballs to download, as far as I
>> can tell. They work with downstream systems for packaging, but my OS does
>> not package end-of-life (EOL) JDKs.
>>
>> So, I have to use the Oracle JDK tarball for JDK7. Unfortunately, Oracle
>> requires users to register to download EOL packages, and registration
>> requires users to provide a lot of details about themselves, their home
>> address, and their employment (required as part of the registration/terms
>> of use). I'm unhappy and reluctant to disclose all that to Oracle (I'm not
>> confident about their privacy practices).
>>
>> The alternative is to use an RPM for OpenJDK from another Linux distro, but
>> that will probably not work outside the system it was designed for, and
>> would probably conflict with my installed JDK8 rpm.
>>
>> So, now it seems I'm screwed a bit, and can't do development in a "pure"
>> JDK7 JAVA_HOME on my modern OS. This is frustrating. Has anybody else run
>> into this yet? What's your solution?
>>
>> I'm half tempted to suggest we require Java 8 for all future releases,
>> because of the difficulty of trying to guarantee support for older versions
>> of Java when the EOL java versions are so increasingly difficult to
>> obtain... but I know that probably wouldn't go over very well.
>>
>>

Re: Official Guidance to users regarding removal of functions

[Benson Margulies]

How do you see this as different from any other major open source platform?
Every one I've ever worked on does deprecate and remove things; generally
deprecation is accompanied by comments and release notes offering
adaptation advice.



On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL 
kep...@ll.mit.edu wrote:

 When we remove functions, do we have any official guidance to our users
 who may have built applications that use those functions?

 Right now, the official position is that the Accumulo developers can
 remove based on a consensus vote. However, this provides no guidance to
 users as to what they are suppose to do? As it stands, our guidance is that
 they have the following choices:

 (0) Diligently watch the Accumulo e-mail list and aggressively weigh in on
 any vote to remove functions that may impact them.

 (1) Find someone to modify the original source code of their applications,
 build it, and *re-verify* the application. I emphasise the re-verify
 because that is usually the most costly part of the process that often
 won't get approved by management.

 (2) Don't upgrade Accumulo.

Re: Official Guidance to users regarding removal of functions

[Benson Margulies]

On Thu, Dec 11, 2014 at 12:11 PM, Mike Drob mad...@cloudera.com wrote:

 Billie,

 Not to be glib, but it reads like your suggestion to Jeremy for when we
 have a 2.0.0 release (assuming semver passes) is to take option (2) Don't
 upgrade Accumulo.

 Please correct my misunderstanding.



That is perfectly fine advice in my view. In stable, long-life products,
major versions are maintained for a _long_ time. Applications rarely move
to new major versions. (I'm using Apache Lucene as a point of comparison.)
So, once an application goes into production on x.y.0, its maintainers
expect that there will be bug fixes and compatible improvements for for
_years_. Moving to a new major version is a big deal, and no one is going
to do it routinely or lightly. Many applications will reach the end of
their own EOL first. There are people still using Apache Lucene 3.x, and
the community is still prepared to make security fixes. The community will
be making functional improvements to 4.x for a very long time, even as
they/we are on the verge of shipping 5.0.



 Mike

 On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi bil...@apache.org
 wrote:

  To clarify John's question: if our vote to adopt semver 2.0.0 passes, our
  intention will be to no longer have breaking public API changes unless
 the
  major version number is incremented, i.e. 1.x.x - 2.x.x. An important
  aspect of semantic versioning is defining what is considered part of the
  public API. So if there are things you need to remain consistent that are
  not covered by Section 9 of the README, we should discuss adding them.
  Actually, strengthening what we consider to be the public API is likely
 to
  be a separate conversation in which (I hope) we will engage the user
 list.
  On Dec 11, 2014 11:51 AM, John Vines vi...@apache.org wrote:
 
   Wouldn't this be resolved with our SemVer sqwitch?
  
   On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL 
   kep...@ll.mit.edu wrote:
  
When we remove functions, do we have any official guidance to our
 users
who may have built applications that use those functions?
   
Right now, the official position is that the Accumulo developers can
remove based on a consensus vote. However, this provides no guidance
 to
users as to what they are suppose to do? As it stands, our guidance
 is
   that
they have the following choices:
   
(0) Diligently watch the Accumulo e-mail list and aggressively weigh
 in
   on
any vote to remove functions that may impact them.
   
(1) Find someone to modify the original source code of their
   applications,
build it, and *re-verify* the application. I emphasise the re-verify
because that is usually the most costly part of the process that
 often
won't get approved by management.
   
(2) Don't upgrade Accumulo.
   
  
 

Re: [VOTE] ACCUMULO-3176

[Benson Margulies]

On Tue, Dec 2, 2014 at 2:32 PM, Keith Turner ke...@deenlo.com wrote:
 On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey bus...@cloudera.com wrote:

 Responses below. I feel like most of these questions (with the noted
 exception of details on my issue with one of the late compromise positions)
 were previously answered, but I've tried to add additional detail below
 where I may have been unclear in prior exchanges.

 While I agree that objections are the start of a conversation, votes are
 meant to be provide closure so the community can move on to other work. I'd
 ask that we try to bring this thread to a close.

Whether that's healthy depends on the depth of disagreement remaining
on the topic, and whether the resolution here turns on a veto or not.

I do not personally believe that the PMC power to veto a commit is
appropriately applied over this sort of disagreement. The community
could choose to use a majority vote to amicably resolve a disagreement
about something like this.

However, I also must admit that I've never been very comfortable with
my ability to articulate the principles behind the writings of the
various very-old-timers on the subject of commit vetos. I suggest that
the PMC invite jimjag or Roy to expound, unless someone else here
feels that they've internalized the Apache conventions well enough to
explain them. At the same time, there's no absolute requirement, as
far as I know, for every community to adopt the voting policies of the
HTTP project; but if the project ends up in an unhappy place then the
board is prone, I suspect, to be unsympathetic.

Since I'm already out on a limb because I don't have time to follow
this in detail, I'm going to exit the conversation here.





 On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner ke...@deenlo.com wrote:

 
 
  The question I was most curious about was why you are ok w/ making this
 API
  change in 2.0 but not 1.7.0.  I do not understand the reasoning behind
  this.
 

 As a matter of background, over time I have become more convinced of the
 need for a stable, coherent API. Too many of the end users I have seen
 endure substantial work because of our altering of the API. This applies
 equally for forwards and backwards compatibility. When someone has a
 requirement to use our software and they find that the particular version
 they need to integrate with is different than they initially expected, I
 would like them to not have to endure project delays merely for updating
 use of our API.

 For 2.0, we already have broad consensus around improving our API in
 ACCUMULO-2589 despite the cost it puts on our user base; both because of a
 better delineation of what is and is not expected to stay constant and
 because we'll have a better formulation of a lifecycle for Accumulo related
 resources. In that particular matter, it's the proper lifecycle that I
 personally find compelling enough to broadly cause a burden. This is
 probably colored by my having dealt with ACCUMULO-2128 and its ilk.

 So, given that we're going to be asking our users to deal with a headache
 come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
 minimize asking them to take on dealing with changes in versions prior to
 that. There may be some future issue that fixes something severe enough to
 warrant changing my position on the matter. This issue did not.

 I talked previously about my position on API changes in general in the
 background info for Josh’s message:

 http://s.apache.org/HJg

 and I had meant to cover the we already agreed to break things in 2.0
 side in this admittedly short offer of compromise:

 http://s.apache.org/imf



 On Mon, Dec 1, 2014 at 4:25 PM, Christopher ctubb...@apache.org wrote:

  Explicit questions and outstanding requests for clarification since your
  last response (see previous emails for details and context):
  -  So, are you arguing for no more API additions until 2.0?
 

 My general preference, as mentioned above and previously in the background
 info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
 that this stance be taken on as a matter of course through this particular
 vote.

 I think any change to our API, prior to 2.0 or after, should be carefully
 considered. How we plan for users to interact with our software over time
 matters.  Through removals we will be directly impacting the ability of
 operational users to adopt our newer versions. Through additions we will be
 impacting how system integrators go about building applications above us.
 It does neither us nor them any good for our API to change merely because
 it improves our abstractions or condenses our support footprint.

 In the consideration of the above and the nice-to-have fixes this
 particular patch brings, I think it can wait for the API overhaul in 2.0.

 The same two previous mailings I mentioned above to Keith are where I went
 through this previously.



  - Please address the fact that there is no breakage here...

 

Re: Running Accumulo on the IBM JVM

[Benson Margulies]

On Thu, Jun 19, 2014 at 10:49 AM, Mike Drob md...@apache.org wrote:
 Hi Hayden! Welcome to Accumulo!

 Detailed responses are inline.

 Mike


 On Thu, Jun 19, 2014 at 6:14 AM, Vicky Kak vicky@gmail.com wrote:

 Hi Hayden,

 Most of the recommendation looks okay to me since there are many change to
 be done I think you should go ahead and create main JIRA which would have
 multiple subtasks addressing all the changes.
 I am almost sure that you might get into similar kind of issue if you run
 other java based NoSql distributions i.e. HBase/Cassandra on IBM jdk, I
 personally had surprises in api calls related to ordering in my application
 a long back ago. Your observations looks reasonable to me.

 Regards,
 Vicky


 On Thu, Jun 19, 2014 at 3:47 PM, Hayden Marchant hay...@il.ibm.com
 wrote:

  Hi there,
 
  I have been working on getting Accumulo running on IBM JDK, as
 preparation
  of including Accumulo in an upcoming version of BigInsights (IBM's Hadoop
  distribution). I have come across a number of issues, to which I have
 made
  some local fixes in my own environment. Since I'm a newbie in Accumulo, I
  wanted to make sure that the approach that I have taken for resolving
  these issues is aligned with the design intent of Accumulo.
 
  Some of the issues are real defects, and some are instances in which the
  assumption of Sun/Oracle JDK being the used JVM is hard-coded into the
  source-code.
 
  I have grouped the issues into 2 sections -  Unit test failures and
  Sun-specific dependencies (though there is an overlap)
 
  1. Unit Test failures - should run consistently no matter which OS, Java
  vendor/version etc...
  a.
 
 
 org.apache.accumulo.core.util.format.ShardedTableDistributionFormatterTest.testAggregate
  . This fails on IBM JRE, since the test is asserting order of elements in
  a HashMap. This consistently passes on Sun , and consistently fails on
  Oracle. Proposal: Change ShardedTableDistributionFormatter.countsByDay to
  TreeMap


 This is probably a real defect. We should not be asserting order on a
 HashMap. Another possible solution is to change the test to check for
 unordered elements - HamCrest matchers may be useful here.

You don't want to slow down the production code just to make a test
case pass, that's for sure. If order is not part of the contract, do
like Mike says, or copy it out and sort it.



 
  b.
 
 
 org.apache.accumulo.core.security.crypto.BlockedIOStreamTest.testGiantWrite.
  This test assumes a max heap of about 1GB. This fails on IBM JRE,
  since the default max heap is not specified, and on IBM JRE this depends
  on the OS (see
 
 
 http://www-01.ibm.com/support/knowledgecenter/SSYKE2_6.0.0/com.ibm.java.doc.diagnostics.60/diag/appendixes/defaults.html?lang=en
  ).
  Proposal: add -Xmx1g to the surefire maven plugin reference in
  parent maven pom.
 

 This might be https://issues.apache.org/jira/browse/ACCUMULO-2774


   c. Both org.apache.accumulo.core.security.crypto.CrypoTest 
  org.apache.accumulo.core.file.rfile.RFileTest have lots of failures due
 to
  calls to SEcureRandom with Random Number Generator Provider hard-coded as
  Sun. The IBM JRE has it's own built in RNG Provider called IBMJCE. 2
  issues - hard-coded calls to SecureRandom.getInstance(algo,SUN) and
  also default value in Property class is SUN.
  Proposal: Add mechanism to override default Property through
  System property through new annotator in Property class. Only usage will
  be by Property.CRYPTO_SECURE_RNG_PROVIDER



 I'm not sure about adding new annotators to Property. However, the
 CryptoTest should be getting the value from the conf instead of hard-coding
 it. Then you can specify the correct value in accumulo-site.xml

 I think another part of the issue is in
 CryptoModuleFactory::fillParamsObjectFromStringMap because it looks like
 that ignores the default setting.

  
  2. Environment/Configuration
  a. The generated configuration files contain references to GC
  params that are specific to Sun JVM. In accumulo-env.sh, the
  ACCUMULO_TSERVER_OPTS contains -XX:NewSize and -XX:MaxNewSize , and also
  in ACCUMULO_GENERAL_OPTS,
  -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 are used.
  b. in bin/accumulo, get ClassNotFoundException due to
  specification of JAXP Doc Builder:
 
 
 -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
  .
  The Sun implementation of Document Builder Factory does not
 exists
  in IBM JDK, so a ClassNotFoundException is thrown on running accumulo
  script
 
  c. MiniAccumuloCluster - in the MiniAccumuloClusterImpl,
  Sun-speciifc GC params are passed as params to the java process (similar
  to section a. )
 
  Single proposal for solving all three above issues:
  Enhance bootstrap_config.sh with request to select Java vendor.
  Selecting this will set correct values for 

Re: [VOTE] Accumulo Bylaws, vote 2

[Benson Margulies]

If you're all going to go spelunking in the Apache policy docs,
perhaps I can help a bit with context.

The original HTTPD project developed a very specific set of policies
for controlling  _commits to the code base_. The ballet of
-1/veto/justification comes out of there. The overall foundation
policy is an expectation that all projects will apply that same
approach to commits unless they can state a very good reason to do
something else.

Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
Justification is polite, but not required. Proceeding in the face of a
-1 is not always a good idea, but the policy envisions it; it
envisions that someone might vote -1 because they _might prefer_ to
wait for some other change. But they can just be outvoted.

Once you get past commits to the codebase and releases, you're more on
your own in deciding how to decide. The particular case at hand, these
bylaws, is an interesting one.

People should be really clear about what they mean when they propose
consensus as a process. Yes, a consensus process is a process in which
every member of the community has a veto. However, it is also a
process in which every member of the community feels a grave weight of
responsibility in using that veto. Focussing on the veto in a
consensus process is not a good sign.

Consensus is a slow, deliberative, process, chosen by communities
which value group cohesion over most everything else. It is also a
process that presumes that there is a _status quo_ which is always
acceptable. The community sticks to the status quo until everyone
involved is ready to accept some change. This approach to
decision-making is pretty hard to apply to a new group trying to chart
a new course.

It is _not_ foundation policy to expect communities to choose
full-blown consensus as the predominant process. Typically, in my
experience, Apache projects do not do full consensus process. Instead,
they strive to give everyone a voice and seek consensus, but
eventually decide via a majority of some kind. Most of the time, the
first part of that (open discussion) achieves a consensus, so that the
second part of that becomes a formality. However, from time to time,
the community chooses to decide by majority in order to decide. The
touchstone of a healthy community is that the minority feel heard and
not steamrolled.

Gitflow

[Benson Margulies]

I have a little favor to ask. I read the discussion about git process
with ignorant interest some months back, and now I am in the process
of trying to use gitflow with a team myself, and feeling a bit
puzzled. Would any of the folks who were providing guidance here be
willing to entertain some questions from me?

Re: Gitflow

[Benson Margulies]

On Fri, Oct 11, 2013 at 10:39 AM, Josh Elser josh.el...@gmail.com wrote:
 Absolutely!

 The tl;dr of it as we have adopted is as follows:

 We have branches for each version currently supported: 1.4.5-SNAPSHOT,
 1.5.1-SNAPSHOT and 1.6.0-SNAPSHOT (which is just in master).

So, comparing to the stock gitflow picture ... The stock gitflow
picture has one 'master' branch that gets tags for the releases, but
not the hotfixes, and one develop branch. Your description reads to me
as an extension of that model to reflect multiple release-history
branches. Do you have the git-flow-ish master/develop distinction for
these, or is it as simple as your next sentence.


 For bugfixes or new features, apply the change in the oldest version fix
 and merge into newer branches.





 Use feature branches to isolate and share your long-running work.

 What's on your mind?

Other than the above, we wonder, 'what use is the master branch in the
canonical gitflow picture? :-)'




 On 10/11/2013 10:32 AM, Benson Margulies wrote:

 I have a little favor to ask. I read the discussion about git process
 with ignorant interest some months back, and now I am in the process
 of trying to use gitflow with a team myself, and feeling a bit
 puzzled. Would any of the folks who were providing guidance here be
 willing to entertain some questions from me?

Re: GIT

[Benson Margulies]

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 md...@mdrob.com 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 ctubb...@apache.org wrote:

 On Tue, May 21, 2013 at 6:05 PM, David Medinets
 david.medin...@gmail.com 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 vi...@apache.org wrote:
 
  +1
 
 
  On Tue, May 21, 2013 at 5:44 PM, Christopher ctubb...@apache.org
 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: Hadoop 2 compatibility issues

[Benson Margulies]

CXF does (4) for the various competing JAX-WS implementations.

The different options are API-compatible, and the profiles just switch
the deps around.

There would be slightly more Maven correctness in marking the deps
optional, forcing each user to pick one explicitly.

However, (4) with good doc on what to put in the POM is really not a
cause for shame. Maven is weak in this area, and it's all tradeoffs.



On Tue, May 14, 2013 at 4:56 PM, John Vines vi...@apache.org wrote:
 I'm an advocate of option 4. You say that it's ignoring the problem,
 whereas I think it's waiting until we have the time to solve the problem
 correctly. Your reasoning for this is for standardizing for maven
 conventions, but the other options, while more 'correct' from a maven
 standpoint or a larger headache for our user base and ourselves. In either
 case, we're going to be breaking some sort of convention, and while it's
 not good, we should be doing the one that's less bad for US. The important
 thing here, now, is that the poms work and we should go with the method
 that leaves the work minimal for our end users to utilize them.

 I do agree that 1. is the correct option in the long run. More
 specifically, I think it boils down to having a single module compatibility
 layer, which is how hbase deals with this issue. But like you said, we
 don't have the time to engineer a proper solution. So let sleeping dogs lie
 and we can revamp the whole system for 1.5.1 or 1.6.0 when we have the
 cycles to do it right.


 On Tue, May 14, 2013 at 4:40 PM, Christopher ctubb...@apache.org wrote:

 So, I've run into a problem with ACCUMULO-1402 that requires a larger
 discussion about how Accumulo 1.5.0 should support Hadoop2.

 The problem is basically that profiles should not contain
 dependencies, because profiles don't get activated transitively. A
 slide deck by the Maven developers point this out as a bad practice...
 yet it's a practice we rely on for our current implementation of
 Hadoop2 support
 (http://www.slideshare.net/aheritier/geneva-jug-30th-march-2010-maven
 slide 80).

 What this means is that even if we go through the work of publishing
 binary artifacts compiled against Hadoop2, neither our Hadoop1
 binaries or our Hadoop2 binaries will be able to transitively resolve
 any dependencies defined in profiles. This has significant
 implications to user code that depends on Accumulo Maven artifacts.
 Every user will essentially have to explicitly add Hadoop dependencies
 for every Accumulo artifact that has dependencies on Hadoop, either
 because we directly or transitively depend on Hadoop (they'll have to
 peek into the profiles in our POMs and copy/paste the profile into
 their project). This becomes more complicated when we consider how
 users will try to use things like Instamo.

 There are workarounds, but none of them are really pleasant.

 1. The best way to support both major Hadoop APIs is to have separate
 modules with separate dependencies directly in the POM. This is a fair
 amount of work, and in my opinion, would be too disruptive for 1.5.0.
 This solution also gets us separate binaries for separate supported
 versions, which is useful.

 2. A second option, and the preferred one I think for 1.5.0, is to put
 a Hadoop2 patch in the branch's contrib directory
 (branches/1.5/contrib) that patches the POM files to support building
 against Hadoop2. (Acknowledgement to Keith for suggesting this
 solution.)

 3. A third option is to fork Accumulo, and maintain two separate
 builds (a more traditional technique). This adds merging nightmare for
 features/patches, but gets around some reflection hacks that we may
 have been motivated to do in the past. I'm not a fan of this option,
 particularly because I don't want to replicate the fork nightmare that
 has been the history of early Hadoop itself.

 4. The last option is to do nothing and to continue to build with the
 separate profiles as we are, and make users discover and specify
 transitive dependencies entirely on their own. I think this is the
 worst option, as it essentially amounts to ignore the problem.

 At the very least, it does not seem reasonable to complete
 ACCUMULO-1402 for 1.5.0, given the complexity of this issue.

 Thoughts? Discussion? Vote on option?

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

Re: Hadoop 2 compatibility issues

[Benson Margulies]

I am a maven developer, and I'm offering this advice based on my
understanding of reason why that generic advice is offered.

If you have different profiles that _build different results_ but all
deliver the same GAV, you have chaos.

If you have different profiles that test against different versions of
dependencies, but all deliver the same byte code at the end of the
day, you don't have chaos.



On Tue, May 14, 2013 at 5:48 PM, Christopher ctubb...@apache.org wrote:
 I think it's interesting that Option 4 seems to be most preferred...
 because it's the *only* option that is explicitly advised against by
 the Maven developers (from the information I've read). I can see its
 appeal, but I really don't think that we should introduce an explicit
 problem for users (that applies to users using even the Hadoop version
 we directly build against... not just those using Hadoop 2... I don't
 know if that point was clear), to only partially support a version of
 Hadoop that is still alpha and has never had a stable release.

 BTW, Option 4 was how I had have achieved a solution for
 ACCUMULO-1402, but am reluctant to apply that patch, with this issue
 outstanding, as it may exacerbate the problem.

 Another implication for Option 4 (the current solution) is for
 1.6.0, with the planned accumulo-maven-plugin... because it means that
 the accumulo-maven-plugin will need to be configured like this:
 plugin
   groupIdorg.apache.accumulo/groupId
   artifactIdaccumulo-maven-plugin/artifactId
   dependencies
... all the required hadoop 1 dependencies to make the plugin work,
 even though this version only works against hadoop 1 anyway...
   /dependencies
   ...
 /plugin

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, May 14, 2013 at 5:42 PM, Christopher ctubb...@apache.org wrote:
 I think Option 2 is the best solution for waiting until we have the
 time to solve the problem correctly, as it ensures that transitive
 dependencies work for the stable version of Hadoop, and using Hadoop2
 is a very simple documentation issue for how to apply the patch and
 rebuild. Option 4 doesn't wait... it explicitly introduces a problem
 for users.

 Option 1 is how I'm tentatively thinking about fixing it properly in 1.6.0.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, May 14, 2013 at 4:56 PM, John Vines vi...@apache.org wrote:
 I'm an advocate of option 4. You say that it's ignoring the problem,
 whereas I think it's waiting until we have the time to solve the problem
 correctly. Your reasoning for this is for standardizing for maven
 conventions, but the other options, while more 'correct' from a maven
 standpoint or a larger headache for our user base and ourselves. In either
 case, we're going to be breaking some sort of convention, and while it's
 not good, we should be doing the one that's less bad for US. The important
 thing here, now, is that the poms work and we should go with the method
 that leaves the work minimal for our end users to utilize them.

 I do agree that 1. is the correct option in the long run. More
 specifically, I think it boils down to having a single module compatibility
 layer, which is how hbase deals with this issue. But like you said, we
 don't have the time to engineer a proper solution. So let sleeping dogs lie
 and we can revamp the whole system for 1.5.1 or 1.6.0 when we have the
 cycles to do it right.


 On Tue, May 14, 2013 at 4:40 PM, Christopher ctubb...@apache.org wrote:

 So, I've run into a problem with ACCUMULO-1402 that requires a larger
 discussion about how Accumulo 1.5.0 should support Hadoop2.

 The problem is basically that profiles should not contain
 dependencies, because profiles don't get activated transitively. A
 slide deck by the Maven developers point this out as a bad practice...
 yet it's a practice we rely on for our current implementation of
 Hadoop2 support
 (http://www.slideshare.net/aheritier/geneva-jug-30th-march-2010-maven
 slide 80).

 What this means is that even if we go through the work of publishing
 binary artifacts compiled against Hadoop2, neither our Hadoop1
 binaries or our Hadoop2 binaries will be able to transitively resolve
 any dependencies defined in profiles. This has significant
 implications to user code that depends on Accumulo Maven artifacts.
 Every user will essentially have to explicitly add Hadoop dependencies
 for every Accumulo artifact that has dependencies on Hadoop, either
 because we directly or transitively depend on Hadoop (they'll have to
 peek into the profiles in our POMs and copy/paste the profile into
 their project). This becomes more complicated when we consider how
 users will try to use things like Instamo.

 There are workarounds, but none of them are really pleasant.

 1. The best way to support both major Hadoop APIs is to have separate
 modules with separate dependencies directly in the POM. This is a fair
 amount of work, and in my opinion, would be too disruptive for 

Re: Hadoop 2 compatibility issues

[Benson Margulies]

Maven will malfunction in various entertaining ways if you try to
change the GAV of the output of the build using a profile.

Maven will malfunction in various entertaining ways if you use
classifiers on real-live-JAR files that get used as
real-live-dependencies, because it has no concept of a
pom-per-classifier.

Where does this leave you/us? (I'm not sure that I've earned an 'us'
recently around here.)

First, I note that 'Apache releases are source releases'. So, one
resort of scoundrels here would be to support only one hadoop in the
convenience binaries that get pushed to Maven Central, and let other
hadoop users take the source release and build for themselves.

Second, I am reduced to suggesting an elaboration of the build in
which some tool edits poms and runs builds. The maven-invoker-plugin
could be used to run that, but a plain old script in a plain old
language might be less painful.

I appreciate that this may not be an appealing contribution to where
things are, but it might be the best of the evil choices.


On Tue, May 14, 2013 at 7:50 PM, John Vines vi...@apache.org wrote:
 The compiled code is compiled code. There are no concerns of dependency
 resolution. So I see no issues in using the profile to define the gav if
 that is feasible.

 Sent from my phone, please pardon the typos and brevity.
 On May 14, 2013 7:47 PM, Christopher ctubb...@apache.org wrote:

 Response to Benson inline, but additional note here:

 It should be noted that the situation will be made worse for the
 solution I was considering for ACCUMULO-1402, which would move the
 accumulo artifacts, classified by the hadoop2 variant, into the
 profiles... meaning they will no longer resolve transitively when they
 did before. Can go into details on that ticket, if needed.

 On Tue, May 14, 2013 at 7:41 PM, Benson Margulies bimargul...@gmail.com
 wrote:
  On Tue, May 14, 2013 at 7:36 PM, Christopher ctubb...@apache.org
 wrote:
  Benson-
 
  They produce different byte-code. That's why we're even considering
  this. ACCUMULO-1402 is the ticket under which our intent is to add
  classifiers, so that they can be distinguished.
 
  whoops, missed that.
 
  Then how do people succeed in just fixing up their dependencies and
 using it?

 The specific differences are things like changes from abstract class
 to an interface. Apparently an import of these do not produce
 compatible byte-code, even though the method signature looks the same.

  In any case, speaking as a Maven-maven, classifiers are absolutely,
  positively, a cure worse than the disease. If you want the details
  just ask.

 Agreed. I just don't see a good alternative here.

 
  All-
 
  To Keith's point, I think perhaps all this concern is a non-issue...
  because as Keith points out, the dependencies in question are marked
  as provided, and dependency resolution doesn't occur for provided
  dependencies anyway... so even if we leave off the profiles, we're in
  the same boat. Maybe not the boat we should be in... but certainly not
  a sinking one as I had first imagined. It's as afloat as it was
  before, when they were not in a profile, but still marked as
  provided.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Tue, May 14, 2013 at 7:09 PM, Benson Margulies 
 bimargul...@gmail.com wrote:
  I just doesn't make very much sense to me to have two different GAV's
  for the very same .class files, just to get different dependencies in
  the poms. However, if someone really wanted that, I'd look to make
  some scripting that created this downstream from the main build.
 
 
  On Tue, May 14, 2013 at 6:16 PM, John Vines vi...@apache.org wrote:
  They're the same currently. I was requesting separate gavs for hadoop
 2.
  It's been on the mailing list and jira.
 
  Sent from my phone, please pardon the typos and brevity.
  On May 14, 2013 6:14 PM, Keith Turner ke...@deenlo.com wrote:
 
  On Tue, May 14, 2013 at 5:51 PM, Benson Margulies 
 bimargul...@gmail.com
  wrote:
 
   I am a maven developer, and I'm offering this advice based on my
   understanding of reason why that generic advice is offered.
  
   If you have different profiles that _build different results_ but
 all
   deliver the same GAV, you have chaos.
  
 
  What GAV are we currently producing for hadoop 1 and hadoop 2?
 
 
  
   If you have different profiles that test against different
 versions of
   dependencies, but all deliver the same byte code at the end of the
   day, you don't have chaos.
  
  
  
   On Tue, May 14, 2013 at 5:48 PM, Christopher ctubb...@apache.org
  wrote:
I think it's interesting that Option 4 seems to be most
 preferred...
because it's the *only* option that is explicitly advised
 against by
the Maven developers (from the information I've read). I can see
 its
appeal, but I really don't think that we should introduce an
 explicit
problem for users (that applies to users using even the Hadoop
 version
we directly build against

Publish Maven Site?

[Benson Margulies]

Does anyone *object* to publishing the maven site? I'm got the 'mvn
sire' part of the process set up, it remains to learn how to use CMS
'extpaths' to make the connection.

Re: distributionManagement section in pom.xml points to Benson's public_html directory.

[Benson Margulies]

Oh gosh, no.

There's a new plugin for integrating the site plugin with the new CMS.

http://maven.apache.org/plugins/maven-scm-publish-plugin/

There are a number of projects now using this, not least Maven itself.
I might have some time for this in the next day or two, but I have to
start by confessing that I have no idea what the ASF CMS situation
'round here.



On Tue, Feb 26, 2013 at 10:08 PM, Christopher ctubb...@apache.org wrote:
 It's as good as any other, for now. We're not doing site builds right
 now, and we're certainly not executing site:deploy, so it doesn't
 matter. However, if there's a better staging area, that'd be better,
 in case we do start generating the maven site. Clearly, Benson was
 playing with this, and may wish to continue to do so, but I'm not
 familiar enough with Apache infrastructure to know where else it could
 be put.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, Feb 26, 2013 at 7:33 PM, David Medinets
 david.medin...@gmail.com wrote:
 This can't be correct... can it?

   distributionManagement
 site
   idaccumulo.mvn.website/id
   nameAccumulo Maven Site/name
   
 urlscp://people.apache.org/x1/home/bimargulies/public_html/accumulo-site-stage/url
 /site
   /distributionManagement

Re: Accumulo 1.6 and beyond feature summit

[Benson Margulies]

On Fri, Feb 1, 2013 at 3:04 PM, Aaron Cordova aa...@cordovas.org wrote:
 Benson,

 Just to be clear (I had to re-read your email a few times to understand) 
 you're saying a real-time online discussion such as Adam is proposing has the 
 potential to exclude some members of the dev community and that we should be 
 sure to stick to things like this email discussion to avoid those problems?

Small adjustment: email avoids these problems, but I'm not telling you
that online is 'forbidden'. Just that, as a community, you should be
careful to avoid excluding people. One schema: publish minutes, and be
sure that you don't consider a decision final until it's ratified
on-list.




 Thanks,

 Aaron


 On Feb 1, 2013, at 2:36 AM, Benson Margulies bimargul...@gmail.com wrote:

 I want to caution everyone that this process skates close to an edge
 of an Apache invariant. An online forum has the potential to exclude
 people in far-away time zones or with other constraints. At Apache, we
 try to maximize the use of email to avoid this problem.

 Nothing here is an absolute -- I'm not trying to torpedo this plan 
 altogether.

 Nothing, that is, except except that _decisions_ must be made on the
 mailing list afterwards.

 If anyone in the dev community feels excluded by this prospect, I
 would encourage you to speak up now, so that the planners can make
 adjustments to minimize that.


 On Thu, Jan 31, 2013 at 10:10 PM, Billie Rinaldi
 billie.rina...@gmail.com wrote:
 On Sun, Jan 27, 2013 at 12:43 PM, Eric Newton eric.new...@gmail.com wrote:

 What is CAS?

   - Switch to Curator.
   - Monitoring.  I'm hoping this will just be integration with an existing
   tool.
   - Namespaces.
   - A simple query language.  Perhaps there's something we can collaborate
   with some of the other NoSQL folks.
   - Update the wiki search example.
   - Automatic tablet merge.
   - Scalable NN


 Is scalable NN == ACCUMULO-722?  I'd be excited about that for 1.6.

 Billie




 Some of these don't need design documents, but some discussion of
 requirements would be nice.

 -Eric



 On Sun, Jan 27, 2013 at 12:26 PM, Keith Turner ke...@deenlo.com wrote:

 This will be very useful.

 Some new features I am thinking about for 1.6 are replication, CAS,
 and Percolator.  I would like to put together a bit of an initial
 design document for each of these.  I'm thinking that a follow up
 online deep dive on the design of each large new 1.6 feature would
 also be very useful.

 In the coming week I plan to spend most of my time testing,
 documenting, fixing bugs, and polishing 1.5.0.  I do not think this
 would leave much time to work on 1.6.  So interleaving design
 discussion about new 1.6 features while 1.5 is being polished would be
 nice.  So once 1.5.0 ships, I would have peer reviewed designs to
 start implementing.

 Keith

 On Sat, Jan 26, 2013 at 8:10 PM, Adam Fuchs afu...@apache.org wrote:
 Folks,

 Now that we're past feature freeze for 1.5, I'd like to set up a
 discussion
 of the features that Accumulo developers are interested in for 1.6 and
 beyond. The purpose of this discussion will be to raise awareness of
 projects that you think are cool and important, and to rally the
 community.
 As a proposed format, let's plan on a series of 2-5 minute
 presentations
 of
 individual features -- what it is, why it's important, how should we
 build
 it, and who needs to help. We'll record the presentations for
 posterity.

 Since the community is now distributed throughout several states, let's
 try
 our hand at an online discussion. Depending on participation, we'll
 pick
 a
 forum that can accomodate everyone. If you're interested in attending,
 please fill out this doodle with what time you would be available:
 http://www.doodle.com/w9zb77ya3ykxr4zv

 If you can, please try to fill out the survey by Tuesday afternoon.
 After
 we get a good feel for times and participation, I'll schedule an online
 forum and send out a meeting invitation. If you would like to present a
 feature, send me an email directly at afu...@apache.org, and I'll make
 sure
 you get time to present it.

 I look forward to seeing what everyone has up their sleeves!

 Cheers,
 Adam

Re: If you are wondering why site:site seems to take about a week ...

[Benson Margulies]

On Tue, Nov 20, 2012 at 2:16 PM, Christopher Tubbs ctubb...@gmail.com wrote:
 That's interesting... because I was under the impression that the reporting
 section is simply translated internally to configuration passed to the
 maven-site-plugin. If this is not the case, I need to learn some more.
 However, if it is the case, then, it seems more natural to not rely on the
 correct translation of the reporting section to plugin configuration, and
 just configure that plugin explicitly.

First, there are issues of configuration inheritance. When a child pom
inherits reporting configuration from a parent pom, there is an
orderly process of merging them. If you do it all in the plugin/
element of the site plugin, there is no orderly process.

Then we've got the problem of forked executions causing very slow site
builds. One of my fellow-committers on Maven offered the opinion that
this problem was *also* exacerbated by the new style of config. I
don't have any details as to why, and he might be wrong, and I might
have misread him.


 Perhaps I've misunderstood you. Were you suggesting ignoring the site build
 entirely, as we're not really using it to generate a site, and just using
 the various independent reporting tools to generate javadoc artifacts, code
 coverage reports for Jenkins, etc., and avoid doing any site building
 whatsoever? Because, I've heard that recommendation before also...

I'm not suggesting punting on the use of the site, I like Maven sites.
The model I am deriving, however, is that some features of Maven sites
just don't work too well. In particular, any reporting mojo that
declares a forked execution is deadly in any project large than tiny.




 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, Nov 20, 2012 at 2:05 PM, Benson Margulies 
 bimargul...@gmail.comwrote:

 On Tue, Nov 20, 2012 at 2:03 PM, Christopher Tubbs ctubb...@gmail.com
 wrote:
  Moving to the natural Maven 3 usage of maven-site-plugin as a normal
 build
  plugin, with configuration for reporting, instead of dealing with the
  massive reporting section that gets mapped to the maven-site-plugin,
 may
  also help.


 Just the opposite. As a member of the Maven PMC, I can sadly report
 that we currently recommend *against* that. It was not thought
 through, it doesn't work very well, and in particular it makes this
 problem worse.


 
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Sun, Nov 18, 2012 at 6:46 PM, Josh Elser josh.el...@gmail.com
 wrote:
 
  +1 For moving cobertura to its own profile, add something saying so to
 the
  readme/website, and let people decide when they want to activate it.
 
 
  On 11/18/2012 05:56 PM, Benson Margulies wrote:
 
  There's a very longstanding bug/confusion in Maven that results from
  reporting plugins that fork executions. That's not the same thing as
  forking a jvm, it's an internal maven business where a plugin says,
  'whoops, to run me you have to make a whole new maven and run all this
  other stuff first'.
 
  The cobertura plugin does this. So does Javadoc in some really
 irritating
  cases.
 
  If folks would like a faster site build, I'd suggest moving cobertura
  to a profile.
 
  If the current 'go for coffee' situation doesn't bother anyone too
  much, we can leave it alone.
 
 

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

And the final answer, from the findbugs maintainer, is:

In org.apache.hadoop.mapred.JobClient, from:

org/apache/hadoop/hadoop-core/0.20.205.0/hadoop-core-0.20.205.0.jar

So, if you want to shut up the warning before FB releases and f-m-p
releases, you can add some version of jackson 1 (whatever hadoop uses)
to the pom as a runtime dependency.



On Sun, Nov 18, 2012 at 10:49 PM, David Medinets
david.medin...@gmail.com wrote:
 Thanks for following up on this issue.

 On Sun, Nov 18, 2012 at 10:02 PM, Benson Margulies
 bimargul...@gmail.com wrote:
 Seems like findbugs thinks its a findbugs bug.

 https://sourceforge.net/tracker/?func=detailatid=614693aid=3588379group_id=96405



 On Sun, Nov 18, 2012 at 5:33 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 David,

 findbugs is gaslighting you. Jackson is nowhere in the classpath of
 accumulo-server. And I grepped all of the jars that *are* in the
 classpath, and none of them include copies of the Jackson
 ObjectMapper.

 -benson




 On Sun, Nov 18, 2012 at 4:37 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 I also don't see jackson anywhere when I run 'dependency:list'. Where
 are you seeing the ObjectMapper class?


 On Sun, Nov 18, 2012 at 4:32 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 There are no jackson deps in any Accumulo poms.  What module do you
 see jackson in?


 On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
 david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: Parse Exception During 'mvn site' execution

[Benson Margulies]

This appears to be a bug/incompatible change in JIRA! The URL that is
supposed to fetch RSS XML fetches HTML instead. I've borrowed my
day-job JIRA SEN to poke Atlassian about it.


On Mon, Nov 19, 2012 at 8:39 AM, Benson Margulies bimargul...@gmail.com wrote:
 I'm going to make the MCHANGES JIRA.


 On Sun, Nov 18, 2012 at 4:22 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 This goes in under the heading of 'oops'. Please enter a JIRA for the
 maven-changes-plugin and I'll see what I can do.


 On Sun, Nov 18, 2012 at 3:37 PM, David Medinets
 david.medin...@gmail.com wrote:
 [INFO] Generating JIRA Report report--- Maven Changes Report Plugin 
 2.7.1
 Nov 18, 2012 3:32:53 PM org.apache.commons.httpclient.HttpMethodBase
 getResponseBody
 WARNING: Going to buffer response body of large or unknown size. Using
 getResponseBodyAsStream instead is recommended.
 [ERROR] maven-changes-plugin: invalid statusId closed
 [ERROR] maven-changes-plugin: invalid statusId resolved
 [INFO] Downloading from JIRA at:
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rsspid=12312121resolutionIds=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=1reset=truedecorator=none
 [WARNING]
 org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
 at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
 at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
 at 
 org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755)
 at 
 org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:302)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:221)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
 at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
 at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.xml.sax.SAXParseException; lineNumber: 11;
 columnNumber: 88; The entity name must immediately follow the '' in
 the entity reference.
 at 
 org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
 Source)
 at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown 
 Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
 Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
 Source

maven-changes-plugin does not work with JIRA 5.1.1 and newer

[Benson Margulies]

Atlassian made an incompatible change to JIRA that they have marked 'won't fix':

https://jira.atlassian.com/browse/JRA-29152

Unless they can provide some alternative, the maven-changes-plugin is
essentially worthless for JIRA instances of that version or newer,
which includes the ASF main JIRA instance. They say that they plan to
include an alternative in 5.2; so once they release 5.2, and ASF JIRA
runs it, someone can patch up the m-c-p to work with it. Until then,
we are all out of luck.

Re: Another source of the site plugin explosion

[Benson Margulies]

It's significantly speedier, but not exactly quick. findbugs and pmd
are quite slow on the code, but at least we're not running them
multiple times any longer.


On Mon, Nov 19, 2012 at 3:48 PM, Keith Turner ke...@deenlo.com wrote:
 On Mon, Nov 19, 2012 at 8:34 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 I'm still verifying this, but it appears that javadoc:aggregate is
 also an offender.

 However, http://jira.codehaus.org/browse/MJAVADOC-171 offers a
 workaround, which I propose to apply.

 Have you verified it yet?  If that speeds things up, it would be a great 
 change.

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

What version of Jackson is in place?


On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: Parse Exception During 'mvn site' execution

[Benson Margulies]

This goes in under the heading of 'oops'. Please enter a JIRA for the
maven-changes-plugin and I'll see what I can do.


On Sun, Nov 18, 2012 at 3:37 PM, David Medinets
david.medin...@gmail.com wrote:
 [INFO] Generating JIRA Report report--- Maven Changes Report Plugin 
 2.7.1
 Nov 18, 2012 3:32:53 PM org.apache.commons.httpclient.HttpMethodBase
 getResponseBody
 WARNING: Going to buffer response body of large or unknown size. Using
 getResponseBodyAsStream instead is recommended.
 [ERROR] maven-changes-plugin: invalid statusId closed
 [ERROR] maven-changes-plugin: invalid statusId resolved
 [INFO] Downloading from JIRA at:
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rsspid=12312121resolutionIds=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=1reset=truedecorator=none
 [WARNING]
 org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
 at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
 at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
 at 
 org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755)
 at 
 org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:302)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:221)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
 at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
 at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.xml.sax.SAXParseException; lineNumber: 11;
 columnNumber: 88; The entity name must immediately follow the '' in
 the entity reference.
 at 
 org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
 Source)
 at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown 
 Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
 at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
 at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown 
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
 Source)
 at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
 Source)
 

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

There are no jackson deps in any Accumulo poms.  What module do you
see jackson in?


On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

I also don't see jackson anywhere when I run 'dependency:list'. Where
are you seeing the ObjectMapper class?


On Sun, Nov 18, 2012 at 4:32 PM, Benson Margulies bimargul...@gmail.com wrote:
 There are no jackson deps in any Accumulo poms.  What module do you
 see jackson in?


 On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
 david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: Site plugin 3.2.

[Benson Margulies]

Ticket created. Test build running.

site:site takes forever due to forked executions. I should really roll
up my sleeves and track down the cause.


On Sun, Nov 18, 2012 at 4:37 PM, Eric Newton eric.new...@gmail.com wrote:
 No, please update it. Yes, create a ticket.  Thanks!


 On Sun, Nov 18, 2012 at 4:31 PM, Benson Margulies 
 bimargul...@gmail.comwrote:

 Anyone object to an upgrade thereto? Should I hang it off of a JIRA?

Ignore my note in a JIRA about lacking access

[Benson Margulies]

I was fooled by the resolve button hiding behind 'workflow'.

Re: thrift

[Benson Margulies]

Except that the build hangs, awaiting a newline, when it gets to this,
so it's quite irritating.

On Sun, Nov 18, 2012 at 5:09 PM, John Vines vi...@apache.org wrote:
 That is more so an info message than anything else. We attempt to rebuild
 the thrift generated stuff in the maven processes, but they are by no means
 mandatory. Thrift stuff doesn't get changed much, and when it is we expect
 the developer to commit the updated thrift generated code.

 For the record, this is resolved by installing thrift on the build machine.

 Sent from my phone, pardon the typos and brevity.
 On Nov 18, 2012 4:45 PM, Benson Margulies bimargul...@gmail.com wrote:

 I would expect the cure to

 ***
 * thrift is not available *
 *   expecting 'thrift -version' to return 0.8 *
 ***

 to be documented on

 http://accumulo.apache.org/source.html

 Can someone point me at the cure and I'll fix up the site?

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

David,

findbugs is gaslighting you. Jackson is nowhere in the classpath of
accumulo-server. And I grepped all of the jars that *are* in the
classpath, and none of them include copies of the Jackson
ObjectMapper.

-benson




On Sun, Nov 18, 2012 at 4:37 PM, Benson Margulies bimargul...@gmail.com wrote:
 I also don't see jackson anywhere when I run 'dependency:list'. Where
 are you seeing the ObjectMapper class?


 On Sun, Nov 18, 2012 at 4:32 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 There are no jackson deps in any Accumulo poms.  What module do you
 see jackson in?


 On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
 david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: What Jar File Contains org.codehaus.jackson.map.ObjectMapper?

[Benson Margulies]

Seems like findbugs thinks its a findbugs bug.

https://sourceforge.net/tracker/?func=detailatid=614693aid=3588379group_id=96405



On Sun, Nov 18, 2012 at 5:33 PM, Benson Margulies bimargul...@gmail.com wrote:
 David,

 findbugs is gaslighting you. Jackson is nowhere in the classpath of
 accumulo-server. And I grepped all of the jars that *are* in the
 classpath, and none of them include copies of the Jackson
 ObjectMapper.

 -benson




 On Sun, Nov 18, 2012 at 4:37 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 I also don't see jackson anywhere when I run 'dependency:list'. Where
 are you seeing the ObjectMapper class?


 On Sun, Nov 18, 2012 at 4:32 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 There are no jackson deps in any Accumulo poms.  What module do you
 see jackson in?


 On Sun, Nov 18, 2012 at 9:59 AM, David Medinets
 david.medin...@gmail.com wrote:
 I am refining the findbugs task in a build.xml. I have identified jar
 files for every class except ObjectMapper. It should be in my maven
 repository but I can't find it. If anyone has insight into this issue,
 please let me know.

Re: Setting Charset in getBytes() call.

[Benson Margulies]

Maybe I'm being particularly dense, but I still think that this is
being made too complex by failing to enumerate the specific goals.

First case; data for which Accumulo is defined to persistently store
*characters*, as opposed to bytes. I would hope that, in all such
cases, we would agree that those characters should be stored in some
Unicode format, never in some legacy encoding.

Second case; data for which Accumulo is defined to store bytes, but,
for convenience, an API allows the user to read and write characters.
In this case, I can imagine two competing API designs. One would be to
mirror Java, and in all such cases give the user the option of
specifying the charset, defaulting to file.encoding. The other would
be to insist on UTF-8. A third possibility - to just respect
file.encoding - seems to me to be retreading the errors of Java 1.x.

Third case; cases in which the user either supplies a text file for
Accumulo to read, or asks Accumulo to write a text file. Having an API
that can default to file.encoding here would be convenient for users,
who want files in their platform's default encoding. Note that this is
incompatible with the notion of *setting* file.encoding as an
implementation technique for getting the string constructor and
getBytes() to do UTF-8.

Finally for today, I had a hard time following the response to my
writing on servlets. I'll vastly simplify my presentation: when a user
of Accumulo writes Java code that calls the Accumulo API, I find it
unacceptable to require that user to set file.encoding to get correct
behavior from Accumulo, except as described in the second case above.
When Accumulo classes are integrated into user applications, Accumulo
must respect file.encoding, or ignore file.encoding, but it cannot
require the user to set it to something in particular to get correct
behavior.

Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())

[Benson Margulies]

On Wed, Oct 31, 2012 at 1:38 PM, Keith Turner ke...@deenlo.com wrote:
 On Wed, Oct 31, 2012 at 1:01 PM, John Vines vi...@apache.org wrote:
 Not wanting to merge is a terrible reason to commit a patch. A patch file
 would have been more then sufficient until we reached a consensus on

 A slight deviation.  I have used review board for potentially
 disruptive changes.  When I used it, I got excellent feedback from the
 community that greatly improved my patches.   A nice tool to be aware
 of if you have a patch that you are uneasy about.

CTR communities deal with this all the time. In a CTR community,
people who make changes are prepared to unmake, remake, or otherwise
adjust changes as needed to achieve consensus. RTC communities do it
the other way around. For the sake of collective sanity, I'd encourage
this group to clarify that it is one or the other, and not try to
achieve too much of a hybrid.



 implementation. The worst case is that the patch had to be merged properly,
 which someone would have had to do. We are a community, and if one person
 does not have the resources to merge a patch due to code changes there are
 plenty of others here who are willing to do it.

 That said, patch files should be the way to go for any sort of contested
 implementation. It gives the community a chance to see that implementation
 firsthand without there being dedication to it. I do not think code should
 ever be committed if there is still reasonable discourse about the
 implementation being had. For the record, I also feel that time shouldn't
 be spent on implementation which is under review, simply because it could
 be a waste of time, with exception for cases where code samples will help
 the discussion.

 John

 On Wed, Oct 31, 2012 at 12:44 PM, David Medinets
 david.medin...@gmail.comwrote:

 On Wed, Oct 31, 2012 at 12:18 PM, Adam Fuchs afu...@apache.org wrote:
  I think the core policy should be if you think your change is at all
 likely
  to be rolled back then don't commit it. This applies to tickets with
 active
  debates. I also don't think we need to be heavy handed in policy -- shame
  of roll back is enough motivation and the cost isn't that high.

 This particular change required a fair bit of analysis (i.e., looking
 at over a thousand method calls). I could only devote that time due to
 Hurricane Sandy barreling down on me. If I had held off on my commit
 and the source code changed, I would have some merging to do. And
 maybe no time to do that. So my time and analysis would have been
 wasted. With the commit, the analysis has been made concrete and the
 community can more forward. In fact,
 https://issues.apache.org/jira/browse/ACCUMULO-840 was created to do
 just that.

  Drew said:
  I haven't been closely following how things have worked with Accumulo,
 but
  I did notice that the getBytes() stuff had been checked in. Just
 wondering
  if this is the norm, or how things should work.

 In normal situations (i.e., in the past) I recall waiting for a
 consensus to develop.

Re: Setting Charset in getBytes() call.

[Benson Margulies]

UTF-8 allows any String to have to go into the database and get back
out. Are there actually use cases in which some application code
pushes in strings, and another pulls out bytes, and would be perturbed
to find UTF-8 as opposed to some other encoding in the bytes?

Re: Setting Charset in getBytes() call.

[Benson Margulies]

On Tue, Oct 30, 2012 at 8:21 PM, Josh Elser josh.el...@gmail.com wrote:
 On 10/30/2012 7:47 PM, David Medinets wrote:

 My issue with this is that you have now hard-coded the fact that everyone
 else is going to use UTF-8.


 Who is everyone else? I agree that I have hard-coded the use of UTF-8.
 On the other hand, I've merely codified an existing practice. Thus the
 issue is now exposed, the places the convention is used are defined.
 Once a consensus is reached, we can implement it with confidence.


 Everyone else is everyone who builds Accumulo since you committed your
 changes and uses it. Ignoring that, forcing a single charset isn't the big
 issue here (as we've *all* agreed that UTF-8 should not cause any
 data-correctness issues) so for now I'll just drop it as it's just creating
 confusion.

 My issue is *how* you implemented the default charset. We already have 3
 people (Marc, Bill and myself) who have stated that we believe inline
 charset declaration is not the correct implementation and that using the JVM
 property is the better implementation.

 I'd encourage others to weigh in to form a complete consensus and shift the
 discussion to that implementation if needed.


 way to fix the problem. I still contest that setting the desired encoding
 (via the appropriate JVM property like Bill Slacum initial suggested) is
 the
 proper way to address the issue.


 It is easy to do both. Create a ByteEncodingInitializer (or somesuch)
 class that reads the JVM property and defines a globally used Charset.
 The find those utf8 definitions and usages and replace them with the
 globally-defined value.


 Again, by setting the 'file.encoding' JVM parameter, such a class is
 unnecessary because it should be handled internal to Java. For Oracle/Sun
 JDK and OpenJDK, setting the file.encoding parameter at run time will use
 the provided charset you wanted without actually changing any code.

If Accumulo was only a pile of servers, you could do this. You could
say that part of the configuration process for the servers is to
specify the desired encoding to file.encoding, and your shell scripts
could set UTF-8 by default.

But Accumulo is *not* just a pile of servers. Setting file.encoding
effects the entire JVM. A webapp that uses Accumulo now would need to
have the entire servlet container have a particular setting of
file.encoding. This just does not work in the wild. Even without the
servlet container issue, a user of Accumulo may need to plug it into
an existing code base that has other reasons to set file.encoding, and
will not like it when Accumulo starts to corrupt his or her string
data.

Re: Setting Charset in getBytes() call.

[Benson Margulies]

On Mon, Oct 29, 2012 at 12:21 PM, Josh Elser josh.el...@gmail.com wrote:
 David, I beg to differ.

 Setting it via the JVM property is a single change to make, whereas if you
 change every single usage of getBytes(), you now forced the next person to
 branch the code, change everything to UTF16 (hypothetical use case) and
 continue a diverged codebase forever.

Typically, the reason(s) that people don't take this approach are:

a: a fear that other JVMs don't have this parameter, or don't have it
under the same name.
b: a desire to read or write files for uses in 'the platform encoding'
whatever it is, in addition to whatever needs to be done in UTF-8.

I'd be very surprised if Accumulo ever decided to do this sort of
thing in UTF-16.



 I would say that the reason that such a JVM property exists is to alleviate
 you from having to make these code changes in the first place.

 On 10/29/2012 12:00 PM, David Medinets wrote:

 I like the idea of making the change explicit in the source code.
 Setting the encoding in the jvm property would be easier but not as
 explicit. I have a few dozen of the files changed. Today I have free
 time since Hurricane Sandy has closed offices.

 On Mon, Oct 29, 2012 at 11:39 AM, William Slacum
 wilhelm.von.cl...@accumulo.net wrote:

 Isn't it easier to just set the JVM property `file.encoding`?

 On Sun, Oct 28, 2012 at 3:18 PM, Ed Kohlwey ekohl...@gmail.com wrote:

 If you use a private static field in each class for the charset, it will
 basically be a singleton because charsets are cached in char
 set.forname.
 IMHO this is a somewhat cleaner approach than having lots of static
 imports
 to utility classes with lots of constants in them.
 On Oct 28, 2012 5:50 PM, David Medinets david.medin...@gmail.com
 wrote:




 https://issues.apache.org/jira/browse/ACCUMULO-241?focusedCommentId=13449680page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13449680


 In this comment, John mentioned that all getBytes() method calls
 should be changed to use UTF8. There are about 1,800 getBytes() calls
 and not all of them involve String objects. I am working on ways to
 identify a subset of these calls to change.

 I have created https://issues.apache.org/jira/browse/ACCUMULO-836 to
 track this issue.

 Should we create one static Charset object?

Class AccumuloDefaultCharset {
  public static Charset UTF8 = Charset.forName(UTF8);
}

 Should we use a static constant?

public static String UTF8 = UTF8;

 I have found one instance of getBytes() in InputFormatBase:

protected static byte[] getPassword(Configuration conf) {
  return Base64.decodeBase64(conf.get(PASSWORD, ).getBytes());
}

 Are there any reasons why I can't start specifying the charset? Is
 UTF8 the right Charset to use? I am not an expert in non-English
 charsets, so guidance would be welcome.

Re: Setting Charset in getBytes() call.

[Benson Margulies]

On Mon, Oct 29, 2012 at 3:18 PM, John Vines vi...@apache.org wrote:
 So perhaps we should have ISO-8859-1 as the standard. Mike- do you see any
 reason to use something beside ISO-8859-1 for the encodings?

I object and caution against *any* plan that involves transcoding from
X to UTF-16 and back where when the data is not always going to be
valid bytes of encoding X. The only clean solution here is to have an
API entirely in terms of bytes, and either let the user do getBytes if
they want to store string data, or provide additional API.




 John

 On Mon, Oct 29, 2012 at 3:14 PM, Michael Flester fles...@gmail.com wrote:

  UTF-8 should always be present (according to the JLS), and as a
 multi-byte
  format should be able to encode any character that you would need to.
 

 UTF-8 cannot encode arbitrary data. All data that we store in accumulo
 is not characters. A safe encoding to use as a pass through when you
 don't know if you are dealing with characters is ISO-8859-1 since we know
 that we can make the round trip from bytes to string to bytes without loss.

Re: Setting Charset in getBytes() call.

[Benson Margulies]

On Mon, Oct 29, 2012 at 8:46 PM, Josh Elser josh.el...@gmail.com wrote:
 +1 Mike.

 1. It would be hard for me to believe Key/Value are ever handled internally
 in terms of Strings, but, if such a case does exist, it would be extremely
 prudent to fix.

 2. FWIW, the Shell does use ISO-8859-1 as its charset which is referenced by
 other commands [1,2]. It would be good to double check all of the other
 commands.

I'm a bit lost. Any possible Java String can be rendered in UTF-8. So,
if you are calling String.getBytes to turn a string into some bytes
for some purpose, I think you need UTF-8.

On the other hand, as Mike pointed out, new String(somebytes, utf-8)
will destroy data for some byte values that are not, in fact, UTF-8.
By why would Accumulo ever need to string-ify some array of bytes of
uncertain parentage?



 [1]
 https://github.com/apache/accumulo/blob/trunk/core/src/main/java/org/apache/accumulo/core/util/shell/Shell.java
 [2]
 https://github.com/apache/accumulo/blob/trunk/core/src/main/java/org/apache/accumulo/core/util/shell/commands/InsertCommand.java


 On 10/29/2012 8:27 PM, Michael Flester wrote:

 I agree with Benson entirely with one caveat. It seems to me that there
 might be two categories of things being discussed

1. User data (keys and values)
2. Ancillary things needed for operation of Accumulo (passwords).

 These could well be considered separately. Trying to do anything with
 keys and values other than treating them as bytes all of the time
 I find quite scary.

 And if this is only being done to satisfy pmd or findbugs, those tools
 can be convinced to modify their reporting about this issue.

Re: Patching and JIRA?

[Benson Margulies]

On Sun, Oct 14, 2012 at 9:13 AM, Christopher Tubbs ctubb...@gmail.com wrote:
 I'd almost prefer all patches to be submitted as a link to a GitHub
 repo, but since our SCM is SVN natively, I'm not sure how well that
 would work. It would certainly be ideal if we had a native Git repo
 for Accumulo... is the one on apache.org writable, or just a read only
 view of what's in svn?

The community can opt to move from svn to git at Apache. If you do so,
however, you still have some issues with patches. The Apache licence
states that patches submitted to Apache mailing lists or otherwise
delivered to Apache infrastructure are official, licensed,
contributions. I'm not sure of the status of 'please pull this from
repo X' email -- I haven't followed the discussions in that area
carefully.



 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Sat, Oct 13, 2012 at 2:24 PM, Drew Farris d...@apache.org wrote:
 Hi All,

 In the past, when I've used JIRA and uploaded multiple versions of
 patches to the same issue, I've simply used the same filename, and
 JIRA took care of putting a strikethrough in the listings for the old
 version of the patch, indicating that they were available but should
 be ignored.

 These days, it simply greys the old patch versions out. It makes
 things a little less clear as to which patches should be applied to
 obtain the fix.

 There is some value in maintaining a patch history, but in many cases
 old patches should be trashed to make it clear which patch should be
 applied to obtain the fix.

 Any patch posted should contain the entire change for a given issue,
 as opposed to requiring individuals working the issue to apply
 multpile patches to obtain an update.

 Does this make sense, or does anyone think patches should be handled
 differently?

 Drew

Re: TooManyFilesException.java - cannot find org.slf4j

[Benson Margulies]

?how? did you load it into eclipse? M2E? maven-eclipse-plugin?

On Sat, Oct 6, 2012 at 11:23 AM, Kristopher Kane kkane.l...@gmail.com wrote:
 Please bear with me as I'm cutting teeth on a lot of things to work on
 ACCUMULO-720... like learning Java.  :-)

 I did an SVN check out of trunk and compiled/ran it. Then I imported
 the checkout into Eclipse and noticed that TooManyFilesException.java
 is complaining about not being able to find org.slf4j.

 When I compiled with Maven everything appeared to finish fine.  Does
 mean that Maven ignored the missing import or that it downloaded the
 dep at compile time?

 Thanks for the help,

 -Kris

Re: Plumbr - memory leak detection

[Benson Margulies]

On Thu, Aug 16, 2012 at 7:03 AM, David Medinets
david.medin...@gmail.com wrote:
 Plumbr has offered a free license to the  Apache Accumulo project. Who
 is the best person to take advantage of this offer?

The right way to do this is to put the license into the private SVN
area where any committer can get to it.


 On Wed, Aug 8, 2012 at 2:46 PM, David Medinets david.medin...@gmail.com 
 wrote:
 http://plumbr.eu/ - I just learned about this commercial software. I'm
 mentioning it because of a recent thread.

Re: Plumbr - memory leak detection

[Benson Margulies]

The vendors of YourKit and JProfiler have been willing to make license
keys available to Apache projects for the asking. Typically, they ask
for an ack on the web site, and that the license be only made
available to committers.


On Wed, Aug 8, 2012 at 3:40 PM, Michael Wall mjw...@gmail.com wrote:
 VisualVM is part of the JDK since 1.6, so you might already have it and not
 know.  Look for jvisualvm in the JAVA_HOME/bin directory right beside the
 java and javac executables.  It doesn't appear to be part of OSX or RHEL by
 default though.  I have found this link to be useful,
 http://java.dzone.com/articles/best-kept-secret-jdk-visualvm

 We have also had success with YourKit,
 http://www.yourkit.com/overview/index.jsp,  but it too is commercial.

 On Wed, Aug 8, 2012 at 3:06 PM, Edmon Begoli ebeg...@gmail.com wrote:

 Have you folks used:

 http://visualvm.java.net/

 It is not as automated as commercial memory leak pursuing tools but I
 think lot can be done with it:

 http://www.munzandmore.com/2011/ora/memleak

 On Wed, Aug 8, 2012 at 2:46 PM, David Medinets david.medin...@gmail.com
 wrote:
  http://plumbr.eu/ - I just learned about this commercial software. I'm
  mentioning it because of a recent thread.

Re: PMC Membership

[Benson Margulies]

This is a discussion amongst the existing PMC on the private list at this point.

On Wed, Aug 1, 2012 at 2:33 PM, Josh Elser josh.el...@gmail.com wrote:
 Cool. Is this being publicly created?


 On 8/1/12 2:24 PM, Benson Margulies wrote:

 On Wed, Aug 1, 2012 at 2:11 PM, Adam Fuchs afu...@apache.org wrote:

 Josh,

 One of the tasks we have not yet taken on is to write bylaws for the
 Accumulo project. This is where things like PMC membership, subprojects,
 committer requirements, etc. are found. Here's an example:
 http://hadoop.apache.org/bylaws.html

 We're working on this.

 Cheers,
 Adam


 On Wed, Aug 1, 2012 at 2:07 PM, Josh Elser josh.el...@gmail.com wrote:

 Out of curiosity, has Accumulo defined how its PMC membership operates?

 I don't recall seeing anything written down about this.

 - Josh

Benson on vacation

[Benson Margulies]

From July 6 through July 16th I will very likely moderate no email nor
on anything.

Re: frustrated with apache.org

[Benson Margulies]

Billie, would you care to open a JIRA ticket?

On Thu, Jun 28, 2012 at 10:56 PM, David Medinets
david.medin...@gmail.com wrote:
 I'm sorry ... It's been a long day. I meant private key and
 infrastruct...@apache.org.

 On Thu, Jun 28, 2012 at 9:41 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 Your private ***key***, yes?

 On Thu, Jun 28, 2012 at 9:22 PM, David Medinets
 david.medin...@gmail.com wrote:
 I've tried twice to request my private be removed from my apache.org
 account so that I can once again contribute but so far r...@apache.org
 and administra...@apache.org have ignored my emails. Is there another
 email address I should be sending to?

Re: frustrated with apache.org

[Benson Margulies]

Your private ***key***, yes?

On Thu, Jun 28, 2012 at 9:22 PM, David Medinets
david.medin...@gmail.com wrote:
 I've tried twice to request my private be removed from my apache.org
 account so that I can once again contribute but so far r...@apache.org
 and administra...@apache.org have ignored my emails. Is there another
 email address I should be sending to?

Re: Unable to Commit - did ASF Password reset affect SVN?

[Benson Margulies]

I think that they are not. Have you followed the reset instructions?

On Wed, Jun 13, 2012 at 6:11 PM, David Medinets
david.medin...@gmail.com wrote:
 I tried to check in my change for ACCUMULO-635 but SVN is not
 accepting my password. I can log into https://issues.apache.org/jira.
 Aren't they the same password?

Re: license and notice for maven plugins?

[Benson Margulies]

no one else worries about this.

On Mar 28, 2012, at 10:37 AM, Billie J Rinaldi
billie.j.rina...@ugov.gov wrote:

 Should maven plugins that don't come from apache.org be listed in the license 
 and notice files?

 Billie