[fedora-java] Warning: Removing commons-* symlinks

[spikefedora at gmail.com]

Hey David,

On 06/06/2011 11:54 PM, David Walluck wrote:
> On 06/06/2011 01:41 PM, spikefedora at gmail.com wrote:
>> The shorter symlink doesn't provides any advantage (at least, I don't
>> know any) but causes trouble from time to time (e.g.
> 
> The shorter symlink provides a great advantage. Namely, it uses the
> upstream name for the artifact. This is what all builds generally
> expect, even ant-based builds.

Unfortunately, even for packages like apache-commons the artifact id
that upstream uses is rather inconsistent (e.g. commons-vfs-*project*),
not to mention the group id.


> If I were going to argue against getting rid of something, I would say
> that %{name} (if it is not equal to the upstream name for the artifact)
> provides no benefit except for confusion, as no Java developer would
> expect the jar to be called this.

Image the generic java codemonkey, firing up his ide and setting up some
libs. He just discovered (I don't know how, because codemonkeys usually
don't care about their OS) that fedora ships apache-commons-logging and
wants to use it in his project. So he does installed it and wants to
link it to his ide now (possibly even the javadoc dir, to use something
like inline api highlighting). And now you really think, that the he is
aware, that the jar is name after the maven artifact id. Our codemonkey
has enough trouble finding the right directory and changes are that he
never even heard about maven.
You have to keep in mind, that packaging java-libs is way more than your
own use-case.

> Some other advantages:
> 
> (1) maven: can get rid of the depmaps entirely. Just use the upstream
> artifactIds (whenever possible).

In an ideal world, I'd totally agree. Unfortunately, projects using
maven poms tend to have rather strange interpretation of what artifact
id to expect from a dependency and I really don't like the idea of
providing a symlink for every broken dependency in a pom file.

> (2) ivy: checks [artifactId]-[version].[ext] and then [artifactId].[ext]
> by default
> (3) gradle flatDir: same as ivy, as it wraps ivy

Well, we already dropped the versioned symlinks. I can't remember any
votes against (But to make sure, you could look at the meeting log).

>> https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters javadir
> 
> I don't see any relation here.

It was decided to drop versioned symlinks to the javadoc directories. We
ran into that a couple of times.

>> and javadocdir. Therefore, I'll remove both the jar and the javadoc
>> symlink at least for the apache-commons packages I (co-)maintain.
>> Please check you spec file if you are using one of those and adapt
> 
> Following similar reasoning to the above, it seems that the javadoc dir
> should not be named after %{name}, but the maven module id.

As I already explained, I don't think that a good idea. That'd cause
more trouble for a dumb user who's not able to help himself, but a tiny
bit less trouble for a someone, who's totally capable of. I know how
much *I* hate it, when I install packages and have to query the files
because the binary name is different from the package name.

> I really think that time would be better spent implementing a solution
> for (1) or patching (2) and (3) to handle the JPP maven repo layout.
> Although, because (1) involves deprecating this layout, I think that
> these are also a waste of time.

Of course, I'm not actually going through all packages and fixing just
symlinks. Your right, that'd be a waste of time. But since I have to
touch all apache-commons specfiles because I have to get rid of maven2,
it's not a big deal to clean them up, too. I was just asking myself, if
we still need those symlinks, asked the guys in #java-devel, and wanted
to be polite and inform other java-developers. In fact, I think typing
this email took way more time that actually doing the work :)

Regards, Chris