* David Walluck <david@zarb.org> [2008-10-15 14:15]:
> I am not sure whye clipse should be a special case. There are quite a
> few desktop applications (tuxguitar, vuze) that could make use of swt.

We put symlinks to the SWT bundle in places that build-classpath can
find it. The rest of the Eclipse bundles are arguably useless outside
of an OSGi environment.

Andrew

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

David Walluck <david@zarb.org> writes:

> Thomas Fitzsimmons wrote:
>> What is the symptom of this problem?
>
> If each jar is to be stored in its own directory, then build-classpath
> and build-jar-repository need to be updated to be able to find these
> jar locations. Otherwise, we just just get
>
> $ build-classpath libreadline-java
> /usr/bin/build-classpath: error: Could not find libreadline-java Java
> extension for this JVM
>
> /usr/bin/build-classpath: error: Some specified jars were not found

OK, which packages are these errors affecting? You could add the
libreadline-java jar to CLASSPATH after the build-classpath invocation.

In any case I don't think you should change libreadline-java to not
follow the packaging guidelines, if that's what you were planning.

Tom

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

Thomas Fitzsimmons wrote:

OK, which packages are these errors affecting? You could add the
libreadline-java jar to CLASSPATH after the build-classpath invocation.


Only libreadline-java is affected right now since that's the only
package that I found adhering to the policy.


So far, all the packages fail in one of two ways: either the package
doesn't work with build-classpath, or it doesn't adhere to the policy.



In any case I don't think you should change libreadline-java to not
follow the packaging guidelines, if that's what you were planning.


I would tend to agree, but the tools have not been updated to support
this configuration. The choice seems to be to change either the tools or
any of the packages to conform to the packaging guidelines.


As it stands now, I am more concerned with breaking existing
build-classpath invocations then following the policy since F10 is
almost frozen and nothing is consistent.


Left as-is, you will just get four packages with four different
policies, and some of these may break existing builds or scripts.


--
Sincerely,

David Walluck
<david@zarb.org>

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

On Wed, Oct 15, 2008 at 4:43 PM, David Walluck <david@zarb.org> wrote:
> Thomas Fitzsimmons wrote:
>>
>> OK, which packages are these errors affecting? You could add the
>> libreadline-java jar to CLASSPATH after the build-classpath invocation.
>
> Only libreadline-java is affected right now since that's the only package
> that I found adhering to the policy.
>
> So far, all the packages fail in one of two ways: either the package doesn't
> work with build-classpath, or it doesn't adhere to the policy.
>
>> In any case I don't think you should change libreadline-java to not
>> follow the packaging guidelines, if that's what you were planning.
>
> I would tend to agree, but the tools have not been updated to support this
> configuration. The choice seems to be to change either the tools or any of
> the packages to conform to the packaging guidelines.
>
> As it stands now, I am more concerned with breaking existing build-classpath
> invocations then following the policy since F10 is almost frozen and nothing
> is consistent.
>
> Left as-is, you will just get four packages with four different policies,
> and some of these may break existing builds or scripts.
>
> --
> Sincerely,
>
> David Walluck
> <david@zarb.org>
>
> --
> fedora-devel-java-list mailing list
> fedora-devel-java-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
>

As a consumer of these packages, particularly tanukiwrapper, I prefer
the jar lives in /usr/share/java/ and the
JNI library live in /usr/lib(64). It's nice to know where ALL of the
jar files live. Having to determine if a jar
is native or not and determine whether to look in /usr/lib,
/usr/lib64, or /usr/share/java seems a bit annoying.

If you look at it from the java side, a developer will put the jar
file with all of their other jars. Then put the
library in the platform specific location. So putting the jars in
/usr/share/java really fits inline with this.

Sorry, just offering my 2 cents as a user /me didn't realize there
was already policy to do the contrary, I
would've spoke up then.

Sincerely,
jesus rodriguez

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

* Jesus M. Rodriguez <jmrodri@gmail.com> [2008-10-15 16:50]:
> As a consumer of these packages, particularly tanukiwrapper, I prefer
> the jar lives in /usr/share/java/ and the
> JNI library live in /usr/lib(64).

As long as the JAR doesn't contain native code ...

Andrew

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

Can't we have the real JAR and the .so in %{_libdir}/%{name} as required
by the guideline and add a symlink to the JAR (only) in /usr/share/java ?


P.S.: This will get worse with the increase of maven use by projects as
it is more strict where the dependency "artifacts" are located. You
could perhaps change build-classpath to look at other places but it will
e harder with maven.


David Walluck wrote:

Thomas Fitzsimmons wrote:

OK, which packages are these errors affecting? You could add the
libreadline-java jar to CLASSPATH after the build-classpath invocation.


Only libreadline-java is affected right now since that's the only
package that I found adhering to the policy.


So far, all the packages fail in one of two ways: either the package
doesn't work with build-classpath, or it doesn't adhere to the policy.



In any case I don't think you should change libreadline-java to not
follow the packaging guidelines, if that's what you were planning.


I would tend to agree, but the tools have not been updated to support
this configuration. The choice seems to be to change either the tools or
any of the packages to conform to the packaging guidelines.


As it stands now, I am more concerned with breaking existing
build-classpath invocations then following the policy since F10 is
almost frozen and nothing is consistent.


Left as-is, you will just get four packages with four different
policies, and some of these may break existing builds or scripts.




--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

Fernando Nasser wrote:
Can't we have the real JAR and the .so in %{_libdir}/%{name} as required
by the guideline and add a symlink to the JAR (only) in /usr/share/java ?


JPackage already provides a location for these jars, and this location
is searched by jpackage-utils. The location is %_jnidir, and it seems to
be defined as %_prefix/lib/java, but it should probably be %_libdir/java.


Contrast this with Debian which palces .so in /usr/lib/jni and the jar
in /usr/share/java.


If JNI using JAR files are really not arch-specific, they should go in
%_javadir. I do not see why the Fedora guidelines place jars in
application-specific directories with the shared library itself.


There are two issues:

1.) No one (Debian, Fedora, JPackage) can agree on the .jar location:
(i.) %_prefix/lib/java (ii.) %_libdir/java (iii.) %_javadir (iv.)
%_libdir/%name.


2.) If the .jar location is only (iv.) %_libdir/%name as in the Fedora
guidelines (no symlinks), then any specs or scripts that use
build-classpath on these jars would need to be re-written, and it is not
clear why they behave differently from all other jars in this way.


And the JPackage specs and scripts automatically become incompatible.

--
Sincerely,

David Walluck
<david@zarb.org>

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

David Walluck wrote:

Fernando Nasser wrote:
Can't we have the real JAR and the .so in %{_libdir}/%{name} as
required by the guideline and add a symlink to the JAR (only) in
/usr/share/java ?


JPackage already provides a location for these jars, and this location
is searched by jpackage-utils. The location is %_jnidir, and it seems
to be defined as %_prefix/lib/java, but it should probably be
%_libdir/java.


Contrast this with Debian which palces .so in /usr/lib/jni and the jar
in /usr/share/java.


If JNI using JAR files are really not arch-specific, they should go in
%_javadir. I do not see why the Fedora guidelines place jars in
application-specific directories with the shared library itself.


There are two issues:

1.) No one (Debian, Fedora, JPackage) can agree on the .jar location:
(i.) %_prefix/lib/java (ii.) %_libdir/java (iii.) %_javadir (iv.)
%_libdir/%name.


2.) If the .jar location is only (iv.) %_libdir/%name as in the Fedora
guidelines (no symlinks), then any specs or scripts that use
build-classpath on these jars would need to be re-written, and it is
not clear why they behave differently from all other jars in this way.


And the JPackage specs and scripts automatically become incompatible.

Breaking compatibility with jpackage just for the change is stupid - at
least I don't see any benefit. Breaking compatibility with nomatter what
should bring some benefits otherwise we are doing work which bring us
only more work and less features.

This also makes things harder for most packagers for several users:
1. Jpackage guidelines and tools are well known - most of the
experienced packagers in the java area either have been part of the
jpackage once are part now or at least are familiar with them. And I'm
not speaking for Fedora guys only.
2. We make our specs harder to maintain - Using build-classpath frees
you from details like whether the jar has native parts or not. But with
the current policy - placing jars in %_libdir/%name if the jar adds some
native parts you should change your spec file. Using build-classpath you
just need to rebuild with no changes.
But wait - there is even more you can use build-classpath in your
startup shell files so you even don't need to rebuild.
Please don't break compatibility with JPackage with some policy if you
really don't have something much better.


I completely support the following steps :
1. %_jnidir should be defined as %_libdir/java
2. All the jars with native parts should be installed in %_jnidir
3. jpackage-utils should be checked for needed modifications for this
change.


Best regards,
Alexander Kurtakov



--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

On Tue, Oct 21, 2008 at 3:46 PM, Fernando Nasser <fnasser@redhat.com> wrote:
> Can't we have the real JAR and the .so in %{_libdir}/%{name} as required by
> the guideline and add a symlink to the JAR (only) in /usr/share/java ?

As a consumer of said libraries, I like this approach.

> P.S.: This will get worse with the increase of maven use by projects as it
> is more strict where the dependency "artifacts" are located. You could
> perhaps change build-classpath to look at other places but it will e harder
> with maven.

Don't get me started on maven.

jesus

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

Fernando Nasser <fnasser-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
writes:

> Can't we have the real JAR and the .so in %{_libdir}/%{name} as
> required by the guideline and add a symlink to the JAR (only) in
> /usr/share/java ?

No, since this would cause ambiguity in the multilib case. Part of
solving the arch-specific JAR problem is having the JPackage wrapper
scripts resolve %{_libdir} based on whether the app will run on a 32-bit
or 64-bit JVM.

Tom

> P.S.: This will get worse with the increase of maven use by projects
> as it is more strict where the dependency "artifacts" are located.
> You could perhaps change build-classpath to look at other places but
> it will e harder with maven.
>
> David Walluck wrote:
>> Thomas Fitzsimmons wrote:
>>> OK, which packages are these errors affecting? You could add the
>>> libreadline-java jar to CLASSPATH after the build-classpath invocation.
>>
>> Only libreadline-java is affected right now since that's the only
>> package that I found adhering to the policy.
>>
>> So far, all the packages fail in one of two ways: either the package
>> doesn't work with build-classpath, or it doesn't adhere to the
>> policy.
>>
>>> In any case I don't think you should change libreadline-java to not
>>> follow the packaging guidelines, if that's what you were planning.
>>
>> I would tend to agree, but the tools have not been updated to
>> support this configuration. The choice seems to be to change either
>> the tools or any of the packages to conform to the packaging
>> guidelines.
>>
>> As it stands now, I am more concerned with breaking existing
>> build-classpath invocations then following the policy since F10 is
>> almost frozen and nothing is consistent.
>>
>> Left as-is, you will just get four packages with four different
>> policies, and some of these may break existing builds or scripts.
>>

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list