Greetings, all,
So, in a fit of productivity, I refactored all 110,000 lines of Hackystat code in the
last 36 hours.
Really. I'm not kidding. :-)
Yes, I had a little help from the Eclipse refactoring tool. To implement the Version 7
architecture (available at
<http://hackydev.ics.hawaii.edu/hackyDevSite/doc/BuildSystem.html>), the package
associated with every single file in the system has to change. This has a tremendous
ripple effect, because that in turn implies that every single import statement in the
system has to be changed. (Other things have to change as well, but you get the idea.)
The way I decided to deal with this was to create a new Eclipse project called
V7Hackystat whose src directory would contain the sources for all 30+ modules in
hackystat-ALL, and whose lib/ directory would contain all of the library jar files needed
to compile the whole thing. (Actually, I defined a classpath variable ANT_HOME and
JBUILDER_HOME for those two kinds of libraries, but everything else I just stuck in the
lib folder).
When I finally got this project organized and compiled, there were around 350 packages to
deal with. I then started going through and using the Eclipse refactoring menu to rename
packages and, in certain cases (for example, the hackyTelemetry.reducer.impl directory),
moving individual classes from one package to another. After finishing, the package
structure looks like:
org.hackystat.core.common.*
.installer.*
.kernel.*
.report.*
.telemetry.*
org.hackystat.sdt.activity.*
.baddata.*
.bufftrans.*
.build.*
.cli.*
.commit.*
.coverage.*
.dependency.*
.filemetric.*
.issue.*
.perf.*
.reviewactivity.*
.reviewissue.*
.unittest.*
org.hackystat.sensor.bcml.*
.build.*
.cccc.*
.cli.*
.cppunit.*
.cvssensor.*
.dependencyfinder.*
.eclipse.*
.emacs.*
.jblanket.*
.jbuilder.*
.jira.*
.junit.*
.jupiter.*
.loadtest.*
.locc.*
.office.*
.vim.*
.visualstudio.*
org.hackystat.app.buildanalysis.*
.cgqm.*
.cocomo.*
.course.*
.experiment.*
.hpcs.*
.mds.*
.pri.*
.prjsize.*
.review.*
.stdcmd.*
.tdd.*
.zorro.*
What's cool is the top four levels of the package hierarchy as displayed above tell you
what module the code lives in (and, vice versa---given the package of any code in the
system, you can determine by looking at the top four levels what module it belongs to!)
Actually, of course, the first two levels (org.hackystat) don't tell you anything. It's
the next two that give the story. Starting with level 3:
org.hackystat.core // the core subsystem--kernel, reports, telemetry, 'common' stuff
like dailydiary etc.
org.hackystat.sdt // where all sensor data type definitions (and SDT-specific
dailyanalysis, dailyprojectdata, etc. live)
org.hackystat.sensor // where sensor code (and related installer definitions
etc live)
org.hackystat.app // applications built on the above.
Add in level 4, and you get the name of a module:
org.hackystat.core.kernel <-> hackyCore_Kernel
org.hackystat.app.tdd <-> hackyApp_Tdd
etc.
There are now, therefore, a grand total of 51 modules in the system. (Given there are 350
packages total, that means that each module has on average 7 subpackages, which kind of
seems reasonable to me.)
Finally, I imported the resulting system into cvs as V7Hackystat. It's 60MB, a little
hefty due to the jar files, but what's nice about it is that you can check it out and see
what the Version 7 module/package structure will look like.
Some caveats:
- This code does compile, but it's guaranteed not to test correctly! I am sure there are
additional edits that need to be done to make things work.
- There is no build system, no local.build.xml, etc. My goal with this exercise was to
provide us all with the Java files associated with each module with all of the package
and import statements correct for version 7. The next step will be to manually create
each module with the appropriate src and build files and import it into the new svn
repository, and use the new build system to test it out.
I am going to start on the SVN stuff next. There are two basic repository structures to
choose from:
(1)
trunk/hackyCore_Kernel
hackyCore_Report
:
branch/hackyCore_Kernel
hackyCore_Report
:
tags/hackyCore_Kernel
hackyCore_Report
:
or, alternatively,
(2)
hackyCore_Kernel/trunk
/branch
/tags
hackyCore_Report/trunk
/branch
/tags
I am leaning toward (1), since branches and tags are cheap in svn and since, in many
cases, you'd like to branch/tag the whole repository. If you have ideas about this,
definitely let me know.
I am going to spend the next several days working on getting org.hackystat.core.*
imported into SVN and running under the new build system. At that point, I will
hopefully understand the issues involved and we can have a meeting to decide how to split
up the remaining 45 modules.
BTW, one of the things you can do is use the V7Hackystat project as a way to manually
track changes you are making to your own code. So, if you want, you take changes you're
making to the version 6 system, manually add them into V7Hackystat (making sure the
results compile, at least), and then commit the changes. That way they'll be there when
someone comes back to that part of the system to use as the basis for constructing a
version 7 module.
Let me know if you comments, questions, or concerns about the above. I can't wait until
we're using this new structure.
Cheers,
Philip
