java-gnome-developer — For people using the bindings to write their own applications

[Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Manuel L. <man...@co...>]

How can I update the progress bar from the GNomeAppBar while running a
process in a dialog window. I have tried Implementing Fireable and a
Time, Runable Using CustomEvents.addEvent and I'm getting always the
same behavior. Progress bar don't get update it till the process is
completed. Is there anyway of showing the progressbar updates while
running a long process ?

[Java-gnome-developer] Share your knowledge

[Jeff M. <ku...@gm...>]

We have created two new pages on the wiki to collect ideas from the
anybody with an opinion.  If you have knowledge on one of these topics
please take the time to add your insights.

The topics are:

1) Java-GNOME Eclipse plugin:  We would like to revive the project that
will deliver a plugin for the eclipse development environment.  What
features are needed?  You can enter your comments at the url
below:

http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JGDiscussionEclipse=
Plugin

2) Java-GNOME Testing Framework: A few of us have been playing around
with adding a JUnit testing framework to Java-GNOME.  Creating tests for
a GUI class library is not an easy task.  What are your thoughts on this?
Enter them at this url:

http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JGDiscussionTestFra=
mework


--=20
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Andrew C. <an...@op...>]

On Fri, 2005-15-04 at 11:48 -0500, Clint Allen wrote:
> Anyway, Debian Sid uses outdated versions of the following packages, and
> to get java-gnome to work, you have to install them from source.
> 
> atk
> libglade
> libgnomecanvas
> libgnomeui

It would be terrific if you could file a bug on Debian's Bug Tracking
System requesting they introduce the necessary dependencies - otherwise,
things will never improve and others will suffer the same fate.

[Of course, if Debian isn't shipping gtk+ 2.6, then, well, you should
probably stick with java-gnome 2.8 (ie, libgtk-java 2.4.9 and
libglade-java 2.8.3.1  ... I would hope Debian is already shipping those
and that they are eligible to end up in their forthcoming stable
release]

AfC
Los Angeles

-- 
Andrew Frederick Cowie
Management Consultant

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Clint A. <ca...@au...>]

Ah, you are correct.  Sorry, I was thinking of some different posts.

Ismael Juma said:
> On Fri, 2005-04-15 at 11:48 -0500, Clint Allen wrote:
>> Hi there Khiraly.  I had the same problem a while back, posted a
message to this list and never got any response.  So I just figured it
out myself
>> (as with most of my questions here).
>> [...]
>
> You sure you never got any response? The following link says
> otherwise. :)
>
> http://article.gmane.org/gmane.comp.gnome.bindings.java/752
>
> Regards,
> Ismael

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Ismael J. <ml...@ju...>]

On Fri, 2005-04-15 at 11:48 -0500, Clint Allen wrote:
> Hi there Khiraly.  I had the same problem a while back, posted a message
> to this list and never got any response.  So I just figured it out myself
> (as with most of my questions here).
> [...]

You sure you never got any response? The following link says
otherwise. :)

http://article.gmane.org/gmane.comp.gnome.bindings.java/752

Regards,
Ismael

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Clint A. <ca...@au...>]

Hi there Khiraly.  I had the same problem a while back, posted a message
to this list and never got any response.  So I just figured it out myself
(as with most of my questions here).
Anyway, Debian Sid uses outdated versions of the following packages, and
to get java-gnome to work, you have to install them from source.

atk
libglade
libgnomecanvas
libgnomeui

Download the latest versions of these packages from your nearest
ftp.gnome.org mirror (I believe the path is /sources), and compile and
install them.  Then compile java-gnome against them, and everything should
work.  Let me know if you have any problems!


Khiraly said:
> Hi!
>
> I have update-ed the libgtk-java (2.6.1) in my debian SID. I can compile
> the applications, but Im not able to run it.
> I have also downloaded the most recent stable libgtk-java (2.6.2),
> exactly the same problem appear.
> I have pasted the error log, but I cant fix it.
>
> Anybody have an idea?
>
>
> Compilation successful
> Exception in thread "main"
> java.lang.UnsatisfiedLinkError: /usr/lib/libgtkjni-2.6.so:
> /usr/lib/libgtkjni-2.6.so: undefined symbol: atk_relation_add_target
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>         at java.lang.System.loadLibrary(System.java:834)
>         at org.gnu.glib.GObject.<clinit>(GObject.java:740)
> ------------
>
> The compiled recent verion:
>
> lama@khiraly:~/Desktop/down/libgtk-java-2.5.91.1/doc/examples$ java
> -classpath :/home/lama/Desktop/down/libgtk-java-2.6.2/gtk2.6.jar
> -Djava.library.path="/home/lama/Desktop/down/libgtk-java-2.6.2/libs"
> textbuffer/TextBuffer
> Exception in thread "main"
> java.lang.UnsatisfiedLinkError:
> /home/lama/Desktop/down/libgtk-java-2.6.2/libs/libgtkjni-2.6.so:
> /home/lama/Desktop/down/libgtk-java-2.6.2/libs/libgtkjni-2.6.so: undefined
> symbol: atk_relation_add_target
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>         at java.lang.System.loadLibrary(System.java:834)
>         at org.gnu.glib.GObject.<clinit>(GObject.java:740)
> lama@khiraly:~/Desktop/down/libgtk-java-2.5.91.1/doc/examples$
>
>
> Best regards,
>
> --
> Khiraly <khi...@gm...>

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Ismael J. <ml...@ju...>]

On Fri, 2005-04-15 at 17:12 +0200, Khiraly wrote:
> Hi!
> 
> I have update-ed the libgtk-java (2.6.1) in my debian SID. I can compile
> the applications, but Im not able to run it.
> I have also downloaded the most recent stable libgtk-java (2.6.2),
> exactly the same problem appear. 
> I have pasted the error log, but I cant fix it. 
> 
> Anybody have an idea?
> 
> 
> Compilation successful
> Exception in thread "main"
> java.lang.UnsatisfiedLinkError: /usr/lib/libgtkjni-2.6.so: /usr/lib/libgtkjni-2.6.so: undefined symbol: atk_relation_add_target
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>         at java.lang.System.loadLibrary(System.java:834)
>         at org.gnu.glib.GObject.<clinit>(GObject.java:740)
> ------------
> [...]

What version of atk are you using? You need at least 1.9.0.

Regards,
Ismael

Re: [Java-gnome-developer] Compile fine, but doesn't run

[Ismael J. <is...@ju...>]

On Fri, 2005-04-15 at 17:12 +0200, Khiraly wrote:
> Hi!
> 
> I have update-ed the libgtk-java (2.6.1) in my debian SID. I can compile
> the applications, but Im not able to run it.
> I have also downloaded the most recent stable libgtk-java (2.6.2),
> exactly the same problem appear. 
> I have pasted the error log, but I cant fix it. 
> 
> Anybody have an idea?
> 
> 
> Compilation successful
> Exception in thread "main"
> java.lang.UnsatisfiedLinkError: /usr/lib/libgtkjni-2.6.so: /usr/lib/libgtkjni-2.6.so: undefined symbol: atk_relation_add_target
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>         at java.lang.System.loadLibrary(System.java:834)
>         at org.gnu.glib.GObject.<clinit>(GObject.java:740)
> ------------
> [...]

What version of atk are you using? You need at least 1.9.0.

Regards,
Ismael

[Java-gnome-developer] Compile fine, but doesn't run

[Khiraly <khi...@gm...>]

Hi!

I have update-ed the libgtk-java (2.6.1) in my debian SID. I can compile
the applications, but Im not able to run it.
I have also downloaded the most recent stable libgtk-java (2.6.2),
exactly the same problem appear. 
I have pasted the error log, but I cant fix it. 

Anybody have an idea?


Compilation successful
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/lib/libgtkjni-2.6.so: /usr/lib/libgtkjni-2.6.so: undefined symbol: atk_relation_add_target
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at org.gnu.glib.GObject.<clinit>(GObject.java:740)
------------

The compiled recent verion:

lama@khiraly:~/Desktop/down/libgtk-java-2.5.91.1/doc/examples$ java
-classpath :/home/lama/Desktop/down/libgtk-java-2.6.2/gtk2.6.jar
-Djava.library.path="/home/lama/Desktop/down/libgtk-java-2.6.2/libs"
textbuffer/TextBuffer
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /home/lama/Desktop/down/libgtk-java-2.6.2/libs/libgtkjni-2.6.so: /home/lama/Desktop/down/libgtk-java-2.6.2/libs/libgtkjni-2.6.so: undefined symbol: atk_relation_add_target
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at org.gnu.glib.GObject.<clinit>(GObject.java:740)
lama@khiraly:~/Desktop/down/libgtk-java-2.5.91.1/doc/examples$ 


Best regards,

-- 
Khiraly <khi...@gm...>

[Java-gnome-developer] [slightly off topic from] Why libswt3-gtk2 isn't split between lib and plugin

[Ray A. <ra...@do...>]

Just clarifying this discussion, which is going slightly off topic. As
of the last official release, the Java-GNOME has a supported port of
libgtk-java and libglade-java for Windows.

Please do not talk around them and make assumptions without first
informing yourselves. 

http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/WindowsCompilation

This port has been going on for about a year (since the first tested
were conducted successfully). These guys deserve credit for all their
hard work, as do you all.


On Mon, 2005-11-04 at 00:58 -0300, Fernando Lozano wrote:
> Hi,
> 
> I think the message was't about the best Java GUI toolkit, but on how to 
> package SWT and apps that depend on them. Nothing prevents the packaging 
> of Java-Gnome and apps that depends on it, and it was done at least by 
> Fedora.
> 
> If everyone would package just the "best" app/library for each category, 
> How would sendmail/postfix and Gnome/KDE users feel?
> 
> But if you don't mind having your app running on Linux only (actually on 
> BSD and other Unixes) Java-Gnome would be a better toolkit. Go see their 
> websites and mailing list archives for specific reaons. :-) Actually, 
> using Java-Gnome is not Unix-only, just nobody did the port for Windows. 
> GTK itself and many apps, like Gimp and Ethereal, run fine under Windows 
> using the GTK port.

> 
> []s, Fernando Lozano
> 
> >On Sun, Apr 10, 2005 at 11:14:22PM -0400, Andrew Overholt wrote:
> >  
> >
> >>What about Java-GNOME?
> >>    
> >>
> >
> >Java-GNOME is a fine project, but in all honesty, SWT is a 
> >tried-tested-and-true solution. Moreover it gives you cross-platform
> >compatibility to Windows (and like it or not, Windows does
> >matter on the desktop).
> >
> >I don't use many Java apps on the desktop. In fact, I used to
> >*hate* java for desktop app because of Swing (mind you, I do
> >Java for a living :)). And yeah, AWT is a joke nowadays for
> >anything serious, so it's not even worth a mention.
> >
> >Eclipse changed all that for me. It showed me that a Java app
> >can look and feel "native". It's nice. If I needed to do a
> >desktop app and wanted to code it in Java, why pick anything
> >else other than SWT for my toolkit?
> >
> >  
> >
> 
> _______________________________________________
> JPackage-discuss mailing list
> JPa...@za...
> https://www.zarb.org/mailman/listinfo/jpackage-discuss
> 
-- 
Ray Auge <ra...@do...>

[Java-gnome-developer] New Java-GNOME bindings releases

[Jeff M. <ku...@gm...>]

The Java-GNOME Team is please to announce the next stable release 
of several bindings packages. This release contains bug fixes and build
enhancements.  This is our first release to fully support Windows compilation 
of our libgtk-java and libglade-java packages. Detailed instructions can be 
found at:

http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/WindowsCompilation

You can download the packages from the following locations:

libgtk-java 2.6.2: 
http://ftp.gnome.org/pub/gnome/sources/libgtk-java/2.6/libgtk-java-2.6.2.tar.gz

libgnome-java 2.10.1:
http://ftp.gnome.org/pub/gnome/sources/libgnome-java/2.10/libgnome-java-2.10.1.tar.gz

libglade-java 2.10.1:
http://ftp.gnome.org/pub/gnome/sources/libglade-java/2.10/libglade-java-2.10.1.tar.gz

libgconf-java 2.10.1:
http://ftp.gnome.org/pub/gnome/sources/libglade-java/2.10/libgconf-java-2.10.1.tar.gz


-- 
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

[Java-gnome-developer] Re: A CustomTreeModel [was: JTable(Swing) to java-gnome]

[Ka-Hing C. <ka...@gm...>]

On Apr 6, 2005 11:07 AM, Joao Victor <jvi...@ya...> wrote:
> Hmm, ok... well, just consider this situation (i don't know if it's possible, that's what i would
> like to know):
> 
> - A CustomTreeModel is constructed and filled with Java objects
> - The C-side creates the Iters, which point to the Java objects in the model
> - Some Java object is GC'ed, because no one in the Java-side is using it anymore
> - The C-side has a reference to an object that doesn't exist anymore
> - The C-side tries to use that reference, and boom.

You have a point, this can happen if someone creates a new object in
getChild and return it without storing it. I am not sure if this is
very common but definitely should be legal.

So local ref and weak ref are out. If global ref is used they we have
to free them in the destructor of TreeIter, which of course is only
possible if TreeIter is aware of CustomTreeModel, which essentially
means if CustomTreeModel is accepted as part of java-gtk. As the
person who started all this, I would say that it's definitely a good
idea (I would even suggest to drop the word "Custom", make this the
base class of all TreeModels, and move the getValue/setValue stuff to
a DefaultTreeModel (like how swing does it)).

Of course, I may not be the most unbiased person :-) What do others think?

-khc

Re: [Java-gnome-developer] Simpler ListView

[Joao V. <jvi...@ya...>]

The one thing i like about this approach is that it's simple, and it looks good. We need to evolve
the CustomTreeModel to see how far we'll be able to go with it.

Am adding the DeleteLocalReference stuff right now, gonna send you when i finish it.

Cheers,
J.V.



--- Ka-Hing Cheung <ka...@gm...> wrote:
> I swear I did it reply all... guess not.
> 
> And please don't take it as a criticism, it just doesn't interest me
> enough for me to comment a lot on.
> 
> -khc
> 
> ---------- Forwarded message ----------
> From: Ka-Hing Cheung <ka...@gm...>
> Date: Apr 5, 2005 5:55 PM
> Subject: Re: [Java-gnome-developer] Simpler ListView
> To: jvi...@ya...
> 
> 
> On Apr 5, 2005 10:49 AM, Joao Victor <jvi...@ya...> wrote:
> > It looks good... what do you think, Ka-Hing?
> 
> I haven't looked at it in detail, but it seems like we are solving
> very different problems:
> 
> 1) This is restricted to a list
> 2) You have to have your data stored in a Vector.
> 
> On the other hand, do you have the CustomTreeModel.c file with all the
> DeleteLocalReference stuff? I would like to work on/complete it this
> weekend.
> 
> -khc



	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Fwd: [Java-gnome-developer] Simpler ListView

[Ka-Hing C. <ka...@gm...>]

I swear I did it reply all... guess not.

And please don't take it as a criticism, it just doesn't interest me
enough for me to comment a lot on.

-khc

---------- Forwarded message ----------
From: Ka-Hing Cheung <ka...@gm...>
Date: Apr 5, 2005 5:55 PM
Subject: Re: [Java-gnome-developer] Simpler ListView
To: jvi...@ya...


On Apr 5, 2005 10:49 AM, Joao Victor <jvi...@ya...> wrote:
> It looks good... what do you think, Ka-Hing?

I haven't looked at it in detail, but it seems like we are solving
very different problems:

1) This is restricted to a list
2) You have to have your data stored in a Vector.

On the other hand, do you have the CustomTreeModel.c file with all the
DeleteLocalReference stuff? I would like to work on/complete it this
weekend.

-khc

[Java-gnome-developer] Continuing the JG events...

[Joao V. <jvi...@ya...>]

Hello all,

Giving continuity to the series of JG events, on Saturday (09/04) i'll be giving a talk about Free
Java and Java-Gnome at a local event called "II GNU/Linux Festival of Salvador"
(http://festival.softwarelivre.org/). Just though i'd let you guys know!

Cheers,
J.V.


	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] Simpler ListView

[Joao V. <jvi...@ya...>]

It looks good... what do you think, Ka-Hing?

As for the problem... it's happening in the refresh() method; i think you can't use an iter after
you've removed it. That might be the problem (after removing it you're calling
iter.getNextIter()).

Maybe there is some problem with ListStore.removeRow(); in the javadoc it says iter should
automatically be updated to the next iter after you remove it, but it seems that's not happening.

BTW, in refresh() there's a part you call 'store.moveRowToEnd(iter);'... but what happens to 'i'
(which is pointing to the row that should be added)?

Oh, and some of the suggestions for the new TreeView are here:
http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/JGDiscussionTreeViewEasier

Cheers,
J.V.


--- Abcdefg <ab...@so...> wrote:
> "I just looked at the code and it looks like it returns null when there
> is not a next item.  Could you verify this?"
> 
> Yes, that's correct and my code does check this but it gives another
> error.(java.lang.Exception: gtk_list_store_iter_next: assertion
> `GTK_LIST_STORE (tree_model)->stamp == iter->stamp' failed) But I just
> realised that I still run libgkt-java-2.4 so it is very likely that this is
> already fixed in a newer one
> 
> I will post back when I have tried it with the newer version
> 
> david



	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] Simpler ListView

[Abcdefg <ab...@so...>]

"I just looked at the code and it looks like it returns null when there
is not a next item.  Could you verify this?"

Yes, that's correct and my code does check this but it gives another
error.(java.lang.Exception: gtk_list_store_iter_next: assertion
`GTK_LIST_STORE (tree_model)->stamp == iter->stamp' failed) But I just
realised that I still run libgkt-java-2.4 so it is very likely that this is
already fixed in a newer one

I will post back when I have tried it with the newer version

david

Re: [Java-gnome-developer] Simpler ListView

[Jeff M. <ku...@gm...>]

On Apr 5, 2005 12:00 PM, Abcdefg <ab...@so...> wrote:
> The error occurs when I do
> Iter.getNextIter() when there is no next item.

I just looked at the code and it looks like it returns null when there 
is not a next item.  Could you verify this?

> 
> Thanks,
> David
> 
> 
> 


-- 
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

[Java-gnome-developer] Simpler ListView

[Abcdefg <ab...@so...>]

Hi,

Often when I work with lists in java I have a Vector with lots of classes in
it. To show this in a ListView in java-gnome is not very easy, that's why
I've created a class called MultiView wich gets its info out the Vector.

It works like this:

Vector v = new Vector();
v.addElement(new AClassThatImplementsMultiViewRow(parameters));
MultiView mv = new MultiView(v);

Please see the Test class in the tarball for more information.

I hope that this class can be of any help to someone. It is a bit buggy and
doesn't have many futures but I want to develop it more.

Also I read in the API and the presentation that you want to improve the
treeview, what do you think of this idee?

When the program runs there is an error in the output which I don't
understand, could someone please take a look at it because I don't know if
it is my fault or a bug in java-gnome.
The error occurs when I do
Iter.getNextIter() when there is no next item.

Thanks,
David

Re: [Java-gnome-developer] Screenshots of Contacts

[Andrew C. <an...@op...>]

On Mon, 2005-04-04 at 16:32 -0300, Joao Victor wrote:

> BTW, Andrew is also developing a nice app, you could take a look at his too.

xseq is still not ready for prime time[1], but you're welcome to look -
if nothing else there's some reasonably well worked LibGlade, TreeView,
TextView and Listener/Event code. See

        http://research.operationaldynamics.com/projects/ 

and in particular /darcs/xseq/HACKING, as linked by that page for
instructions of how to retreive and build the it.

AfC
Toronto

[1] "Prime Time": even to this audience, I'm reluctant to be to forward
about promoting my work because it's not yet at the point where it
explains itself. That matters because there is an very specific problem
space I'm working on and the design is constrained and explained by
quite a number of unusual factors - and I don't want to club myself to
death trying to endlessly justify it until its gestalt makes sense.

As we speak, I'm working on some FAQ type pages to help explain many of
these things, both from a "what is this for", "why is it this way", and
"why is the code [architecture] the way it is" perspective. Once I can
invite people to read those, then it's more amenable to being presented
widely.

Nevertheless, there's some good java-gnome code in there, and so people
are certainly welcome to look at it.

Re: [Java-gnome-developer] Screenshots of Contacts

[Joao V. <jvi...@ya...>]

--- Khiraly <khi...@gm...> wrote:
> Can you put somewhere on the net? 

Ok, i'll send to your email tonight... i was waiting for somebody to ask for it :P

BTW, Andrew is also developing a nice app, you could take a look at his app too.

Cheers,
J.V.

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

News from JG-con? [was: Re: [Java-gnome-developer] Ebuilds for java-gnome 2.10 series now available]

[Joao V. <jvi...@ya...>]

--- Andrew Cowie <an...@op...> wrote:
> While we were having the hack-fest in Toronto this weekend, 

BTW, where are the screenshots? - i mean, the pictures of the event! ;)

Cheers,
J.V.


__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Java-gnome-developer] Screenshots of Contacts

[Khiraly <khi...@gm...>]

2005-02-23, sze keltez=E9ssel 21:20-kor Joao Victor ezt =EDrta:
> There's still lots of neat funcionalities i'm planning to make...
> haven't put it on any cvs yet,
> but i will in the future. If there's anyone interested in working on
> it too, just let me know ;)

Hi!

Im still interested for the source code. I want to see a more complex
java-gnome example.

Can you put somewhere on the net? Or you can directly email me, if you
want.

Best regards,=20
 Khiraly

[Java-gnome-developer] Ebuilds for java-gnome 2.10 series now available

[Andrew C. <an...@op...>]

While we were having the hack-fest in Toronto this weekend, I worked on
bringing the java-gnome ebuilds I maintain up to date  for the 2.10
release series.

As usual, I've posted the work on our website, see
http://research.operationaldynamics.com/linux/gentoo/

Those of you running Gentoo can get these ebuilds quickly and easily by=20
downloading the tarball referenced there and unpacking it into your
portage overlay:
http://research.operationaldynamics.com/linux/gentoo/java-gnome-2.10.0_ebui=
lds.tar.gz

The digests from upstream are all verified; the MD5 sum of this file is
7ac67bbc9eb8d1d0341dc6e6526bf78b

AfC
Toronto

--=20
Andrew Frederick Cowie
Management Consultant

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [Java-gnome-developer] starting a new project/Re: [Java-gnome-developer] Re: "Java-GNOME Con 1"

[Ray A. <ra...@do...>]

Hey All,

On this note, has anyone used ant's recently (well, about a year) added
support for gcj native builds, libs, linking, etc... Ant really is very
straight forwared to use and readable.

Ray,

PS: I really wanted to go the "Java-GNOME Con 1", since I live so close,
but probably wouldn't have been much help AND couldn't get away. Hope
those who attended had fun/were productive. Maybe next year.

On Thu, 2005-31-03 at 19:13 +0200, Olivier Evalet wrote:
> Hi Andrew,
> 
> > 
> > I *will* be splicing this work out at some point. I thought
> > "configure4j" a nice moniker.
> > 
> Great, I can help you ! do you have a TODO?
> 
> I read your scripts (very clean code, thanks!!) and I did some small 
> changes (attached files):
> -------------------------------------------------------------------
> 1) set default configure options (for my project)
> 2) set default main class on configure $MAINCLASS
> 3) set native gcj jars $NATIVE_JARS on configure
> 4) add generic $ext_jars  to extend classpath
> 5) added the "make native" option on the Makefile
> 6) tested on debian an gentoo ;)
> 
> STILL TODO
> 1) check gcj, gij, etc... version
> 
> -------------------------------------------------------------------
> It will be nice to build the classpath for extra libraries, but there 
> are not true jar finder on distribs (or I dont know how todo). I found 
> different way:
> 
> a)gentoo, pkg-config --variable classpath or java-config, but not all 
> packages are configured for that ...
> 
> b)debian, I found nothing, there are some idea but nothing is really done
> http://java.debian.net/index.php/
> 
> c)redhat, I can't test it!
> 
> There are some hacks possible for debian and gentoo with tools like 
> find, dpkg and qpkg.
> 
> 
> 
> Regards,
> Olivier
> 
> PS please be indulgent with my poor English ;)
> 
> 
> plain text document attachment (Makefile)
> #
> # If you need to debug some classpath, includes, or command line arguments
> # option, then comment out MAKEFLAGS line below, or set V=1 on the command
> # line before make.
> #
> ifdef V
> else
> MAKEFLAGS=-s
> endif
> 
> all: build/classes-dist
> 
> .PHONY: all run test clean distclean
> 
> # --------------------------------------------------------------------
> # Variable setup. You may want to set your editor to wrap to see the
> # full CLASSPATH
> # --------------------------------------------------------------------
> 
> -include .config
> 
> # [this  will be called by the above include if .config is missing.
> # we don't call ./configure automatically to allow scope for
> # manual configuration and overrides]
> .config:
> 	echo
> 	echo "You need to run ./configure to check prerequisites"
> 	echo "and setup preferences before you can build xseq."
> 	( if [ ! -x configure ] ; then chmod +x configure ; echo "I just made it executable for you." ; fi )
> 	echo
> 	exit 1
> 
> # Variables we expect to be set in .config are:
> #	JAVAGNOME_JARS
> #	XML_JARS
> #	JUNIT_JARS
> #	JNI_PATH
> #	JAVAC[_CMD]	[expected to be 9 chars wide]
> #	JAVA[_CMD]	[expected to be 9 chars wide]
> 
> # [This is just a quick sanity check]
> build/config: build/dirs .config
> 	@echo "CHECK     build system configuration"
> 	( if [ ! "$(JAVAGNOME_JARS)" ] ; then echo "Sanity check failed. Run ./configure" ; exit 1 ; fi )
> 	touch $@
> 
> # [not in use at present; code and unit tests in stash/]
> # BERKELEY_JARS=/usr/lib/db-4.2.jar
> 
> # [note that Berkeley DB isn't used just now, so its jars are not here]
> CLASSPATH=$(JAVAGNOME_JARS):$(XML_JARS):$(EXT_JARS)
> 
> #SOURCES_DIST=$(shell find src -name '*.java')
> SOURCES_DIST=$(shell find src -name '*.java')
> SOURCES_TESTS=$(shell find tests -name '*.java')
> 
> # [we now go to the bother of listing the .class targets individually in order
> # to allow us to use gcj, which doesn't compile all the things it needs to 
> # (as javac does) even though it has to finds things by scanning. This
> # can considerably slow a javac build depending on the order which classes
> # are encountered; oh well]
> CLASSES_DIST=$(shell echo $(SOURCES_DIST) | sed -e's/.java/.class/g' -e's/src/tmp\/classes/g')
> CLASSES_TESTS=$(shell echo $(SOURCES_TESTS) | sed -e's/.java/.class/g' -e's/tests/tmp\/classes/g')
> 
> #
> # convenience target: setup pre-reqs
> #
> build/dirs:
> 	@echo "MKDIR     preping temporary files and build directories"
> 	-test -d build || mkdir build
> 	-test -d tmp/classes || mkdir -p tmp/classes
> 	-test -d tmp/native || mkdir -p tmp/native
> 	touch $@
> 
> # [these are only necessary as a defence against the system having evolved
> # since it was ./configured. Java is so bad at identifying the root cause 
> # being missing files that were expected that such a safety check helps
> # innocent builders maintain their sanity.]
> build/check-jars:
> 	@echo "CHECK     prerequite core jar files"
> 	( if [ ! "$(CLASSPATH)" ] ; then echo "\"CLASSPATH\" variable is an empty. How did you get here?" ; exit 1 ; fi )
> 	( for i in `echo $(CLASSPATH) | sed -e's/:/ /g'` ; do if [ ! -f $$i ] ; then echo $$i not found. ; exit 1 ; fi ; done )
> 	touch $@
> 
> build/check-jars-tests:
> 	@echo "CHECK     prerequite unit test jar files"
> 	( if [ ! "$(JUNIT_JARS)" ] ; then echo "\"JUNIT_JARS\" variable is an empty. How did you get here?" ; exit 1 ; fi )
> 	( for i in `echo $(JUNIT_JARS) | sed -e's/:/ /g'` ; do if [ ! -f $$i ] ; then echo $$i not found. ; exit 1 ; fi ; done )
> 	touch $@
> 
> # --------------------------------------------------------------------
> # Source compilation
> # --------------------------------------------------------------------
> 
> # [anything Java JVM runtime should depend on this target]
> build/classes: build/classes-dist build/classes-tests
> 
> tmp/classes/%.class: src/%.java
> 	@echo "$(JAVAC_CMD) $<"
> 	$(JAVAC) -d tmp/classes -classpath tmp/classes:$(CLASSPATH):src $<
> 
> tmp/classes/%.class: tests/%.java
> 	@echo "$(JAVAC_CMD) $<"
> 	$(JAVAC) -d tmp/classes -classpath tmp/classes:$(CLASSPATH):$(JUNIT_JARS):src:tests $<
> 
> #
> # build the sources (that are part of the distributed app)
> #
> 
> build/classes-dist: build/config build/check-jars $(CLASSES_DIST)
> 	touch $@
> 
> #
> # build the test sources
> #
> build/classes-tests: build/config build/check-jars-tests build/classes-dist $(CLASSES_TESTS)
> 	touch $@
> 
> # --------------------------------------------------------------------
> # Runtime convenience targets
> # --------------------------------------------------------------------
> 
> test: build/classes
> 	@echo "$(JAVA_CMD) AllXmlTests [JUnit]"
> 	LD_LIBRARY_PATH=$(JNI_PATH) \
> 	$(JAVA) -classpath $(CLASSPATH):$(JUNIT_JARS):tmp/classes xseq.services.AllXmlTests
> 	@echo "$(JAVA_CMD) AllDomainTests [JUnit]"
> 	LD_LIBRARY_PATH=$(JNI_PATH) \
> 	$(JAVA) -classpath $(CLASSPATH):$(JUNIT_JARS):tmp/classes xseq.domain.AllDomainTests
> 
> # [this is classes and not classes-dist because at the moment any use of this 
> # target is to setup, but needing a the support of a test environment, which
> # WindowRunner provides]
> debug: build/classes
> 	@echo "$(JAVA_CMD) $(MAINCLASS) --debug=all"
> 	LD_LIBRARY_PATH=$(JNI_PATH) \
> 	$(JAVA) -classpath $(CLASSPATH):tmp/classes $(MAINCLASS) --debug=all
> 
> # [to be changed to classes-dist and xseq.client.ProcedureClient]
> run: build/classes
> 	@echo "$(JAVA_CMD) $(MAINCLASS)"
> 	LD_LIBRARY_PATH=$(JNI_PATH) \
> 	$(JAVA) -classpath $(CLASSPATH):tmp/classes $(MAINCLASS)
> 
> # [try to build native ]
> native: 
> 	@echo "Build native $(MAINCLASS) "
> 	gcj --encoding=ISO8859-1 -classpath $(CLASSPATH)  -L`echo $(JNI_PATH) | sed -e's/:/ -L/g'` \
> 	$(NATIVE_JARS) -fPIC --main=$(MAINCLASS) -o $(MAINCLASS) $(SOURCES_DIST)
> 
> # --------------------------------------------------------------------
> # House keeping
> # --------------------------------------------------------------------
> 
> # [note that we don't remove .config here, as a) darcs doesn't pick it up
> # so if it's hanging around it won't cause problems, and b) if it is removed 
> # here, then `make clean all` fails]
> clean:
> 	@echo "RM        temporary build directories"
> 	-rm -rf build
> 	-rm -rf tmp
> 	-rm -rf hs_err_*
> 	-rm $(MAINCLASS)
> distclean: clean
> 	@echo "RM        build configuration information"
> 	-rm -f .config .config.tmp
> 	@echo "RM        development artifacts"
> 	-rm -f share/*.gladep share/*.glade.bak share/*.gladep.bak
> plain text document attachment (configure)
> #!/usr/bin/perl -w
> 
> use strict;
> 
> use File::Basename;
> 
> #
> # Configure xseq for building. We:
> #
> # - determine the operating system
> #
> # - set known defaults that correspond to that OS
> #
> # - for items where we have multiple possibilities, work through the
> #   possibilities until we find one
> #
> # - for items where there are options to choose from (notably which java
> #   compiler and VM we're using), we select a sensible default unless
> #   instructed otherwise on the command line.
> #
> 
> my $os;
> 
> # There's nothing worse than having an old config file, getting half way
> # through this, having it break, and then being able to build, but getting
> # errors because configure really didn't finish. We do leave .config.tmp 
> # in place on error to facilitate troubleshooting.
> 
> `rm -f .config`;
> 
> # --------------------------------------------------------------------
> # Process command line arguments for overrides
> # --------------------------------------------------------------------
> 
> my $quiet;
> my $compiler	= "gcj";
> my $runtime	= "gij";
> my $main	= "org.programmers.installer.InstallBase";
> 
> foreach my $arg (@ARGV) {
> 	my ($key, $value) = split /=/, "$arg";
> 
> 	if ($key eq "quiet") {
> 		$quiet = 1;
> 	} elsif ($key =~ /^runtime/) {
> 		$runtime="$value";
> 	} elsif ($key =~ /^compiler/) {
> 		$compiler="$value"
> 	} elsif ($key =~ /^main/) {
> 		$main="$value";
> 	}
> }
> 
> # --------------------------------------------------------------------
> # Utility and checking functions
> # --------------------------------------------------------------------
> 
> #
> # Very simply: if the msg does not contain a newline, then it is assumed
> # to introduce a statement, so we print it and left pad it with spaces.
> # If the text does contain a newline, then probably it is concluding a 
> # statment (ok, failed, whatever) but not necessarily - just print the thing
> # without any padding.
> #
> sub output {
> 	my $str = shift;
> 	if ($str =~ /\n/) {
> 		print $str unless $quiet;
> 	} else {
> 		printf "%-35s", $str unless $quiet;
> 	}
> }
> 
> sub which {
> 	my $program = shift;
> 	my $ret = `which $program 2>/dev/null`;
> 	chomp $ret;
> 	return $ret;
> }
> 
> sub bail {
> 	my $status = shift || "failed";
> 	my $msg = shift || "";
> 
> 	# assuming that we're in an incomplete line 
> 	output "$status\n\n";
> 
> 
> 	print "$msg\n\n" if $msg;
> 	print "Failed to complete configuration.\n";
> 	exit(1);
> }
> 
> if ( ! defined($main)) {
> 	bail "failed", "You must specify a main class to configure a project\n";
> 	return;
> }
> 
> 
> sub check_lib (\@$) {
> 	my $arraylibs = $_[0];
> 	my $native = $_[1];
> 	if (defined($native)){
> 		output " - native lib $native";
> 		# TODO must be checked, but the LIB_PATH is required
> 		push (@$arraylibs," -l$native");
> 		print "found\n";
> 	}
> }
> 
> sub check_prereq (\@$$$) {
> 	my $arrayref = $_[0];
> 	my $item = $_[1];
> 	my $file = $_[2];
> 	my $package = $_[3];
> 
> 	output " - ".$item;
> 
> 	my $str;
> 
> 	if ( ! -f "$file" ) {
> 		$str = "In order to build $main, you need ".basename($file)." (we\n";
> 		$str .= "expected to find it in ".dirname($file).") which is part of\n";
> 		$str .= "the $item Java library. On a ".ucfirst($os)." system,\n";
> 		$str .= "you should be able to get this requirement by doing:\n\n";
> 		$str .= "     # ";
> 
> 		if ($os eq "gentoo") {
> 			$str .= "emerge";
> 		} elsif ($os eq "debian") {
> 			$str .= "apt-get install";
> 		} elsif ($os eq "fedora") {
> 			$str .= "yum install";
> 		} else {
> 			$str .= "[FIXME fetch and install command for this OS]"; 
> 		}
> 		$str .= " $package";
> 
> 		bail "not found!", $str;
> 	}
> 	print "found\n";
> 
> 
> 	push (@$arrayref, $file);
> }
> 
> # if we return without setting the variable pointed at by scalarref, its being
> # empty will be used later to indicate that this compiler wasn't present /
> # usable.
> #
> # The "not present" check is somewhat spurious given the input in many cases
> # is the result of a `which` call.
> 
> sub check_compiler (\$$$$) {
> 	my $scalarref = $_[0];
> 	my $item = $_[1];
> 	my $program = $_[2];
> 	my $args = $_[3];
> 
> 	chomp $program;
> 	if ( ! -f "$program") {
> 		$$scalarref = "";
> 		return;
> 	}
> 
> 	# appealing to my sense of economy, we only print something out if 
> 	# it's there - that way we can list lots of options to check without
> 	# cluttering things endlessly.
> 	output " - ".$item;
> 
> 	if ( ! -x "$program") {
> 		output "found but not executable\n";
> 		$$scalarref = "";
> 		return;
> 	}
> 
> 	# Ok, so inline code is lame, but it's so small, and only one,
> 	# and, avoids having a file in tests/ that will be picked up later
> 	# as neededing compiling.
> 	open HELLO, ">Hello.java";
> 	print HELLO <<HERE ;
> public class Hello {
> 	public static void main(String[] args) {
> 		System.out.print("Hello");
> 	}
> }
> HERE
> 	close HELLO;
> 
> 	`$program $args Hello.java >/dev/null 2>&1`;
> 	if ($? != 0) {
> 		output "doesn't work\n";
> 		$$scalarref = "";
> 		return
> 	}
> 
> 	output "works\n";
> 	$$scalarref = "$program $args";
> }
> 
> 
> sub check_runtime (\$$$$) {
> 	my $scalarref = $_[0];
> 	my $item = $_[1];
> 	my $program = $_[2];
> 	my $args = $_[3];
> 
> 	chomp $program;
> 	if ( ! -f "$program") {
> 		$$scalarref = "";
> 		return;
> 	}
> 
> 	output " - ".$item;
> 
> 	if ( ! -x "$program") {
> 		output "found but not executable\n";
> 		$$scalarref = "";
> 		return;
> 	}
> 	my $output = `$program $args Hello 2>/dev/null`;
> 
> 	if (($? != 0) || ($output ne "Hello")) {
> 		output "doesn't work\n";
> 		$$scalarref = "";
> 		return
> 	}
> 
> 	output "works\n";
> 	$$scalarref = "$program $args";
> }
> 
> 
> # --------------------------------------------------------------------
> # Determine Operating System
> # --------------------------------------------------------------------
> 
> output "\n";
> 
> open CONFIG, ">.config.tmp";
> print CONFIG <<HERE ;
> # This is an automatically generated Makefile fragment which is used to
> # configure xseq for building. Do not edit (your changes will be overwritten
> # next time ./configure is run), do not commit to repository. Anyone packaging
> # xseq on any operating system: please do not override this file by patching
> # it! Figure out what the problem is, and let us know so we can improve the
> # ./configure perl script which generates it.
> 
> HERE
> 
> output "Indentify operating system:";
> 
> if (( -f "/etc/gentoo-release" ) || ( -f "/etc/make.conf" )) {
> 	output "Gentoo\n";
> 	$os = "gentoo";
> } elsif ( -f "/etc/debian_version") {
> 	output "Debian\n";
> 	# and Ubuntu
> 	$os = "debian";
> } elsif ( -f "/etc/fedora-release" ) {
> 	output "Fedora Core";
> 	$os = "fedora";
> }
> 
> if ($os) {
> 	print CONFIG "OS=$os\n";
> } else {
> 	bail "unknown!", <<HERE ;
> What we really need you to do is to look into this configure program, and
> tell us what to add. Based on the examples of what is specified for other
> distributions, you can probably quickly figure out what the appropriate
> settings are for your platform. 
> 
> Letting us know what changes you had to make here (ie, whatever actions
> resulted in a .config that allows you to build, test, and run xseq) we can
> help others with your operating system take advantage of this program.
> HERE
> }
> 
> output "\n";
> 
> 
> # --------------------------------------------------------------------
> # Specifiy locations of dependencies, by operating system, and 
> # verify pre-requsites are present.
> # --------------------------------------------------------------------
> 
> my @xml_jars;
> my @javagnome_jars;
> my @junit_jars;
> my @ext_jars;
> my @native_jars;
> my $jni_path;
> 
> 
> output "Check for required native jars:\n";
> #
> # ADD YOUR NATIVE JARS HERE
> #
> check_lib(@native_jars,"gtkjar2.4");
> check_lib(@native_jars,"gladejar2.8");
> check_lib(@native_jars,"gnomejar2.8");
> check_lib(@native_jars, "partedjava-1.0");
> 
> output "\n";
> output "Check for required jar files:\n";
> 
> 
> # ADVICE TO PEOPLE EXTENDING THIS SECTION FOR THEIR OWN OPERATING SYSTEM:
> # You might as well list things in such an order that you tell the builder
> # the package whose dependencies will bring the rest of the pre-requisites 
> # in along the way...
> 
> 
> if ($os eq "gentoo") {
> 	check_prereq(@xml_jars,
> 		"Xerces XML parser",
> 		"/usr/share/xerces-2/lib/xercesImpl.jar",
> 		"xerces");
> 	check_prereq(@xml_jars,
> 		"Apache XML Commons DOM APIs",
> 		"/usr/share/xerces-2/lib/xml-apis.jar",
> 		"xml-commons");
> 
> 	check_prereq(@javagnome_jars,
> 		"GTK+ Java bindings",
> 		"/usr/share/libgtk-java-2.4/lib/gtk2.4.jar",
> 		"libgtk-java");
> 
> 	check_prereq(@javagnome_jars,
> 		"LibGlade Java bindings",
> 		"/usr/share/libglade-java-2.8/lib/glade2.8.jar",
> 		"libglade-java");
> 
> 	check_prereq(@junit_jars,
> 		"JUnit test framework",
> 		"/usr/share/junit/lib/junit.jar",
> 		"junit");
> 
> 	check_prereq(@ext_jars,
> 		"Parted java bindings",
> 		"/usr/share/java/parted1.0-1.0.jar",
> 		"parted-java");
> 
> 
> 
> 	$jni_path = "/usr/lib";
> 
> } elsif ($os eq "debian") {
> 	# This is a GNU lookalike, but is not necessary - and libxerces-2 
> 	# pulls in libjaxp1.2-java which contains xml-apis.jar, just not by
> 	# that name
> 	#check_prereq(@xml_jars,
> 	#	"W3C DOM APIs",
> 	#	"/usr/share/java/gnujaxp-1.1.jar",
> 	#	"libgnujaxp-java");
> 	check_prereq(@xml_jars,
> 		"Xerces XML parser",
> 		"/usr/share/java/xercesImpl.jar",
> 		"libxerces2-java");
> 	check_prereq(@xml_jars,
> 		"Apache XML Commons DOM APIs",
> 		"/usr/share/java/jaxp-1.2.jar",
> 		"libjaxp1.2-java");
> 
> 	check_prereq(@javagnome_jars,
> 		"GTK+ Java bindings",
> 		"/usr/share/java/gtk2.4.jar",
> 		"libgtk2-java");
> 	check_prereq(@javagnome_jars,
> 		"LibGlade Java bindings",
> 		"/usr/share/java/glade2.8.jar",
> 		"libglade2-java");
> 
> 	check_prereq(@junit_jars,
> 		"JUnit test framework",
> 		"/usr/share/java/junit.jar",
> 		"junit");
> 
> 	check_prereq(@ext_jars,
> 		"Parted java bindings",
> 		"/usr/share/java/parted1.0-1.0.jar",
> 		"parted-java");
> 
> 	$jni_path = "/usr/lib:/usr/lib/jni";
> 	
> } elsif ($os eq "fedora") {
> 	check_prereq(@xml_jars,
> 		"Xerces XML parser",
> 		"/usr/share/java/xerces-j2.jar",
> 		"xerces-j2");
> 	check_prereq(@xml_jars,
> 		"Apache XML Commons DOM APIs",
> 		"/usr/share/java/jaxp-1.2.jar",
> 		"libjaxp1.2-java");
> 	check_prereq(@xml_jars,
> 		"Xerces Samples",
> 		"/usr/share/xerces-j2/xerces-j2-samples.jar",
> 		"xerces-j2-demo");
> 
> 	check_prereq(@javagnome_jars,
> 		"GTK+ Java bindings",
> 		"/usr/share/java/gtk2.4.jar",
> 		"libgtk-java");
> 	check_prereq(@javagnome_jars,
> 		"LibGlade Java bindings",
> 		"/usr/share/java/glade2.8.jar",
> 		"libglade-java");
> 
> 	check_prereq(@junit_jars,
> 		"JUnit test framework",
> 		"/usr/share/java/junit.jar",
> 		"junit");
> 
> 	$jni_path = "/usr/lib";
> 	
> } else {
> 	bail "failed!", "This OS not configured with defaults!\nTHIS IS AN INTERNAL ERROR, PLEASE FILE A BUG.";
> }
> 
> 
> # --------------------------------------------------------------------
> # Record jar locations
> # --------------------------------------------------------------------
> 
> print CONFIG <<HERE ;
> 
> # The lists of jars are colon separated, suitable for being
> # concatonated into a CLASSPATH
> 
> HERE
> 
> print CONFIG "XML_JARS=".join(":", @xml_jars)."\n";
> print CONFIG "JAVAGNOME_JARS=".join(":",@javagnome_jars)."\n";
> print CONFIG "JUNIT_JARS=".join(":",@junit_jars)."\n";
> print CONFIG "EXT_JARS=".join(":",@ext_jars)."\n";
> print CONFIG "NATIVE_JARS=".join(" ",@native_jars)."\n";
> 
> print CONFIG <<HERE ;
> 
> # the JNI_PATH is what is passed as LD_LIBRARY_PATH when running
> # java Virtual Machines so that JNI shared libraries are picked up 
> 
> HERE
> print CONFIG "JNI_PATH=$jni_path\n";
> print CONFIG "MAINCLASS=$main\n";
> 
> output "\n";
> 
> # --------------------------------------------------------------------
> # Check compilers: locations, necessary arguments, and that they work
> # --------------------------------------------------------------------
> 
> output "Check Java compilers:\n";
> 
> # compilers we will check for:
> my $javac;
> my $jikes;
> my $gcjC;	# The moniker $gcjC referes to `gcj -C`. In the future will
> 		# use the variable $gcj to mean "gcj as used to build native
> 		# code". See HACKING for details.
> 
> if ($os eq "gentoo") {
> 	if ( ! -x "/usr/bin/java-config") {
> 		bail "", "INTERNAL ERROR couldn't find java-config";
> 	}
> 
> 	# check jikes. Since Jikes isn't a JRE of its own, it needs to be
> 	# told about where to find the Java system classes. (java.lang, etc)
> 	# we make an educated guess until java-config can tell us properly.
> 	my $rt = `java-config -O`;
> 	chomp $rt;
> 	$rt .="/jre/lib/rt.jar";
> 	check_compiler($jikes, "IBM jikes", which("jikes"), "-bootclasspath $rt") if ( -f "$rt");
> 	
> 	# check javac (the one specified by Gentoo's java-config tool)
> 	# The $vendor business is just some precision prettiness for the
> 	# display.
> 	my $path; my $vendor;
> 	$path = `java-config --javac`;
> 	if ($path =~ /sun/i) {
> 		$vendor = "Sun";
> 	} elsif ($path =~ /blackdown/i) {
> 		$vendor = "Blackdown";
> 	} elsif ($path =~ /ibm/i) {
> 		$vendor = "IBM";
> 	} else {
> 		$vendor = "System";
> 	}
> 	check_compiler($javac, "$vendor javac", $path, "");
> 
> 	# check gcj. -C means generate .class files, not .o files (which are
> 	# for linking into native executables.
> 	check_compiler($gcjC, "GCJ gcj -C (bytecode mode)", which("gcj"), "-C");
> 
> } elsif ($os eq "debian") {
> 	# we can do much better than this, especially for java/javac.
> 	# Do we access the alternatives system, or just go with known
> 	# paths, or...? `which` is lame
> 
> 	# check jikes. Since Jikes isn't a JRE of its own, it needs to be told
> 	# about where to find the Java system classes. (java.lang, etc) The
> 	# only way they'll be present is if a real Java VM is installed FIXME:
> 	# How to find those on a Debian system? See the Gentoo block above for
> 	# ideas. (at last report, libgcj's version of the GNU CLASSPATH
> 	# libraries won't work here)
> 	check_compiler($jikes, "IBM jikes", which("jikes"), "-bootclasspath FIXME");
> 
> 	# check for a proper "real" JDK's javac as installed (and maybe
> 	# selected in the alternatives system) by the user. In other words,
> 	# javac -> /opt/sun-jdk-1.4.2.02/bin/javac, not javac -> kaffec.
> 	check_compiler($javac, "Real javac", which("javac"), "");
> 
> 	# check gcj. The moniker $gcjC referes to `gcj -C`. See HACKING.
> 	check_compiler($gcjC, "GCJ (bytecode mode)", which("gcj"), "-C");
> 
> } elsif ($os eq "fedora") {
> 	# we can do much better than this, especially for java/javac.
> 	# Should we just go with known paths, or...? `which` is so lame
> 
> 	# check for jikes. Presumably -bootclasspath will need to be set
> 	# like on Gentoo and Debian; to what?
> 	check_compiler($jikes, "IBM jikes", which("jikes"), "-bootclasspath FIXME");
> 
> 	# check for a proper JDK javac as installed (and selected in a FIXME
> 	# redhat specific way if there is such a thing). NOT kaffec!
> 	check_compiler($javac, "Real javac", which("javac"), "");
> 
> 	# check for gcj
> 	check_compiler($gcjC, "GCJ (bytecode mode)", which("gcj"), "-C");
> 
> } else {
> 	bail "failed!", "This OS not configured with a workable Java compiler checks!\nTHIS IS AN INTERNAL ERROR, PLEASE FILE A BUG.";
> }
> 
> output "\n";
> 
> # --------------------------------------------------------------------
> # Check runtimes
> # --------------------------------------------------------------------
> 
> output "Check Java virtual machines:\n";
> 
> # runtimes we will check for:
> my $java;
> my $gij;
> my $kaffe;
> 
> if ($os eq "gentoo") {
> 	# check java (the one specified by Gentoo's java-config tool)
> 	# Is there any actual scenario where the javac would be from one 
> 	# vendor's JDK and the java from anothers JRE? I can't imagine, but
> 	# do the $vendor check again. It's only cosmetic in any event.
> 	my $path; my $vendor;
> 	$path = `java-config --java`;
> 	if ($path =~ /sun/i) {
> 		$vendor = "Sun";
> 	} elsif ($path =~ /blackdown/i) {
> 		$vendor = "Blackdown";
> 	} elsif ($path =~ /ibm/i) {
> 		$vendor = "IBM";
> 	} else {
> 		$vendor = "System";
> 	}
> 	check_runtime($java, "$vendor java VM", $path, "");
> 
> 	# check gij (the bytecode interpreter from the GCJ project)
> 	check_runtime($gij, "GCJ gij", which("gij"), "");
> 
> 	# check kaffe
> 	check_runtime($kaffe, "kaffe VM", which("kaffe"), "");
> 
> } elsif ($os eq "debian") {
> 	# check for a proper JDK/JRE java Virtual Machine (presumably either
> 	# blackdown, or the real thing from Sun or IBM, as installed by the
> 	# user).  NOTE that this does *NOT* mean Sable VM or kaffe (so, if the
> 	# Debian alternatives system can say that's what's providing
> 	# java-runtime, then we need to take advantage of that. This is for a
> 	# real JRE only, ie java -> /opt/sun-jdk-1.4.2.02/bin/java, not for
> 	# java -> kaffe.
> 	check_runtime($java, "Real java VM", which("java"), "");
> 
> 	# check gij (the bytecode interpreter from the GCJ project). In Debian
> 	# it is in package gij-3.4 and so named in /usr/bin.
> 	check_runtime($gij, "GCJ gij", which("gij-3.4"), "");
> 
> 	# check kaffe. Don't take it personally, but kaffe is not meant as a
> 	# robust production ready VM.  It's a research tool (so described on
> 	# their home page) but given the progress in GNU classpath lately it
> 	# *may* work, so we do check for it  - we just don't pick it by
> 	# preference.
> 	check_runtime($kaffe, "Kaffe VM", which("kaffe"), "");
> 
> } elsif ($os eq "fedora") {
> 	# check for a proper JDK/JRE java Virtual Machine (as installed and
> 	# selected in a FIXME redhat specific way if there is such a thing)
> 	# note that this does NOT mean Sable VM or kaffe.
> 	check_runtime($java, "Real java VM", which("java"), "");
> 
> 	# check gij (the bytecode interpreter from the GCJ project)
> 	check_runtime($gij, "GCJ gij", which("gij"), "");
> 
> 	# check kaffe. See the comment about Kaffe above in the Debian block.
> 	check_runtime($kaffe, "Kaffe VM", which("kaffe"), "");
> } else {
> 	bail "failed!", "This OS not configured with appropriate Java VM checks!\nTHIS IS AN INTERNAL ERROR, PLEASE FILE A BUG.";
> }
> 
> 
> # --------------------------------------------------------------------
> # Choose between java compilers and VMs
> # --------------------------------------------------------------------
> 
> output "\n";
> 
> print CONFIG <<HERE ;
> 
> # the JAVAC variable contains the path to the java source compiler, the JAVA
> # variable contains the path to the java runtime virtual machine. In both
> # cases, the _CMD variable is for the terse output when make commands are 
> # running.
> 
> HERE
> 
> 
> output "Select compiler:";
> 
> if ($compiler) {
> 	# if overridden, check override...
> 	if ($compiler eq "javac") {
> 		bail "bad override", "javac specified but not detected as a workable compiler." unless $javac;
> 	} elsif ($compiler eq "jikes") {
> 		bail "bad override", "jikes specified but not detected as a workable compiler." unless $jikes;
> 	} elsif ($compiler eq "gcj") {
> 		bail "bad override", "gcj (-C) specified but gcj not detected as a workable compiler." unless $gcjC;
> 	} else {
> 		bail "bad override", <<HERE ;
> You specified compiler=$compiler on the command line, but that's not an option.
> Valid choices are javac, jikes, or gcj - but of course that compiler must be
> installed (and detected!) in order to be able to specifiy it.
> HERE
> 	}
> 
> } else {
> 	# otherwise, pick a compiler.
> 	if ($jikes) {
> 		$compiler = "jikes";
> 	} elsif ($javac) {
> 		$compiler = "javac";
> 	} elsif ($gcjC) {
> 		$compiler = "gcj";
> 	} else {
> 		bail "failed", "No java compiler was detected.";
> 	}
> }
> 
> if ($compiler eq "javac") {
> 	print CONFIG "JAVAC=$javac\n";
> 	print CONFIG "JAVAC_CMD=JAVAC    \n";
> } elsif ($compiler eq "jikes") {
> 	print CONFIG "JAVAC=$jikes\n";
> 	print CONFIG "JAVAC_CMD=JIKES    \n";
> } elsif ($compiler eq "gcj") {
> 	print CONFIG "JAVAC=$gcjC\n";
> 	print CONFIG "JAVAC_CMD=GCJ [-C] \n";
> } else {
> 	bail "failed", "INTERNAL ERROR no compiler selected.";
> }
> output "$compiler\n";
> 
> 
> output "Select runtime:";
> 
> # Note that java is favoured over gij only because the error messages
> # are better! (Ok, and, frankly, the compliance is obviously better
> # if its a real Java VM). The Free ones are getting there...
> 
> if ($runtime) {
> 	# if overridden, check override...
> 	if ($runtime eq "java")  {
> 		bail "bad override", "java specified but not detected." unless $java;
> 	} elsif ($runtime eq "gij") {
> 		bail "bad override", "gij specified but not detected." unless $gij;
> 	} elsif ($runtime eq "kaffe") {
> 		bail "bad override", "kaffe specified but not detected." unless $kaffe;
> 	} else {
> 		bail "bad override", <<HERE ;
> You specified runtime=$runtime on the command line, but that's not an option.
> Valid choices are java, gij, or kaffe - but of course that virtual machine
> must be installed (and detected!) before you can specifiy it.
> HERE
> 	}
> 
> } else {
> 	if ($java) {
> 		$runtime = "java";
> 	} elsif ($gij) {
> 		$runtime = "gij";
> 	} elsif ($kaffe) {
> 		$runtime = "kaffe";
> 	} else {
> 		bail "failed", "No usable Java runtime environment was detected.";
> 	}
> }
> 
> if ($runtime eq "java") {
> 	print CONFIG "JAVA=$java\n";
> 	print CONFIG "JAVA_CMD=JAVA     \n";
> } elsif ($runtime eq "gij") {
> 	print CONFIG "JAVA=$gij\n";
> 	print CONFIG "JAVA_CMD=GIJ      \n";
> } elsif ($runtime eq "kaffe") {
> 	print CONFIG "JAVA=$kaffe\n";
> 	print CONFIG "JAVA_CMD=KAFFE    \n";
> } else {
> 	bail "failed", "INTERNAL ERROR no virtual machine selected";
> }
> output "$runtime\n";
> 
> `rm Hello.java Hello.class`;
> 
> 
> # --------------------------------------------------------------------
> # Done! Create .config file
> # --------------------------------------------------------------------
> 
> output "Write .config file:";
> close CONFIG;
> system "mv .config.tmp .config";
> 
> output "ok\n";
> output "\n";
> 
-- 
Ray Auge <ra...@do...>