Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Hadoop 2 compatibility issues


+
Christopher 2013-05-14, 20:40
+
Sean Busbey 2013-05-14, 20:52
+
Christopher 2013-05-14, 21:39
+
John Vines 2013-05-14, 20:56
+
Benson Margulies 2013-05-14, 21:16
+
Adam Fuchs 2013-05-14, 21:35
+
Christopher 2013-05-14, 21:42
+
Christopher 2013-05-14, 21:48
+
Benson Margulies 2013-05-14, 21:51
+
Keith Turner 2013-05-14, 22:13
+
John Vines 2013-05-14, 22:16
+
Benson Margulies 2013-05-14, 23:09
+
John Vines 2013-05-14, 23:43
+
Christopher 2013-05-14, 23:36
+
Benson Margulies 2013-05-14, 23:41
+
Christopher 2013-05-14, 23:47
+
John Vines 2013-05-14, 23:50
Copy link to this message
-
Re: Hadoop 2 compatibility issues
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> wrote:
>> > On Tue, May 14, 2013 at 7:36 PM, Christopher <[EMAIL PROTECTED]>
>> 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 <
>> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >>>> They're the same currently. I was requesting separate gavs for hadoop
>> 2.
>> >>>> It's been on the mailing list and jira.
+
Christopher 2013-05-15, 01:01
+
Adam Fuchs 2013-05-15, 21:31
+
Christopher 2013-05-15, 21:44
+
John Vines 2013-05-16, 00:03
+
Eric Newton 2013-05-16, 15:23
+
Adam Fuchs 2013-05-16, 15:51
+
John Vines 2013-05-14, 23:46
+
Josh Elser 2013-05-14, 23:36
+
John Vines 2013-05-14, 21:59
+
John Vines 2013-05-14, 21:52
+
Keith Turner 2013-05-14, 22:08
+
Sean Busbey 2013-05-14, 22:14
+
Eric Newton 2013-05-14, 23:23
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB