Re: Help needed running Swing apps using gij

[Arnaud Vandyck]

Max Gilead <[EMAIL PROTECTED]> wrote:

> Max Gilead wrote:
> > Johan Walles wrote:
> > 
> >> I have a written a self-learning go-moku game in Java and made a
> >> jar-file out of it.  It runs fine with SUN's java implementation.
> >> When I try to run it with gij-3.2 (1:3.2.1-0pre3) I get:



> >> Obviously JFrame can't be found.  However, it seems to me that
> >> GNU Classpath actually has a JFrame implementation.  Otherwise,
> >> what is javax/swing/JFrame.class doing in Classpath's
> >> /usr/share/classpath/glibj.zip?

Well, it's not a free way to do it but you can download the Swing
implementation of Sun in a single jar[1].

[1] http://java.sun.com/products/jfc/download.html#1.1

-- Arnaud Vandyck




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: policy suggestion: API docs are not for users

[Mark Howard]

On Tue, 2002-12-31 at 22:53, T. Alexander Popiel wrote:
> 
> Ant is as much a framework as a tool; 

Thanks for the reply. I didn't know that much about ant - I had thought
it was a mere application. 

When you say frequently, how often do you mean. I personally have never
had to extend ant (and so never needed the api). Do you disagree that it
would be worthwhile to split the package into one containing the core
manual and an additional one with the api docs and any advanced manual?
(sorry, haven't looked at the package in detail so don't know exactly
what this might be).

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: policy suggestion: API docs are not for users

[Joe Phillips]

On Tue, 2002-12-31 at 17:53, T. Alexander Popiel wrote:

> Thus, the API is in the end-user docs, not just the developer docs.
> I suppose that one could argue that anyone trying to use ant for
> their own programs (instead of just using it as an incidental tool
> for building someone else's program) should install an ant-dev package,
> too... but that seems slightly strange to me, since the person is
> still acting as an end-user for the tool, instead of incorporating
> it into their program.

While you are correct in saying that in some cases, in order to use ant
you need to extend it, I do feel that by extending ant, you then become
an ant developer.  

IMHO, it would be appropriate to have a separate package for those
intending to extend ant as opposed to use it as-is.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

JAVA_HOME policy?

[Joe Phillips]

Recently, I've been building JBOSS/Tomcat packages for internal use and
eventual general release (I'll follow-up with another email for the
location of my working packages).

In doing so, I've had the need to build/back-port various other Java
packages to Debian stable.  As I've done this, I've seen package after
package (mine included) depend on a JAVA_HOME environment variable set
somewhere, in some script.  Most packages seem to use a config file or
init-script to define a local JAVA_HOME.  Source packages often have
JAVA_HOME coded into debian/rules.

There are obviously a bunch of java packages out there simply based on
the different java homes I've seen hard-coded into each package.

I like the idea of JAVA_HOME in general.  I don't like that it's
hard-coded into all these packages.  It becomes a mess to upgrade my
JDK/JRE package...oh yeah, update /etc/default/*, grep through init
scripts, etc, etc.  Every time I build a source package, I also need to
be sure I set the JAVA_HOME to match my system.

I'm wondering if there's a better way to handle JAVA_HOME.

Two options I can think of off the top of my head are...

1- a java-config program much like gnome-config or gtk-config.
   this java-config would be maintained by the package developer
   and could return things like JAVA_HOME and maybe other useful data.
   java-configs could use the alternatives system as well so
   /usr/bin/java-config always matches your /usr/bin/java and 
   /usr/bin/javac.

2- an /etc/default/java file with populated JAVA_HOME, again using
   alternatives.  Then source packages and other JAVA_HOME-needing
   scripts can source it in order to get the correct JAVA_HOME.

Have there been discussions regarding this?  What's the concensus on how
we should address JAVA_HOME?  There must be a better way to handle it
than what we currently have.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: policy suggestion: API docs are not for users

[Egon Willighagen]

On Thursday 02 January 2003 22:36, Joe Phillips wrote:
> On Tue, 2002-12-31 at 17:53, T. Alexander Popiel wrote:
> > Thus, the API is in the end-user docs, not just the developer docs.
> > I suppose that one could argue that anyone trying to use ant for
> > their own programs (instead of just using it as an incidental tool
> > for building someone else's program) should install an ant-dev package,
> > too... but that seems slightly strange to me, since the person is
> > still acting as an end-user for the tool, instead of incorporating
> > it into their program.
>
> While you are correct in saying that in some cases, in order to use ant
> you need to extend it, I do feel that by extending ant, you then become
> an ant developer.

Mmmm... making a custom task is not really being Ant development...

> IMHO, it would be appropriate to have a separate package for those
> intending to extend ant as opposed to use it as-is.

But anyway, what about libx packages? Those are libraries too. Where is the
API documentation of those packages? It seems exactly like that...

Egon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JAVA_HOME policy?

[Andrew Pimlott]

Oooh--I'll answer this!

On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME.  Source packages often have JAVA_HOME coded into
> debian/rules.

Any package that depends on JAVA_HOME should be taken out and shot.
Or, more politely, when it is packaged for Debian, those portions
should be excised.

> I'm wondering if there's a better way to handle JAVA_HOME.

Figure out what these packages really "need" JAVA_HOME for, and
figure out how we can provide that in a general way, that can be
supported by all java implementations (with emphasis on the free
ones).

Andrew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Eclipse

[Mark Wielaard]

Hi,

On Tue, 2002-12-31 at 20:22, Mark Howard wrote:
>   You probably have been following your ITP report (119885) and the
> debian-java mailing list, but I'd just like to make sure you know that a
> few people have packaged this unofficially and there have been offers of
> advice from people at RedHat who made their packages. Hopefully you will
> all be able to work together and make an excellent job. I look forward
> to trying the results. 

This might be a good opportunity to point to the Eclipse on gij page:
http://www.klomp.org/mark/gij_eclipse/

There is still a lot todo before Eclipse will be completely supported on
the free java platforms. But what we have is a decent start. Note that
we have not yet been able to compile Eclipse from source with gcj, so it
is a bit premature to say that Eclipse can go into main soon. (gcj 3.3
will probably only support what can already been seen on the screenshots
at the above page. And it will be at least February before it is
released, maybe later. And I don't know how soon Debian will adopt GCC
3.3.)

The gcj hackers are currently working very hard on the next gcj (3.3)
release. But if people want to try to get more of Eclipse working with
gcj/gij then please let us know at [EMAIL PROTECTED] so we can help.

Most of the patches mentioned on the above page have already gone into
CVS (and will be part of the 3.3 release).

Cheers,

Mark


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help needed running Swing apps using gij

[Arnaud Vandyck]

Max Gilead <[EMAIL PROTECTED]> wrote:

> Max Gilead wrote:
> > Johan Walles wrote:
> > 
> >> I have a written a self-learning go-moku game in Java and made a
> >> jar-file out of it.  It runs fine with SUN's java implementation.
> >> When I try to run it with gij-3.2 (1:3.2.1-0pre3) I get:



> >> Obviously JFrame can't be found.  However, it seems to me that
> >> GNU Classpath actually has a JFrame implementation.  Otherwise,
> >> what is javax/swing/JFrame.class doing in Classpath's
> >> /usr/share/classpath/glibj.zip?

Well, it's not a free way to do it but you can download the Swing
implementation of Sun in a single jar[1].

[1] http://java.sun.com/products/jfc/download.html#1.1

-- Arnaud Vandyck

Re: policy suggestion: API docs are not for users

[Mark Howard]

On Tue, 2002-12-31 at 22:53, T. Alexander Popiel wrote:
> 
> Ant is as much a framework as a tool; 

Thanks for the reply. I didn't know that much about ant - I had thought
it was a mere application. 

When you say frequently, how often do you mean. I personally have never
had to extend ant (and so never needed the api). Do you disagree that it
would be worthwhile to split the package into one containing the core
manual and an additional one with the api docs and any advanced manual?
(sorry, haven't looked at the package in detail so don't know exactly
what this might be).

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: policy suggestion: API docs are not for users

[Joe Phillips]

On Tue, 2002-12-31 at 17:53, T. Alexander Popiel wrote:

> Thus, the API is in the end-user docs, not just the developer docs.
> I suppose that one could argue that anyone trying to use ant for
> their own programs (instead of just using it as an incidental tool
> for building someone else's program) should install an ant-dev package,
> too... but that seems slightly strange to me, since the person is
> still acting as an end-user for the tool, instead of incorporating
> it into their program.

While you are correct in saying that in some cases, in order to use ant
you need to extend it, I do feel that by extending ant, you then become
an ant developer.  

IMHO, it would be appropriate to have a separate package for those
intending to extend ant as opposed to use it as-is.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training

JAVA_HOME policy?

[Joe Phillips]

Recently, I've been building JBOSS/Tomcat packages for internal use and
eventual general release (I'll follow-up with another email for the
location of my working packages).

In doing so, I've had the need to build/back-port various other Java
packages to Debian stable.  As I've done this, I've seen package after
package (mine included) depend on a JAVA_HOME environment variable set
somewhere, in some script.  Most packages seem to use a config file or
init-script to define a local JAVA_HOME.  Source packages often have
JAVA_HOME coded into debian/rules.

There are obviously a bunch of java packages out there simply based on
the different java homes I've seen hard-coded into each package.

I like the idea of JAVA_HOME in general.  I don't like that it's
hard-coded into all these packages.  It becomes a mess to upgrade my
JDK/JRE package...oh yeah, update /etc/default/*, grep through init
scripts, etc, etc.  Every time I build a source package, I also need to
be sure I set the JAVA_HOME to match my system.

I'm wondering if there's a better way to handle JAVA_HOME.

Two options I can think of off the top of my head are...

1- a java-config program much like gnome-config or gtk-config.
   this java-config would be maintained by the package developer
   and could return things like JAVA_HOME and maybe other useful data.
   java-configs could use the alternatives system as well so
   /usr/bin/java-config always matches your /usr/bin/java and 
   /usr/bin/javac.

2- an /etc/default/java file with populated JAVA_HOME, again using
   alternatives.  Then source packages and other JAVA_HOME-needing
   scripts can source it in order to get the correct JAVA_HOME.

Have there been discussions regarding this?  What's the concensus on how
we should address JAVA_HOME?  There must be a better way to handle it
than what we currently have.

-joe
-- 
 Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
 UNIX, Linux and Java Training

Re: policy suggestion: API docs are not for users

[Egon Willighagen]

On Thursday 02 January 2003 22:36, Joe Phillips wrote:
> On Tue, 2002-12-31 at 17:53, T. Alexander Popiel wrote:
> > Thus, the API is in the end-user docs, not just the developer docs.
> > I suppose that one could argue that anyone trying to use ant for
> > their own programs (instead of just using it as an incidental tool
> > for building someone else's program) should install an ant-dev package,
> > too... but that seems slightly strange to me, since the person is
> > still acting as an end-user for the tool, instead of incorporating
> > it into their program.
>
> While you are correct in saying that in some cases, in order to use ant
> you need to extend it, I do feel that by extending ant, you then become
> an ant developer.

Mmmm... making a custom task is not really being Ant development...

> IMHO, it would be appropriate to have a separate package for those
> intending to extend ant as opposed to use it as-is.

But anyway, what about libx packages? Those are libraries too. Where is the
API documentation of those packages? It seems exactly like that...

Egon

Re: JAVA_HOME policy?

[Andrew Pimlott]

Oooh--I'll answer this!

On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME.  Source packages often have JAVA_HOME coded into
> debian/rules.

Any package that depends on JAVA_HOME should be taken out and shot.
Or, more politely, when it is packaged for Debian, those portions
should be excised.

> I'm wondering if there's a better way to handle JAVA_HOME.

Figure out what these packages really "need" JAVA_HOME for, and
figure out how we can provide that in a general way, that can be
supported by all java implementations (with emphasis on the free
ones).

Andrew

Re: Eclipse

[Mark Wielaard]

Hi,

On Tue, 2002-12-31 at 20:22, Mark Howard wrote:
>   You probably have been following your ITP report (119885) and the
> debian-java mailing list, but I'd just like to make sure you know that a
> few people have packaged this unofficially and there have been offers of
> advice from people at RedHat who made their packages. Hopefully you will
> all be able to work together and make an excellent job. I look forward
> to trying the results. 

This might be a good opportunity to point to the Eclipse on gij page:
http://www.klomp.org/mark/gij_eclipse/

There is still a lot todo before Eclipse will be completely supported on
the free java platforms. But what we have is a decent start. Note that
we have not yet been able to compile Eclipse from source with gcj, so it
is a bit premature to say that Eclipse can go into main soon. (gcj 3.3
will probably only support what can already been seen on the screenshots
at the above page. And it will be at least February before it is
released, maybe later. And I don't know how soon Debian will adopt GCC
3.3.)

The gcj hackers are currently working very hard on the next gcj (3.3)
release. But if people want to try to get more of Eclipse working with
gcj/gij then please let us know at [EMAIL PROTECTED] so we can help.

Most of the patches mentioned on the above page have already gone into
CVS (and will be part of the 3.3 release).

Cheers,

Mark