How many different <depType>s do you see. >From what you've described before, it looks like almost one per plugin. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
news <[EMAIL PROTECTED]> wrote on 08/09/2003 11:41:30 PM: > [EMAIL PROTECTED] wrote: > > > Yes, resolving dependencies all the time is a PITA. > > > > What's your suggested alternative? > > > > Do plugins declare whether they need the dependencies? > > Some other method of us guessing? > > If the project dependencies list had a clue as to which > type of dependency they are, then they can be resolved > occordingly. > > As one person rightfully pointed out, there are runtime, > build time, and test time dependencies. There may be more, > (possibly a packaging time?), but for the sake of simplicity/ > discussion that should be enough. > > The java:compile and test:compile would resolve all the > dependencies necessary for it at that time. That can either > be done by having different dependencies sections like this: > > <buildDependencies/> > <testDependencies/> > <runtimeDependencies/> > > Or it can be done something like this: > > <dependencies> > <dependency> > <depType>build</depType> > <!-- ... --> > </dependency> > </dependencies> > > Either way, the project specific dependencies would not > need to be resolved until the proper plugin needed them. > The **:compile plugins would grab the build dependencies > plus whatever else it needed (like test dependencies for > the test:compile). > > In the end, it is (conceptually speaking) not difficult. > Not having messed with much of the code, I cannot vouch > for the technical aspects of it. > > > > --------------------------------------------------------------------- > 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]
