Break out TLB into Java and Alien distributions

[GoogleCodeExporter]

Right now we bundle ant, ant-junit, xerces etc that are only used in Java but 
we bundle them in tlb.rb as well.

This increases the gem size and people do not like that. :)

Split our distribution into TLB Java and TLB non-java.

The way this would work out would be:

* Split TLB into 3 modules - core, java and alien.
* Introduce new ivy.xml files that get used to build the given distribution

Original issue reported on code.google.com by itspa...@gmail.com on 7 Feb 2011 at 8:42

[GoogleCodeExporter]

Original comment by itspa...@gmail.com on 7 Feb 2011 at 8:46

[GoogleCodeExporter]

We can split the codebase in 5 modules, 
       common 
        /  \
       /    \
      /      \
     /        \ 
  balancer  server
    / \
   /   \
  /     \
java  alien

'common'   : needs to have things like SuiteTimeEntry, TlbEntryRepository, 
utils etc.
'balancer' : will need to hold algorithms, and tlb.service.Server 
implementations.
'java'     : can hold java support specific code (junit, twist and ant stuff).
'alien'    : can hold BalancingInitializer, TlbClient, *Reporters etc.
'server'   : can hold TlbServerInitializer, TlbApplication, TlbResource(and 
subclasses) etc.

We need to bundle only 'server'(as tlb-server.jar), 'alien'(as tlb-alien.jar) 
and 'java'(as tlb-java.jar). Classes can be flattened out between modules(as 
in, 'balancer' and 'common' classes can be flattened out in 'alien' and 'java' 
jars) and 'common' classes can be flattened out in 'server' as well.

No module other than 'balancer' and 'server' needs to depend on restlet stuff. 
None other than 'java' needs to depend on 'junit' and 'ant-junit'/'ant'.

This should give us smaller jars.

Original comment by singh.janmejay on 12 Feb 2011 at 5:18

[GoogleCodeExporter]

Again, our 'bundling tlb distribution' task depends on this one. But there is 
some more work to to done apart from what comes from this task, so its not 
completely blocked yet.

Original comment by singh.janmejay on 12 Feb 2011 at 5:20

[GoogleCodeExporter]

We should not change any class-names or package-structure because a lot of 
those are referred to by config-env-variable values.

Original comment by singh.janmejay on 13 Feb 2011 at 1:48

[GoogleCodeExporter]

pushed to a different branch called 'modularization'

Original comment by singh.janmejay on 16 Feb 2011 at 11:32

[GoogleCodeExporter]

Original comment by singh.janmejay on 27 Feb 2011 at 12:58

[GoogleCodeExporter]

Original comment by singh.janmejay on 27 Feb 2011 at 12:58

• Changed state: Fixed