Re: Proposed changes to plan elements related to classloaders.
I've done some more historical research and now want to keep the include element and am inclined to keep the import element with its current name. Discussion inline. On Nov 18, 2005, at 3:35 PM, David Jencks wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group Now I want: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:import minOccurs=0 maxOccurs=unbounded/ xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/ !-- this should be a ref also -- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. Reasons for keeping import: 1. We have already put out M5 using import, and I remember promising that we wouldn't change the xml incompatibly. 2. Apparently the term import is used by osgi for a similar purpose. include is removed. Reasons for keeping include: What include does is to copy the contents of the dependency into the car file. This is not particularly useful for server side configurations that depend on other configurations, and really need a repository. However, its really intended for building small executable jars that include everything they need to run. For instance the shutdown jar would be an ideal candidate for this. We can include as much kernel, gbeans, etc as we need and still fit it all into a single jar that can be moved around away from the repo and still work without reliance on fragile mechanisms such as manifest classpath. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. I still want to do this. thanks david jencks Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
This sounds great! Please further split out the data types so they're not all dependencyType (even though they all have URIs or maven chunks). Let's have one type where URI means a configID, and a separate type where URI means an index into the local repository. Maybe they could just be called configIDType and repositoryEntryType. Even if the contents are the same, they have different meanings and we can document them accordingly in the schema. Also, parent sounds pretty clear as to what it is, but dependency doesn't necessarily (isn't a parent kind of a dependency?). It might be nice to try to think of a name to use instead of dependency that says code to add to the classloader for the current module, like maybe additional-jar? Thanks, Aaron On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
There is a JIRA issue I re-opened on those classes tags. They are duped in Tomcat and Jetty. I would like to see them at the web builder level. David Jencks wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
On Nov 18, 2005, at 3:58 PM, Aaron Mulder wrote: This sounds great! Please further split out the data types so they're not all dependencyType (even though they all have URIs or maven chunks). Let's have one type where URI means a configID, and a separate type where URI means an index into the local repository. Maybe they could just be called configIDType and repositoryEntryType. Even if the contents are the same, they have different meanings and we can document them accordingly in the schema. I'd be willing to change the type name to something more neutral, but not to duplicate it. We can document the elements rather than the types. Considering the likely future I'd rather leave it dependencyType. Also, parent sounds pretty clear as to what it is, but dependency doesn't necessarily (isn't a parent kind of a dependency?). It might be nice to try to think of a name to use instead of dependency that says code to add to the classloader for the current module, like maybe additional-jar? Dain has a plan that I hope he will explain soon that should make all of these elements identical in form, name, and function. Dependency is what maven calls them and I don't see a strong reason to change their name. thanks david jencks Thanks, Aaron On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
On Nov 18, 2005, at 4:05 PM, Jeff Genender wrote: There is a JIRA issue I re-opened on those classes tags. They are duped in Tomcat and Jetty. I would like to see them at the web builder level. I noticed they were missing from the generic schema. My local changes use the same group everywhere including web-builder, so this would fix your issue? thanks david jencks David Jencks wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
Yes! ;-) David Jencks wrote: On Nov 18, 2005, at 4:05 PM, Jeff Genender wrote: There is a JIRA issue I re-opened on those classes tags. They are duped in Tomcat and Jetty. I would like to see them at the web builder level. I noticed they were missing from the generic schema. My local changes use the same group everywhere including web-builder, so this would fix your issue? thanks david jencks David Jencks wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: Dain has a plan that I hope he will explain soon that should make all of these elements identical in form, name, and function. Dependency is what maven calls them and I don't see a strong reason to change their name. If there's a plan on the way, why are we discussing this before we hear the plan? Dain, speak up, man! Aaron On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
On Nov 18, 2005, at 4:17 PM, Aaron Mulder wrote: On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: Dain has a plan that I hope he will explain soon that should make all of these elements identical in form, name, and function. Dependency is what maven calls them and I don't see a strong reason to change their name. If there's a plan on the way, why are we discussing this before we hear the plan? Dain, speak up, man! IIUC his plan requires maven 2 so won't be feasible for geronimo 1.0 david jencks Aaron On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: It's become apparent recently that some of the elements in our plans related to classloading are a bit confusing. In particular, there is an include element that no one is sure what is for and is not used, and a similarly named import element that is like the parentId, only better :-). Also the lists of special classes for the classloader are in between the import and dependency elements. I'd like to change the schema for all plans to use this: xs:group name=classloader-infoGroup xs:sequence xs:element ref=sys:parent minOccurs=0 maxOccurs=unbounded/ !--xs:element name=include type=sys:dependencyType minOccurs=0 maxOccurs=unbounded/-- xs:element ref=sys:dependency minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:hidden-classes minOccurs=0 maxOccurs=unbounded/ xs:element ref=sys:non-overridable-classes minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:group The differences are that: import is renamed parent. This seems less confusing to me. I can support backwards compatibility in most plans, although perhaps not plain gbean plans. include is removed. the class lists are moved to the end. This makes more sense to me, in that first we have the info on what goes into the current classloader in the way of parents and contents, and then we have the modifications to that list. Comments? thanks david jencks
Re: Proposed changes to plan elements related to classloaders.
On Nov 18, 2005, at 4:24 PM, David Jencks wrote: On Nov 18, 2005, at 4:17 PM, Aaron Mulder wrote: On 11/18/05, David Jencks [EMAIL PROTECTED] wrote: Dain has a plan that I hope he will explain soon that should make all of these elements identical in form, name, and function. Dependency is what maven calls them and I don't see a strong reason to change their name. If there's a plan on the way, why are we discussing this before we hear the plan? Dain, speak up, man! IIUC his plan requires maven 2 so won't be feasible for geronimo 1.0 I'm going to try to type it up tomorrow (traveling tomorrow so should have free time on the airplane). One of the parts of the idea is to use maven-artifact from maven 2 to manage the repository and to help with class loader building, so staying close to the maven 2 xml format will help. -dain
