Excerpts from David Walluck's message of Mon Jun 06 23:54:13 +0200 2011:
> 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.
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@xxxxxxxxxx>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: PGP signature
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
