I made some changes for ACCUMULO-935 that may be unexpected, so here's
some information that may help:
Use 'mvn -DDEV_ACCUMULO_HOME package' to output built artifacts to an
external directory, so the workspace does not get dirtied with
unversioned files outside of the target directories, that need
Minor correction. The basic method for specifying the external directory is:
mvn -DDEV_ACCUMULO_HOME= package
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Jun 3, 2013 at 4:04 PM, Christopher wrote:
> I made some changes for ACCUMULO-935 that may be unexpected, so here's
> some
What happens if I don't set the property? Does everything end up under
target?
On Mon, Jun 3, 2013 at 4:06 PM, Christopher wrote:
> Minor correction. The basic method for specifying the external directory
> is:
> mvn -DDEV_ACCUMULO_HOME= package
>
> --
> Christopher L Tubbs II
> http://gravatar
Nope. If you don't set the property, then it won't copy files to that
directory, and you'll have to build the binary assembly or rpm or deb
and unpack/install that, as we expect end-users to normally do, in
order to get a similar structure.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Oh, well, I should clarify... the things that would normally go *in*
that directory (such as jars) would still end up in their respective
target directories (except those things copied directly from the
source tree, like the scripts and configuration).
--
Christopher L Tubbs II
http://gravatar.com
Given all the previous discussions about this, and assuming all points
and counterpoints have already been sufficiently enumerated, I'd like
to put it to a vote, explicitly:
Should we switch to JDK 1.7 for Accumulo 1.6.0, to take advantage of
newer features (ACCUMULO-905), or should we continue to
Can you clarify what you mean?
- I would be ok with making JDK 1.7 the "default" for Accumulo 1.6.0. I
think this mostly boils down to the JDK which we would be performing our
testing with.
- I don't want to alienate JDK/JRE 1.6 users from using Accumulo 1.6.0,
so I am not in favor of removing
Dropping JDK6 support is a pretty big deal.
Is it worth making it a 2.0.0 feature instead of 1.6.0?
If not, what would be the distinction for a 2.0.0?
In the mean time we could explicitly change testing to be on JDK7 instead
of JDK6 as an initial step.
On Mon, Jun 3, 2013 at 4:51 PM, Christoph
Let's be specific: which Java-1.7-only feature is motivating this change?
Without knowing the upside I am inclined to vote no because of the number
of platforms that I regularly see that are running java 1.6.
Adam
On Mon, Jun 3, 2013 at 4:51 PM, Christopher wrote:
> Given all the previous dis
Let me clarify myself a bit, as I just had a chat session with Keith and
Christopher...
The concern I have is that moving to Java1.7 (jdk or jre), the second
bullet from below, is that this may force a departure from the typical
lifecycle for Accumulo 1.5. If the collective "we" are happy with
+1
By the time Accumulo 1.6. release, Java 1.7 will have been released for
over two years.
On Mon, Jun 3, 2013 at 4:51 PM, Christopher wrote:
> Given all the previous discussions about this, and assuming all points
> and counterpoints have already been sufficiently enumerated, I'd like
> to pu
Adam, the question isn't whether we should stop supporting users on
Java 1.6. The question is whether they'd be enticed by 1.6.0 features
enough to be willing to install its prerequisites. Accumulo 1.5.0 will
continue to run on 1.6 JVMs without issue, and we can continue to
support that so long as
I forgot to mention this, but this vote will be held open for 72
hours. Since I forgot to mention this right away, consider the clock
starting now.
I'll consider the vote as having passed with a majority of voters
approving (vs. unanimous), since I don't think negative votes will be
reconcilable th
On Mon, Jun 3, 2013 at 5:21 PM, Sean Busbey wrote:
> Dropping JDK6 support is a pretty big deal.
I don't know that it's as big a deal as many think it is, but it is
certainly big enough to require a vote, I think.
> Is it worth making it a 2.0.0 feature instead of 1.6.0?
>
> If not, what would b
On Mon, Jun 3, 2013 at 5:21 PM, Sean Busbey wrote:
> Dropping JDK6 support is a pretty big deal.
>
> Is it worth making it a 2.0.0 feature instead of 1.6.0?
>
> If not, what would be the distinction for a 2.0.0?
>
One thing 2.0 could be used for is a new incompatible API.
>
> In the mean time
On Mon, Jun 3, 2013 at 6:23 PM, Christopher wrote:
> On Mon, Jun 3, 2013 at 5:21 PM, Sean Busbey wrote:
>
> > In the mean time we could explicitly change testing to be on JDK7 instead
> > of JDK6 as an initial step.
>
> I don't know what you mean by this. I've been running on JRE7 for
> quite so
+1 because:
- Java 1.6 has reached EOL, making Java 1.7 inevitable
- we're very early in the planning phase for Accumulo 1.6, which means we
hopefully won't break or invalidate already-contributed features to it
I don't think a 2.0.0 should be motivated by an upgrade in a dependency,
even if it'
On Mon, Jun 3, 2013 at 6:31 PM, Sean Busbey wrote:
> On Mon, Jun 3, 2013 at 6:23 PM, Christopher wrote:
>> On Mon, Jun 3, 2013 at 5:21 PM, Sean Busbey wrote:
[snip]
> I was thinking specifically of the CI builds on jenkins.
I see. We can do that, certainly.
> --
> Sean
--
Christopher L Tubbs
On Mon, Jun 3, 2013 at 5:04 PM, Josh Elser wrote:
>
Also, some quick searching leads me to believe that 1.6 bytecode will run
> on a 1.7 JVM, but not vice versa. Does anyone know if this is the case? I
> apologize if I'm bringing up an already-discussed subject.
>
>
Just to confirm, the JDK7
+1 with reservations. This seems like a big API change, not because our
dependency changes, but doesn't it force all consumers to change to Java 7 as
well if new language features are used in the client? Looks like Java 6
compiled iterators should work without change.
I wonder if would make
Not necessarily. There is always the difference in implementation
against the JDK implementation.
The Oracle site Sean linked actually goes through a bunch (all?) of
changes. The TreeMap change has already bit me once.
On 06/03/2013 08:54 PM, Dave Marion wrote:
Looks like Java 6 compiled ite
Is JDK 1.7 is supported in the common Hadoop distros?
Hortonworks doc doesn't seem to list a version. A Hortonworks forum page
claims JDK 1.7 isn't supported as of April 2013:
http://hortonworks.com/community/forums/topic/jdk-7/
CDH4 claims JDK 1.6 and 1.7 support:
http://www.cloudera.com/conten
22 matches
Mail list logo
