Hi, On Thu, 2008-05-08 at 13:39 -0700, Jihoon Kim wrote: > Thanks to both for your responses and feedbacks and I will try to > answer some of the questions regarding the contribution. > > (a) > Adobe Flex has been open sourced through MPL [as noted in a previous > thread]. But since I still wanted to be cautious; I have asked the > users to download the free Adobe Flex SDK when using these components.
It does appear that the "flex sdk" itself is indeed open source. But in the end, flex is just a way to drive a Flash implementation, yes? And AFAIK the only flash player that exists which Flex can drive is a binary download from Adobe. Am I wrong? I'm certainly no expert in this area.. It appears that the MPL license is also a little tricky to deal with. I'm no expert here, but here's a link to some (draft) ASF policy: http://people.apache.org/~rubys/3party.html > > (b) > It is true that the contribution relies on Adobe Flex's SDK in > compiling the mxml file to swf file and that the contribution is > inherently dependent upon Flex, but the idea and desire for this > contribution is to glue Adobe Flex to JavaServer Faces components. > This way: > (1) Users can still perform the binding of data to managed beans > on the server side for their RIA. > (2) Users can include swf into their regular applications without > performing anything outside of Java. > (3) Users can create apps with mixture of Flash, JavaScript, and > HTML with absolute abstraction. > > Also, since it generates the preMxml, Mxml, and SWF files to the > directories, debugging is made easy. I'm not disagreeing with your goal or architecture. If Flex can be encapsulated as a component-set or renderkit for jsf, then that would certainly be useful for some people. But the ASF is not the only place in the world where JSF-related development occurs. The question is whether this project would benefit by being within the ASF, and whether the ASF would benefit by hosting this project. > (c) > I assume that the group which will maintain this code will increase in > number, because personally I think it to be one of the areas that has > a lot of potential and do think that it will be able to bring a lot of > additional ideas to the project. For example, I initially wanted to > create components that detect the browser setting and either direct > application to components based on Dojo or Adobe Flex, but thought > this would be better for separation and perhaps in the future there > could be components that performs this action. This code is not really just a patch to an existing project; it is quite a lot of code and requires specific knowledge to maintain. So IMO it needs to be treated like a separate project within myfaces. The problem is that it's not possible to accept a project, publish it on an ASF site as an official ASF project, then hope developers join. If they don't then the ASF is left with a project that it cannot maintain, and that damages our reputation. If a project can find half-a-dozen people, not all employed by the same company, including some existing apache committers, then that would probably be enough to qualify as a "sustainable" development community. Otherwise, there is a special area within the ASF called "the incubator" where projects can start and try to build the necessary community to become an "official" project. See: incubator.apache.org Would you mind telling us why you wrote this code? Is it a personal project (you just thought it would be cool), or are you planning to commercially offer related services, or is this sponsored by some specific company? Note that commercial reasons are not a problem; Oracle are a major contributor to Trinidad for example. > (d) > As for this one, I was hoping if I could get some feedback on where > the contribution should be placed at, if it is to be accepted. I would suggest that the best place would be as a new subproject, like "orchestra" or "portlet bridge" are. It would definitely belong in the MyFaces family (rather than anywhere else in Apache) but I don't think it fits as part of Tomahawk. As I noted earlier, people who use tomahawk won't always want Flex, and people who want Flex won't always want the other tomahawk components. It could also be a new "myfaces commons" module, but we haven't really figured out how to structure those anyway. And it isn't really a "common module", but a component library just like tomahawk is. Regards, Simon
