[15:39:32] csalvia: hey. Welcome! (Just catching up on mailing lists.) :) [15:40:21] I'm Aaron Halfaker from the research side of analytics. [15:51:01] Hi halfak [15:55:00] Hey. [16:34:07] nuria, whenever your back, i think i fixed it [16:38:49] ok, i am back [18:20:23] (PS1) Milimetric: Update for February 2014 meeting [analytics/reportcard/data] - https://gerrit.wikimedia.org/r/109320 [18:20:39] (CR) Milimetric: [C: 2 V: 2] Update for February 2014 meeting [analytics/reportcard/data] - https://gerrit.wikimedia.org/r/109320 (owner: Milimetric) [18:21:49] milimetric: hiiiI!II!I! [18:21:53] whatcha doing today!? [18:21:59] looking at wikimetrics in labs w me?! :p [19:46:23] qchris or nuria, anyone want to help me with archiva? [19:46:34] nuria wants! [19:46:36] :-D [19:46:37] hah [19:46:46] So what's the problem? [19:46:57] mm, trying to get a proxy connection to cloudera up [19:47:00] to build camus [19:47:02] not quite working [19:47:04] dunno [19:47:26] What's the error message? [19:47:59] [WARNING] The POM for org.apache.hadoop:hadoop-core:jar:2.0.0-mr1-cdh4.3.1 is missing, no dependency information available [19:48:05] [ERROR] Failed to execute goal on project camus-api: Could not resolve dependencies for project com.linkedin.camus:camus-api:jar:0.1.0-SNAPSHOT: The following artifacts could not be resolved: org.apache.hadoop:hadoop-core:jar:2.0.0-mr1-cdh4.3.1, org.apache.hadoop:hadoop-common:jar:2.0.0-cdh4.3.1: Failure to find org.apache.hadoop:hadoop-core:jar:2.0.0-mr1-cdh4.3.1 in http://10.11.12.13:8079/archiva/repository/internal/ was cached in the [19:48:18] it worked for maven central stuff [19:48:33] i'm poking around in archiva UI and googleing, trying to make cloudera repo work too [19:48:35] no luck yet [19:48:43] Oh. So that's only local on your machine. Right? [19:48:46] those lovely error messages, super descriptive [19:48:51] yeah, i'm running archiva on my vm [19:48:56] and have pointed my settings.xml file to it [19:48:59] as its only mirror [19:49:34] it was able to proxy and download mvn central deps [19:49:43] and doesn't it chache locally what it has alredy seen? [19:49:49] Mhmmm I guess we really want it to mirror and not pull from the real cloudera repo. Right? [19:50:27] if you blow your local cache you get the same? [19:50:28] I guess I'll boot the google machine then :-) [19:51:51] :) [19:52:03] nuria, i don't think it is configured properly yet [19:52:09] the maven central proxy came setup by default [19:52:20] i'm trying to setup the proxy for cloudera, hasn't worked yet [19:52:21] Do you have the section somewhere in the public to look at? [19:52:33] my settings.xml? [19:52:55] Archiva's [19:52:59] hm [19:53:15] How did you add the proxy? [19:55:39] also, maven is redaing your settings files right? [19:56:19] *reading [20:22:50] heyq qchris [20:22:55] looks like kafka is in maven central! [20:22:56] :) [20:22:56] http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.kafka%22 [20:23:00] really? [20:23:03] Awesome! [20:23:07] but, it has artifactIds based on the version of scala being used [20:23:18] is there a way to make an artifactId alias or something [20:23:32] so that I only have to say 'kafka_2.9.1' in the parent pom.xml? [20:23:39] and don't have to change it in every sub project pom? [20:23:57] The parent pom can have stubs for the children [20:24:01] camus uses that IIRC. [20:24:11] stubs.. [20:24:13] But I am not sure they do what you want. [20:24:34] Like specifying the version in the parent pom and not in thechildren [20:24:38] i know you can change the version in just the parent pom [20:24:38] yeah [20:24:39] but [20:24:43] this is actually a different articactId [20:24:44] and all children use the version of the parent pom. [20:24:51] Mhmm. [20:24:52] same version of kafka [20:25:05] just different artifacts built with different versions of scala [20:25:47] Like changing the groupId of the artifacts on the fly? [20:26:24] Oh ... [20:26:28] you want both changed [20:26:34] Now I see what you are talking about [20:26:39] no artifactId [20:26:39] yeah [20:26:52] parent pom should say [20:26:52] kafka_2.9.1 [20:26:54] but [20:27:02] linking kafka/kafka-0.8-SNAPSHOT to org.apache.kafka/kafka_2.10-0.8.0 [20:27:05] i don't want to change every reference to kafka just because we use a certain scala version [20:27:16] this will work [20:27:17] [20:27:17] org.apache.kafka [20:27:17] kafka_2.9.1 [20:27:17] 0.8.0 [20:27:17] [20:27:18] i think [20:27:25] if i also change every sub pom from [20:27:33] Honestly ... I'd change it in every place, because otherwise [20:27:40] only archiva knows how to build things [20:27:41] [20:27:41] org.apache.kafka [20:27:41] kafka [20:27:41] [20:27:41] to [20:27:45] Not the projects themselves [20:27:45] [20:27:45] org.apache.kafka [20:27:45] kafka_2.9.1 [20:27:45] [20:28:02] you mean the subprojects? [20:28:15] hmm, naw, this is a camus related setting [20:28:18] not an archiva related setting [20:28:22] its kiiinda like changing the version [20:28:27] Just in camus? [20:28:35] except the versionname is in the artifactId [20:28:37] yeah [20:28:39] just in camus [20:29:02] in camus i just want to say: [20:29:07] I would not know how to link in the way you'd need to. [20:29:09] pom.xml, use kafka_2.9.1 [20:29:12] but in the subprojects [20:29:15] use kafka [20:29:19] hmm aye rats [20:29:20] ok [20:29:31] It may be possible, but I'd just sed -e 's/.../.../' it [20:30:06] aye [20:30:06] ok [20:30:11] Sorry [20:30:20] Maybe manybubbles knows a trick? [20:30:58] Oh ... manybubbles seems offline :-( [20:31:15] oh its only in once other place i think anywa :) [20:31:45] Oh ... wait ... could not you trick maven into doing the right thing using properties? [20:31:56] oh maybe yeah [20:31:57] Like using a property as artifactID. [20:31:59] how do I do that? [20:32:41] Let me find an example for you ... [20:33:47] camus' parent pom already das a properties tag [20:34:01] Just add a different tag underneath [20:34:26] And then you can use that value by ${TAGNAME} [20:34:34] ${project.version} [20:34:36] ? [20:34:38] where TAGNAME is the tag name that you usied in the properties section. [20:34:45] Something like that. yes. [20:34:52] where does that get set? [20:36:00] That's inferred automatically [21:27:09] ottomata: I tried locally, and you can use Maven's properties as groupId, and artifactId. [21:27:20] Still ... it feels un-maven-y. [21:34:59] ottomata: Toby said you guys were slurping in mobile varnish data? If so, you should have banner impression data and I'd be interested in poking at it with hive [21:47:40] oooh banner impression data, yummy [22:36:05] mwalker: I see those requests (coming from mobile site) going to both desktop and mobile meta ... [22:36:11] Should they only go to mobile? [22:37:16] s/both/either of/ [22:41:52] they should just go to mobile... but due to code/configuration issues the requests hit both domains [22:42:03] it hits desktop and then gets redirected to mobile [22:42:32] it's a long standing task on my plate to 'mobilify' centralnotice urls so we don't go through the painful redirect [22:51:35] Up to my knowledge, only the mobile varnishes (mdot domain) get fed into hive. [22:51:49] So you would miss requests to the desktop site there. [22:52:04] But it seems that is ok and expected from your side. [22:52:56] I like the word 'mobilify' ... gonna write that in my vocabulary book :-)