Rich,
Yes, I mean building a Beehive Webproject inside NetBeans 5.0 much like
it going to be with struts and JSF. For a nb Web Project there is a possibility
of "registering" frameworks, there is inicial support for JSF and Struts. I
think it would be cool having Beehive as another option for web framework.
http://web.netbeans.org/extensionSupport/ExtensionSupportUISpec.html
http://web.netbeans.org/struts/struts-support-ui-spec.html
Glauber Adriano
Rich Feit wrote:
I forgot to mention under #2 that having some sort of Beehive support in
NetBeans would be great. This means support for building a Beehive project?
Rich Feit wrote:
I changed the subject line here, just so this doesn't get lost among the
discussion of netui-blank. Here's my take on these three questions:
1. I don't think maven-ized samples would be bundled with v1. Adam
Jenkins is contributing the maven plugin (which is much-needed), but I
think that a maven option wouldn't be worked into the distribution
until v1.1 (or whatever the next point release is). That's just my
guess. The reason for this can be found in my answer to #3. :) It
does look like Eddie is working on getting our JARs out on the
repository in time for v1:
http://mail-archives.apache.org/mod_mbox/beehive-user/200509.mbox/[EMAIL
PROTECTED]
.
2. I agree that the loss of momentum on Pollinate is disappointing,
although I'm still really hopeful that something will appear under
Eclipse eventually. I agree with Adam's statement that this is a
missing piece which would really help carry Beehive forward (by making
it more accessible and also digestible by management types). A
discussion about collaboration with the Pollinate project is probably
something we should have after v1 goes out.
3. v1. Yes, I would be shocked if we didn't release it this week. This
project model issue is the only one we need to resolve, as far as I
know, and so far everyone's been supportive of it.
Rich
Glauber Adriano Reis wrote:
I'm happy now, the layout makes its way smothly into NetBeans when you
import it as an
external web project.
I've got 3 questions:
1 - would maven-ized samples be bundled with V1? If so, I read in the
mailing list
about the plugin(I was working on such a thing as well but stoped
since it had
been already developed) but I cannot find the plugin or anything
mentioning it in JIRA.
2 - Such a pity that Pollinate project is dead. What you guys think?
...the latest
NeBeans version to be released (v5) will have struts support. I think
it would be cool
having some sort of minimal beehive support as well, I'd be very glad
working on it (since I probably
wont use WebLogic 9 eclipse plugins) but want you opinion.
3 - Is Beehive V1 due out this week? I'm pretty much anxious... :)
Glauber Adriano
Eddie O'Neil wrote:
All--
I've got a patch ready which will reorganize the
<dist-root>/samples/netui-blank web project from a source-in model
like:
fooWeb/
Controller.java
index.jsp
WEB-INF/
web.xml
src/
build.xml
build.properties
Foo.java
to a source-peer model like:
fooWeb/
build.xml
build.properties
src/
Foo.java
web/
index.jsp
Controller.java
WEB-INF/
web.xml
This brings the OOTB NetUI project model in-line with that prescribed
by Tomcat and used in many projects. It's also what Adriano suggested
and used for his NetBeans project.
We're getting in the last days before 1.0 here, so we need to do
two things:
1) agree that this is the right thing to do
2) review the patch in this bug --
http://issues.apache.org/jira/browse/BEEHIVE-921
Please do both; if you disagree with (1), say so! :)
Once / if we agree on this, I'll commit it and take a couple of hours
to rework some documentation. And, hopefully we can branch and ship
1.0. :)
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Sounds great! Leaving netui-samples and netui-jsf seems like the right
thing to hold off for 1.1.
Eddie O'Neil wrote:
Awesome. I'll make this change for netui-blank but will leave
netui-jsf and netui-samples for the sake of stability. We can fix
those for Beehive 1.1.
This would switch the default NetUI project model to something that
looks like this:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/source.html
which is basically:
fooWebProject/
web/
src/
build.xml
build.properties
with a build that works like samples/petstoreWeb.
Any other thoughts about doing this?
Eddie
On 9/9/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I definitely agree on #2 (if I'm understanding you correctly) -- I
think
it should support the Tomcat model you're describing. Originally I'd
suggested supporting both because netui-blank is in the old project
model, so I assumed that this is the only one we would be supporting.
So I support making this change...
Rich
Eddie O'Neil wrote:
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
