Comments in-line.
Note, I've taken the user list off of this discussion for the moment...
Bryan Che wrote:
Eddie O'Neil wrote:
Cool! Yeah, this is sort of what I'm working on now for the distribution but haven't gotten around to doing it internally.
What build.xml file does this patch? There are several of them. <g>
It patches /trunk/build.xml
Gotcha, thanks!
It might be worth having a standalone build file that can be included with a webapp rather than a single one to use for all webapps. The targets would be the same but the BEEHIVE_PROJECT environment variable would be set in the build file itself and probably just point to ${basedir}.
What would you think about that?
Doing this could present a couple difficulties:
-if the canonical project build.xml gets updated, then you'll have to be sure to remember copy that build.xml file to all your projects. This could lead to projects with build.xml files that are out of sync
The way we're (currently) dealing with this is that the canonical build files are imported using Ant 1.6 <import>. That way, any build file that imports the buildWebappCore.xml Ant file is always up-to-date with *the* file that does builds. So, unless the APIs to the this build file change (which hopefully won't happen often), callers should be fine. This typically is setup like this:
build.xml
- define local properties such as webapp context root
- import buildWebappCore.xml to pickup the canonical Beehive webapp build tasks
- import runTomcatCore.xml to pickup the canonical Tomcat start/deploy tasks
- define any custom targets needed to build a .war distribution, perform additional build steps, generate Javadoc, etc.
I think part of the reason I'm a little hesitant to add these to $BEEHIVE_HOME/build.xml is that there are clean / build / deploy / undeploy / redeploy / start / stop targets that all need to be there in order to do everything to a Tomcat webapp in one place. Just doesn't feel like this belongs in the top-level project build file.
But, we can certainly debate the merits either way. <g>
-unless creating a webapp is somehow automated, this places an extra burden on developers to copy the appropriate build.xml to their new webapp
I actually think creating a webapp from the dev tree *should* be automated -- in addition to making it easy for users, it'd be nice for it to be equally easy for Beehive devs.
It'd be an Ant target that creates a directory that contains basically everything that's in:
$BEEHIVE_HOME/netui/build/dist/webapp
and can call targets like build / clean / deploy / undeploy / redeploy / start / stop.
Today or tomorrow, I'm going to checkin a build file a la the one described above that would be used to build a webapp created from a Beehive distribution. Maybe that would help shed some light one way that this could work... Let me know if anyone would like a preliminary copy of this sent into the dev list.
Also, it might be worth getting the Tomcat deploy / undeploy targets wired in -- these would use the same ${basedir} for the webapp root and would need a context root property as well.
Yes, that would be useful.
Bryan
