Warning: Removing commons-* symlinks

[spike]

Hi,

As some of you may know, apache-commons packages usually install their
jar(s) to apache-commons-*.jar and provides a symlink named
commons-*.jar. Some also provide a similar symlink for the javadoc
directory, some don't.
The shorter symlink doesn't provides any advantage (at least, I don't
know any) but causes trouble from time to time (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters javadir
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
accordingly. If you are a apache-commons maintainer (Carl, Mat, Mohamed,
Orion and Sandro), please consider to do the same for your packages or
let me know if you want me to do it for you.

Regards, Chris

[Mat Booth]

On 6 June 2011 18:41,  <spikefedora(a)gmail.com&gt; wrote:
>  Hi,
>
>  As some of you may know, apache-commons packages usually install their
>  jar(s) to apache-commons-*.jar and provides a symlink named
>  commons-*.jar. Some also provide a similar symlink for the javadoc
>  directory, some don't.
>  The shorter symlink doesn't provides any advantage (at least, I don't
>  know any) but causes trouble from time to time (e.g.
>  https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters javadir
>  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
>  accordingly. If you are a apache-commons maintainer (Carl, Mat, Mohamed,
>  Orion and Sandro), please consider to do the same for your packages or
>  let me know if you want me to do it for you.
>
>  Regards, Chris
>  --
>  java-devel mailing list
>  java-devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/java-devel
>  

Feel free to do so on my packages, I'm really bogged down right now. I
can grant you co-maintainership if you need it.


-- 
Mat Booth
http://fedoraproject.org/get-fedora

[David Walluck]

On 06/06/2011 01:41 PM, spikefedora(a)gmail.com wrote:
>  As some of you may know, apache-commons packages usually install
> their
>  jar(s) to apache-commons-*.jar and provides a symlink named
>  commons-*.jar. Some also provide a similar symlink for the javadoc
>  directory, some don't.
>  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.

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.

Some other advantages:

(1) maven: can get rid of the depmaps entirely. Just use the upstream
artifactIds (whenever possible).
(2) ivy: checks [artifactId]-[version].[ext] and then [artifactId].[ext]
by default
(3) gradle flatDir: same as ivy, as it wraps ivy

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

>  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.

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.

-- 
Sincerely,

David Walluck
<david(a)zarb.org&gt;

[Stanislav Ochotnicky]

Excerpts from David Walluck's message of Mon Jun 06 23:54:13 +0200 2011:
>  On 06/06/2011 01:41 PM, spikefedora(a)gmail.com wrote:
>  > As some of you may know, apache-commons packages usually install their
>  > jar(s) to apache-commons-*.jar and provides a symlink named
>  > commons-*.jar. Some also provide a similar symlink for the javadoc
>  > directory, some don't.
>  > 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.
>
>  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. 
Well truth is that current guidelines state that:
"If the package provides a single JAR and the filename provided by the
build is neither %{name}-%{version}.jar nor %{name}.jar then this file
MUST be installed as %{name}.jar and a symbolic link with the usual
name must be provided."

So in theory our guidelines now require apache-commons-X.jar and
commons-X.jar symlink. I hate adding unnecessary stuff to
packages...so would it be a problem to get rid of apache-commons-X.jar
and just have commons-X.jar? I guess not.

As for the guidelines...They are here to guide us, but they are not
immutable law. I am for any change that means less work for packagers
and fewer places where we can make mistakes. Although I think there
will be name collisions in a few places if we try to do this, it might
be worth the change.

So David...could you perhaps prepare a change of the guidelines for
naming jar files? It's usually done by copying current guidelines and
changing what needs to be changed. We can look at it during next SIG
meeting. Note that I would oppose -version symlinks because they
complicate packaging. However I'd be all for writing a simple script
that would create those symlinks for people who want them (it's a few
lines of sh) and adding it to jpackage-utils or to some other package.

>  Some other advantages:
>
>  (1) maven: can get rid of the depmaps entirely. Just use the upstream
>  artifactIds (whenever possible). 
This is actually not true, because we have subdirectories inside
_javadir. Plus sometimes upstream changes their group/artifactids and
we don't want to handle 10 different symlinks in a spec. Work is
under way (maven provides RPM dep generator) that will enable matching
between artifactId and rpm name. Then we can go a step further and
match to jar name if need be. But that's long term goal and can't
be done before next rebuild.


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

>  > https://bugzilla.redhat.com/show_bug.cgi?id=447156) and clutters
> javadir
>
>  I don't see any relation here. 
Relation is that having javadoc directories that are symlinked to
other directories can make updates painful as hell. Therefore getting
rid of those symlinks is a good thing.

>  > 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. 
I agree that jars should probably be names after upstream jars, but
javadoc dirs should IMO match our rpm names. If we did it your way
what would we name javadocs for rpms with multiple jars?

>  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. 
We cannot get rid of depmaps anytime soon. Maybe when our Java stack
is in a really good shape and we have figured out what we need/want
then we can think about it. I do believe that depmap system should be
changed for something different that is more complete and flexible,
but it can't be done overnight. I should have probably done it with
maven-3.x, but sadly I didn't know what I was doing when I started
packaging it...

That said...there are changes in maven packaging
approaching[1]. Namely I hope to get rid of %update_maven_depmap
macros in %post and %postun by reading fragments during maven
startup. It will have performance impact on resolving in mvn-local and
mvn-rpmbuild, but I believe it's gonna be worth it. Alos other things
will change (placement of fragments, pom files etc.). See the page for
details

[1] https://fedoraproject.org/wiki/Migration_from_maven2

--
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com

[spike]

Hey David,

On 06/06/2011 11:54 PM, David Walluck wrote:
>  On 06/06/2011 01:41 PM, spikefedora(a)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