harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: where to put tests?
Date Thu, 22 Dec 2005 14:06:47 GMT
Geir Magnusson Jr. wrote:
> This is sort of the way I'm familiar with, but a little different to 
> ensure that all tests are in a separate tree.  This is closer to your 
> option 2.
> 
> I mean :
> 
> java-src/
>    src/
>        archive/
>           org/
>             apache/
>               harmony/
>                  classlib/
>                      archive/
>                          Foo.java
>        luni/  <- peer to archive...
>        net/
>        ...
>     test/    <- peer to src
>        archive/
>            org/
>             apache/
>                harmony/
>                   classlib/
>                       archive/
>                            TestFoo.java
>         luni/
>         net/
> 
> It's fairly easy to handle when packaging as you can package the  entire
> test/ tree separate from src/ w/ no problems.  It's also a  fairly
> common convention around here

Ok, this is the branch the tests lower in the repository tree, and
maintain a parallel component hierarchy below that ...

> - the only diff from what I've  worked
> with in the past is there is a module-like architecture w/o  java-src,
> namely the segmentation by archive, net, luni, etc.
> 
> 
> What I'm used to, using the names we have is something like
> 
> modules/
>    luni/
>      src/
>        java/
>        test/
>    archive/
>      src/
>       java/
>       test/
>    net/
>      src/
>       java/
>       test/

... and this is the option to branch the tests higher in the tree,
within the component.  This is ok too.

I would like to accomodate competing component impementations, say
"net/" and "geir's-super-net/" within the same structure -- and be able
to share the API tests.  Just thinking aloud, I guess that simply
becomes a packaging issue, i.e. the ability to run the net-tests.jar
against any build.

> In our case, we have the complication of native code as well.  Does  it
> make sense to commit completely by module, where each module is  has all
> the java, multi-platform native and test code under one root  in the tree?

I had thought about that too, and it's a reasonable goal.  It will take
some major refactoring and makefile hackery, but it is doable.


> modules/
>    luni/
>       src/
>         java/
>            src/
>            test/
>         native/
>            win32/
>               src/
>               test/
>            linux32/
>               src/
>               test/
>            osX/
>               src/
>               test/
>    archive/
>       src/
>         java/
>            src/
>            test/
>         native/
>            win32/
>               src/
>               test/
>            linux32/
>               src/
>               test/
>            osX/
>               src/
>               test/
> 
> And module is every module that we have, like port, launcher, etc.  
> Some don't have Java, but that's ok - you get a very good high-level 
> view of the produced artifacts by looking in the modules directory.
> 
> modules/
>    archive/
>    luni/
>    io/
>    math/
>    launcher/
>     port/
> 
> whatever we come up with.
> 
> Also, it means that if a module has some specific build need, that is 
> handled right there by the build config w/in the module - the build  for
> the classlib is a top level that kicks off each module in a  standard
> way, but then each module build is specific to the module.

Almost, there are dependencies between modules that require a 'global'
view of build, or specific incremental capabilitites of the Java
compiler.  For example, there are cyclical dependencies between LUNI and
SECURITY that means each cannot be built independently of the other.

There are ways to get around this cycle, you can:
 - build everything together, and let the compiler see all types
simultaneously;
 - use the partial compilation capabilities as found in the Eclipse Java
compiler.  This will emit .class files even is some methods do not
compile; then by repeatedly compiling the components you will converge
on a coherent build;
 - use compile-against stub JARs.  Some cycles can be removed by having
empty impl. stubs that define the APIs sinply to allow compilation.  In
general though this won't be guaranteed to remove all cycles.

Once you have done a 'global' build, and put the results into your
target, then you can subsequently compile local changes to components
indpendently against that target.

>  Otherwise,
> we need a global all-knowing build that spans all modules,  which sounds
> like we could run into maintenance problems in the future.

I agree that we should defer as much of the build/packaging into the
components as possible.

> It also means any special test framework for a module is also the 
> business of just that module.

Yes.

> What do you thinK?

Again, no strong feeling about:
  modules/
    luni/
       src/
         java/
            src/
            test/

vs.
  modules/
    luni/
       src/
         java/
            src/
  tests/
    luni/
       src/
         java/
            src/




-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message