On Jun 12, 2008, at 12:06 PM, Hernan Cunico wrote:
Joe Bohn wrote:
<snip>
...
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.
I agree, creating a database or connection pool does not make the
sample app but rather complements it and it is already covered in
other sections of the doc. So yes, it make sense to have a "Sample
applications prerequisite plugin" that would be common to all
samples, creates a sample database, connection pools and defines any
other configuration that might be required by some of the samples.
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.
That's one of my biggest points. The plans are created automatically
by the car-maven-plugin, but for that you need to provide at least a
plan.xml and don't really know what else. That is as far as I know
about the maven plugin. This is links back to my previous comment
about requiring a new user to be familiar with the Geronimo plugin
architecture and the car-maven-plugin in particular.
um, how does typing
mvn clean install
require you to know anything about maven or our c-m-p plugin or our
plugin architecture?
Do you find the instructions on http://cwiki.apache.org/confluence/display/GMOxDOC21/Sample+applications
insufficiently clear about how to build the samples and find the
completed plan in case you want to deploy the sample by hand?
BTW IMO the samples space should link to this page rather than having
a list of links to the individual samples.
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.
So, would this require the user to repackage the binaries to include
the plans?
um, no. Dealing with plans included in javaee artifacts is a
proprietary extension, not javaee behavior. The javaee spec way to
deploy something is with an external plan, per jsr-88. I suggest we
use it.
thanks
david jencks
what do others think?
What are the alternatives?
Why not keeping the sample apps as just that, sample apps. Let's fix/
improve them where needed, keep an ear being an ear, a war being a
war..... If we don't offer simple sample applications then we should
provide some sections in the doc for adapting/migrating applications
to Geronimo and include less specialized samples there.
Cheers!
Hernan
Cheers!
Hernan
