Maybe we just check to see if the target exists before we generate it? IE, if a project already has a build.main, we don't generate that target.
Of course, they will need to access the predefined classpaths & source paths created by jbossbuild, ie,
main.buildpath - classpath for building main
main.output.dir - output/classes/main
main.src.dir - src/main/
Otherwise they will hard code that stuff.
Looking at this from a higher level I can make a problem statement such as,
"JBossBuild generates a number of targets to execute. The execution instructions within those targets are defined in the tasks.xml file. A single target may require many different ways of executing a task (e.g. releasing a file could consist of a simple copy, an explosion of a jar, or a copying of a directory). This has led to the addition of attributes to types which are used to make determinations about which course of action to pursue.
It may be better to abstract the concept one step further and delegate the logic to specialized ANT tasks.
<targetdef target="release"> <main> <release-deployments/> </main> </targetdef>
The release-deployments task has all of the object information available to to it via the static build instance. It can then release the items described by the build.
1) Much cleaner
2) Greater flexibility
3) Easier to develop and understand
4) Hides the implementation details from the user (it's mavenish in that aspect) - this could be considered a con as well
1) In order to change what a task does, you must release a new jbossbuild.jar
Yes, I agree tasks.xml, in its completed incarnation, is a beast.
perhaps instead of wholesale conversion to ant tasks, we could just identify the ugliest parts and try to clean those up with a task or two.
The show target is a bug plus, which we would lose if we went with custom tasks 100%.