Sorry for the resending... I thought my other message didn't get sent... this is something I don't quite like my gmail which didn't update the message sent by me promptly.
Lin On Fri, Sep 19, 2008 at 1:07 PM, Lin Sun <[EMAIL PROTECTED]> wrote: > I think if we want to make users easier to build a project, the best > is that we can construct the dependency list automatically for the > user, perhaps at deployment time. This would even save the user from > listing plugin groups as dependencies in various geronimo deployment > plans. Maybe it is worthy while to investigate if it is possible to > do this? > > Lin > > On Wed, Sep 17, 2008 at 6:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: >> David Jencks wrote: >>> >>> On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote: >>> >>>> David Jencks wrote: >>>>> >>>>> On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote: >>>>>> >>>>>> David Jencks wrote: >>>>>>> >>>>>>> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote: >>>>>>>> >>>>>>>> Thanks for making these changes David. I think this mostly addresses >>>>>>>> my concern that plugingroups can be used anywhere plugins are used (it >>>>>>>> certainly helps now that they are all cars :-) ). >>>>>>>> >>>>>>>> So with the subject change ... is it now true what Lin mentioned >>>>>>>> earlier in the "[DISCUSS] plugingroups - another idea" thread: >>>>>>>> >>>>>>>> Lin Sun wrote: >>>>>>>> > For option 1, I guess I don't understand why we need the >>>>>>>> > classLoader >>>>>>>> > attribute. I think for plugin groups, we should not add the >>>>>>>> > plugin >>>>>>>> > group itself to the classloader, but we should add the dependencies >>>>>>>> > to >>>>>>>> > the classloader. For instance, if we support Joe's scenario, when >>>>>>>> > a >>>>>>>> > user specifies a plugin group as a dependency in his deployment >>>>>>>> > plan, >>>>>>>> > it would just add the dependencies that the plugin group depends on >>>>>>>> > to >>>>>>>> > the project's classloader. >>>>>>>> >>>>>>>> Will the dependencies of the plugingroup be added to the project's >>>>>>>> classloader? That would certainly resolve any concerns. >>>>>>> >>>>>>> I _think_ they will be in the maven build's classloader but definitely >>>>>>> not in the geronimo classloader. While this is inconsistent I don't >>>>>>> yet >>>>>>> see a reasonable use case for a plugingroup that doesn't have a >>>>>>> classloader >>>>>>> but does indicate a group of plugins that need to be added to some >>>>>>> projects >>>>>>> classloader. I needed the new functionality for other purposes so I >>>>>>> haven't >>>>>>> spent a lot of time thinking about this but a real concrete use case >>>>>>> would >>>>>>> go a long way for me. >>>>>> >>>>>> >>>>>> The scenario I had in mind is very simple. >>>>>> >>>>>> 1) A user has decided (for whatever reason) that they need a core >>>>>> server built on Geronimo including Jetty & Axis2. >>>>>> 2) The user will build multiple web applications and combine them on >>>>>> server images as the need arises and so they don't want to include the >>>>>> applications themselves in a custom server assembly. >>>>>> 2) To address the core server need, the user chooses to assemble their >>>>>> own server image with the two universal pre-reqs: the web-jetty and >>>>>> webservices-axis2 plugingroups. >>>>>> 3) The user then goes about building their web applications and >>>>>> generating geronimo plugins for these web apps to ease deployment. They >>>>>> want to ensure these applications are installed in the correct server >>>>>> configuration so they set the prereqs for the applications to match the >>>>>> core >>>>>> server image that they had earlier constructed - a prereq on the >>>>>> web-jetty >>>>>> and webservices-axis2 plugingroups. >>>>>> 4) The user will then install the server in the appropriate location(s) >>>>>> and deploy combinations of the applications on the as necessary on the >>>>>> server instances. >>>>>> >>>>>> Of course it is more correct to have the applications prereq the >>>>>> individual plugins necessary for jetty and axis2 runtimes rather than the >>>>>> plugingroups. However, that would mean that the user must understand the >>>>>> detailed plugins for building applications but only the plugingroups for >>>>>> building server images ... and the whole point of the plugingroups was to >>>>>> simplify things for the user so they could deal with higher level >>>>>> concepts. >>>>>> If that simplification makes sense for assembling a server (a relatively >>>>>> infrequent activity) why would it not also make sense for assembling an >>>>>> application (a somewhat more frequent activity)? >>>>>> >>>>>> And yes, I understand (as will the user) that the plugingroups may be >>>>>> pulling in more than they really need to run the applications - esp. if >>>>>> we >>>>>> continue to combine core function, deployers, and console extensions in >>>>>> the >>>>>> plugingroups. That may be a valid reason to alter the granularity of the >>>>>> groups we are creating. If not, another reason to split things up a >>>>>> little >>>>>> finer is to facilitate the construction of servers without deployment >>>>>> capabilities - but that's really a separate discussion. >>>>> >>>>> To me it seems more like you are suggesting plugin groups as a >>>>> workaround to another problem in the current plugin system, and I don't >>>>> think your suggestion will really help. >>>>> If you are using maven to build plugins, currently you have to specify >>>>> explicitly in the car-maven-plugin which deployment plugins you want to >>>>> use, >>>>> and include them as (provided) dependencies in the pom. This means you >>>>> need >>>>> to know what you want quite explicitly, and I don't see how plugin groups >>>>> can help with this yet.... certainly an area for discussion. >>>>> Now, the deployers all add the required dependencies to the plan, such >>>>> as in your example axis2 and jetty, so the app certainly won't start >>>>> without >>>>> those present. However at the moment we have no way for the c-m-p to find >>>>> out about those added dependencies and add them to the geronimo-plugin.xml >>>>> so you have to list them yourself. >>>>> It seems to me that if we can somehow use plugin groups in the c-m-p >>>>> configuration to specify more concisely what deployers we want, and get >>>>> the >>>>> dependencies added by the deployers into the geronimo-plugin.xml, then we >>>>> will have the convenience you want without the extra classloader or funny >>>>> "this isn't really a plugin, include my dependencies" behavior that I'm >>>>> nervous about. >>>> >>>> Yes, you are correct that the deployers are an issue when configuring the >>>> c-m-p. That is a important issue, but not the one I was trying to discuss >>>> here. >>> >>> I think they are related.... see below :-) >> >> No doubt they are related. I was only trying to tackle one thing at a time. >> If plugingroups were interchangeable with plugins we could leverage >> deployer plugingroups in c-m-p configuration as well. >> >>>> >>>> >>>> If you look at the jaxws-calculator sample it demonstrates something >>>> similar to my contrived scenario. The jaxws-calculator-jetty plugin has >>>> dependencies on 3 other plugins - jetty6, jasper, and cxf (to match my >>>> scenario above let's just pretend this is axis2 rather than cxf). If the >>>> user is already familiar with a set of plugin groups they would probably >>>> find it more intuitive to declare dependencies on the groups rather than >>>> individual plugins. In this example they could declare dependencies on >>>> web-jetty and webservices-axis2 to match what they had specified when >>>> assembling the server. >>>> >>> >>> What I'd like to see is that the user configures the c-m-p so it works and >>> deploys against the jetty web container, jasper jsp stuff, and axis2 web >>> services. I'd like everything else to flow from that without any more user >>> input. What's missing right now is >>> - easier way to set the required deployers (although it isn't too hard >>> now) >>> - getting the default environment dependencies from the builders into the >>> geronimo-plugin.xml >>> >>> If you are deploying something into a running server I want the generated >>> geronimo-plugin.xml to include all these default env dependencies as well: >>> the result should be that the user only has to specify what server bits they >>> want once, either in the c-m-p "which deployers to use" configuration or >>> what is running in the server they deploy against. >>> >>> To reiterate over and over again once more :-/ I think getting the default >>> env deps into the geronimo-plugin.xml removes any usefulness for the plugin >>> groups as explicit dependencies for user applications. I think we might >>> look for a way to simplify or automate choosing the deployers to use. I >>> don't know if something like plugin groups might be useful here, or not. We >>> might look into byte code dependency analysis like dependency:analyze uses >>> to detect use of servlet, ejb, connector, jms, .... classes and pick them >>> from some kind of list, but I'm not sure this relates well to the plugin >>> groups you are thinking of. I'm thinking of a list that says >>> "jetty-deployer, cxf-deployer, openejb-deployer, jasper-deployer..." >> >> Ok, I see what you are saying. Rather than call out the dependencies >> directly and in addition to that call out the deployers in the c-m-p >> configuration - the user could skip the dependencies and rely on the >> deployer's default environment to fill them in. >> >> Perhaps that will work most of the time for plugingroups that we create that >> also have some related deployer (and maybe all of our plugingroups will have >> deployer equivalents). But will all dependencies included in a plugingroup >> also be pulled in by some deployer's default environment? >> >> However, what happens with user or 3rd party created plugingroups? Will >> they always have comparable deployers and hence default environments so they >> don't need to be specified as a dependency? >> >> Perhaps the user wants the base server to include some core Geronimo bits >> (Jetty, Axis2, etc...) and some of their own functions ... perhaps a >> plugingroup of utilities provided by some 3rd party. For example, let's say >> there is a plugingroup that includes several common debug utilities like >> configurable logging, first-failure data capture, policy validation, etc... >> let's call it "debug utilities". Next the user assembles a server using a >> combination of the geronimo plugingroups and "debug utilities" for a base >> server image. They plan on using this image multiple times to manage >> multiple configurations rather than creating unique assemblies. If they >> want to build plugins for their applications that will be deployed to this >> image, they can configure the c-m-p deployers and thereby pull in the >> default environment dependencies for the geronimo plugingroups. But they >> still have to include the individual plugins from "debug utilities" as >> dependencies if we don't support using the plugingroup in as dependencies. >> >> Again, my goal is only to get some consistency for the end user. I still >> think it's a good idea that our users will appreciate. >> >> Some more rambling thoughts .... >> While I understand and appreciate the idea of configuring the deployers for >> c-m-p and having them pull in the necessary default environments, it seems a >> bit backward from a user perspective. If we want users to embrace plugins >> and using maven to construct them, I think it would make more sense to a >> user if we approach the problem from the other angle. A user creating a >> plugin probably already has some idea of the dependencies they will need >> (either plugins or plugingroups if appropriate). If we let them specify >> the dependencies we should be able to determine which of those dependencies >> requires a particular deployer (at least dependencies of ours). We could >> make it more general purpose by always naming the deployers consistently >> based upon the module that they support (ex. -deployer in the artifactId). >> I'm not sure how we would accomplish that (perhaps another maven plugin that >> front-ends c-m-p) or how we would know if a deployer exists for a given >> plugin. But it seems a bit more intuitive to me than telling the user >> figure out the c-m-p deployers based upon their dependencies and then omit >> the dependencies so that the deployers can pull them in via the default >> environment. >> >> I hope I'm not driving you crazy ... it just seems obvious to me that users >> will want to leverage plugingroups the same way that they leverage plugins. >> >> Joe >> >> >>> >>> thanks >>> david jencks >>> >>> >>> >>> >>>> >>>>> thanks >>>>> david jencks >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Joe >>>>>> >>>> >>> >>> >> >> >
