geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <>
Subject Re: Questions about site
Date Tue, 02 May 2006 15:27:10 GMT
Aaron Mulder wrote:
> As far as whether plugins are valuable, here's an example to consider.
> Let's say someone gives you an EAR that contains a WAR and an EJB
> JAR, and uses JMS as well as a database pool.  Your task is to get
> this running in Geronimo.
> Strategy 1: File-based (they provide EAR, you write 5 XML files)
> - install any required 3rd party JARs
> - write a Geronimo deployment plan for WAR
> - write a Geronimo deployment plan for EJB JAR
> - write a Geronimo deployment plan for EAR
> - write a Geronimo deployment plan for the DB pool
> - write a Geronimo deployment plan for the JMS resources
> - deploy all those in some sensible order, each with the accompanying
> JAR file (the TranQL RAR and ActiveMQ RAR for the resources)
> Strategy 2: Use the console to your advantage (they provide EAR, you
> write 3 XML files)
> - install any required 3rd party JARs
> - write a Geronimo deployment plan for WAR
> - write a Geronimo deployment plan for EJB JAR
> - write a Geronimo deployment plan for EAR
> - use the console to configure, test, and deploy the DB pool
> - use the console to configure and deploy the JMS resources
> - deploy the application
> Strategy 3: Install from a plugin (they provide plugin)
> - point Geronimo to the application plugin.  Application, DB Pool,
> and JMS resources are all downloaded with their dependencies and
> everything is installed automatically in one shot.

What I read from these three strategies you described is like you would no longer able to
your *ARs with all the required deployment plans. Is that so? why would you be able to package
XMLs in a plugin but not in WAR or JAR ...

If someone gives you an EAR as you say then that's all you have, an EAR, not a plugin. If
person is able to provide you with a plugin then that person can also provide you with an
including all the app deployment plans as well as the plans (even scripts) for deploying other

resources such as data sources and JMS connection factories, etc.

> As far as whether different kinds of things should be plugins, patches
> and updates can use the plugin infrastructure, so we might as well
> consider them.  And I don't think that either sample applications or
> an LDAP server are "core functions" that should be included with the
> default Geronimo download.  It's fine if we have an installer package
> that lets you select some extensions to include in your installation,
> but if you just grap a zip or tarball, I'd much prefer that it was
> very clean/lightweight with easy links to install additional
> functionality.

So you are saying we are moving to have just one minimal distribution (little-G) and then
we build 
our own custom Geronimo solution?

I would really like to have a separate discussion about this approach.

We should also expand more about what is the vision, strategy and goals for the Geronimo project
cast it in stone. Speaking just for myself, I have not had a good sense of direction lately.
might be good to spend some time revising and discussing some of the things we give as granted
some things we may have forgotten.

Having just three bullets on the welcome page does not quite say it, does it!? :)

> Another use case is the minimal Tomcat server.  It will be possible to
> start with the lightest-weight Geronimo installation and add JMS or DB
> pools or EJB or the full J2EE bundle via plugins.  Without
> re-installing your apps or restarting the server!  Let's say you have
> an existing web app and you want to add JMS.  Much nicer to make the
> new version of your app depend on an ActiveMQ resource group and just
> redeploy the plugin for your app and have JMS features downloaded and
> added to your server at runtime, so in the process of the app upgrade
> the new server features go in, the new resources go it, and it all
> goes live.  Bam! (if you favor Emeril.)  No need to do a separate
> Geronimo/J2EE installation and repeat any configuration you may have
> done in your old installation and them add new resources in the
> console and only then deploy your new app and find out at that time
> whether you've done everything right and all the dependencies are
> there (oops, forgot the security realm).

The jelly is starting to jell :D

A few things to consider though:
- Must consider offline installation.
- You should be able to point to not just URLs but also a local directory.
- You should be able to export just about anything in Geronimo as a plugin, no matter how
resource/app was originally deployed (portability)

> For "production" use, I think it'll be nice in many situations to
> transfer a module directly from one server to another without
> redeploying.  For example, from a dev box to a QA box, perhaps.  Make

But that would not be production, that would be part of the development cycle, right!?

> absolutely sure you're using the same code.  It won't always be
> appropriate, like if you require different EJB env-entry settings for
> the different environments, but it could handle something like your
> database pool points to a different DB in each environment but the app
> always points to the same database pool name.

Yup, while still in the development cycle (including QA) you will always point to different

resources. So I still can not see the difference from what I would normally do. For instance,
have the application running on the test environment. This app uses a data source that points
to a 
local database. When you are done with testing and QA you move that app to the production

environment where you already have configured a data source with the same name but with different

connection parameters and pointing to the production database. Here is where I still can not
see the 
difference of having a plugin, you would require multiple plugins which in turn would only
either the application and deployment plans or the plans for a resource....

> Finally, I think plugins will be pretty effective for examples since
> they minimize the number of steps to get a group of related things
> installed.  It's certainly possible to pack a lot into a single EAR if
> you're sufficiently clever about it, but with plugins it should be
> easier to have 1-stop installs for whatever modules you want people to
> have to work through things.  There are even plugin lists so you can
> install 10 otherwise unrelated things in one bundle.  No good if you
> want to teach them how to write a deployment plan, but hey.

What would be the steps for removing a plugin? I think it is equally important, if we provide
single step install, we should also provide a single step uninstall and deal with all the


> Thanks,
>    Aaron
> On 5/1/06, Hernan Cunico <> wrote:
>> I think the issue to be discussed should be more than just the 
>> physical location of the plugin server.
>> We have just way to many alternatives to do the same thing, which is 
>> to DEPLOY.
>> For what I understand about the idea behind the plugins, they seem to 
>> be good for installing some
>> things and not so good for others. If the long-term plan is to move 
>> everything to plugins, then I
>> think it is a bad move.
>> We need to clearly separate what and how we deploy in Geronimo.  We 
>> could separate into groups such
>> as (I am intentionally not including resources):
>> 1. Geronimo modules
>> 2. Sample applications
>> 3. User applications
>> 4. Vendor applications
>> This is just a rough, and certainly not complete, grouping but helps 
>> to express my point. Following
>> the order from the list:
>> Having some Geronimo "modules" and sample applications available as 
>> plugins may be OK if these are
>> hosted within the ASF. I think this could be a relatively painless way 
>> to distribute a patch/update
>> to the single server installation users (if you have many servers this 
>> is not a viable solution).
>> We develop/integrate the modules and samples so we provide, as a 
>> deployment alternative, the Apache
>> Geronimo plugins site. When fully documented, it ends up being a 
>> working sample site for configuring
>> your own plugins site.
>> But it would not feel right if you need to install the LDAP module (to 
>> give just an example) and you
>> have to go outside the ASF, a different server from where you 
>> downloaded the Geronimo binary, to get
>> part of the Apache Geronimo standard functionality.
>> If not hosted at the ASF, how would we ensure server availability, 
>> performance and maintenance?
>> In terms of user applications, I think it is very  unlikely that this 
>> will became the method of
>> choice for  installing everyday applications. In a production 
>> environment, it is very likely that
>> the command line tool will be the most popular alternative.
>> As for vendors applications, if you build your custom solution around 
>> Apache Geronimo it is probably
>> that you will distribute it all in one package (Apache Geronimo 
>> included). Just like with the
>> Geronimo modules example, plugins may be a good alternative for 
>> distributing patches/updates, but we
>> wouldn't call them plugins anymore would we!?
>> In this case the vendor should choose to have their own plugins site 
>> implementing the security (if
>> needed) to match the appropriate downloads depending on the licensing 
>> and sensitivity of the plugins
>> to be installed.
>> Two final thoughts. First, I would really like to see and participate 
>> in the discussions before
>> seeing the changes already implemented. Second and last, the whole 
>> deployment strategy should be
>> revised, including the repository. Having too many options does not 
>> make the things easier.
>> Cheers!
>> Hernan
>> Aaron Mulder wrote:
>> > I thought the point of this thread was to have a discussion?  Please,
>> > let's not have any more votes, let's have a discussion.  Can you
>> > describe your position?
>> >
>> > I think it makes perfect sense to move documentation and tutorials to
>> > the Geronimo/Confluence/Apache site.  But my understanding of the
>> > Apache distribution rules is that no code not developed at Apache can
>> > be distributed by the Apache infrastructure.  To be as inclusive as
>> > possible of non-Apache BSD, GPL, and commercial plugins, I think the
>> > primary plugin repository needs to be separate.  We really want to
>> > offer our users the best of all available plugins.
>> >
>> > Also note that I'm not taking any position on the location of source
>> > code.  The source and configuration files for any plugins developed by
>> > Apache will continue to be hosted at Apache, and the output of those
>> > builds will continue to be available on Apache infrastructure. However,
>> > the common plugin repository will also need a copy of the
>> > packaged plugin files to make available for installation -- alongside
>> > the packaged plugin files for any non-Apache plugins.
>> >
>> > And, of course, we're only discussing plugins -- third-party add-ons
>> > to Geronimo.  I'm not suggesting any changes to the core Geronimo
>> > features or distribution model.
>> >
>> > Thanks,
>> >    Aaron
>> >
>> > On 5/1/06, Alan D. Cabrera <> wrote:
>> >
>> >> I do not agree.  I do not think that we should have any sites that are
>> >> non-ASF, much less any non-ASF sites being the default.  I do admit 
>> that
>> >> I have not thoroughly thought it out and am willing to discuss the
>> >> matter further.
>> >>
>> >> Until such time, please consider this my -1 veto until we work this 
>> out.
>> >>
>> >>
>> >> Regards,
>> >> Alan
>> >>
>> >> Dain Sundstrom wrote:
>> >> > I personally don't see a problem with this site specifically.  The
>> >> > console appears to support several plugin sites, so if anyone else
>> >> > wants to setup a site they can.  All I see us deciding is what sites
>> >> > get added to the list by default, and which site is selected by
>> >> default.
>> >> >
>> >> > -dain
>> >> >
>> >> > On May 1, 2006, at 6:45 AM, Jeff Genender wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> Aaron Mulder wrote:
>> >> >>> On 5/1/06, John Sisson <> wrote:
>> >> >>>> I noticed that the 1.1 console has the

>> site
>> >> >>>> as a
>> >> >>>> default value for the URL in the "Import/Export Configurations"
>> >> page.
>> >> >>>> This was introduced in
>> >> >>>> .
>> >> >>>>
>> >> >>>> I have a few questions:
>> >> >>>>
>> >> >>>> Was the plugin concept, site etc. discussed on the dev
list?  I
>> >> >>>> haven't
>> >> >>>> been able to find much at all.
>> >> >>>
>> >> >>> No, not really as such, more in little bits and pieces and
>> >> discussions
>> >> >>> at TSSJS and so on.  Though I think it was covered in some

>> detail in
>> >> >>> the vision and goals writeup.  I need to do a better job of
>> >> describing
>> >> >>> the plugin architecture, but I've been kind of holding off

>> until it
>> >> >>> gets out of the testing stages and I can put together a writeup

>> with
>> >> >>> some walkthroughs and so on.  But I'll send out some 
>> documentation on
>> >> >>> it later today.
>> >> >>>
>> >> >>
>> >> >> I think there needs to be significant discussion about this on
>> >> >> community forums.  This one has caught a few folks by surprise.
>> >> >>
>> >> >>>> Where is this site currently hosted?
>> >> >>>
>> >> >>> Erin's currently donating the hosting.
>> >> >>>
>> >> >>>> Will it be an ASF hosted site before the 1.1 release goes
>> >> >>>
>> >> >>> No.  Among other things, it needs to be able to host non-ASL

>> plugins,
>> >> >>> including GPL, commercial, whatever.  We really need a central

>> site
>> >> >>> for *all* plugins, not separate places for ASL plugins and
>> >> >>> open source and non-open source plugins.
>> >> >>>
>> >> >>
>> >> >> The hosting location is an issue.  I think this needs discussion
>> >> and if
>> >> >> it is going to be hosted somewhere that is non-ASF, I think an
>> >> >> source locale such as Codehaus or SourceForge would be 
>> appropriate.  I
>> >> >> personally am not happy with a link off our portal going to 
>> someone's
>> >> >> personal site.  We need consensus on this.
>> >> >>
>> >> >>>> Where is the source for the site?
>> >> >>>
>> >> >>> The source for the plugins themselves is presently entirely
in the
>> >> >>> Geronimo SVN tree.  To make a configuration into a plugin,
>> just
>> >> >>> need an extra XML descriptor, and the Geronimo packaging plugin

>> has
>> >> >>> hooks to insert that into CARs as they are built.  However,
as new
>> >> >>> plugins come in, it will no longer be the case that all the
>> >> >>> source is at Apache.
>> >> >>>
>> >> >>> The source for the web site itself is on the site.  It's not
>> >> >>> source (e.g. the images are not redistributable as such), however,
>> >> >>> we'd be glad to set up accounts for any Geronimo committers
>> want
>> >> >>> to work on the site.  And the web site really isn't the important
>> >> part
>> >> >>> -- it just a way to navigate to the plugins themselves.
>> >> >>
>> >> >> This gets a -1 from me.  Any links off our portal should pass 
>> muster
>> >> >> with the powers that be, which I believe probably should pass 
>> through
>> >> >> the PMC and very likely Apache, the community, and I would hope
>> >> that the
>> >> >> hosting link is just as open as Geronimo/Apache is
>> >> >> (Codehaus/SF/, etc).  If Apache, the PMC, and everyone

>> else is
>> >> >> ok with this, then I am willing to acquiesce based on consensus,
>> >> albeit
>> >> >> with great dismay.  The plugin idea is great, but the way in which
>> >> this
>> >> >> has gone about is not community focused.
>> >> >>
>> >> >> I don't mean to be the negative voice, but something this big
>> >> should go
>> >> >> through significant discussion with the Geronimo community before
>> >> >> implementing it.
>> >> >>
>> >> >> I would like to hear what others think about this.
>> >> >>
>> >> >> Jeff
>> >> >
>> >>
>> >>
>> >

View raw message