Ah, I think I see what your reading from my comments and I don't mean
what you're thinking, ie not producing separate patchable jars and
having one monolithic build file. That would be suicide!
Just to be clear what I'm saying, those single file system projects I
have worked on are absolutely split up into components that can be
used in other projects and build and tested separately and self
contained- they are just jar files. However this is achieved solely
by the package name, ie everything under that package is one
component eg
com
----acme
--------gui (gui.jar)
--------model (model.jar)
--------util (util.jar)
So only the deployers know that their jar files map onto the above
packages, but the developers don't even care. They're just worried
about the code tree. I don't know the experiences of folk here, but
the details of the build files are of little consequence to about 90%
of developers on a project, other than the fact that there is this
funny build file that has to complete successfully before you are
allowed to check in. Relative to Maven I'm the same: I really don't
care which jar file contains the plugin class that's throwing an
exception, I just want to find it quickly by pressing (shift+apple+n)
so that I can see what the problem is.
What I've been trying to do is to place a pom where you see a jar so
that you could instantly see which packages correspond to deployable
elements at a glance.
A horror story for you: I worked on one project where the build.xml
file was autogenerated by velocity and was over 3000 line long and
growing. Every time you added a top level package to your source tree
it would grow some more by copying a set of tags at the end.
Eventually there was noone on the project left that knew much about
how it worked!
Honestly though I don't wish to advocate one way over the other.
On 8 Sep 2005, at 16:28, John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comments inline.
Cheers,
john
Ashley Williams wrote:
| Hi John,
|
| Looking forward to the properties code btw
It's in. Good luck! :)
<snip/>
| I won't lecture you on the ins and outs of modular source trees -
I'm
| sure you know already - but I will mention one specific point, for
| clarity. Having a monolithic source tree has a rather dramatic
ownership
| cost. It means that everyone working on it must be concerned with
| regressions across the tree, and it hides what would otherwise be
| reusable and generally useful functionality from groups outside
the team
| members that maintain that codebase. Therefore, for the longer term,
| it's better to chop this stuff up and make a series of finer grained
| artifacts that encapsulate some coherent, sane set of functionality.
|
|
|> Not sure I agree with your original assumptions. The java package
|> namespace is one thing and the carving up into component jar
files etc
|> is another. The package namespace is monolithic whichever way
you look
|> at it, ie it's always going to be one package tree. Having one
or many
|> filesystem trees won't affect the source code authors one jot,
but it
|> will have an impact how the deployment team go about their
business. Eg
|> they will dictate that a certain file structure convenient for
the jar
|> command (multiple fs trees), or they will apply some filtering
rules
|> (single fs tree). Yeah I know, the deployer is just the coder in a
|> different hat ;)
Have you ever looked at the Spring source tree? Or the Eclipse one?
While it might make complete sense browsing the class hierarchy in any
of the jars created by either of these projects, trying to understand
where these jars come from the source tree is an exercise in
frustration. While the package namespace is monolithic, splitting
these
projects into pieces would provide a clear, targetted way of finding,
building, and maybe patching/fixing the source code for a given
jar. It
makes parallel release cycles simpler, too, since the whole monolithic
project doesn't have to pass tests in order to release a revision
on one
subset of the functionality. This isn't just a deployment issue, it's
about the entire development approach. If you have multiple teams
working on multiple deadlines which will result in releases of their
respective code - potentially at different times - why would you want
that code to reside in the same monolithic codebase? If you're
assuming
a single release cycle for all artifacts produced from that codebase,
isn't it reasonable to assume that some of that huge codebase could be
reused in different projects, and that that reuse might uncover patch
scenarios and a separation of the release cycle for that artifact? If
you don't have separate release cycles per artifact, the only other
scenario I can think of for producing multiple artifacts is separation
across a client/server type boundary...which is the only long-term
legitimate use case for filtered compiles that I've heard, IMO.
Short-term practicality notwithstanding, of course. :)
|
|> For me I don't care whether the code is in a database, single fs
tree
|> or multiple fs trees or even accessed through jndi, but I do
disagree
|> that splitting up your filing system along the lines of your
component
|> distribution is automatically a wise thing to do for any given
project.
Splitting of a codebase has the same pro- arguments as splitting up
the
java packaging structure. There may be reasons for putting all classes
in the default package '.' but I haven't heard them...beyond the
ever-present short-term need to "just get it working." I'm not making
any assertion about automatic or absolute, just arguing from my own
experiences.
<snip/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDIFiNK3h2CZwO/4URAoxLAJ9uxhERzVelnCubCYQ+scfPxZ83qQCeLQlZ
iRxxX7F1s5x/hA1fsIWaFm8=
=Lsbu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
