----- Original Message -----
From: "David Walluck" <david(a)zarb.org>
To: java-devel(a)lists.fedoraproject.org
Sent: Friday, February 22, 2013 2:54:53 PM
Subject: Re: [fedora-java] New Java guidelines
On 02/22/2013 02:43 PM, Jon VanAlten wrote:
> Under Filenames:
> "Alternatively, the file can be installed to the subdirectory
> %{_javadir}/%{name}/ under its usual name."
>
> It seems like the guidelines are intended to provide an obvious
> mapping from package name to jar file name. This loophole breaks
> the mapping. I'm not sure why, what problem is this trying to
> solve (that isn't solved by a symlink with the usual name)?
I have disagreed with the Fedora naming and location policy for a
long
time now. This includes the fact the JNI-using jars presumably should
not have a separate directory as this is not the case in the upstream
maven repositories, which require it to have a unique artifactId
instead.
In my option, a package MUST use the upstream jar names. Do you
really
want to continue to have jar names that only exist in Fedora? This
must
be a confusion for both developers and packagers with no real gain
that
I can think of.
Of course, in a flat layout we sometimes find a jar name that has no
indication of which project it came from. It it not clear what to do
in
that case (placing in %{_javadir}/<project name> is an option,
although
if I were to do it over I would probably use the maven groupId
instead.).
That's assuming it's a maven artifact. But in general, I can sort
of agree that guidelines that specify divergence from upstream are
not exactly ideal. I wonder though, for xmvn and the automated
dependency fluff being introduced, how well does this work if there
is no mapping from fedora package name to jar location? Would
packages that introduce such jars need to add virtual provides? I
admit, I ask this as someone 100% ignorant of the implementation.
> but... under Specfile Template for Apache Maven:
> "# BR java-devel only if you need specific version
> [BuildRequires: java-devel >= java version]"
I think maven(-local) should already Requires: java-devel such that
if
you're building with maven this should already be covered.
No arguments here, my concern is more about conflicts among different
sections of the guidelines. If we make changes, I'd like to see them
be as newbie-proof as possible. If one section says A and another B,
I can see the possibility of this being a repeated question on list
and/or new package review BZ.
cheers,
jon