> -----Original Message----- > From: Brian Ewins [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2003 11:36 AM > To: Maven Users List > Subject: Re: Why no multiple locations of sources? ( was Re: > inter-project dependencies for the Eclipse plugin ) > > > Michal Maczka wrote: > > > > But there are even worst cases when pipelining is useless. > > > > E.g. consider following use case > > > > 1) First run of Maven : > > I start XDoclet it creates some classes and updates java path > for the rest > > of plugins (e.g. javac) > > > > 2) Second/Third etc.. run of Maven > > I don't want to regenerate one more time XDoclet stuff .. but I > want to have > > the source previously generated visible in my path. > > That would be handled exactly as it is now, I'm not sure I see your > point? i.e., each plugin in a pipeline invokes its dependents, which end > up doing nothing because their output already exists? The pipeline is > not passing the file contents (I guess this might be what you're > thinking?), only data structures (eg FileSets) which allow you to get > access to the files. >
Yeap you right. And I guess that I am right too ... becouse I believe that, we alredy have a workflow of goals in Maven. The problem I see is that Maven is in a big part implemented in scripting language. This is hugh adavatange for a lot of things, but this is also is a cause of many weeknesess of Maven. You want to have goals which are formaly declaring what thay return/modify etc. I think that such things are getting too be to complicated to be really maintanable. > > > > The only way it can be handled properly is to make it on plugin level. > > So plugins like XDoclet should be equipped with some hooks for > making such > > things > > and hide some details into which directories they will put > their sources. > > All I am suggesting is that saying 'goal A depends on goal B' generally > means 'goal A depends on the /output of/ goal B'. At the moment, B knows > where its output went, but A is just guessing. So we require A to have > knowledge of how B works in order to get hold of B's data. That hides > /less/ about which directories B uses than my suggestion. > so basically B should not update the path. and in A (when needed)you should use something like: B:getUpatedOutputPath() which will "black-box" what B does to the output > The 'official' way to deal with code generators is to chuck their output > into the 'global list of sources'. Are we suggesting global variables > are a good thing? >Also, this mechanism only deals with .java files - > there is no equivalent fat pipe for documentation etc AFAIK. (BTW this > can also be seen as inverting the problem in the previous para - now B > knows how A works and is pushing its data at A) > There are always some global variables. E.g worflow information are globals I think that you are just speaking about making the same sort of things in a diferent way - e.g through more formal set of APIs. But I think that those things really are alredy in Maven! My idea of reorganizing the sources' meta information was aiming at exactly the same goal: unification of the workflow. It is usually easier to work with one common abstraction then with couple simmilar things (like now we have 4 types of different sources, javaclass path and probably other things) > There also seems to be a clash with the Inversion of Control > principle[1] here: either A is pulling data from B, or B is pushing data > at A (or equivalently, A pulls from a global, B pushes to a global). It > should be the framework telling A what files to process, which happens > to include the output of B because the current 'flow' declares that > dependency. > > To some extent I'm echoing Bob McWhirter here, and suggesting that > "everything is workflow"[2] - including maven. > > -Baz > Cool sentence! regards (also to Bob!) Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
