Josh and I spoke in IRC for a bit, regarding his comments about the filenames of the release artifacts.
The summary is: it would be nice if Maven could automatically produce tarballs with the "apache-" prefix; it cannot, so the names are fine as is. Transcript follows (minus interrupting bot and join/leave notices). Times are EDT. --- (03:00:16 PM) ctubbsii: elserj: I wanted to discuss your concerns about the file naming conventions for Fluo release artifacts. You mentioned that you thought future releases should be differently named/prefixed. I'd like to address that sooner, rather than later, if we can, because I don't think it would be a good idea. (03:00:52 PM) elserj: hi (03:00:57 PM) ctubbsii: hi :) (03:01:02 PM) elserj: i need to double-check the official release docs (03:01:15 PM) elserj: i _like_ to see apache-foo*.tar.gz (03:01:20 PM) elserj: but I don’t think it’s explicitly required? (03:01:44 PM) elserj: just because, when a user downloads it, it’s the first real thing they see to reaffirm that this is “Apache Fluo" (03:02:01 PM) ctubbsii: You mean first, after they've navigated our website to get to it? (03:02:10 PM) elserj: ok ok, 2nd? (03:02:11 PM) elserj: :P (03:02:16 PM) ctubbsii: Or 3dozenth. (03:02:19 PM) elserj: well (03:02:24 PM) ctubbsii: :) (03:02:24 PM) elserj: consider `yum install fluo`? (03:02:28 PM) elserj: i guess (03:02:46 PM) elserj: but even that (03:02:53 PM) elserj: might be based on an official apache release (03:02:55 PM) elserj: anyways (03:03:02 PM) elserj: i don’t think it’s required by policy (03:03:07 PM) elserj: it’s just something I personally like to see (03:03:13 PM) elserj: and seemed relevant to mention given recent drama (03:04:19 PM) ctubbsii: I think there's good reasons not to do it. If you want me to elaborate, I can, but I was hoping we could just avoid it by dismissing the concern as relatively subjective. (03:06:43 PM) ctubbsii: If there's a compelling reason to go that route, I want to make sure to give it its full consideration, though. (03:07:28 PM) elserj: No, I’m curious what your hesitation(s) is/are (03:09:26 PM) elserj: my only concern is that using the full project name in the areas most likely to hit user’s eyes (03:09:42 PM) elserj: and, I was assuming that it would be a very low-impact change to make (I think we do that in accumulo, no?) (03:10:16 PM) ctubbsii: So, without doing any maven hoop-jumping, the way this would work is we basically change the artifactId in all the artifacts. This changes their maven coordinates, which has consequences. We could just rename the tarball after producing it with the maven release process, but that adds manual steps (and I prefer automation on releases, as much as possible). (03:12:31 PM) ctubbsii: We do not prefix the tarballs in accumulo with "apache-" for the same reasons. (03:13:23 PM) ctubbsii: For what it's worth, neither does httpd, hadoop, thrift, hadoop, and many others (though their reasons may be different than mine, especially for the non-maven builds). (03:13:57 PM) elserj: Yeah, I would not be recommending changing artifactId’s (03:14:08 PM) elserj: i thought there was an easy finalName attribute that would allow this (03:14:36 PM) elserj: maybe that explains my confusion on why apache.pom doesn’t just do this already (03:14:38 PM) ctubbsii: finalName will change the directory name inside the tarball, but not the artifact file name. (03:14:51 PM) elserj: which would be ultimately attached and deployed? (03:14:59 PM) elserj: (by the deploy phase) (03:15:56 PM) ctubbsii: The file name is chosen by the deploy, based not on the finalName, but on the actual artifactId. The only way you can change this is by changing the artifactId, or by attaching the file to a different module (with a different artifactId). (03:17:02 PM) ctubbsii: Now... as I said, we can rename the tarball outside of maven, but that makes the names inconsistent with what's in maven, which can add confusion to users downloading from one place or another, and it would be a manual step. (03:43:27 PM) elserj: oops (03:43:32 PM) elserj: sorry i got distracted (03:44:00 PM) ctubbsii: np (03:44:17 PM) elserj: it would be nice if the deploy-plugin (or assembly-plugin) were smart enough to follow that artifact through (03:44:48 PM) elserj: but can understand why that isn’t done by default (03:47:37 PM) elserj: i don’t see anything on a quick glance through official docs, so fine by me (03:47:51 PM) elserj: most projects don’t have a fully-automated release process (03:48:17 PM) elserj: e.g. some script that prepares artifacts and requires the RM to deploy them, so that’s probably where the named artifacts came from (03:54:43 PM) ctubbsii: The deploy plugin can't deploy to another artifactId, because it's build tasks must remain limited to "this" project, which has a pom, and artifacts. A pom for "artfactId1" cannot publish artifacts for "artifactId2". That would cause all kinds of breakage if it could. (03:54:48 PM) ctubbsii: Yeah, even projects which do maven release automation often have follow-on manual steps (often to remove the deployed source-release and any binary tarballs). (03:54:49 PM) ctubbsii: I prefer simplicity and let the automation work as intended, with minimal modification... as much as possible, stick to the conventions established by the automation. (03:56:16 PM) elserj: yeah understood (03:56:27 PM) elserj: irked by it (03:56:29 PM) ctubbsii: You also mentioned that "fluo-" be part of the "build-resources" artifact name. There are two reasons why I think we don't need to do this: (03:56:51 PM) elserj: but don’t like the steps required to make the automation work as intended (03:57:01 PM) elserj: still in g:o.a.f? (03:57:26 PM) ctubbsii: Yes. (03:57:28 PM) ctubbsii: 1) the artifact is primarily intended to be used by the parent POM during development of Fluo. It is not intended primarily for users. It is only being "released" (and going through the official source tarball release process) because we need it in Maven Central for Fluo builds. (03:58:30 PM) elserj: maybe the disconnect there is because the maven coordinates are only related to official release artifact (03:58:33 PM) ctubbsii: 2) Since it is released, and not actually part of "fluo" itself, I don't want to mislead people into thinking it is part of, or required by Fluo. It has the groupId to denote where it came from, but nothing it contains is special for Fluo. (03:59:07 PM) elserj: i would assert that if the fluo ppmc is releasing it, it’s a part of fluo :) (03:59:26 PM) ctubbsii: No more than wikisearch is part of Accumulo... (03:59:30 PM) elserj: sure (03:59:34 PM) elserj: well (03:59:38 PM) elserj: if we ever released wikisearch (03:59:55 PM) elserj: simple enough: if you release foo, I believe it is a part of that project (04:00:10 PM) elserj: if not the softwar project, the community (04:00:13 PM) ctubbsii: But this is even less related to fluo... because it's just an arbitrary set of checkstyle/formatter rules. (04:00:31 PM) elserj: community > code and what not (04:00:54 PM) ctubbsii: We actually tried to keep these separate from Apache Fluo, making use of a release which was not part of Fluo... but you saw how that went. (04:01:00 PM) elserj: lol (04:01:22 PM) elserj: yeah, so i think i disagree on your point #2 (04:01:35 PM) elserj: and will concede that the final coordinate people will use to access the release imply fluo for point #1 (04:01:44 PM) ctubbsii: Main thing is I don't want people looking for Fluo artifacts in Maven Central, and wondering if they need this, and what to do with it. (04:01:57 PM) elserj: why would they look in central? (04:02:10 PM) elserj: shouldn’t they look on fluo.i.a.o to see what they should use? (04:02:40 PM) elserj: i am used to seeing projects publish the coordinates they expect users to need to use (04:02:59 PM) elserj: it may be in other transitive things that the project creates, but the user doesn’t explicitly need to know (04:03:45 PM) ctubbsii: Because Maven Central is a huge index of pretty much every available open source Java library out there... and it's easier to do a search there than to try to figure out what website to go to. You have to remember that most people don't start at our site. They are coming from external. (04:03:45 PM) ctubbsii: I've searched Maven Central many times for things like gson, jetty, etc. I don't need their website... I need their artifacts. (04:03:54 PM) elserj: i agree making it fluo-build-resources with a G:org.apache.fluo would be duplicative (04:04:31 PM) elserj: devil’s advocate, you did say earlier that the website is the first landing place for users of fluo ;) (04:06:09 PM) ctubbsii: Not quite what I said. I just meant that however they download it, they're getting it from a place which is going to bombard them with the fact that it's from Apache. This is true on our website, and it's also true in Maven Central. (these are the only two places the PPMC is going to deploy release artifacts). (04:07:37 PM) elserj: do you have a problem with g:o.a.f a:build-resources ? (04:07:44 PM) elserj: trying to refocus (04:08:14 PM) ctubbsii: Not sure what you're asking.... that's what the artifact is currently named. (04:08:18 PM) elserj: yes (04:08:21 PM) elserj: and are you happy with that (04:09:14 PM) ctubbsii: Yes. I think the question is, are you? (04:09:23 PM) elserj: yes, i’m fine with it (04:09:34 PM) ctubbsii: Okay, so is there any other issue with the artifactIds we should discuss as follow-on action from your vote-thread concerns? Are you okay with the names of all of the artifacts as is? (04:09:42 PM) elserj: i think there is a disconnect with GAV and source-release names (04:09:47 PM) elserj: but i don’t think that’s a blocker (04:10:04 PM) ctubbsii: What disconnect? (04:10:09 PM) elserj: e.g. someone downloading the release from dist.a.o wouldn’t ever see the GAV, but the consumption of these artifacts is always through maven' (04:10:32 PM) elserj: if you go to dist.a.o, you would not know what the gav was by tarball name only (04:10:54 PM) elserj: but again, not a big worry. The people doing this are effectively zero. (04:11:02 PM) elserj: Just pointing it out (04:11:24 PM) elserj: I am fine with the artifact names per asf release policy (04:11:42 PM) ctubbsii: Right... but you could search for the file by name and find it. (04:11:54 PM) elserj: I will continue to lament that we can’t have apache-foo-source-release.tar.gz put in there easily by the apache.pom :) (04:11:59 PM) elserj: yes, you could (04:13:10 PM) ctubbsii: If we weren't a Maven project, I'd lament with you. Most of what I'm pushing for is with respect to what makes sense as a Maven project. (04:13:24 PM) ctubbsii: Should I copy/paste this transcript to the dev list for archival purposes? (04:13:40 PM) elserj: I do not mind if you do. I leave it up to your discretion
