RE: Is there any reason we have to resolve dependencies all the t ime?
And for things like creating the dependency classpath? Where Ant removes non-existent files and paths? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Lester Ward <[EMAIL PROTECTED]> wrote on 08/09/2003 11:17:58 PM: > > [EMAIL PROTECTED] wrote: > > > Yes, resolving dependencies all the time is a PITA. > > > > > > What's your suggested alternative? > > My understanding is that the problem is that the plugin manager resolves > dependencies long before any goal is executed. If that's true, I suggest the > following: > > 1) If the plugin manager cannot resolve dependencies, it does .not. > automatically fail the build. Instead, it puts the build into a "bad > dependency" state. > > 2) By default, execution of all goals first checks the "bad dependency" > state. If true, the goal fails. However... > > 3) A goal can be given an attribute that allows it to skip this check and > continue executing, even if "bad dependency" is true. Not many goals could > do this, but clean:clean could. > > - > 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]
Re: Is there any reason we have to resolve dependencies all the t ime?
Cool. Got a patch? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Laird Nelson <[EMAIL PROTECTED]> wrote on 09/09/2003 01:46:09 AM: > Berin Loritsch wrote: > > > Right. However as long as we can merge the dependencies at the proper > > time, we could fix the blind loading and resolving of all dependencies > > until we really need them. > > Yes, that's my point. We're in agreement. > > Laird > > > - > 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]
Re: Is there any reason we have to resolve dependencies all the t ime?
Laird Nelson wrote: Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Yes, that's my point. We're in agreement. :) It appears that there is a post 1.0 fix for the whole mess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Yes, that's my point. We're in agreement. Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
On Mon, 2003-09-08 at 09:33, Berin Loritsch wrote: > Laird Nelson wrote: > > > Andy Jefferson wrote: > > > >> You could take it further and think of the whole issue of dependencies > >> and the fact that there are basically 3 'types' ... build, test, and > >> runtime. > >> > > Or: each plugin has dependencies, and the java:compile one fills its > > dependency list from the POM, the test:* one fills its dependency list > > from some other location in the POM, etc. > > Right. However as long as we can merge the dependencies at the proper > time, we could fix the blind loading and resolving of all dependencies > until we really need them. > > > > > Saying that each plugin can have a dependency but that that dependency > > list can come from anywhere (like the POM, i.e. it doesn't need to be > > hardcoded) allows for more flexibility in the future. > > > > L > > But can Maven be altered so that the dependency won't be resolved unless > it is really needed? Sure it can but for now the plan is to get what we have out as 1.0 as soon as possible. Soon after that is done I will release the componentized version of Maven which is the long-term future of Maven and what the book will be based on. > For example, why with the "clean" target do all the project dependencies > (which don't differentiate as to use) need to be resolved? > > > > - > 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]
RE: Is there any reason we have to resolve dependencies all the t ime?
> 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). There may be plugins that fit into more than one of the "categories". For example, is multiproject a run-time, compile-time or test-time plugin? If you want to go this route, plugins should probably be considered compile-time by default, unless told otherwise. I think my earlier suggestion (which focuses on user-controlled goals rather then "third party" controlled plugins) is both easier and more workable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
Laird Nelson wrote: Andy Jefferson wrote: You could take it further and think of the whole issue of dependencies and the fact that there are basically 3 'types' ... build, test, and runtime. Or: each plugin has dependencies, and the java:compile one fills its dependency list from the POM, the test:* one fills its dependency list from some other location in the POM, etc. Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Saying that each plugin can have a dependency but that that dependency list can come from anywhere (like the POM, i.e. it doesn't need to be hardcoded) allows for more flexibility in the future. L But can Maven be altered so that the dependency won't be resolved unless it is really needed? For example, why with the "clean" target do all the project dependencies (which don't differentiate as to use) need to be resolved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is there any reason we have to resolve dependencies all the t ime?
> [EMAIL PROTECTED] wrote: > > Yes, resolving dependencies all the time is a PITA. > > > > What's your suggested alternative? My understanding is that the problem is that the plugin manager resolves dependencies long before any goal is executed. If that's true, I suggest the following: 1) If the plugin manager cannot resolve dependencies, it does .not. automatically fail the build. Instead, it puts the build into a "bad dependency" state. 2) By default, execution of all goals first checks the "bad dependency" state. If true, the goal fails. However... 3) A goal can be given an attribute that allows it to skip this check and continue executing, even if "bad dependency" is true. Not many goals could do this, but clean:clean could. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
That's impossible. How can the test plugin know what test classes and other jars I need for my code? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Laird Nelson <[EMAIL PROTECTED]> wrote on 06/09/2003 04:45:58 AM: > Andy Jefferson wrote: > > >You could take it further and think of the whole issue of > dependencies and the > >fact that there are basically 3 'types' ... build, test, and runtime. > > > > > Or: each plugin has dependencies, and the java:compile one fills its > dependency list from the POM, the test:* one fills its dependency list > from some other location in the POM, etc. > > Saying that each plugin can have a dependency but that that dependency > list can come from anywhere (like the POM, i.e. it doesn't need to be > hardcoded) allows for more flexibility in the future. > > L > > > - > 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]
Re: Is there any reason we have to resolve dependencies all the t ime?
Andy Jefferson wrote: You could take it further and think of the whole issue of dependencies and the fact that there are basically 3 'types' ... build, test, and runtime. Or: each plugin has dependencies, and the java:compile one fills its dependency list from the POM, the test:* one fills its dependency list from some other location in the POM, etc. Saying that each plugin can have a dependency but that that dependency list can come from anywhere (like the POM, i.e. it doesn't need to be hardcoded) allows for more flexibility in the future. L - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
On Friday 05 Sep 2003 18:30, Lester Ward wrote:
> > For things like "maven clean" resolving the project's
> > dependencies seems like overkill.
>
> Ditto. See my recent post ("Using Reactor") for a good example of why this
> strategy is not very helpful.
You could take it further and think of the whole issue of dependencies and the
fact that there are basically 3 'types' ... build, test, and runtime.
The build dependencies should only be used in the build process (e.g
java:compile)
The test dependencies should only be used in the test process (e.g test
plugin).
The runtime dependencies only used in a runtime-like plugin.
Clean doesn't come into any of those so should do just what it claims to do -
clean out working directories and files.
--
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is there any reason we have to resolve dependencies all the t ime?
> For things like "maven clean" resolving the project's
> dependencies seems like overkill.
Ditto. See my recent post ("Using Reactor") for a good example of why this
strategy is not very helpful.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
