geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: Restructuring trunk (LONG)
Date Tue, 10 Apr 2007 14:08:33 GMT
Inline below...

-Donald

Jason Dillon wrote:
> 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).
> 

Have you looked at the Maven Proxy project?
    http://maven-proxy.codehaus.org/

We're using it for internal builds of Geronimo and it works nicely for 
everything except SNAPSHOTS, which you either have to configure it to 
always or never look for new artifacts, which is not a dynamic 
configuration setting.  Other that that, its great, because it lets me 
create a settings.xml for m2 that says its a mirrorOf * and then I can 
configure the proxy (which is just a servlet I have running in Tomcat 
5.5) to specify exactly which order of local rsync mirrors (either 
available thru HTTP or local file:// access) and remote/live repos to 
search for artifacts.


>>> 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
> 
> 
> 
> 

Mime
View raw message