geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Restructuring trunk (LONG)
Date Mon, 09 Apr 2007 22:36:54 GMT
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:




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.


View raw message