3 Replies Latest reply on Oct 27, 2005 6:42 PM by ryan.campbell

JBBuild Usability- multiple actions in tasks.xml

ruel.loehr Oct 24, 2005 6:22 PM

The last issue which I encountered deals with what happens when the user needs to deviate from a planned course of action. Let's look at first how buildmagic works. In the buildmagic.ent a number of default targets are created, e.g. a default compilation target. The user has a choice however, in his module's build.xml, he can easily add his own compilation target and choose not to call the buildmagic provided one.

With JBossBuild this is not as easy to achieve. If a user wished to replicate this action they would need to modify the tasks.xml file and insert their own custom code there. They would also need a unique way to distinguish there code so that it would be executed.

<source if="@{custom}">
 <javac srcdir="@{sourcePath}"
 destdir="@{output}"
 fork="true"
 >
 <classpath>
 <buildpathelements/>
 </classpath>
 <src path="@{sourcePath}"/>
 <srcelements/>
 </javac>
 </source>

Currently the way it works is the user would the use attributes if, when, and null to specify when the code would executed. This works for a small number of cases but would not scale if a large number of user required custom cases. The most adequate solution IMO would be to allow a user to "override" targets. I feel this issue needs discussion before a detail solution is proposed.

http://jira.jboss.com/jira/browse/JBBUILD-172

1. Re: JBBuild Usability- multiple actions in tasks.xml

ryan.campbell Oct 26, 2005 5:49 PM (in response to ruel.loehr)

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.
Actions
2. Re: JBBuild Usability- multiple actions in tasks.xml

ruel.loehr Oct 27, 2005 6:37 PM (in response to ruel.loehr)
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.

The pro's:
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

The con's:
1) In order to change what a task does, you must release a new jbossbuild.jar
Actions
3. Re: JBBuild Usability- multiple actions in tasks.xml

ryan.campbell Oct 27, 2005 6:42 PM (in response to ruel.loehr)

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%.
Actions

Go to original post