Some comments: - Runtime and compile time are rarely different (as far as source compile goes) - I can see Plugin Dependencies as a possible type - Test Time should probably extend runtime.
I like the notion of dependency type. Do you see this as an attribute of dependency? It would be possible to have each type could map to a Class Realm (or class realm reference) - is what your thinking. Plugins, like javac, junit, etc, could have default class realm references. It would then also be possible for each plugin to provide a property that can override this. Default (not explicitly stated) could be 'global' type that is shared across all realms. Is this enough extensibility? This would be nice and could help avoid some of the JAR override collisions occurring in the dependency resolution (that Jason was talking about in Plexus). - Mike P.S. I'm addicted to Maven. I have to get back to work before I lose my job :-) Since I joined this list I barely sleep, and I wake up excited. > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 10:16 PM > To: Turbine Maven Developers List > Subject: Re: POM repository and dependency references > > On Tue, 2003-03-04 at 22:11, Colin Sampaleanu wrote: > > Jason van Zyl wrote: > > > > >On Tue, 2003-03-04 at 21:40, Colin Sampaleanu wrote: > > > > > > > > >>Jason van Zyl wrote: > > >> > > >>>I doubt the full dependency resolution will be in beta-9. We need to > > >>>start pushing POMs into the repository. Once there we can build a > > >>>database of anything related to projects. The top on my list is the > > >>>dependency graph of all projects. > > >>> > > >>What are your thoughts on handling compile-time vs test-time vs run- > time > > >>dependencies. I appreciate the existing dependency system, it's a lot > > >>better than ant with no dependencies at all, but it'd be nice to be > able > > >>to differentiate between the various uses somehow. > > >> > > >Dependencies can state types so we could do anything we like really. > The > > >default type is of 'jar' but we could use a type of 'test'. In the POM > > >currently there is no distinction between compile-time and test-time. > > >This could be changed easily. As for run-time, this is simply the > > >aggregration of compile-time dependencies of the dependencies stated in > > >the source POM. > > > > > >But we could definitely mark them as I don't want to leave people > > >crippled when there are problems with the resolution mechanism. You > will > > >always be able to state things as verbosely as you wish so maybe a > > >'run-time' type could be added for those who don't want to use the > > >transitive dependency resolution mechanism. > > > > > > > > I don't think it's safe to make that assumption that run-time > > dependencies are always the aggregation of the compile-time dependencies > > from the POMs (although it's probably a safe default). While plugins > > normally declare most of the real compile-time only dependencies, you > > could still have a compile-time only dependency for any arbitrary code > > you call from maven.xml (as a hypothetical example, let's say calling > > out to a transform tool of some sort, or to a dependency analyzer, or > > whatever). Even with plugins, sometimes you also need to add a > > dependency to handle a broken plugin that doesn't properly declare it's > > dependencies. > > Obviously this needs to be changed in order for this to work. > > > In an ideal world :-), I'd like to be able to build a related group of > > projects/artifacts, have maven resolve all the compile time > > dependencies, and when the artifacts are in the repository, be able to > > say, that one needs these dependencies to run, and these to run tests, > > etc. I think it's a safe assumption to say that people will come out > > with other dependency categorizations, so the best scheme is one that is > > extensible, and doesn't force duplication of declarations. > > I agree. > > > > > > >The general rule of thumb I follow is to make things as convenient and > > >easy as possible but always allow full verbosity and final control in > > >the POM so a project can decide what they want to do and aren't whacked > > >by any magic behaviour. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: turbine-maven-dev- > [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > --------------------------------------------------------------------- > 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]
