On Apr 9, 2007, at 11:08 AM, Prasad Kashyap wrote:
Went through your (quite interesting) doctoral dissertation and added
some comments inline :-)
:-)
This isn't going to be possible for all of our dependencies, though I
think that if we can move to this model it would help improve the
maintainability of version information. While that information might
not be in one place anymore, I think that it would help improve
things as it will move the relevant versions close to the modules
that actually use them and thus make management of those version much
easier (as well as making it clear where those deps are used). The
top-level pom's dependencyManagement section is quite difficult to
manage at the moment IMO. I think for the most part we can do this
for most feature components, and for situations where other modules
need those deps, it would be best to have dependent modules depend on
the components/*/* module instead of on the dependency directly, and
if needed create modules simply to provide the dependencies for this
reason.
How about the repositories for these dependencies. Do you envisage
these being split up too or maintained in a single place ? Or would
that become a moot point with the impl of a single (dedicated) repo ?
What repositories? Most of these artifacts live in central... and
according to Jason Van Zyl, artifacts in central are never removed.
And he isn't so found of adding extra magical repository bits to
subvert the system.
I was looking at making a magical proxy wagon impl to handle this...
though after talking to Jason more I've pushed off that work, not to
mention that with the current m2 wagon bits, we can't inject custom
handlers for http/https easily, we would have to use a new magical
proxy protocol (only to tell the wagon system which provider to pick
up), and then we'd have to define a new proxy:// repo as central and
then add some magical rewriting of dependency poms to strip out any
repo muck they have... all too complicated IMO.
So for now I'm deferring that work, and for now will try to depend on
central having artifacts that never get lost (which I still have very
mixed feelings about).
I know that some of you might be thinking about that evil windows
path length problem... and its always in the back of my mind...
mostly cursing it for being so dumb, but still its there. And if
that ends up becoming an issue, then I think we should really
consider dropping the org.apache bits from the groupId. But thats
just an idea,
If we ever took this route, then could we put the components under a
"components" name in the groupId ? Eg:
geronimo.server.components.activemq
Sure, I would prefer to use another groupId here, but because of the
stupid long path muck it becomes difficult. Droping "org.apache."
saves us 11 chars, adding "components." tacks on 11 more.
Just a thought. This will make the framework/* and the components/*
modules consistent w.r.t their groupIds. The groupIds can be mapped to
their source dir layout.
Yup. But I fear that we are already pushing the limits... :-\
This will also prevent a proliferation of sub-dirs under the
geronimo.server directory in the m2 local repo.
Eg:
geronimo/server/framework
geronimo/server/javaee
geronimo/server/buildsupport
geronimo/server/testsupport
geronimo/server/components
geronimo/server/activemq
geronimo/server/openejb
Yup, though we are going to have a lot of those anyways... but it is
ideal to keep the structure similar to what the build tree uses,
though I only think that is needed for the first few levels, else the
groupId management gets way out of hand.
It would be nice to keep the artifacts of our logical piece called
components grouped together and by themselves. Just wondering out
aloud.
I'm not sure what you mean exactly... but if you mean to have all of
the activemq related modules under one groupId and openejb under its
own, etc... then ya, that is the idea. Though that will be done
either way... its just a matter of do we call the groupId:
[org.apache.]geronimo.server.activemq
or:
[org.apache.]geronimo.server.components.activemq
<rant>
I really hate to have to make special cases for crappy operating
systems. Thank the gods that winblows can handle longish file names,
else we'd have to make everything 8.3 with cryptic names. Lucky
though that the ms foolios hacked in a translation layer for 8.3 to
longish names years ago. Just too bad they didn't re-write their
shizzle to fix the problem, instead they just put a fat bandaid on it.
</rant>
--jason
