> You're right that the docs suck and this would be one way to try and > enforce it. If there are no public properties then that would have to be > explicitly stated too. >
I am all for not only explicitly stating public properties(+1) but also for a) stating public goals b) expressing constrains of properties (I have "dumb" GUIs in my mind, which can try to help to customize plugin). IMHO all those things are somehow linked together and can be most likely solved in a common way. Having in mind that we are aiming at having not only jelly plugins (Java rocks :)), we can think ahead and try to find a common way of describing the functionality exported by the given plugin. Maybe some 'smart' XML file stating plugin "exports" could be a solution (exports = goals + properties). This file can be probably auto-generated from jelly script or java code. [off topic] Other think we can think of is to enforce that goal ( an example) war:war is implemented in war plugin (string before colon determines the plugin name) It's not that simple as goals can be overridden in maven.xml etc. It is important for make things like: maven help -Dplugin=war (displays goals exported by war plugin) possible but first of all it's required for better scalability and for simplifying lazy loading of plugins and possibly downloading them on demand (war plugin was requested via invocation of war:war goal, and if it's not installed - we can try to fetch it). Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
