At 06:32 PM 6/1/01 +0100, Jose Alberto Fernandez wrote: >The question for me is how reusable do we want the information in the "peer" >projects to be.
You know I advocate using it as a separate component ;) >In one extreme, if we want it to behave like "include" (not >that I am advocating anything) it will require for the including project to >have access to anything available in the included project. Because it is >like a macro expansion. right - yuck. >What we habe been talking is that <projectref> loads an instantiation of the >project (given the <param>s passed in the declaration). You can access >anything in the namesapace, any properties AND any IDed type instances. If >you can access the instantiated values of a type, then it seems to be a >logical consequence that you may need to have access to the type itself. I am not sure we have 100% decided about accessing of propertys in other projects just yet. At this stage I haven't seen any need for such functionality. >For <tasks> one may have a simillar argument. If you have access to the >targets in the instantiated project, you may also want to have access to the >tasks defined in there. not likely. I don't think any access path should have access to task objects/proxys. We discussed this sort of thing ages ago with respect to scripting using BSF task and it was generally poo pooed ;) >For example a projectref may define a group of libraries that are used for >performing its work. The tasks may be interdependent in the sense of >compatibility between version or what have you. > >I would think, one may want all this things said in just one place, for >maintainability reasons. The referring projects will just use the consistent >by just indirecting on the projectref namespace. I could see a need for centralizing it *if* we were making task definitions not location independent. But I think it would be good to make typedefs position independent. So much like you do "import java.net.URL;" everywhere you need I think the same should apply to build files. The only exception being tasks that are not packaged in an antlib jar - however I think that that is rare case and we shouldn't encourage that sort of behaviour. >> Personally I would prefer namespace resolution for types (and >> aspects) to >> be static "type" information rather than dynamic "instance" >> information. So >> namespace of type would refer to the library it was exported >> from (or a >> user assigned value). >> > >But if you look at <projectref> as static. It is not a task, it is simillar >to <taskdef> but for projects. I know that there is certain dynamic behavior >for <taskdef> and such, but in principle it is defining a static thing that >cannot once defined. Yes - it is an integration of templating into the core ... *shudder*. I am fairly certain I don't agree with your vision ;) >> Can anyone give a good usecase forsharing type defs between >> peer projects? >> > >Does anyone has a good example on when one may need a new type definition? >The predefined ones have been sufficient for me. I would need something like >that first, to be able to come up with an example. ;-) I have a few. I use ant for content creation for a Virtual Environment (think 3d game). This involves tasks for texture manipulation/packing, geometry compiling/manipulation/packing, script compiling/manipulating etc. I have to define all these taskdefs in the the top of my build files. There is a similar case for a specialize build environment for web development. Basically it is manipulating and shuffling web docs around which required some specialized site-specific tasks. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
