Roger Shimizu 於 2020/12/10 上午1:27 寫道:
Dear Thorsten,
Thanks for your kind hint and help!
Problem resolved, and I just uploaded the -2 version.
Glad to hear it's solved!
Just a personal opinion: Setting the classpath in the manifest seems inflexible to me
because there is no way (at
Dear Thorsten,
Thanks for your kind hint and help!
Problem resolved, and I just uploaded the -2 version.
On Tue, Dec 8, 2020 at 2:32 AM Thorsten Glaser wrote:
>
> On Tue, 8 Dec 2020, Roger Shimizu wrote:
>
> > So my next question is, how to figure out all the classpath, since
&
On Tue, 8 Dec 2020, Roger Shimizu wrote:
> So my next question is, how to figure out all the classpath, since
> this package really depends on a lot of java libraries.
I noticed that the MANIFEST file also contains a large list of
Classpath entries. I think if you take all these and subs
On Tue, Dec 8, 2020 at 2:01 AM Thorsten Glaser wrote:
>
> On Tue, 8 Dec 2020, Roger Shimizu wrote:
>
> > However the pkg still cannot be used due to classpath issue, I guess.
> > After installing xperia-flashtool, and run java command, it report error:
> >
> >
On Tue, 8 Dec 2020, Roger Shimizu wrote:
> However the pkg still cannot be used due to classpath issue, I guess.
> After installing xperia-flashtool, and run java command, it report error:
>
>
> $ java -jar /usr/share/xperia-flashtool/x10flasher.jar
> I tried to add clas
Dear java and mentors list,
Thanks to ftpmaster's effort and efficiency, my package
xperia-flashtool and all its dependencies all hit unstable lately.
(PS. xperia-flashtool is the open source ROM image flashing tool for
xperia phone.)
However the pkg still cannot be used due to classpath
Hi,
Am 20.03.2018 um 11:57 schrieb Jose Gutierrez de la Concha:
[...]
> So far all the entries use file:/ isn't this considerted a valid
> absolute and I missing something or the warning is bogus?
I'm not sure if file:/ is valid. I would just use
/usr/share/java/foo.jar:/usr/share/java/bar.jar
Hi,
I getting this lintian warning when building my package
W: zeroc-icegridgui: classpath-contains-relative-path
usr/share/java/icegridgui.jar: file:/usr/share/java/ice-3.7.0.jar,
file:/usr/share/java/icessl-3.7.0.jar,
file:/usr/share/java/icelocatordiscovery-3.7.0.jar, file:/usr/share/java/ice
Package: lintian
Version: 2.5.50.1
Severity: normal
Hi,
I think the Lintian warning about a "missing classpath" in Java
libraries and applications is not very helpful at the moment.
Newcomers and even seasoned Java developers are either confused by it
or simply ignore it thus its use
2015-09-16 21:39 GMT+02:00 Emmanuel Bourg :
> Le 16/09/2015 20:13, Guillaume Turri a écrit :
>
>> * If I don't do anything special regarding the class-path, then I get
>> the lintian warning missing-classpath [1]
>
> Hi Guillaume,
>
> You can ignore this warni
Le 16/09/2015 20:13, Guillaume Turri a écrit :
> * If I don't do anything special regarding the class-path, then I get
> the lintian warning missing-classpath [1]
Hi Guillaume,
You can ignore this warning, this classpath is rarely useful and most of
the libraries packaged don
On Wed, Sep 16, 2015 at 9:13 PM, Guillaume Turri
wrote:
> [...]
> I've tried to look in existing packages and in the documentation, but
> couldn't find an answer. I would
> be grateful if you can give me some pointers.
>
Take a look into epubcheck package, I fix classpa
then I get
the lintian warning missing-classpath [1]
* If I add the classpath via the pom.xml, ie
org.apache.maven.plugins
maven-jar-plugin
true
then the warning goes away, but the MANIFEST of the built jar
hello Andrew,
thanks for the suggestion. I tried relative paths but see the same
issue.
However, I noticed the current version 1.8 of triplea uses insubstantial
7.3 and so:
@Scott, would you consider upgrading triplea to 1.8 together with the
upload of insubstantial 7.3?
Thanks and Best Regards
Classloader issues are always a pain to diagnose. I wrote up a small
test program and it appears to work on this machine, but then I found
this little tidbit in the oracle docs [1].
Class-Path: The value of this attribute specifies the relative URLs of
the extensions or libraries that this applica
hi,
I am finishing insubstantial (flamingo/substance/trident) and most
r-deps use substance for additional L&Fs, so I just needed to replace
occurrences of:
org.jvnet.substance.skin.SubstanceAutumnLookAndFeel
with:
org.pushingpixels.substance.api.skin.SubstanceAutumnLookAndFeel
etc.
This is a
f this the wrong
way or there is a more current way, please let me know.
jmxetric gives me a lintian warning,
W: libjmxetric-java: missing-classpath libgmetric4j-java
but I'm not sure about the generated classpath thing anyway, jmxetric is
really only used on the boot-classpath, as descri
Hi!
On Thu, Sep 20, 2012 at 07:04:51PM +0200, Mathieu Malaterre wrote:
> Exception in thread "main" java.io.FileNotFoundException: Could not
> locate clojure/data/json__init.class or clojure/data/json.clj on
IIRC, clojure.contrib.json was moved to clojure.data.json which is not
part of Clojure co
;main" java.io.FileNotFoundException: Could not
locate clojure/data/json__init.class or clojure/data/json.clj on
classpath: , compiling:(core.clj:15)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3390)
at clojure.lang.Compiler.compile1(Compiler.java:7038)
On Tue, Jan 17, 2012 at 11:44:06PM +0100, Ludovic Claude wrote:
> You could have use:
>
> override_jh_build:
> ant -Djavac.classpath=/usr/share/java/junit.jar:/usr/share/java/jdom1.jar
Just out of academical interest I tried this but failed:
-do-compile:
[mkdir] Created dir: /tmp/buildd/li
> what might be the difference between ant-junit.jar and junit.jar
ant-junit.jar is an extension for Ant which provides the task to
Ant. It relies on junit.jar to provide the actual JUnit classes used to
run the tests.
> why it seems impossible to tweak a valid CLASSPATH into the build
;ll leave the explanation what might be the difference between
ant-junit.jar and junit.jar and why it seems impossible to tweak
a valid CLASSPATH into the build system without patching it to
some of the mysteries of Java packaging.
Kind regards and thanks for your hints anyway
Andreas.
--
ith *.dsc file. The build log says:
>
> BUILD FAILED
> /tmp/buildd/liboptions-java-0.0.20120113/nbproject/build-impl.xml:919: The
> following error occurred while executing this line:
> /tmp/buildd/liboptions-java-0.0.20120113/nbproject/build-impl.xml:341: The
> for
owing error occurred while executing this line:
/tmp/buildd/liboptions-java-0.0.20120113/nbproject/build-impl.xml:341: The
for must include junit.jar if not in Ant's own classpath
So I tried several approaches.
1. Add to build.xml
as well as
(see patch in debian/patch
On Mon, 2011-06-06 at 09:56 +0200, Torsten Werner wrote:
> it might help to submit a bug report of severity wishlist.
On my list of things TODO
Cheers
James
--
James Page
Software Engineer, Ubuntu Server Team
signature.asc
Description: This is a digitally signed message part
Hi James,
On Fri, Jun 3, 2011 at 12:50 PM, James Page wrote:
> If you happen to be packaging Maven based projects and want to make sure
> that the Class-Path entries in JAR files are set correctly you can use
> javahelper in conjunction with maven-debian-helper (see [0]).
>
> It would be nice to
386 (version 1.1.3-1) ...
N:
N: Processing source package freeplane (version 1.1.3-1) ...
N:
N: Processing binary package libjortho-freeplane-java (version 1.1.3-1) ...
N:
N: Processing binary package freeplane (version 1.1.3-1) ...
W: freeplane: classpath-contains-relative-path
usr/
lly a
>>> class-path!?
>>
>> Not the entire classpath, only the "../" entry of it.
> I meant actually the following error:
> W: freeplane: missing-classpath libcommons-lang-java,
> libjgoodies-forms-java, libbatik-java, libxerces2-java,
> libxml-commons
On 05/06/11 13:07, Eric Lavarde wrote:
Actually could you test it with Lintian from the current git master?
Note that the new Lintian will only output the "wrong" parts of a
class-path entry, so the output will differ here.
If it's simple and you tell me how :-)
Eric
Answering to myself, uuh,
On 04/06/11 14:54, Niels Thykier wrote:
On 2011-06-04 14:43, Eric Lavarde wrote:
But once I've patched away the class-path entry, it complains about a
missing class-path, and no jar file in Freeplane has actually a
class-path!?
Not the entire classpath, only the "../" entry
ot; part in freeplaneeditor.jar, which would be
>> a relative path to a directory, which seems to be a genuine issue.
> But once I've patched away the class-path entry, it complains about a
> missing class-path, and no jar file in Freeplane has actually a
> class-path!?
>
Not the
On 04/06/11 14:07, Niels Thykier wrote:
A strange thing is that Lintian does only complain about
freeplaneeditor.jar and not about the other jar files!?
It complains about the "../" part in freeplaneeditor.jar, which would be
a relative path to a directory, which seems to be a genuine issue.
B
that each of these real manifests has the symbolic name
> Bundle-SymbolicName.
>
> The structure with ./lib/*.jar and ./META-INF/MANIFEST.INF in the same
> directory is, as far as I understand, only a coincidental convention,
Indeed, I have seen jar files in the root of OSGi-bundle.
> bu
Hello,
I'm not a big OSGi specialist, but let me give back what I understand:
On 04/06/11 12:16, Niels Thykier wrote:
2. my actual problem is that the classpath is actually not needed by
> Freeplane because it uses Knopflerfish / OSGi framework which resolves
> itself dependenci
On 2011-06-04 09:52, Eric Lavarde wrote:
> Hello,
>
> while repackaging Freeplane, I noticed that there a few new Lintian
> checks in regard to Java...
>
> I had first the warning:
>
> W: freeplane: classpath-contains-relative-path
> usr/share/freeplane/
Hello,
while repackaging Freeplane, I noticed that there a few new Lintian
checks in regard to Java...
I had first the warning:
W: freeplane: classpath-contains-relative-path
usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor.jar: ../
freeplaneeditor.jar freeplaneviewer.jar
Your message dated Mon, 16 Aug 2010 08:36:14 +0200
with message-id <4c68dc5e.1090...@thykier.net>
and subject line [POLICY-PROPOSAL] Drop java*-runtime/compiler, create,
classpath-jre/jdk, and java-jre/jdk
has caused the Debian Bug report #365408,
regarding [POLICY-PROPOSAL] Drop java*-r
Package: ftp.debian.org
Severity: normal
Hi,
there are no reverse (Build-)Depends anymore. Some packages still
Depends: classpath-doc which is a virtual package provided by
libgcj-doc. But many packages have already been updated to use
default-jdk-doc instead.
Torsten
--
To UNSUBSCRIBE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tag 365408 + wontfix
thanks
Hi
Based the latest entries and the latest update to the policy, I am marking
this as wontfix. That being said, I intend to propose the removal of the
java*-compiler packages.
~Niels
-BEGIN PGP SIGNATURE-
Ver
Processing commands for cont...@bugs.debian.org:
> tag 365408 + wontfix
Bug #365408 [java-common] [POLICY-PROPOSAL] Drop java*-runtime/compiler, create
classpath-jre/jdk and java-jre/jdk
Added tag(s) wontfix.
> thanks
Stopping processing here.
Please contact me if you need assistance.
On Tue Dec 15 00:51, Pablo Duboue wrote:
> The idea would be to generate the bundle-classpath based on the
> dependencies of the Debian packages. There are many ways this
> can be done at different moments in time. The most off-hands one
> would be to have a "bundle-classpath"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
There was a posting [1] in the Eclipse linuxtools-dev mailing list
about External bundle-classpath entries that might be quite relevant
for us.
The idea would be to generate the bundle-classpath based on the
dependencies of the Debian packages
On Tue, Nov 24, 2009 at 8:27 PM, Damien Raude-Morvan
wrote:
> On Tue, 24 Nov 2009 00:09:13 +0530, Onkar Shinde
> wrote:
>
> Hi Onkar,
>
>> Please add the dependencies of this package to the classpath so that
>> (build)rdepends don't have to specifical
On Tue, 24 Nov 2009 00:09:13 +0530, Onkar Shinde
wrote:
Hi Onkar,
> Please add the dependencies of this package to the classpath so that
> (build)rdepends don't have to specifically take into consideration those
> depedencies.
Nice idea, I'll try to do that on Spring Framew
On Mon, Sep 21, 2009 at 08:10:46AM +0200, Michael Koch wrote:
> On Sun, Sep 20, 2009 at 06:22:13PM +0200, Matthias Klose wrote:
> > On 20.09.2009 13:43, Niels Thykier wrote:
> > >Package: java-common
> > >Version: 0.33
> > >Severity: normal
> > >
> > >I second this proposal using the java-{jre,jdk}
On Sun, Sep 20, 2009 at 06:22:13PM +0200, Matthias Klose wrote:
> On 20.09.2009 13:43, Niels Thykier wrote:
> >Package: java-common
> >Version: 0.33
> >Severity: normal
> >
> >I second this proposal using the java-{jre,jdk} for free and
> >java-{jre,jdk}-nonfree
> >for nonfree packages.
>
> No, w
On 20.09.2009 13:43, Niels Thykier wrote:
Package: java-common
Version: 0.33
Severity: normal
I second this proposal using the java-{jre,jdk} for free and
java-{jre,jdk}-nonfree
for nonfree packages.
No, we should develop against a spec, not against a product. maybe this was more
wanted in t
Package: java-common
Version: 0.33
Severity: normal
I second this proposal using the java-{jre,jdk} for free and
java-{jre,jdk}-nonfree
for nonfree packages.
~Niels
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500,
Hello,
On Sat, Jul 18, 2009 at 07:47:11PM -0400, Matthias Klose wrote:
> reassign 537290 classpath-common
> thanks
>
> No, there's nothing wrong with gcj-jdk. It defines a conflict with
> the current classpath-common. What needs to be done: update
> classpath to 0.98, bu
reassign 537290 classpath-common
thanks
No, there's nothing wrong with gcj-jdk. It defines a conflict with the current
classpath-common. What needs to be done: update classpath to 0.98, build cacao
using the new classpath, then decide what to do with the tools which are both
built by gc
reassign 473289 ftp.debian.org
thanks
this should be removed instead. These tools are now up to date in the
icepick package.
Gregory B. Prokopski writes:
> Package: wnpp
> Severity: normal
>
> Hi,
>
> This package needs a new maintainer,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
Package: wnpp
Severity: normal
Hi,
This package needs a new maintainer,
G.
--
What would you attempt to do if you knew you could not fail?
Package: wnpp
Severity: normal
Hi,
This package needs a new maintainer,
G.
PS: This package needs to go together with sablevm package.
--
What would you attempt to do if you knew you could not fail?
[Michael Koch 2006-08-19]
> Expect it today or tomorrow in incoming.debian.org.
Is it hard to package?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Aug 17, 2006 at 07:19:44PM +0530, ???
[??] (Praveen) ??? [???] (A) wrote:
> Hi,
>
> I am too keen to try out jboss on classpth 0.92. Anyone working on the
> packaging? It would be great if we can have it go to etch.
Expect it today or tomorrow in i
Hi, I am too keen to try out jboss on classpth 0.92. Anyone working on the packaging? It would be great if we can have it go to etch.CheersPraveenPS: Last time when I reinstalled I decided to be lot saner by only using testing :-(
-- "Value your freedom, or you will lose it, teaches history.`Don't
Mark Wielaard writes:
> Make sure that it is removed from
> libjava/java/text/DateFormat.java and that there is a new file
> libjava/classpath/java/text/DateFormat.java
> Similar for SimpleDateFormat.java.
that was the hint needed. I had some empty .java files still laying
arou
Hi Matthias,
On Sat, 2006-08-05 at 23:15 +0200, Matthias Klose wrote:
> Using the gcj/jc1 from the gcc-4_1-rh-branch to build the merged
> sources shows the same behaviour, so I assume that the problem is in
> the libjava/classpath merge, not in the gcc/java merge. Any help or
> sug
Recently the FC developers did backport the classpath 0.92 changes
from the trunk to to the gcc-4_1-rh-branch; currently trying to port
these changes to the gcc-4_1-branch. You can find a diff at [1],
consisting of two patches to make the big patch apply cleanly and one
patch applied after the
is really a bad example as this package
has really a bad history. The SableVM people just want to force users to
use their VM. This package is not in line with the Debian Java
maintainers.
I still think that we need a distinction between classpath-derived and
SUN-derived VMs. Perhaps later for Har
is really a bad example as this package
has really a bad history. The SableVM people just want to force users to
use their VM. This package is not in line with the Debian Java
maintainers.
I still think that we need a distinction between classpath-derived and
SUN-derived VMs. Perhaps later for Har
Arnaud Vandyck <[EMAIL PROTECTED]>
> MJ Ray a Âcrit :
> [...]
> > A virtual package name is a functional label, not a product name.
> > Java is the name of an island and a natural language too.
> > I'm surprised if Sun can prevent use of a word in this way.
>
> A function that is used to call a
> > A virtual package name is a functional label, not a product name.
> > Java is the name of an island and a natural language too.
> > I'm surprised if Sun can prevent use of a word in this way.
>
> A function that is used to call a runtime, compiler, etc of the Java(tm)
> language!
>
> Java? i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
MJ Ray a écrit :
[...]
> A virtual package name is a functional label, not a product name.
> Java is the name of an island and a natural language too.
> I'm surprised if Sun can prevent use of a word in this way.
A function that is used to call a run
Arnaud Vandyck <[EMAIL PROTECTED]>
> The major question is about replacing java1-runtime, java1-compiler,
> java2-runtime and java2-compiler virtual packages by classpath-jre,
> classpath-jdk for free java implementation and java-jre and java-jdk for
> non-free implementations.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cc'ing to debian-legal: summary:
The major question is about replacing java1-runtime, java1-compiler,
java2-runtime and java2-compiler virtual packages by classpath-jre,
classpath-jdk for free java implementation and java-jre and java-jdk for
non
jdk-nonfree
>
> So you think Sun will be OK with that? I'm not sure.
>
> > The first two would be used by all implementations, whether free of
> > non-free. The last two would be reserved for non-free implementations.
>
> That's what we want but with classpath-* for
Blackdown etc)
> java-jre-nonfree
> java-jdk-nonfree
So you think Sun will be OK with that? I'm not sure.
> The first two would be used by all implementations, whether free of
> non-free. The last two would be reserved for non-free implementations.
That's what we want
> > I strongly oppose the classpath/java distinction for classpath vs.
> > non-free JREs and JDKs. Instead I propose dropping classpath-* as well,
> > and only using java-jre and java-jdk.
>
> So people that wants to use Java should install non-free software?
> That&#x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Fry wrote:
>>Note that I added a paragraph from a proposal from Stefan Gybas,
>>modified by Ben Burton (see Bug#227587). Even if they did not really get
>>a consensus, I think, with the change of the virtual packages
> Note that I added a paragraph from a proposal from Stefan Gybas,
> modified by Ben Burton (see Bug#227587). Even if they did not really get
> a consensus, I think, with the change of the virtual packages to
> classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Vandyck wrote:
[...]
> One of the result of our discussions in Oldenburg (devjam) and in
> Bruxelles (FOSDEM) is about the use of the virtual packages.
I forgot to thanks Wolfgang Baer, Michael Koch, Matthias Klose, Stefan
Gybas, Ben Burton and
was not useful anymore. First, nobody uses Java 1 and the
state of GNU Classpath is far better then Java 1.
For some informations, you can go to the draft:
http://wiki.debian.org/Java/Draft
I'd like to reach a consensus about the attached patch before sending
other proposals.
If you read the
[Wolfgang Baer]
> Hi all,
>
> this is now going to be GNU classpath specific. I just post to the openjump
> list to let them know that its not a problem in their codebase.
I know. But the question was what kind of errors are now showing up
with classpath, so I decided to show them.
On Sun, Feb 26, 2006 at 01:20:24PM +0100, Mladen Adamovic wrote:
> Joost Kraaijeveld wrote:
> >After installing the Sun JVM using java-package I have a classpath.
> >Where do I edit (and add the PostgreSQL jdbc driver) this (systemwide?)
> >classpath?
> >
> I
Joost Kraaijeveld wrote:
After installing the Sun JVM using java-package I have a classpath.
Where do I edit (and add the PostgreSQL jdbc driver) this (systemwide?)
classpath?
It should be in /etc/profile or ~/.profile (just for the current user).
I have in /etc/profile
export
CLASSPATH
Hi,
After installing the Sun JVM using java-package I have a classpath.
Where do I edit (and add the PostgreSQL jdbc driver) this (systemwide?)
classpath?
TIA
--
Groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail
Hi Petter,
Petter Reinholdtsen wrote:
I just found classpath-tools listed quite high on
http://haydn.debian.org/~thuriaux-guest/qa/global.html>. The
package look like it could need some care. Is the package still
useful? I could not quite see what it does.
It's only needed for sab
GNU Classpath & friends meeting during Fosdem 2006.
The various free software library, runtimes, compiler and tool
projects around GNU Classpath will meet in Brussel to discuss what has
happened in the last year in the Free Software community and what the
next year will bring us during Fo
Hi Petter,
On Sat, 2005-12-24 at 10:47 +0100, Petter Reinholdtsen wrote:
> I just found classpath-tools listed quite high on
> http://haydn.debian.org/~thuriaux-guest/qa/global.html>. The
> package look like it could need some care. Is the package still
> useful? I could not qu
I just found classpath-tools listed quite high on
http://haydn.debian.org/~thuriaux-guest/qa/global.html>. The
package look like it could need some care. Is the package still
useful? I could not quite see what it does.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Hi all,
Like the last couple of years we want to come together with all the
projects around GNU Classpath and the various free runtimes, compiler
and tool projects to discuss what has happened in the last year in the
Free Software community and what the next year will bring us during
FOSDEM.
The
On Sat, Oct 29, 2005 at 01:08:47AM +0200, Andreas Pakulat wrote:
> On 28.10.05 16:39:27, Gordon Pedersen wrote:
> > On Fri, Oct 28, 2005 at 04:10:32PM +0200, Andreas Pakulat wrote:
> > > On 28.10.05 08:01:40, Gordon Pedersen wrote:
> > I'd assumed that on linux with java apps, one can execute them
he constructor...
>
> I don't know how to check source on the official java library code.
Sun's jdk has the source for most classes in the src.zip file. For free
implementations you should be able to do a apt-get source
> > > I wonder if it may just be a matte
irectory?
Nothing else in the directory.
> > But if if try either of the following commands from another
> > directory, the errors shown below commands appear:
> >
> > $ java -jar /usr/share/java/tt.jar
> > $ java -classpath /usr/share/java/tt.jar -j
commands appear:
>
> $ java -jar /usr/share/java/tt.jar
> $ java -classpath /usr/share/java/tt.jar -jar /usr/share/java/tt.jar
>
> Exception in thread "main" java.lang.NullPointerException
> at javax.swing.ImageIcon.(ImageIcon.java:161)
H
l commands discussed below, no CLASSPATH environment
variable has been defined.
No errors if I switch to the .jar file directory and issue this
command:
$ java -jar tt.jar
But if if try either of the following commands from another
directory, the errors shown below commands appear:
$
NU/Linux distribution packages.
>
> So we are proposing a developer and packager meeting around
> coordinating and improving the state of packaging of large scale
> applications written in the java programming language using the GNU
> Classpath, gcj and other free java-like tool cha
improving the state of packaging of large scale
applications written in the java programming language using the GNU
Classpath, gcj and other free java-like tool chains for the various
GNU/Linux distributions.
Please see DevJam wiki for details:
http://java.debian.net/index.php/DevJam
We hope to
Hi EVERYBODY!
I have developed java programs on the Windows platform.
Now I will develope with Eclipse on Debian.
But how can I set the $CLASS_PATH?
I have just recognized to make for jdk/bin/java a hard link to /usr/bin!
I like Debian, but I have to fight ;)
best regards,
don
--
To UNSUBSCR
gt; Great -- which implementation does Debian ship it with? That's all
> that really matters.
Both runtimes in question (as most free runtimes) are based on the GNU
Classpath core class library (which is the same as libgcj which comes
with GCC and provides the runtime library for the gij i
png
> http://people.redhat.com/~graydon/free-swing-feb-25-2004.png
[...]
> For more detailed info and what to check out when you want to help with
> this effort please see the following two mailinglist threads:
> http://gcc.gnu.org/ml/java/2004-02/msg00063.html
> http://mail.gnu.org
he current problems with
> >picking the 'right' java executable for the job in a more general
> >fashion than what we have now (weird and useless /usr/bin/java
> >interface with even weirder alternatives scheme) or your proposal,
> >which seems to try to band-ai
he current problems with
> >picking the 'right' java executable for the job in a more general
> >fashion than what we have now (weird and useless /usr/bin/java
> >interface with even weirder alternatives scheme) or your proposal,
> >which seems to try to band-ai
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
>VMs by introducing a non-free interface with another weird rating
>system.
Note that this programm still has to sort out, what 'java' is *able* to
run it. The app may add some classpath jars as well, depending on
which java is used. I don'T think that could be done with
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
>VMs by introducing a non-free interface with another weird rating
>system.
Note that this programm still has to sort out, what 'java' is *able* to
run it. The app may add some classpath jars as well, depending on
which java is used. I don'T think that could be done with
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
1 - 100 of 511 matches
Mail list logo
