Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
On 4/9/07, Matt Benson [EMAIL PROTECTED] wrote: --- Simon Kitching [EMAIL PROTECTED] wrote: I'm definitely interested. BeanUtils tries to do too many things in one lib, and besides it is really ugly internally. So something like Morph would be very useful to have. To be honest, Morph currently does probably as much as or more than BeanUtils. However, its functionality areas are fairly well compartmentalized so that a Morph @ ASF could be easily digested into smaller components over time. This is what I actually hope to see, FWIW... Never did reply to this. Sorry. I'm aiming to call a proper vote on commons-dev about TLP stuff in a week or so (for the board meeting in a month) then I'm +1 for Morph to wind its way through the Incubator into Commons after that. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
--- Simon Kitching [EMAIL PROTECTED] wrote: I'm definitely interested. BeanUtils tries to do too many things in one lib, and besides it is really ugly internally. So something like Morph would be very useful to have. To be honest, Morph currently does probably as much as or more than BeanUtils. However, its functionality areas are fairly well compartmentalized so that a Morph @ ASF could be easily digested into smaller components over time. This is what I actually hope to see, FWIW... -Matt For a commons-digester 2.x (if it ever occurs) I would definitely like to get rid of the existing BeanUtils dependency, and that means finding some alternative. However I don't personally have the time necessary to work on this at the moment. Regards, Simon On Tue, 2007-04-03 at 07:16 -0700, Matt Benson wrote: Just wanted to confirm the complete lack of interest here. Unless I hear differently, I'll assume that's lazy [-0]s all around and let the matter drop. Thanks, Matt --- Matt Benson [EMAIL PROTECTED] wrote: Morph's incubation proposal follows, sent here first in an effort to gain the sponsorship of Jakarta, and possibly to attract mentors as well. :) Thanks! Morph defines a comprehensive API for performing object-to-object conversions in Java. PROPOSAL BACKGROUND/RATIONALE As information flows through an application, it undergoes multiple transformations. While the most prevalent examples of this in the J2EE space are well-known (e.g. HTTP request parameters to domain/data transfer objects, DTOs to domain objects) the overall problem space is characterized by the lack of a simple, well-known, conveniently extensible solution. At least one JSR (295) describes such a facility as a dependency. Having identified the basic commonalities among the best known application operations requiring object conversion, Morph consolidates these into a single API which, along with various bundled implementation classes, seeks to achieve the oft-repeated software development goal of making the simple things easy, and the hard things possible with regard to its problem domain. CURRENT STATUS Meritocracy: The Morph team is eager to invest more fully in the meritocracy approach taken by the ASF. To date, however, Morph's development team has been accumulated by a sort of meritocracy-on-spec approach: Matt Benson was originally given commit rights solely on the basis of his ideas; only later did his work vindicate that decision. [If sponsored by Jakarta: This is a similar approach to that taken in the Jakarta community: a community member simply announces his desire to work on a component, then proceeds with the community's blessing.] Community: It is somewhat difficult to gauge the size of Morph's community. There have been modest but consistent downloads of the project since its initial prerelease: these average 21/month over 28 months. The traffic on its user and developer lists is similarly light, but several bug fixes and enhancements have resulted from the input of Morph's users. An additional possible benefit of Morph's joining the Apache community is that increased cooperation with and buy-in from other ASF projects may increase its user and/or developer communities. Core Developers: Matt Sgarlata is Morph's founding architect and developer. He has been a member of the Jakarta and Struts user communities for some years. Matt Benson is a member of the Apache Ant PMC and a Jakarta committer, so is familiar with (and fond of) the consensus and transparency encouraged in ASF development. Alignment: Morph currently contains interoperability code for commons-beanutils, commons-chain, and Velocity. Because it is Morph's secondary purpose to provide implementations of common conversions, code that facilitates Morph's use with well-known libraries in easily anticipated ways is considered in-scope. As has already been implied, it is expected that citizenship at the ASF would facilitate cooperation with existing projects to mutal benefit. Finally, precedent demonstrating the desirability of such a project at Apache exists in the form of Jakarta commons-convert (this component ultimately failed to achieve maturity). Morph's original design specifications are actually the generic subset of those drafted on the commons-dev mailing list as a next-generation implementation of this project. KNOWN RISKS Orphaned Products: The Morph developers are part of its user base. Object conversion may be relevant to any of various components of a basic Java application. The risk of itch cessation is therefore
Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
I'm definitely interested. BeanUtils tries to do too many things in one lib, and besides it is really ugly internally. So something like Morph would be very useful to have. For a commons-digester 2.x (if it ever occurs) I would definitely like to get rid of the existing BeanUtils dependency, and that means finding some alternative. However I don't personally have the time necessary to work on this at the moment. Regards, Simon On Tue, 2007-04-03 at 07:16 -0700, Matt Benson wrote: Just wanted to confirm the complete lack of interest here. Unless I hear differently, I'll assume that's lazy [-0]s all around and let the matter drop. Thanks, Matt --- Matt Benson [EMAIL PROTECTED] wrote: Morph's incubation proposal follows, sent here first in an effort to gain the sponsorship of Jakarta, and possibly to attract mentors as well. :) Thanks! Morph defines a comprehensive API for performing object-to-object conversions in Java. PROPOSAL BACKGROUND/RATIONALE As information flows through an application, it undergoes multiple transformations. While the most prevalent examples of this in the J2EE space are well-known (e.g. HTTP request parameters to domain/data transfer objects, DTOs to domain objects) the overall problem space is characterized by the lack of a simple, well-known, conveniently extensible solution. At least one JSR (295) describes such a facility as a dependency. Having identified the basic commonalities among the best known application operations requiring object conversion, Morph consolidates these into a single API which, along with various bundled implementation classes, seeks to achieve the oft-repeated software development goal of making the simple things easy, and the hard things possible with regard to its problem domain. CURRENT STATUS Meritocracy: The Morph team is eager to invest more fully in the meritocracy approach taken by the ASF. To date, however, Morph's development team has been accumulated by a sort of meritocracy-on-spec approach: Matt Benson was originally given commit rights solely on the basis of his ideas; only later did his work vindicate that decision. [If sponsored by Jakarta: This is a similar approach to that taken in the Jakarta community: a community member simply announces his desire to work on a component, then proceeds with the community's blessing.] Community: It is somewhat difficult to gauge the size of Morph's community. There have been modest but consistent downloads of the project since its initial prerelease: these average 21/month over 28 months. The traffic on its user and developer lists is similarly light, but several bug fixes and enhancements have resulted from the input of Morph's users. An additional possible benefit of Morph's joining the Apache community is that increased cooperation with and buy-in from other ASF projects may increase its user and/or developer communities. Core Developers: Matt Sgarlata is Morph's founding architect and developer. He has been a member of the Jakarta and Struts user communities for some years. Matt Benson is a member of the Apache Ant PMC and a Jakarta committer, so is familiar with (and fond of) the consensus and transparency encouraged in ASF development. Alignment: Morph currently contains interoperability code for commons-beanutils, commons-chain, and Velocity. Because it is Morph's secondary purpose to provide implementations of common conversions, code that facilitates Morph's use with well-known libraries in easily anticipated ways is considered in-scope. As has already been implied, it is expected that citizenship at the ASF would facilitate cooperation with existing projects to mutal benefit. Finally, precedent demonstrating the desirability of such a project at Apache exists in the form of Jakarta commons-convert (this component ultimately failed to achieve maturity). Morph's original design specifications are actually the generic subset of those drafted on the commons-dev mailing list as a next-generation implementation of this project. KNOWN RISKS Orphaned Products: The Morph developers are part of its user base. Object conversion may be relevant to any of various components of a basic Java application. The risk of itch cessation is therefore minimized; Morph should continue to be an applicable technology at low risk for being abandoned by its developers. Inexperience with Open Source: As previously indicated, one of the initial committers has some years of experience as a committer and PMC member at the ASF. Additionally, Morph has always been open-source software, with its evolution being directly guided by user input and developer consensus in similar fashion to other Apache projects. Homogenous
Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
Sorry for the lack of reply. I'm completely interested in mentoring (Roller just went TLP, and OpenEJB should be going that way very soon, so I'm free on the Incubator stuff right now). I'll reply more later. Anyone else interested? Hen On 4/3/07, Matt Benson [EMAIL PROTECTED] wrote: Just wanted to confirm the complete lack of interest here. Unless I hear differently, I'll assume that's lazy [-0]s all around and let the matter drop. Thanks, Matt --- Matt Benson [EMAIL PROTECTED] wrote: Morph's incubation proposal follows, sent here first in an effort to gain the sponsorship of Jakarta, and possibly to attract mentors as well. :) Thanks! Morph defines a comprehensive API for performing object-to-object conversions in Java. PROPOSAL BACKGROUND/RATIONALE As information flows through an application, it undergoes multiple transformations. While the most prevalent examples of this in the J2EE space are well-known (e.g. HTTP request parameters to domain/data transfer objects, DTOs to domain objects) the overall problem space is characterized by the lack of a simple, well-known, conveniently extensible solution. At least one JSR (295) describes such a facility as a dependency. Having identified the basic commonalities among the best known application operations requiring object conversion, Morph consolidates these into a single API which, along with various bundled implementation classes, seeks to achieve the oft-repeated software development goal of making the simple things easy, and the hard things possible with regard to its problem domain. CURRENT STATUS Meritocracy: The Morph team is eager to invest more fully in the meritocracy approach taken by the ASF. To date, however, Morph's development team has been accumulated by a sort of meritocracy-on-spec approach: Matt Benson was originally given commit rights solely on the basis of his ideas; only later did his work vindicate that decision. [If sponsored by Jakarta: This is a similar approach to that taken in the Jakarta community: a community member simply announces his desire to work on a component, then proceeds with the community's blessing.] Community: It is somewhat difficult to gauge the size of Morph's community. There have been modest but consistent downloads of the project since its initial prerelease: these average 21/month over 28 months. The traffic on its user and developer lists is similarly light, but several bug fixes and enhancements have resulted from the input of Morph's users. An additional possible benefit of Morph's joining the Apache community is that increased cooperation with and buy-in from other ASF projects may increase its user and/or developer communities. Core Developers: Matt Sgarlata is Morph's founding architect and developer. He has been a member of the Jakarta and Struts user communities for some years. Matt Benson is a member of the Apache Ant PMC and a Jakarta committer, so is familiar with (and fond of) the consensus and transparency encouraged in ASF development. Alignment: Morph currently contains interoperability code for commons-beanutils, commons-chain, and Velocity. Because it is Morph's secondary purpose to provide implementations of common conversions, code that facilitates Morph's use with well-known libraries in easily anticipated ways is considered in-scope. As has already been implied, it is expected that citizenship at the ASF would facilitate cooperation with existing projects to mutal benefit. Finally, precedent demonstrating the desirability of such a project at Apache exists in the form of Jakarta commons-convert (this component ultimately failed to achieve maturity). Morph's original design specifications are actually the generic subset of those drafted on the commons-dev mailing list as a next-generation implementation of this project. KNOWN RISKS Orphaned Products: The Morph developers are part of its user base. Object conversion may be relevant to any of various components of a basic Java application. The risk of itch cessation is therefore minimized; Morph should continue to be an applicable technology at low risk for being abandoned by its developers. Inexperience with Open Source: As previously indicated, one of the initial committers has some years of experience as a committer and PMC member at the ASF. Additionally, Morph has always been open-source software, with its evolution being directly guided by user input and developer consensus in similar fashion to other Apache projects. Homogenous Developers: On the plus side, the initial committers are united only by their common interest in Morph (and their coincidental first names and middle initials). However, both hail from the United States, and acknowledge this as a less-than-optimal level of diversity. As Java Locale support is a key strength of Morph's transformation API,
