Alex, Sorry for the delay, I have been very busy last week with the new GraniteDS release, among other things.
My answers below: 2012/11/14 Alex Harui <aha...@adobe.com> > > > > On 11/14/12 2:57 PM, "Franck Wolff" <franck.wo...@graniteds.org> wrote: > > > Alex, > > > > My answers below: > > > > 2012/11/14 Alex Harui <aha...@adobe.com> > > > >> OK, I skimmed through the files. Code-wise, it looks very nice, so > thank > >> you for being willing to donate this work. > >> > >> One thing that was bugging me as I was looking at the code is this: Did > you > >> look at the Java code for the Java equivalents when writing your code, > are > >> any portions of your code "substantial copies" of the Java sources, and > if > >> so, does Java's source license allow you to leverage their code, and if > so, > >> without attribution? I would think there are BigDecimal equivalents in > >> other platforms as well so this must all be "ok", but I think we need > to be > >> sure. > >> > > > > Good point. All classes from the org.granite.math package were written > from > > scratch, but part of the BigDecimal code is inspired (not copied though) > > from the Java implementation. What do you suggest in order to make sure > > that there is no legal issue? > If you've never seen their code, I think we are good. > Well, I did see their code but I didn't copy it and I don't think this a problem. However, you can double-check upon this potential issue. > > > > > >> Some other questions: > >> 1) Terminology/Names: I saw a reference to "Bean" in one of the files. > >> That > >> is also a Java concept, but is that term trademarked? I think > "JavaBean" > >> is, but I think it would be hard to trademark just "Bean". > >> > > > > I don't think Bean is a trademark and we can change that term if > necessary. > OK, I think we are ok here as well. > > > > > >> 2) Packaging: All the packages are currently org.granite.*. Do you > have a > >> large body of users who will complain loudly if you change the package > >> name? > >> > > > > I don't think so: changing package names is just a research / replace > > operation... > OK, we'll I'm open to suggestions for package names and the swc name. I > think it shouldn't have granite in it because it is your company's name. So > org.apache.flex.math > org.apache.flex.reflect > org.apache.flex.validation > And for the swc, other than the Container dependency and ObjectUtil > dependency, I didn't see a lot of other Flex dependencies so I think all of > these classes can go in one new swc? I don't see a reason to put it under > "experimental". I considered names like "asjava.swc" since these are all > based on java features? > Ok, I can be whatever the community wants. > > > > > > >> 3) I noticed FormValidator had a reference to mx.core.Container. That > ties > >> you to the "mx" project in SVN. Does it work with Spark Form? > >> > > > > Yes, it works with Flex 4 and Spark Form. The explicit use and import of > > mx.core.Container could be changed to something based on reflection if > > necessary. > This is not important for the donation, but Container and ObjectUtil bring > in a huge set of dependencies which will not be good for smaller apps. > We can get rid of this dependency later. Franck. > > > > > > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
