Hernan,
I had some of the same concerns but I don't think we're very far off
from the original goal as long as we address the documentation
correctly. Some more comments to your specific concerns below.
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".
No arguments here. We should keep the source code as simple as possible
to demonstrate the concepts and ensure that the user has an example as a
way to kick-start their own development.
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.
I don't think we are forcing them to be familiar with Geronimo plugins.
However, we are using the deployment plans created from the
car-maven-plugin so we must point them at those plans. The trick here
is to point them at the plan without necessarily getting into the
details of plugins. BTW, we have also been including the target plans
in the wiki doc itself ... so the user doesn't even need to build to see
a plan unless they really want to do so. IIRC the samples have always
required maven to build (at least in the 2.0 timeframe).
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.
If we can formally release the plugins, then binaries will still be
available without the need to build them (no using maven, svn, or
anything else). However, I don't think the svn requirement is a
critical issue given that we were already requiring maven. If, for some
reason, this is an issue we can always make a source distribution zip
available along with the binaries.
The biggest thing that we need to avoid (IMO) is any attempt to use the
wiki as a code repository. We've already proven that isn't manageable.
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.
I agree that plugins are distribution mechanism. There are 2 main
differences regarding plugins with the latest sample changes:
1) The datasource definitions have been provided in a plugin rather than
requiring the user to create the definitions via the admin console based
on the system database. In that sense ... you could look at the admin
console and manual directions earlier as our "distribution mechanism".
We have to pick something for this purpose and I think the plugin is
perhaps easier for the user. I don't think manually creating the DB
configurations adds any value to the samples. If there is value then we
can come up with some more manual steps ... but I think that might be
more confusing for the users.
2) The Geronimo deployment plans are created as a result of building the
plugins rather that included as pure source. This is a little more
difficult for the user IMO because the user must build to see the plan.
However, we have started adding adding a copy of the plan into the
documentation (where we had included a copy of the plans earlier). I
think a user that doesn't want to build can take the distributed
artifacts (ears, wars) and distribute them with the plans that we
include in the doc if they want to avoid the plugins.
what do others think?
What are the alternatives?
Cheers!
Hernan
