[geclipse-dev] Re: Missing tests

[Markus Knauer <mknauer@xxxxxxxxxxxxxx>]

some comments below... 

I moved this discussion to geclipse-dev; maybe it is getting interesting for 
others.

Markus

On Wednesday 28 May 2008, Ariel Garcia wrote:
> > David suggests [1] to use plug-ins instead of fragments, but I think
> > this is not the way to go in our case because we had reasons to use
> > fragments (some of our testcases are accessing package-private methods
> > and fields) OR to split eu.geclipse.test into a part *without* and a
> > part *with* dependencies. Maybe this will work, but Andrew came up with
> > another solution...
> >
> > In [2] he mentioned the new build property "allowBinaryCycles=true" that
> > has been introduced in Eclipse 3.4. This should make our problem
> > solvable (it doesn't solve it out-of-the-box, but it makes it
> > 'solvable'), but it includes a move from 3.3 to 3.4, which is a major
> > task and cannot be done within a day.
> > 
> > [1] http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00665.html 
> > [2] http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00666.html
>
> yes, i saw those emails...
> well, IF we could switch the build system to Ganymede while keeping Europa
> as the "default" platform, then that would be a really nice alternative,
> because it would allow us to simplify the mess a lot...
>  -> for each plugin a Test Fragment  which can test internals and also
> depend on the e.g.test plugin...

Maybe it is much easier as it looks on a first glance. We have that separated 
in the build:

/data/buildspace/targets contains the targets that are used to compile 
against -> at the moment 3.3.1.1 and that could stay at that level.

/data/buildspace/buildeclipse contains the Eclipse that is used to build 
g-Eclipse against the target. In the end, this is the one that needs to be 
updated to a decent 3.4 Eclipse SDK.

> Well, that would produce packages with 3.4 per default... but so what...
> end on June is the 3.4 release so it should be fine...

The packages are created by their own application (/data/buildspace/epp) using 
the Europa features mirrored to /data/mirror/download.eclipse.org. I wouldn't 
change that either.

> As i didn't try gEclipse with 3.4 yet i have no clue how many problems to
> solve would appear, switching the build system would not be a big issue
> (but not a reasonable target before the review anyway)

I know *some* problems, because I already switched many times to the latest 
3.4RC build of the platform. That leads to the situation, that I have 
currently no working g-Eclipse environment, but this is another issue and my 
fault. :(

> Otherwise, if we have to keep 3.3... the current structure is quite ugly...
> because we (can) have for each {plugin}.{package}.{class}
> a test in
>    {fragment}.{package}.{class}_PDETest
> and a test in
>    eu.geclipse.test.{package}.{class}_PDETest
> We could have two bundles for each plugin, a  one a test fragmet and one a
> test plugin, but that doesn't make things much nicer either...

Yes, fully agreed.

> So we could say: we give 3.4 a try after the review, and see, but the
> tests... we would need to move them around (to e.g.test) until the build
> is ready or wait...

Maybe we should try it after the milestone release on Friday, and maybe it is 
less work than expected (okay, I am dreaming).