Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » Java
  • » Current status of your swt-gtk package [RSS Feed]

#1 Oct. 5, 2005 18:44:48

Shaun J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


2005/10/2, Michael Koch <>:
> Hello Shaun,
>
> as we spoke some time ago you wanted to get your swt-gtk packages to
> testing and then supersede them by the ones generate from the new
> Eclispe 3.1 (3.1.1 in the meanwhile). My packages are ready and
> gracefully work as a replacement to your packages. While doing this work
> I checked your package and saw that it violates the Debian Java Policy
> in more then one way. Sure, the things are easy to fix. I just wonder if
> you or we should put work into this and then throw it away later.
>
> At DevJam meeting I spoke with several people about the situation.
> They all think we should replace the existing swt-gtk package as soon as
> possible to give it enough time to stabilize and get testing through a big
> userbase before the next release of Debian. Whenever that will happen.
>
> What's your opinion about this now?
>
> Cheers,
> Michael

Billy Biggs, an SWT developer, is working on producing a separate SWT
source package.

2005/9/14, Billy Biggs <>:
> I'm dorking away at the autoconf'ed SWT download now. It's going
> well, won't be hard, etc etc. I did take a look at the SWT package of
> 3.1 and have a bunch of quick comments.

When this work is complete and SWT is its own package, I believe it
would be best to maintain SWT in its own proper Debian source package.

If you would like to expand on the Debian Java Policy violations, I
would be happy to hear them.

Cheers,
Shaun

Offline

#2 Oct. 5, 2005 19:22:13

Billy B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


Shaun Jackman ():

> > as we spoke some time ago you wanted to get your swt-gtk packages to
> > testing and then supersede them by the ones generate from the new
> > Eclispe 3.1 (3.1.1 in the meanwhile). My packages are ready and
> > gracefully work as a replacement to your packages. While doing this
> > work I checked your package and saw that it violates the Debian Java
> > Policy in more then one way. Sure, the things are easy to fix. I
> > just wonder if you or we should put work into this and then throw it
> > away later.
> >
> > At DevJam meeting I spoke with several people about the situation.
> > They all think we should replace the existing swt-gtk package as
> > soon as possible to give it enough time to stabilize and get testing
> > through a big userbase before the next release of Debian. Whenever
> > that will happen.
> >
> > What's your opinion about this now?
>
> Billy Biggs, an SWT developer, is working on producing a separate SWT
> source package.

Shaun and Michael,

I'm sort of torn on this issue myself though.

- In my opinion, SWT should have a source download that is more easily
buildable, and so I'm working on this.

However, the Eclipse srcIncluded zip is maybe better for this as it
is now.

- The SWT plug-in is different in its filesystem layout in the
Eclipse plugins folder than the standalone SWT.

However, the source code is clearly the same, and it is easy to
create SWT source packages since its only the final filesystem
layout that differs.

So regardless of what you guys want to do, know that I don't really
have a strong opinion on the matter. I think if it were up to me, I'd
just go with Michael's packages since I think it will be easier to
coordinate fixing bugs.

-Billy


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

Offline

#3 Oct. 9, 2005 23:02:10

Michael K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


On Wed, Oct 05, 2005 at 01:03:33PM -0500, Billy Biggs wrote:
> Shaun Jackman ():
>
> > > as we spoke some time ago you wanted to get your swt-gtk packages to
> > > testing and then supersede them by the ones generate from the new
> > > Eclispe 3.1 (3.1.1 in the meanwhile). My packages are ready and
> > > gracefully work as a replacement to your packages. While doing this
> > > work I checked your package and saw that it violates the Debian Java
> > > Policy in more then one way. Sure, the things are easy to fix. I
> > > just wonder if you or we should put work into this and then throw it
> > > away later.
> > >
> > > At DevJam meeting I spoke with several people about the situation.
> > > They all think we should replace the existing swt-gtk package as
> > > soon as possible to give it enough time to stabilize and get testing
> > > through a big userbase before the next release of Debian. Whenever
> > > that will happen.
> > >
> > > What's your opinion about this now?
> >
> > Billy Biggs, an SWT developer, is working on producing a separate SWT
> > source package.
>
> Shaun and Michael,
>
> I'm sort of torn on this issue myself though.
>
> - In my opinion, SWT should have a source download that is more easily
> buildable, and so I'm working on this.
>
> However, the Eclipse srcIncluded zip is maybe better for this as it
> is now.
>
> - The SWT plug-in is different in its filesystem layout in the
> Eclipse plugins folder than the standalone SWT.
>
> However, the source code is clearly the same, and it is easy to
> create SWT source packages since its only the final filesystem
> layout that differs.
>
> So regardless of what you guys want to do, know that I don't really
> have a strong opinion on the matter. I think if it were up to me, I'd
> just go with Michael's packages since I think it will be easier to
> coordinate fixing bugs.

I dont know what to do. My opinion would be to build all from the
eclipse source to make sure both eclipse and swt have the same versions.
Eclipse is a critical application. We need to make sure it works. It
would not be too difficult to produce both layouts from one source like
eclipse.


Until we have a real solution I will do a (sponsored) upload of Eclipse
3.1.1-1 to the Debian archive to get more feedback and be able to use the
Debian BTS for bug/wishlist/patch tracking. This eclipse will contain
its own SWT packages which just Conflicts with Shauns. No Replaces. Both
will reside in the archive. They can just not get installed both at the
same time. We (my sponsor and I) will upload Eclipse to the contrib section
for now as it depends on lucene and tomcat5 which are still in contrib.
When both have moved to then main section we will move Eclipse to the main
section too. No showstopper then anymore.


Cheers,
Michael
--
Escape the Java Trap with GNU Classpath!http://www.gnu.org/philosophy/java-trap.htmlJoin the community athttp://planet.classpath.org/--
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Offline

#4 Oct. 9, 2005 23:45:44

Andreas P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


On 10.10.05 00:01:02, Michael Koch wrote:
> We (my sponsor and I) will upload Eclipse to the contrib section for
> now as it depends on lucene and tomcat5 which are still in contrib.

I'm curious: Why does Eclipse depend on tomcat5? At least the binaries
from eclipse.org don't need it.

Andreas

--
You are wise, witty, and wonderful, but you spend too much time reading
this sort of trash.

Offline

#5 Oct. 10, 2005 03:26:01

Barry H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Pakulat wrote:
> On 10.10.05 00:01:02, Michael Koch wrote:
>
>>We (my sponsor and I) will upload Eclipse to the contrib section for
>>now as it depends on lucene and tomcat5 which are still in contrib.
>
>
> I'm curious: Why does Eclipse depend on tomcat5? At least the binaries
> from eclipse.org don't need it.

Eclipse binaries don't depend on it because they bundle Tomcat within
themselves, like they do nearly everything else except the JDK. They
use an embedded Tomcat 4; we use tomcat5 because it was much closer to
moving to main than tomcat4. Tomcat is used as the help engine when you
view Eclipse's internal help.

Regards,
- --
Barry Hawkins
site: www.bytemason.org
weblog: www.yepthatsme.com

Registered Linux User #368650
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -http://enigmail.mozdev.orgiD8DBQFDSdEoHuKcDICy0QoRAqPKAKCIiw8WM2ZlU379O/msuDd2cWNRUwCg5ZGp
c9u/XJsKlK9iLSgnSaUbl3U=
=LOS9
-----END PGP SIGNATURE-----


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

Offline

#6 Oct. 10, 2005 03:57:31

Billy B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


Andreas Pakulat ():

> On 10.10.05 00:01:02, Michael Koch wrote:
> > We (my sponsor and I) will upload Eclipse to the contrib section for
> > now as it depends on lucene and tomcat5 which are still in contrib.
>
> I'm curious: Why does Eclipse depend on tomcat5? At least the binaries
> from eclipse.org don't need it.

My understanding is this:

The binaries from eclipse.org include Tomcat4, it is used to run the
help server. Some part of tomcat4 requires non-free tools to build, and
so is not included in debian. There are two options: rip out the
non-free part of tomcat4 (the part isn't used by Eclipse) or update
Eclipse to tomcat5 and patch any broken pieces there.

-Billy


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

Offline

#7 Oct. 10, 2005 06:10:07

Michael K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


On Sun, Oct 09, 2005 at 09:41:51PM -0500, Billy Biggs wrote:
> Andreas Pakulat ():
>
> > On 10.10.05 00:01:02, Michael Koch wrote:
> > > We (my sponsor and I) will upload Eclipse to the contrib section for
> > > now as it depends on lucene and tomcat5 which are still in contrib.
> >
> > I'm curious: Why does Eclipse depend on tomcat5? At least the binaries
> > from eclipse.org don't need it.
>
> My understanding is this:
>
> The binaries from eclipse.org include Tomcat4, it is used to run the
> help server. Some part of tomcat4 requires non-free tools to build, and
> so is not included in debian. There are two options: rip out the
> non-free part of tomcat4 (the part isn't used by Eclipse) or update
> Eclipse to tomcat5 and patch any broken pieces there.

The second option was done long ago, originally for Fedora.


Cheers,
Michael
--
Escape the Java Trap with GNU Classpath!http://www.gnu.org/philosophy/java-trap.htmlJoin the community athttp://planet.classpath.org/--
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Offline

#8 Oct. 18, 2005 22:13:09

Joe S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


Michael said:The second option was done long ago, originally for Fedora.It would be the best if Eclipse.org just moved up to tomcat5. The moredebian's eclipse deviates from upsteam the more of a pain it is on both thedebian maintainer and on upstream.Off topic but just to throw this out, this would seem to be the best (interms of speed) theoretetical JVM:This a a merged static and dynamic compilation system that gains speed inechange for a (slight?) increase in processor usage, resource usage, anddiskspace usage.A static compiler that can optionally embed code for profiling which canthen be used for later static recompiling, which would re-optimize based onthe code paths most used (think like what gcc can do with '-fprofile-arcs').The static compiler would also optionally be able to embed enoughinformation to allow the dynamic ahead-of-time compiler (no, that is not atypo, read on) to re-optimize.The resulting binaries would be linked to a dynamic compiler. The dynamiccompiler would be able to JIT compile java code as is needed. The resultingnative code would be cached, and stored to disk. While the program is idlethe dynamic compier can perform ahead-of-time compilation of bytecode, aswell as reoptimize the existing machine code it generated based on profilinginformation, as well as staticly compiled code that had the nessesaryinformation embeded. (In the case of the native code geneated by JIT thatinformation is can be gleamed from the original bytecode, which is not thecase with staticly compiled code, so any needed information would need to beembeded.)Obviously the dynamic compiler could also be used to run java code directly,and an interface for doing so should be provided.(This mostly describes 'Excelsior JET', although I'm not sure that thatsystem supports dynamic reoptimization of the executables generated by thestatic compiler.)--
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Offline

#9 Oct. 19, 2005 06:24:14

Michael K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


On Tue, Oct 18, 2005 at 04:55:07PM -0400, Joe Smith wrote:
>
> Michael said:
> >The second option was done long ago, originally for Fedora.
> >
> It would be the best if Eclipse.org just moved up to tomcat5. The more
> debian's eclipse deviates from upsteam the more of a pain it is on both the
> debian maintainer and on upstream.

We used tomcat5 when packaging Eclipse 3.1(.1) as its the only version
we can bring into Debian main. Upstream still uses tomcat4 due to some
reasons. We cant from the legal point of view.

> Off topic but just to throw this out, this would seem to be the best (in
> terms of speed) theoretetical JVM:
>
> This a a merged static and dynamic compilation system that gains speed in
> echange for a (slight?) increase in processor usage, resource usage, and
> diskspace usage.
>
> A static compiler that can optionally embed code for profiling which can
> then be used for later static recompiling, which would re-optimize based on
> the code paths most used (think like what gcc can do with
> '-fprofile-arcs'). The static compiler would also optionally be able to
> embed enough information to allow the dynamic ahead-of-time compiler (no,
> that is not a typo, read on) to re-optimize.
> The resulting binaries would be linked to a dynamic compiler. The dynamic
> compiler would be able to JIT compile java code as is needed. The resulting
> native code would be cached, and stored to disk. While the program is idle
> the dynamic compier can perform ahead-of-time compilation of bytecode, as
> well as reoptimize the existing machine code it generated based on
> profiling information, as well as staticly compiled code that had the
> nessesary information embeded. (In the case of the native code geneated by
> JIT that information is can be gleamed from the original bytecode, which is
> not the case with staticly compiled code, so any needed information would
> need to be embeded.)
>
> Obviously the dynamic compiler could also be used to run java code
> directly, and an interface for doing so should be provided.
>
> (This mostly describes 'Excelsior JET', although I'm not sure that that
> system supports dynamic reoptimization of the executables generated by the
> static compiler.)

Excelsior JET is not free we cant use it. If you want somethink like
this to be used for eclipse please start reading the GCJ mailing lists
and start hacking on it. There is much stuff to do before we can even
think about your proposal. As always patches are welcome. ;-)


Cheers,
Michaeö
--
Escape the Java Trap with GNU Classpath!http://www.gnu.org/philosophy/java-trap.htmlJoin the community athttp://planet.classpath.org/--
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Offline

#10 Oct. 19, 2005 23:10:28

Joe S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Current status of your swt-gtk package


"Michael Koch" <> wrote in messageOn Tue, Oct 18, 2005 at 04:55:07PM -0400, Joe Smith wrote:Michael said:
>The second option was done long ago, originally for Fedora.
>
It would be the best if Eclipse.org just moved up to tomcat5. The moredebian's eclipse deviates from upsteam the more of a pain it is on boththedebian maintainer and on upstream.We used tomcat5 when packaging Eclipse 3.1(.1) as its the only version
we can bring into Debian main. Upstream still uses tomcat4 due to some
reasons. We cant from the legal point of view.I understand that. What I was saying is that it seemed odd that upstream hadnot done this. It may be a wise dea to prod upstream and see if they willupdate for 3.2. I doubt the breakage is too severe.Also is the tomcat package in debian formated correctly to be seen byeclipse? As far as I know Eclipse's tomcat has the plugin metadata included,which i doubt a 'native' tomcat would have.Also, I have half-heartedly followed the drama relating to getting eclipse3.X in Debian. However there are a few small things i seem to have missed.The new packages run on kaffe? (it sounds that way, If you used a differentfree jvm them just 's/kaffe//' for the followingquestions.)Did you remove the depends on an 'offical' JVM, or do 'kaffe|...'?If you removed the depends on the 'offical' JVM rather than make it achoice, please reconsider. Explanation: I have a JVM from sun installed onmy system solely for reasons of practicallity. Since I already have thatinstalled, and that is known to run Eclipse just fine, I do not want towaste space downloading kaffe.--
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Offline

  • Root
  • » Java
  • » Current status of your swt-gtk package [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support