At this very moment I'm not being able to build the samples so I can't really
comment on the current binaries structure.
If the samples were not working I think we should have fixed the specific
errors, same thing goes for the docs. In previous releases, the samples worked.
I like the idea of having a Geronimo Best Practices section in the doc; but
again, I would rather have the samples as simple as possible. Stick to the very
basics, what are the minimum requirements any given application needs to run on
Geronimo. Plugins is gravy on top. This is just my very personal opinion.
A Best Practices section would be fantastic, it would also be great to have
other sections for creating specific plugins (configurations, applications,
custom server assemblies, etc). There is where I think would be best to have
all these differentiating features in Geronimo.
My considerations with maven are just as arguable if you will and it's based on
first impressions. For example, building a very basic web sample app (let's say
1 jsp), it may take some time to build depending connectivity speed and
availability of the repos; actually the first few times it is likely to fail.
This last one in particular is why I can't build the samples at this moment.
5th attempt now and failing at different intervals. If this is annoying to me,
it must be for others as well. So again, I think simple is better.
I was not suggesting to include the samples source and binaries in Confluence.
I'm saying that's what we had in the past and it was pretty easy for the
readers to get the source and/or binaries. I agree, neither the doc nor the
sample code was perfect but those samples, AFAICT, worked.
To get the source and binaries out of Confluence all we needed to do was to put
the source in svn, fix the issues with the code and docs and make the binaries
available the same way we do with the server binaries.
Sorry for keep repeating myself but I still don't see why we need to do such a
huge transformation to these very simple sample apps.
Cheers!
Hernan
David Jencks wrote:
On Jun 12, 2008, at 9:33 AM, Hernan Cunico wrote:
Hi All,
I'm looking back into the sample apps (samples and docs) and I think
we are missing the point of the samples.
We kinda had this discussion some time ago and I thought we were going
to go in a different way.
The purpose of the sample applications was to demonstrate Geronimo
support/implementation of the different functionalities and features.
To provide some sort of transition path from any other app/platform to
Geronimo. Start easy with the basic requirements, understanding the
Geronimo specific deployment plans, etc. and then gradually involve
the different G specific "goodies".
If we require all users to understand and be familiar with Geronimo
plugins and maven so then they can get their hands on a sample
application for Geronimo; I think we are adding unnecessary barriers
for new users.
In the past, we provided the samples source and in most cases the
binaries ready to install, all along as part of the full sample
documentation. Users were not required to use svn, plugins, or maven
if all they wanted to do was to get familiar with how to implement
JAX-WS in Geronimo for instance.
Plugins are a way to distribute these applications, a convenience to
install the sample binaries once the samples get released. Plugins
should not be a requirement for sample applications, it should be an
option.
what do others think?
I think some realism about our capabilities for maintaining the
documentation is called for. If the samples had been being kept up to
date, working, adapted to latest geronimo, etc, I'd say you might have a
point. However they didn't work, the documentation was full of
misleading statements and errors, and they didn't demonstrate best
practices in geronimo. One of my main goals working on the samples is
to produce something simple and automated enough so we have some slight
chance of keeping it up to date: even with the simplifications I've
introduced I don't have a lot of hope for this.
When the samples are released, if we stick with the current setup based
on plugins, we will be publishing the javaee application artifacts and
the plugins. The plans to deploy the artifacts independently are inside
the plugins. While this is not the most convenient location the plans
will be available.
I also don't think that requiring users to build the sample projects
with maven is unreasonable. We certainly don't provide any other way of
building the applications, and I don't see any reason or argument why we
should. If you build the apps you get the plans in
<sample>-[jetty|tomcat]/target/resources/META-INF/plan.xml. I've tried
to state this clearly in the top level samples documentation.
If you are suggesting including source and binary attachments in
confluence I think that is a bad idea -- they will never get updated --
but could be considered after we release the samples. We certainly
can't do that before a release vote.
thanks
david jencks
Cheers!
Hernan
