Gregory Kick wrote:
>> The reason I suggested to keep the directory names shorter, is because
>> it's easier for us developers (like in terms of shell file name
>> completion.) Given that the directory names and artifactIds can be
>> independent, I don't see the point of having redundant "codemodel-"
>> prefix on every module.
>
> I work with Maven source from bash and my tab key is intact... :-)
It's just that it's more keys you have to type in. You first type 'co'
then get your "codemodel-" portion completed, then type a few more (like
'co' again) to get the rest of "core" completed.
>> Just to recap, I believe the proposal was to call directories like:
>>
>> codemodel/
>> pom.xml (for 'codemodel-parent' module)
>> core/
>> pom.xml (for 'codemodel' module)
>> annotation-compiler/
>> pom.xml (for 'codemodel-annotation-compiler' module)
>>
>> The reason I'm suggesting the codemodel-parent, codemodel, and
>> codemodel-annotation-compiler is because it's easier for the users,
>> which includes a large number of non-Maven users.
>
> I don't really agree here because I would think that the
> project-subproject convention in use by maven and other large,
> influential projects (spring) makes the -parent suffix overtly counter
> intuitive. I mean sure, you can figure it out, but if I saw a list of
> codemodel-* artifacts and a codemodel artifact i would think that
> codemodel would be the top-level. There are only 3 artifacts in this
> case so it's not at all a big deal, but it could get to be a bit
> strange for larger projects (e.g. jaxb).
The point is that the top level POM project does not have any jar
artifact. So when people are looking at our artifacts, there are only
two jars. I think it makes more sense to see "codemodel.jar" and
"codemodel-annotation-compiler.jar", as opposed to "codemodel-core.jar"
and "codemodel-annotation-compiler.jar".
The other argument is the backward compatibility argument. Our existing
Ant build produces codemodel.jar and codemodel-annotation-compoler.jar,
I thought.
JAXB artifacts would be a whole lot trickier, as changing the jar names
nor its contents is really not an option, and there's a lot of
re-jarring involved in it. But that's something we can worry about later.
>> We can afford to have longer names on things that users don't see.
>> Instead, we should be using shorter name for things people use.
>
> Wait, so are you saying that the directories aren't the issue?
I think a directory name issue is a lesser issue, because directory
names in the workspace really only affect developers, whereas artifact
names affect users.
> And
> does "shorter names for things people use" refer to codemodel v.
> codemodel-core?
Yes.
> As far as the whole -core thing goes, that was just a best guess. It
> doesn't at all matter to me what you think the best name for it is,
> but I don't think that it should be called codemodel alone (for the
> reasons stated above) if it's going to inherit from the same parent
> project as the annotation compiler. I think that there's some
> consensus in the maven community that the hyphen indicates a hierarchy
> (since maven 2.x when -parent projects were phased out) and I don't
> think that it's worth swimming upstream just to end up with the
> codemodel artifact. I can't imagine anyone taking to the streets
> because they had to type out a bit longer of an artifactId for clarity
> (especially when "int x" will get you excommunicated from the church
> of I-had-to-read-your-code). It seems to me that if it really is an
> issue then it would be better to reevaluate the project hierarchy and
> move the annotation compiler out of the codemodel umbrella.
I think you are right that hyphens are often used to indicate a
hierarchy, but it's also true that there are often hierarchies without
such visible marker in artifactId.
For example, all Apache POMs eventually inherit from Apache's
organization POM. Some projects, like Shale, have 'shale-master' POM on
the side. So it's not that Maven doesn't handle such notions.
I just realized that anothe possible interaction with this issue might
be how we generate distribution packages (the assembly target.) I'd
imagine we'd want to run it from the top level, and have it create
something like "codemodel-2.1.bin.tgz", so that's an argument for using
-core, I guess.
Or was it possible to use artifactId=codemodel-core but have the jar
file named something different, like codemodel.jar? Hmm.
> And the point of that naming convention doc was that this discussion
> is complete outside its scope. If we establish some clear conventions
> then we could recommend them.
>
> Anyway, at the end of the day, you're the owner and can do whatever
> you want, but in a vote, the proposed directory/pom structure revision
> that was outlined gets my -1 (with a +1 for changing codemodel-core to
> codemodel-something-else).
I don't really believe in "I'm the owner so I get my way" approach, at
least not now.
I'm curious what Lexi's take on this would be.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com