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: [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]
