Re: Assemblies assemblies everywhere and which one to ship?
On Jan 12, 2007, at 5:06 PM, Matt Hogstrom wrote: Here is my concern...Assume a downloads page that looks like this: Java Enterprise Edition Certified Releases - Tomcat Axis OpenJPA - Jetty CXF Cayenne Other Releases - Tomcat CXF OpenJPA - Jetty Axis Cayenne Minimal Assemblies - Tomcat ... There is a difference between being Between being what? :-P Personally I would love to see the downloads page have exactly 2 links to archives... one for a zip and another for a tgz, and that single assemble can easily be configured to be minimal, tomcat, jetty, javaee with any flavor you want. I think we will need to bless a specific configuration as JavaEE certified, but I don't think we should have separate builds for that. For 2.0 probably will have to do that, but for post-2.0, I think we should focus on fixing the need for all that build-time stuff to configure the server... and get away from needing all those per-webcontainer configs, and have just one assembly with a really easy way to configure what components it uses. --jason
Re: Assemblies assemblies everywhere and which one to ship?
Here is my concern...Assume a downloads page that looks like this: Java Enterprise Edition Certified Releases - Tomcat Axis OpenJPA - Jetty CXF Cayenne Other Releases - Tomcat CXF OpenJPA - Jetty Axis Cayenne Minimal Assemblies - Tomcat ... There is a difference between being On Jan 12, 2007, at 3:22 AM, Alan D. Cabrera wrote: On Jan 11, 2007, at 7:27 AM, Matt Hogstrom wrote: What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? I think that you are correct but I think that you may have missed David's point in that there would be almost no work in testing new combinations once the constituent parts have been tested in previous combinations. Regards, Alan Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
You can install a plugin from the command line deploy tool -- just use the "install-plugin" command point it to the CAR file. The down side is that if that plugin has dependencies, they will be resolved against a remote repository (as listed in the plugin metadata). So you'd presently have to pluginize all the dependencies and install them in "just the right order" to avoid hitting a remote repo. One of the items on the plugin todo list is to support something like a ZIP file where everything attempts to resolve against the contents of the ZIP before going to remote repositories. For purposes of an installer, you could extract all the "source JARs" to a directory formatted like a Maven 2 repo, and then use a file:/// URL as the remote repository. I think the problem there is that the remote repository listed in the plugin metadata presently overrides the location the plugin was actually loaded from. It should be easy enough to add some kind of flag to reverse that so the "current" repository gets priority during an install. Thanks, Aaron On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: How easy is it to install a set of plugins from the command-line? And don't plugins require a remote repository to hold the archives? While I think that this is good to allow installation of custom plugins, I don't think its good to use a remote repo to install system components. I'd rather ship everything in one assembly, and then have a simple command-line tool to allow customization of what is installed. I'm no expert on how plugins currently work, but it is my understanding that it is not that easy to configure a server to use a set of plugins from he command-line (or driven off of a configuration file). For build automation and TCK testing it would be a PITA to require the console and then need to automate clicks to setup the right configuration for testing. Eventually... I think that everything (except the core kernel and deployment system) should be in some self-contained plugin, which could be zipped up in an archive, or as a set of xmls and jars which could be deployed into the server. My understanding is that we are not really to that point yet, hopefully once 2.0 is out we can focus on some of these usability and configuration issues. --jason On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote: > On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> If we do start shipping 8 (or more) different assemblies... which >> I think is >> crazy, then we probably don't want to hook them all up to the >> default build, >> as it will just cause it take longer and longer to run. >> >> We really need to get plugins functional so that we can build one >> assembly. >> >> Please... :-) > > AFAIK the plugin functionality already works sufficiently well to > support this approach. And the infrastructure should already be in > place as well since the plugin repository catalogs at > geronimo.apache.org point to maven repos where the Geronimo CARs get > published. > > Granted we've only used plugins for installing applications so far and > really haven't tried using plugins to install or replace core jee5 > services, so there may be missing functionality that needs our > attention. Only way to know for sure is to identify each config that > should be provided as plugin, map out its dependencies, and add a > geronimo-plugin.xml to the CAR file that maven builds. Then update > the plugin catalog so when that CAR gets published to the maven repo > it will be installable as a plugin. There are several examples in > trunk/configs. > > Best wishes, > Paul
Re: Assemblies assemblies everywhere and which one to ship?
On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: How easy is it to install a set of plugins from the command-line? The CLI provided by bin/deploy.sh provides an interactive shell for this. To list and install plugins from the Geronimo 2.0 plugin repository type : deploy.sh search-plugins http://geronimo.apache.org/plugins/geronimo-2.0/ Or you can install a plugin file that you've downloaded to your local filesystem by typing : deploy.sh install-plugin PluginFile If you've built geronimo locally then you can point this command at the plugins under ~/.m2/repository/org/apache/geronimo/configs. And don't plugins require a remote repository to hold the archives? A plugin can be installed from the local filesystem as shown above. While I think that this is good to allow installation of custom plugins, I don't think its good to use a remote repo to install system components. I'd rather ship everything in one assembly, and then have a simple command-line tool to allow customization of what is installed. You could tar up the org/apache/geronimo/configs portion of a maven repo, add a catalog to the root of that repository (i.e. geronimo-plugins.xml) and include that in geronimo's micro-G distrbution. Then users could use the CLI (or some installation script we provide) to selectively install plugins using a file:// URL that points at that local repository. I'm no expert on how plugins currently work, but it is my understanding that it is not that easy to configure a server to use a set of plugins from he command-line (or driven off of a configuration file). For build automation and TCK testing it would be a PITA to require the console and then need to automate clicks to setup the right configuration for testing. The console makes it easier to browse a plugin repository, but it is not required to install plugins. Eventually... I think that everything (except the core kernel and deployment system) should be in some self-contained plugin, which could be zipped up in an archive, or as a set of xmls and jars which could be deployed into the server. My understanding is that we are not really to that point yet, hopefully once 2.0 is out we can focus on some of these usability and configuration issues. --jason On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote: > On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> If we do start shipping 8 (or more) different assemblies... which >> I think is >> crazy, then we probably don't want to hook them all up to the >> default build, >> as it will just cause it take longer and longer to run. >> >> We really need to get plugins functional so that we can build one >> assembly. >> >> Please... :-) > > AFAIK the plugin functionality already works sufficiently well to > support this approach. And the infrastructure should already be in > place as well since the plugin repository catalogs at > geronimo.apache.org point to maven repos where the Geronimo CARs get > published. > > Granted we've only used plugins for installing applications so far and > really haven't tried using plugins to install or replace core jee5 > services, so there may be missing functionality that needs our > attention. Only way to know for sure is to identify each config that > should be provided as plugin, map out its dependencies, and add a > geronimo-plugin.xml to the CAR file that maven builds. Then update > the plugin catalog so when that CAR gets published to the maven repo > it will be installable as a plugin. There are several examples in > trunk/configs. > > Best wishes, > Paul
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 12, 2007, at 10:43 AM, Jason Dillon wrote: How easy is it to install a set of plugins from the command-line? And don't plugins require a remote repository to hold the archives? While I think that this is good to allow installation of custom plugins, I don't think its good to use a remote repo to install system components. I'd rather ship everything in one assembly, and then have a simple command-line tool to allow customization of what is installed. I'm no expert on how plugins currently work, but it is my understanding that it is not that easy to configure a server to use a set of plugins from he command-line (or driven off of a configuration file). For build automation and TCK testing it would be a PITA to require the console and then need to automate clicks to setup the right configuration for testing. Eventually... I think that everything (except the core kernel and deployment system) should be in some self-contained plugin, which could be zipped up in an archive, or as a set of xmls and jars which could be deployed into the server. My understanding is that we are not really to that point yet, hopefully once 2.0 is out we can focus on some of these usability and configuration issues. Can't one of the maven plugins install geronimo plugins? e.g. the car-maven-plugin? I think its the same as installing a config/module into a server under construction like we do in the assemblies. I think there's a command line deployer option to install a plugin but I'm not sure I've used it. My idea with the abandoned installer project was to start with a basic server (what joe has as "framework" I think) and add configs/ plugins from a maven repo inside the installer jar. I still think this is the way to build an installer. Another possibility for something you can download is one server with all the configs/plugins in it and a lot of different config.xmls for different purposes. A script could copy the appropriate config.xml in place and then prune the server's repo so only the stuff used in the config.xml is left. A slight variation on this would start with a basic framework config.xml and scripts would enable various configs/ plugins, followed by pruning. Lots of promising ideas, so little time. thanks david jencks --jason On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote: On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: If we do start shipping 8 (or more) different assemblies... which I think is crazy, then we probably don't want to hook them all up to the default build, as it will just cause it take longer and longer to run. We really need to get plugins functional so that we can build one assembly. Please... :-) AFAIK the plugin functionality already works sufficiently well to support this approach. And the infrastructure should already be in place as well since the plugin repository catalogs at geronimo.apache.org point to maven repos where the Geronimo CARs get published. Granted we've only used plugins for installing applications so far and really haven't tried using plugins to install or replace core jee5 services, so there may be missing functionality that needs our attention. Only way to know for sure is to identify each config that should be provided as plugin, map out its dependencies, and add a geronimo-plugin.xml to the CAR file that maven builds. Then update the plugin catalog so when that CAR gets published to the maven repo it will be installable as a plugin. There are several examples in trunk/configs. Best wishes, Paul
Re: Assemblies assemblies everywhere and which one to ship?
How easy is it to install a set of plugins from the command-line? And don't plugins require a remote repository to hold the archives? While I think that this is good to allow installation of custom plugins, I don't think its good to use a remote repo to install system components. I'd rather ship everything in one assembly, and then have a simple command-line tool to allow customization of what is installed. I'm no expert on how plugins currently work, but it is my understanding that it is not that easy to configure a server to use a set of plugins from he command-line (or driven off of a configuration file). For build automation and TCK testing it would be a PITA to require the console and then need to automate clicks to setup the right configuration for testing. Eventually... I think that everything (except the core kernel and deployment system) should be in some self-contained plugin, which could be zipped up in an archive, or as a set of xmls and jars which could be deployed into the server. My understanding is that we are not really to that point yet, hopefully once 2.0 is out we can focus on some of these usability and configuration issues. --jason On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote: On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: If we do start shipping 8 (or more) different assemblies... which I think is crazy, then we probably don't want to hook them all up to the default build, as it will just cause it take longer and longer to run. We really need to get plugins functional so that we can build one assembly. Please... :-) AFAIK the plugin functionality already works sufficiently well to support this approach. And the infrastructure should already be in place as well since the plugin repository catalogs at geronimo.apache.org point to maven repos where the Geronimo CARs get published. Granted we've only used plugins for installing applications so far and really haven't tried using plugins to install or replace core jee5 services, so there may be missing functionality that needs our attention. Only way to know for sure is to identify each config that should be provided as plugin, map out its dependencies, and add a geronimo-plugin.xml to the CAR file that maven builds. Then update the plugin catalog so when that CAR gets published to the maven repo it will be installable as a plugin. There are several examples in trunk/configs. Best wishes, Paul
Re: Assemblies assemblies everywhere and which one to ship?
Paul McMahan wrote: On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: If we do start shipping 8 (or more) different assemblies... which I think is crazy, then we probably don't want to hook them all up to the default build, as it will just cause it take longer and longer to run. We really need to get plugins functional so that we can build one assembly. Please... :-) AFAIK the plugin functionality already works sufficiently well to support this approach. And the infrastructure should already be in place as well since the plugin repository catalogs at geronimo.apache.org point to maven repos where the Geronimo CARs get published. Granted we've only used plugins for installing applications so far and really haven't tried using plugins to install or replace core jee5 services, so there may be missing functionality that needs our attention. Well, not core "jee5" services exactly ... but I did create plugins for tomcat & jetty as well as their respective deployers and I could successfully install those into micro-G (at least they worked a few months ago). So we know this is possible. Joe Only way to know for sure is to identify each config that should be provided as plugin, map out its dependencies, and add a geronimo-plugin.xml to the CAR file that maven builds. Then update the plugin catalog so when that CAR gets published to the maven repo it will be installable as a plugin. There are several examples in trunk/configs. Best wishes, Paul
Re: Assemblies assemblies everywhere and which one to ship?
On 1/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: If we do start shipping 8 (or more) different assemblies... which I think is crazy, then we probably don't want to hook them all up to the default build, as it will just cause it take longer and longer to run. We really need to get plugins functional so that we can build one assembly. Please... :-) AFAIK the plugin functionality already works sufficiently well to support this approach. And the infrastructure should already be in place as well since the plugin repository catalogs at geronimo.apache.org point to maven repos where the Geronimo CARs get published. Granted we've only used plugins for installing applications so far and really haven't tried using plugins to install or replace core jee5 services, so there may be missing functionality that needs our attention. Only way to know for sure is to identify each config that should be provided as plugin, map out its dependencies, and add a geronimo-plugin.xml to the CAR file that maven builds. Then update the plugin catalog so when that CAR gets published to the maven repo it will be installable as a plugin. There are several examples in trunk/configs. Best wishes, Paul
Re: Assemblies assemblies everywhere and which one to ship?
If we do start shipping 8 (or more) different assemblies... which I think is crazy, then we probably don't want to hook them all up to the default build, as it will just cause it take longer and longer to run. We really need to get plugins functional so that we can build one assembly. Please... :-) --jason On Jan 12, 2007, at 8:52 AM, Matt Hogstrom wrote: I understood the point but since every permutation takes at least two days, hardware, and time to nurture I was more concerned about getting in a situation where we wouldn't release anything until we had 8 different assemblies. On Jan 12, 2007, at 3:22 AM, Alan D. Cabrera wrote: On Jan 11, 2007, at 7:27 AM, Matt Hogstrom wrote: What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? I think that you are correct but I think that you may have missed David's point in that there would be almost no work in testing new combinations once the constituent parts have been tested in previous combinations. Regards, Alan Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
I understood the point but since every permutation takes at least two days, hardware, and time to nurture I was more concerned about getting in a situation where we wouldn't release anything until we had 8 different assemblies. On Jan 12, 2007, at 3:22 AM, Alan D. Cabrera wrote: On Jan 11, 2007, at 7:27 AM, Matt Hogstrom wrote: What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? I think that you are correct but I think that you may have missed David's point in that there would be almost no work in testing new combinations once the constituent parts have been tested in previous combinations. Regards, Alan Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
Alan, There are 2 things here: 1. Making sure our code works in all combinations 2. Passing the TCK. Both are mutually exclusive. We are talking about #2 here :) We can run all combinations to everyone's heart's content. But that is not needed to pass the TCK. -- dims On 1/12/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: On Jan 11, 2007, at 9:48 AM, Davanum Srinivas wrote: I don't think there is any requirement of exact combination of components for TCK compliance. AFAIK, we need to ship the exact code we tested, that's it. FWIW, it's self-certification as well :) So i am happy if all the components are put thru the grinder at least once. I don't agree. We're talking about a lot of code and the possibility of a combination that does not pass the TCK is very plausible. Regards, Alan -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 11, 2007, at 9:48 AM, Davanum Srinivas wrote: I don't think there is any requirement of exact combination of components for TCK compliance. AFAIK, we need to ship the exact code we tested, that's it. FWIW, it's self-certification as well :) So i am happy if all the components are put thru the grinder at least once. I don't agree. We're talking about a lot of code and the possibility of a combination that does not pass the TCK is very plausible. Regards, Alan
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 11, 2007, at 7:27 AM, Matt Hogstrom wrote: What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? I think that you are correct but I think that you may have missed David's point in that there would be almost no work in testing new combinations once the constituent parts have been tested in previous combinations. Regards, Alan
Re: Assemblies assemblies everywhere and which one to ship?
Matt, I don't think there is any requirement of exact combination of components for TCK compliance. AFAIK, we need to ship the exact code we tested, that's it. FWIW, it's self-certification as well :) So i am happy if all the components are put thru the grinder at least once. thanks, -- dims On 1/11/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Geir, What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? On Jan 11, 2007, at 12:53 AM, David Jencks wrote: > > On Jan 11, 2007, at 12:01 AM, Jarek Gawor wrote: > >> How hard is it to switch between the different assemblies once the >> TCK >> testing environment is setup? If it is easy enough, maybe we should >> first test all 8 assemblies and then concentrate on only those that >> pass the most tests. > > I guess I have the opposite point of view :-). I suspect if we get > all the tests passing for each component in one configuration, they > will pretty much pass in all the other configurations, e.g. if cxf > + jetty + openjpa works then cxf + tomcat + cayenne will work too, > so the main chore will be to verify this. If it's simple enough to > run the tck this won't be impossibly difficult to test all the > combinations, just take a bunch of machine time. > > thanks > david jencks > >> >> Jarek >> >> On 1/9/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >>> I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF >>> +Cayenne) is >>> enough. All components should be tested at least once. If we get >>> time, >>> we could do more :) >>> >>> -- dims >>> >>> On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >>> > On Jan 7, 2007, at 9:38 PM, David Jencks wrote: >>> > >>> > > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: >>> > > >>> > >> I was thinking about M2 this weekend and was considering >>> many of >>> > >> the challenges we face in putting out certified releases. >>> Up till >>> > >> now the number of permutations has been pretty limited and that >>> > >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer >>> > >> that simple. Here are the choices I know of today: >>> > >> >>> > >> Web Container (Tomcat / Jetty) >>> > >> WebServices (Axis 2 / CXF) >>> > >> EJB 3.0 Persistence (OpenJPA / Cayenne) >>> > >> >>> > >> I think this makes 6 different assemblies and of course 6 >>> separate >>> > >> certification efforts. Perhaps we can do this and perhaps we >>> > >> can't. Based on where projects are at and their desire to >>> > >> participate in helping to integrate (and do TCK testing :). >>> > > >>> > > ummm 2 * 2 * 2 == 8 >>> > > >>> > > I could be very wrong but I thought that the cmp 2.1 support in >>> > > openejb3 was relying on openjpa-specific features. If so I >>> wonder >>> > > if it will be tricky to run the tck on other jpa >>> implementations. >>> > >>> > Well, we depend on being able to listen to events on the EM which >>> > there is no spec interface for. I'm sure Cayanne has and >>> interface >>> > that can provide us with the events, and when they send us the >>> info >>> > we can add a hook for their Impl. >>> > >>> > In general, I think we should just pick a single JPA >>> implementation >>> > to ship with G because it is very easy for an application to >>> request >>> > a different implementation using specification defined properties. >>> > >>> > Of course that will leave us with 4 javaee assemblies and 2 >>> minimal >>> > assemblies. >>> > >>> > -dain >>> > >>> >>> >>> -- >>> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service >>> Developers) >>> > > Matt Hogstrom [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
Geir, What are the specifics around claiming certification? My understanding is that to claim an assembly as certified that specific configuration is tested and made available. Apart from that we can ship any permutation but cannot claim those as certified. So if we TCK tested: Tomcat Axis OpenJPA and Jetty CXF Cayenne then Tomcat CXF OpenJPA would not be considered a certified release. It would most likely work but we couldn't claim that specific assembly as certified. Is that correct? On Jan 11, 2007, at 12:53 AM, David Jencks wrote: On Jan 11, 2007, at 12:01 AM, Jarek Gawor wrote: How hard is it to switch between the different assemblies once the TCK testing environment is setup? If it is easy enough, maybe we should first test all 8 assemblies and then concentrate on only those that pass the most tests. I guess I have the opposite point of view :-). I suspect if we get all the tests passing for each component in one configuration, they will pretty much pass in all the other configurations, e.g. if cxf + jetty + openjpa works then cxf + tomcat + cayenne will work too, so the main chore will be to verify this. If it's simple enough to run the tck this won't be impossibly difficult to test all the combinations, just take a bunch of machine time. thanks david jencks Jarek On 1/9/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF +Cayenne) is enough. All components should be tested at least once. If we get time, we could do more :) -- dims On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > On Jan 7, 2007, at 9:38 PM, David Jencks wrote: > > > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: > > > >> I was thinking about M2 this weekend and was considering many of > >> the challenges we face in putting out certified releases. Up till > >> now the number of permutations has been pretty limited and that > >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer > >> that simple. Here are the choices I know of today: > >> > >> Web Container (Tomcat / Jetty) > >> WebServices (Axis 2 / CXF) > >> EJB 3.0 Persistence (OpenJPA / Cayenne) > >> > >> I think this makes 6 different assemblies and of course 6 separate > >> certification efforts. Perhaps we can do this and perhaps we > >> can't. Based on where projects are at and their desire to > >> participate in helping to integrate (and do TCK testing :). > > > > ummm 2 * 2 * 2 == 8 > > > > I could be very wrong but I thought that the cmp 2.1 support in > > openejb3 was relying on openjpa-specific features. If so I wonder > > if it will be tricky to run the tck on other jpa implementations. > > Well, we depend on being able to listen to events on the EM which > there is no spec interface for. I'm sure Cayanne has and interface > that can provide us with the events, and when they send us the info > we can add a hook for their Impl. > > In general, I think we should just pick a single JPA implementation > to ship with G because it is very easy for an application to request > a different implementation using specification defined properties. > > Of course that will leave us with 4 javaee assemblies and 2 minimal > assemblies. > > -dain > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
I agree with david. -- dims On 1/11/07, David Jencks <[EMAIL PROTECTED]> wrote: On Jan 11, 2007, at 12:01 AM, Jarek Gawor wrote: > How hard is it to switch between the different assemblies once the TCK > testing environment is setup? If it is easy enough, maybe we should > first test all 8 assemblies and then concentrate on only those that > pass the most tests. I guess I have the opposite point of view :-). I suspect if we get all the tests passing for each component in one configuration, they will pretty much pass in all the other configurations, e.g. if cxf + jetty + openjpa works then cxf + tomcat + cayenne will work too, so the main chore will be to verify this. If it's simple enough to run the tck this won't be impossibly difficult to test all the combinations, just take a bunch of machine time. thanks david jencks > > Jarek > > On 1/9/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF+Cayenne) is >> enough. All components should be tested at least once. If we get >> time, >> we could do more :) >> >> -- dims >> >> On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >> > On Jan 7, 2007, at 9:38 PM, David Jencks wrote: >> > >> > > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: >> > > >> > >> I was thinking about M2 this weekend and was considering many of >> > >> the challenges we face in putting out certified releases. Up >> till >> > >> now the number of permutations has been pretty limited and that >> > >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer >> > >> that simple. Here are the choices I know of today: >> > >> >> > >> Web Container (Tomcat / Jetty) >> > >> WebServices (Axis 2 / CXF) >> > >> EJB 3.0 Persistence (OpenJPA / Cayenne) >> > >> >> > >> I think this makes 6 different assemblies and of course 6 >> separate >> > >> certification efforts. Perhaps we can do this and perhaps we >> > >> can't. Based on where projects are at and their desire to >> > >> participate in helping to integrate (and do TCK testing :). >> > > >> > > ummm 2 * 2 * 2 == 8 >> > > >> > > I could be very wrong but I thought that the cmp 2.1 support in >> > > openejb3 was relying on openjpa-specific features. If so I >> wonder >> > > if it will be tricky to run the tck on other jpa implementations. >> > >> > Well, we depend on being able to listen to events on the EM which >> > there is no spec interface for. I'm sure Cayanne has and interface >> > that can provide us with the events, and when they send us the info >> > we can add a hook for their Impl. >> > >> > In general, I think we should just pick a single JPA implementation >> > to ship with G because it is very easy for an application to >> request >> > a different implementation using specification defined properties. >> > >> > Of course that will leave us with 4 javaee assemblies and 2 minimal >> > assemblies. >> > >> > -dain >> > >> >> >> -- >> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service >> Developers) >> -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 11, 2007, at 12:01 AM, Jarek Gawor wrote: How hard is it to switch between the different assemblies once the TCK testing environment is setup? If it is easy enough, maybe we should first test all 8 assemblies and then concentrate on only those that pass the most tests. I guess I have the opposite point of view :-). I suspect if we get all the tests passing for each component in one configuration, they will pretty much pass in all the other configurations, e.g. if cxf + jetty + openjpa works then cxf + tomcat + cayenne will work too, so the main chore will be to verify this. If it's simple enough to run the tck this won't be impossibly difficult to test all the combinations, just take a bunch of machine time. thanks david jencks Jarek On 1/9/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF+Cayenne) is enough. All components should be tested at least once. If we get time, we could do more :) -- dims On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > On Jan 7, 2007, at 9:38 PM, David Jencks wrote: > > > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: > > > >> I was thinking about M2 this weekend and was considering many of > >> the challenges we face in putting out certified releases. Up till > >> now the number of permutations has been pretty limited and that > >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer > >> that simple. Here are the choices I know of today: > >> > >> Web Container (Tomcat / Jetty) > >> WebServices (Axis 2 / CXF) > >> EJB 3.0 Persistence (OpenJPA / Cayenne) > >> > >> I think this makes 6 different assemblies and of course 6 separate > >> certification efforts. Perhaps we can do this and perhaps we > >> can't. Based on where projects are at and their desire to > >> participate in helping to integrate (and do TCK testing :). > > > > ummm 2 * 2 * 2 == 8 > > > > I could be very wrong but I thought that the cmp 2.1 support in > > openejb3 was relying on openjpa-specific features. If so I wonder > > if it will be tricky to run the tck on other jpa implementations. > > Well, we depend on being able to listen to events on the EM which > there is no spec interface for. I'm sure Cayanne has and interface > that can provide us with the events, and when they send us the info > we can add a hook for their Impl. > > In general, I think we should just pick a single JPA implementation > to ship with G because it is very easy for an application to request > a different implementation using specification defined properties. > > Of course that will leave us with 4 javaee assemblies and 2 minimal > assemblies. > > -dain > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
How hard is it to switch between the different assemblies once the TCK testing environment is setup? If it is easy enough, maybe we should first test all 8 assemblies and then concentrate on only those that pass the most tests. Jarek On 1/9/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF+Cayenne) is enough. All components should be tested at least once. If we get time, we could do more :) -- dims On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > On Jan 7, 2007, at 9:38 PM, David Jencks wrote: > > > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: > > > >> I was thinking about M2 this weekend and was considering many of > >> the challenges we face in putting out certified releases. Up till > >> now the number of permutations has been pretty limited and that > >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer > >> that simple. Here are the choices I know of today: > >> > >> Web Container (Tomcat / Jetty) > >> WebServices (Axis 2 / CXF) > >> EJB 3.0 Persistence (OpenJPA / Cayenne) > >> > >> I think this makes 6 different assemblies and of course 6 separate > >> certification efforts. Perhaps we can do this and perhaps we > >> can't. Based on where projects are at and their desire to > >> participate in helping to integrate (and do TCK testing :). > > > > ummm 2 * 2 * 2 == 8 > > > > I could be very wrong but I thought that the cmp 2.1 support in > > openejb3 was relying on openjpa-specific features. If so I wonder > > if it will be tricky to run the tck on other jpa implementations. > > Well, we depend on being able to listen to events on the EM which > there is no spec interface for. I'm sure Cayanne has and interface > that can provide us with the events, and when they send us the info > we can add a hook for their Impl. > > In general, I think we should just pick a single JPA implementation > to ship with G because it is very easy for an application to request > a different implementation using specification defined properties. > > Of course that will leave us with 4 javaee assemblies and 2 minimal > assemblies. > > -dain > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
I think testing say (Tomcat+Axis2+OpenJPA) and (Jetty+CXF+Cayenne) is enough. All components should be tested at least once. If we get time, we could do more :) -- dims On 1/8/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jan 7, 2007, at 9:38 PM, David Jencks wrote: > On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: > >> I was thinking about M2 this weekend and was considering many of >> the challenges we face in putting out certified releases. Up till >> now the number of permutations has been pretty limited and that >> has been Jetty and Tomcat. With Java EE 5.0 life is no longer >> that simple. Here are the choices I know of today: >> >> Web Container (Tomcat / Jetty) >> WebServices (Axis 2 / CXF) >> EJB 3.0 Persistence (OpenJPA / Cayenne) >> >> I think this makes 6 different assemblies and of course 6 separate >> certification efforts. Perhaps we can do this and perhaps we >> can't. Based on where projects are at and their desire to >> participate in helping to integrate (and do TCK testing :). > > ummm 2 * 2 * 2 == 8 > > I could be very wrong but I thought that the cmp 2.1 support in > openejb3 was relying on openjpa-specific features. If so I wonder > if it will be tricky to run the tck on other jpa implementations. Well, we depend on being able to listen to events on the EM which there is no spec interface for. I'm sure Cayanne has and interface that can provide us with the events, and when they send us the info we can add a hook for their Impl. In general, I think we should just pick a single JPA implementation to ship with G because it is very easy for an application to request a different implementation using specification defined properties. Of course that will leave us with 4 javaee assemblies and 2 minimal assemblies. -dain -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 8, 2007, at 11:59 AM, Andrus Adamchik wrote: On Jan 8, 2007, at 9:39 PM, Dain Sundstrom wrote: Well, we depend on being able to listen to events on the EM which there is no spec interface for. I'm sure Cayanne has and interface that can provide us with the events, and when they send us the info we can add a hook for their Impl. What kind of events? We need afterLoad, beforeStore, afterAttach, beforeDelete, and afterDetach so we can make the proper EJB Entity bean callbacks. The code we use for OpenJPA is here: http://svn.apache.org/viewvc/incubator/openejb/trunk/openejb3/ container/openejb-core/src/main/java/org/apache/openejb/core/cmp/jpa/ JpaCmpEngine.java?revision=492404&view=markup&pathrev=492419 look for OpenJPALifecycleListener inner class. -dain
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 8, 2007, at 9:39 PM, Dain Sundstrom wrote: Well, we depend on being able to listen to events on the EM which there is no spec interface for. I'm sure Cayanne has and interface that can provide us with the events, and when they send us the info we can add a hook for their Impl. What kind of events? Andrus
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 8, 2007, at 9:46 PM, Dain Sundstrom wrote: FWIU, JPA has a separate TCK for certification. You should ask on jcp-open at apache.org. We'll try that - thanks! Andrus
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 8, 2007, at 10:18 AM, Andrus Adamchik wrote: (I'm not sure of the state of Cayenne) It looks like Geronimo are the caretakers of the Sun TCK at Apache (something we, Cayenne developers, still can't get access to). While Cayenne JPA provider requires fair amount of work to be compliant, it would be really helpful in our own testing effort if we could test our provider as a part of Geronimo assembly against the TCK. A decision on the readiness of a given assembly can be made around a release time, but it would be really nice if we could participate in the TCK testing. How can we help with this BTW? FWIU, JPA has a separate TCK for certification. You should ask on jcp-open at apache.org. -dain
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 7, 2007, at 9:38 PM, David Jencks wrote: On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: I was thinking about M2 this weekend and was considering many of the challenges we face in putting out certified releases. Up till now the number of permutations has been pretty limited and that has been Jetty and Tomcat. With Java EE 5.0 life is no longer that simple. Here are the choices I know of today: Web Container (Tomcat / Jetty) WebServices (Axis 2 / CXF) EJB 3.0 Persistence (OpenJPA / Cayenne) I think this makes 6 different assemblies and of course 6 separate certification efforts. Perhaps we can do this and perhaps we can't. Based on where projects are at and their desire to participate in helping to integrate (and do TCK testing :). ummm 2 * 2 * 2 == 8 I could be very wrong but I thought that the cmp 2.1 support in openejb3 was relying on openjpa-specific features. If so I wonder if it will be tricky to run the tck on other jpa implementations. Well, we depend on being able to listen to events on the EM which there is no spec interface for. I'm sure Cayanne has and interface that can provide us with the events, and when they send us the info we can add a hook for their Impl. In general, I think we should just pick a single JPA implementation to ship with G because it is very easy for an application to request a different implementation using specification defined properties. Of course that will leave us with 4 javaee assemblies and 2 minimal assemblies. -dain
Re: Assemblies assemblies everywhere and which one to ship?
(I'm not sure of the state of Cayenne) It looks like Geronimo are the caretakers of the Sun TCK at Apache (something we, Cayenne developers, still can't get access to). While Cayenne JPA provider requires fair amount of work to be compliant, it would be really helpful in our own testing effort if we could test our provider as a part of Geronimo assembly against the TCK. A decision on the readiness of a given assembly can be made around a release time, but it would be really nice if we could participate in the TCK testing. How can we help with this BTW? Andrus On Jan 8, 2007, at 8:08 PM, Matt Hogstrom wrote: I don't think its just TCK. I agree we should scope the configuration to a limited set but I'm also concerned about making assemblies available. Given my math challenged 6 which is really 8 I don't think we would want to generate every one of them. So I think from the download page perspective I think we need to identify the assemblies which may be something like: Jetty Axis OpenJPA Tomcat CXF OpenJPA (I'm not sure of the state of Cayenne) The provide a "stubbed out" version that would allow a user to install their preferred component via a plugin. Just a thought. On Jan 8, 2007, at 9:53 AM, Jason Dillon wrote: On Jan 8, 2007, at 12:38 AM, David Jencks wrote: rather than saying we'll only ship when we have all 6 it seems more appropriate to me to say that we'll ship the assemblies that people are willing to work on which includes TCK testing. Any other ideas on how to handle this? Anyone interested in a specific configuration and want to step up to TCK testing? I think maybe we should concentrate on packaging things as plugins, although this doesn't really affect what we run through the tck. Do we really need to run the TCK on every possible permutation? Why don't we bless a specific configuration and then concentrate the TCK effort on that specific assembly? --jason Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
I don't think its just TCK. I agree we should scope the configuration to a limited set but I'm also concerned about making assemblies available. Given my math challenged 6 which is really 8 I don't think we would want to generate every one of them. So I think from the download page perspective I think we need to identify the assemblies which may be something like: Jetty Axis OpenJPA Tomcat CXF OpenJPA (I'm not sure of the state of Cayenne) The provide a "stubbed out" version that would allow a user to install their preferred component via a plugin. Just a thought. On Jan 8, 2007, at 9:53 AM, Jason Dillon wrote: On Jan 8, 2007, at 12:38 AM, David Jencks wrote: rather than saying we'll only ship when we have all 6 it seems more appropriate to me to say that we'll ship the assemblies that people are willing to work on which includes TCK testing. Any other ideas on how to handle this? Anyone interested in a specific configuration and want to step up to TCK testing? I think maybe we should concentrate on packaging things as plugins, although this doesn't really affect what we run through the tck. Do we really need to run the TCK on every possible permutation? Why don't we bless a specific configuration and then concentrate the TCK effort on that specific assembly? --jason Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 8, 2007, at 12:38 AM, David Jencks wrote: rather than saying we'll only ship when we have all 6 it seems more appropriate to me to say that we'll ship the assemblies that people are willing to work on which includes TCK testing. Any other ideas on how to handle this? Anyone interested in a specific configuration and want to step up to TCK testing? I think maybe we should concentrate on packaging things as plugins, although this doesn't really affect what we run through the tck. Do we really need to run the TCK on every possible permutation? Why don't we bless a specific configuration and then concentrate the TCK effort on that specific assembly? --jason
Re: Assemblies assemblies everywhere and which one to ship?
2 is bad enough already... 6 or 8 or 10 or whatever is insane IMO. Just because G is flexible enough to be configured in such different ways, does not mean that we need (or should) to ship assemblies with those configurations or run the TCK against them. I think we really need to pick one and then use that for the assembly and TCK testing. Our inability to pick between jetty and tomcat is already causing a bunch of unneeded burden on the team... I would really like to see us avoid that with other components, as well as finally picking a webcontainer. --jason On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: I was thinking about M2 this weekend and was considering many of the challenges we face in putting out certified releases. Up till now the number of permutations has been pretty limited and that has been Jetty and Tomcat. With Java EE 5.0 life is no longer that simple. Here are the choices I know of today: Web Container (Tomcat / Jetty) WebServices (Axis 2 / CXF) EJB 3.0 Persistence (OpenJPA / Cayenne) I think this makes 6 different assemblies and of course 6 separate certification efforts. Perhaps we can do this and perhaps we can't. Based on where projects are at and their desire to participate in helping to integrate (and do TCK testing :). rather than saying we'll only ship when we have all 6 it seems more appropriate to me to say that we'll ship the assemblies that people are willing to work on which includes TCK testing. Any other ideas on how to handle this? Anyone interested in a specific configuration and want to step up to TCK testing? Matt Hogstrom [EMAIL PROTECTED]
Re: Assemblies assemblies everywhere and which one to ship?
On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote: I was thinking about M2 this weekend and was considering many of the challenges we face in putting out certified releases. Up till now the number of permutations has been pretty limited and that has been Jetty and Tomcat. With Java EE 5.0 life is no longer that simple. Here are the choices I know of today: Web Container (Tomcat / Jetty) WebServices (Axis 2 / CXF) EJB 3.0 Persistence (OpenJPA / Cayenne) I think this makes 6 different assemblies and of course 6 separate certification efforts. Perhaps we can do this and perhaps we can't. Based on where projects are at and their desire to participate in helping to integrate (and do TCK testing :). ummm 2 * 2 * 2 == 8 I could be very wrong but I thought that the cmp 2.1 support in openejb3 was relying on openjpa-specific features. If so I wonder if it will be tricky to run the tck on other jpa implementations. rather than saying we'll only ship when we have all 6 it seems more appropriate to me to say that we'll ship the assemblies that people are willing to work on which includes TCK testing. Any other ideas on how to handle this? Anyone interested in a specific configuration and want to step up to TCK testing? I think maybe we should concentrate on packaging things as plugins, although this doesn't really affect what we run through the tck. thanks david jencks Matt Hogstrom [EMAIL PROTECTED]
