Hi Brian, Brian E. Fox wrote on Thursday, January 18, 2007 7:53 AM:
> I guess I'm a little behind in this thread: > > 1st, I think dependency:list is effectively the same as the > existing dependency:resolve is it not? The artifacts need to > be resolved if you are going to include transitive stuff. Yes, quite similar. It just that you imply with "resolve" also the scope "test". So dependency:resolve would be equal to dependency:test -Dtype=list > 2nd, I like this suggestion best so far: > "dependency:<scope> -Dtype=<list|tree> > > then everybody has the possibility to configure a property in > his settings for the preferred view type ..." > > Although I'm on the fence about having to make a separate > goal for each. I think this is still very close to resolve. > It would be nice if there was a way to alias a goal to > something that exists and default the params without having > to create a whole new class. Yes. Definitely. Maybe it's already possible and we just did not find out. Don't know Plexus descriptor enough. OTOH the classes are quite lightwight i.e. have simply a ctor with default params for the super class. > The existing resolve goal needs to be tweaked a little to > allow it to function even if some artifacts can't be resolved > (a fail at end essentially) since its initial reason for > existence was to quickly force a download of everything > needed for going offline, or to test proxies etc. If you do > this on a tree that has internal dependencies, it will die > out before it completes unless you have already built it > (negating most cases of needing to resolve). Skipping those > artifacts would work around it. The change needed is to > remove the requiresDependencyResolution flag and > programaticaly resolve them...the code already exists since > the copy/unpack goals do it anyway. Good info. Thanks. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
