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.activemqSure, 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/openejbYup, 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
smime.p7s
Description: S/MIME Cryptographic Signature
