Re: Moving Eclipse-3.3 to tree

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

Jean-Noël Rivasseau wrote:
> Hello all,
> 
> At this point all the dependencies for Eclipse were moved to main tree
> (they use the osgi eclass so they make suitable jars for Eclipse). So
> there is only now for Eclipse itself to be moved there.

Great!

> Just wanted to check that junit-4.4-r1, which was also moved to tree,
> does not trigger circular dependencies anymore (I checked on the
> bugzilla and it seems it is ok).

It really shouldn't now, I fixed all old junit depends to 3.8*. Also the
junit in tree depends on hamcrest-core and not whole hamcrest anymore so
it doesn't pull all the stuff it used to, and which triggered the problem.

> For information I plan to move it as 3.3.1.1 <http://3.3.1.1>, deleting
> the ebuilds in the experimental overlay except the ali_bush latest one
> (-r2).

Any reason to keep it? I doubt but ali_bush please respond. Is it the
timezones making communication hard? :)

> Finally I need advice on the following (which is the only thing left to
> be done on my agenda before putting Eclipse in tree):
> 
> 1) It looks a better Gentoo way (eg, users know about /etc/conf.d, they
> may not know about eclipse.ini)

Yeah but /etc/conf.d is really intended only for services, i.e.
/etc/init.d/*

> 2) It would have a simpler configuration syntax (pure familiar Bash
> syntax resulting in things like ECLIPSE_MAX_MEMORY="128M", whereas the
> syntax in the eclipse.ini file is more obscure even for me - looks like
> there should be one option per line).
> What is your feedback on this? Other options could include sourcing
> ~/.eclipserc, I don't like that much (it would create yet another .*
> file in the home directory). Plus this is probably something to set
> globally on the system.

The usual way for programs is /etc/eclipserc for system-wide and
~/.eclipserc for user overrides. If you could support this, great. Not
sure how much patching is involved to get rid of eclipse.ini and use
this way.

Caster

P.S. Any plans for future splitting eclipse into more pieces? :) We need
separate jface for example. There's already in java-experimental as
result of serkan's effort and his eclipse-rcp.eclass but I still have
doubts about this way of building from the src.zip which is only
intended for source discovery when writing code in eclipse...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHjy9BtbrAj05h3oQRAhU6AKCJvV9EP3UEYRZ1/TR3603g95I0wwCgjl9g
aGHl0+th8DH5U7nyvw89z1M=
=FeBh
-----END PGP SIGNATURE-----
-- 
[email protected] mailing list