Comments in line.
[EMAIL PROTECTED] wrote:
Eddie O'Neil wrote:
Bob--
Thanks for the tarball; I was able to overlay it and run the build / test targets up to needing the VersionGenerator patch.
Great, thanks for the feedback.
If we're going to have the beehive.version in the JAR name for all of the JARs produced, it'd be cool to have the timestamp of the current build in beehive.version. Presumably this could be set in the build-common.xml file.
Yah, right now it just takes a string from beehive-common.properties, which is your svn-snapshot descriptor at this point. But we can certainly take a version from the command-line (for releases) and if none supplied, generate a datetimestamp.
Yeah, svn-snapshot was better than nothing -- using datetimestamp would be even better. Just didn't have a place to hang that that everyone would use when creating their distro JARs. Should have that now. <g>
There are also some NetUI related issues that we should talk about when you're ready to switch there; for example:
- how the use of top-level <path>s affects the build files that the distribution ships.
Was thinking about that some also. Perhaps we put them into a
build-paths.xml at the root, so that just the <path>s can be included elsewhere, particularly once we generate starter projects
and builds for users.
Yeah, that seems right. At worst, we end up with two build-paths.xml files -- one for SVN and one for the distro to support their different file layouts.
- for a property-less build, one thing that would help is cleaning up the way NetUI builds webapp templates.
If you're generally happy with this direction, I can punt on over into netui tomorrow, assuming your <subant> changes have settled. That alone should help my task. Consistency is a Good Thing.
Sure, NetUI has been cleaned up quite a bit now. The two places where things could get a little more interesting are the NetUI webapp template and the test recorder. The former just needs to be simplified; I've got some thoughts there I'll send along. The latter just needs to change to support the <path>s defined at the top-level.
Thoughts from the controls testers?
btw, for the ApacheCon dist, v1/alpha/ is the branch I should be on?
Good question. <g> I've done all of my work in trunk/ and not worried about having that ready for ApacheCon. If others have opinions here (Ken?), speak now and I can likely roll my trunk/ changes back into v1/alpha.
-bob
