On 06/06/2011 01:41 PM, spikefedora@xxxxxxxxx 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@xxxxxxxx>
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
