I think it doesn't make sense that you can refer to something about some project without depending on it.
The only use-case I know is when you really only depend on the module, not the project (i.e. the home and srcdir type of references).
ugh. Conceptually, that's a big nono. To me,
repository =~ where one gets stuff
module =~ some pragmatic unit introduced in between a repository and a
project to approximate how old-style (ie cvs, not svn) source
control servers are organised
project =~ the "core unit" of logical software organisation
dependency =~ relationship between projectsA relationship between a project and a module other than the one it is contained in to me signals that that referenced module is some kind of "core unit" integral to software organisation. Meaning the module is-a project. Just have
<repository>
<module>
<!-- nothing interesting here -->
<project>
...
</project>
</module>
<repository>but keep the model simple. Even if the <module/> really is empty. Make sense?
If you need to be aware of the project to do your build, isn't that some form of dependency?
Yes, but maybe a form that is not related to building a project at all.
Right. You might depend on a project because your documentation has hyperlinks to stuff in its javadocs. Who knows? ;)
We used to have such a situation in the dom4j/jaxen situation. dom4j copied parts of jaxen into its own build area (or the other way around, I don't have access to my Gump descriptors right now) and compiled them. So it doesn't depend on the project jaxen, just on the presence of its sources.
good example!
Now, what I'm saying is that dom4j /does/ depend on jaxen, so there is
<project name="dom4j"> <depend project="jaxen"/> </project>
only we need to mark up this dependency, ie
<project name="dom4j"> <!-- dom4j needs to get access to jaxen sources --> <depend project="jaxen" type="src" id="homedir"/> </project>
<project name="subversion-python-bindings"> <!-- subversion needs access to the python *.h files --> <depend project="python" type="headers" id="dev-headers"/> </project>
Similar things could be something like "I depend on the project.xml of another module so I can reference it". Or just "I need the location of some include files so I can tell configure where to find them".
totally.
If we add module level dependency and more interesting types than "depend --> add the jars to CLASSPATH", we would address those issues.
yep. In Gump3, I made Dependency into a real object inside the model. Currently its a little broken (when you <depend/> on the same project multiple times for different artifacts, that counts as multipe dependencies, which is wrong), but the key bit is that you can have loads of information about the dependency added onto it.
(in graph theory speak, we can have arbitrarily colored edges)
If that is the case, <property/> inside <ant/> right now should automatically mean a <depend/> (right now a <depend/> inside <ant/> also means a <property/>).
I like things to be explicit, so I'd rather remove "<depend/> inside of <ant/>" completely and don't create any dependencies implicitly. But that may be just me - and I'm able to adapt 8-).
no, it's not just you! I guess what I should've said is that <property/> referencing a project is illegal withouth a <depend/> to the same project. Yep.
thanks for the input!
cheers,
Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
