1) yes, this simply adds a convenience target to beehive-imports.xml.
It doesn't attempt to fix the validation problem discussed earlier --
depending on how it's fixed, that might be an SVN-side issue with
building the distribution.
2) I agree that we are moving away from the WEB-INF/src project model
and onto the Tomcat model where web/ and src/ are peers. This target
certainly could support both models, but it's just easier to have it
support the one Tomcat prescribes that is widely used and is easily
supported in various IDEs. We can document how to setup a project with
source-in-webapp. If there was enough interest, we could make this
change now...it only affects netui-samples, netui-blank, and netui-jsf.
Thoughts?
Eddie
Rich Feit wrote:
I see - so this isn't the complex part of the change we were talking
about. This is simply adding an ant target to beehive-imports.xml. It
seems like a good addition, but one question I have is whether we should
be supporting different project models with something like this. Seems
like we're moving away from a source-under-web-content model. What do
you think?
Rich
Eddie O'Neil wrote:
Here's the Ant that will do this; it patches
trunk/user/beehive-imports.xml and can be run as:
$> ant -f beehive-imports.xml new.netui.webapp
which will prompt for a destination directory for the project. Or, it
can be run like:
$> ant -f beehive-imports.xml new.netui.webapp -Dwebapp.dir
which will skp the prompt since "webapp.dir" has already been provided.
I think this will be *really* useful and less error-prone than the
alternative.
Thoughts?
Eddie
<snip>
<target name="new.netui.webapp"
description="Create a new NetUI-enabled Beehive webapp">
<input message="Provide a fully-qualified web project path:"
addproperty="webapp.dir"/>
<copy todir="${webapp.dir}">
<fileset dir="${basedir}/samples/netui-blank">
<include name="**/*"/>
</fileset>
</copy>
<deploy-netui webappDir="${webapp.dir}"/>
<echo>Created a NetUI-enabled in ${webapp.dir}</echo>
</target>
</snip>
On 9/9/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
Gotcha. As far as the docs, I've got a placeholder in the
netui/projects.xml doc already that describes the cp / ant -f step.
So, that part is easy. ;)
Patch forthcoming...
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Oh, I just meant we should take a week to have people play with it if we
put it in for 1.0, that's all. I think we'd want to get it into the
docs, too, especially where there are instructions for copying
netui-blank, etc. What do you think about that?
I'd definitely take a look at the diff, though, even if it's something
we hold until v1.1.
Rich
Eddie O'Neil wrote:
Yeah -- I don't think it would take a week (probably just a couple
of hours), but it's a little different than how we do things right now
because we need to support two scenarios:
- create a new webapp
- inject the runtime files (JARs / resources) into the samples
We've got the latter and could easily add the former.
But, we'll get very little test mileage on it in the near term. I
can take a crack at it and see what you think of the diff...
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Definitely, this would be a great thing to have. I have a local script
that does exactly this -- in retrospect, this should have made me think
of an ant target. I think it's something that we should do for 1.1,
unless we want to delay the release for a week or so...
Rich
Eddie O'Neil wrote:
It's complicated. :)
We really need a target that can "seed" a Beehive webapp including
all of the validation config files, runtime JARs, and NetUI URL
addressable resources. Today, this is done using a command like:
cp -rf samples/netui-blank <project-dir>
ant -f ant/beehive-runtime.xml deploy.beehive.webapp.runtime
-Dwebapp.dir=<project-dir>
If, for example, you just do the latter, you'll end up with a webapp
that has the runtime but no web.xml or validation config files. And,
that's kind of bad...
Would be *very* nice to have a target that just does:
ant -f beehive-imports.xml new.beehive.webapp -Dproject.dir=...
It could even prompt for the project.dir -- kind of like a new project
wizard in Ant.
We could do this for 1.0, but it's not an insignificant change.
It's *definitely* something we need for 1.1...
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Yeah, if it's complicated at all, I agree.
Daryl Olander wrote:
+1 to doing the real fix post 1.0
On 9/9/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
I take it back...this isn't a straightforward thing to fix
unfortunately because it affects the Ant used to provide the runtime
in both the distribution and SVN builds.
It wouldn't be hard to change it, but if we're going to do that, we
should add the beehive-netui-validator-config.xml file (and consider
adding web.xml) to those as well...
I agree (now) having them checked in is the right thing unless we
want to tackle the bigger problem of copying all of the config files.
And, I'd rather ship 1.0 and fix that later. :)
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
OK, I certainly don't have an objection to that... thanks.
Rich
Eddie O'Neil wrote:
Right, it doesn't *have* to happen now, but doing it now ensures
that we're consistent. So, I'm going to go ahead and fix while you're
getting the compiler change in.
:)
Eddie
Rich Feit wrote:
I haven't started it -- it doesn't seem like anything that has to go
into v1, right? Just checking. I did update the checked-in files to
be
of the right version -- this is just the longer-term fix to ensure
that
this doesn't happen again... :)
Rich
Eddie O'Neil wrote:
Rich--
Have you started fixing BEEHIVE-914 yet? If not, let me know and
I'll take that one.
Eddie
