You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Om <bi...@gmail.com> on 2012/11/09 01:49:07 UTC
Re: Proposal for contributing code from GraniteDS
Franck,
Sorry it a while for me to respond. I am assuming you are still interested
in contributing the validation framework to Apache Flex. Please let me
know how you would like to proceed. I have some free cycles and I can help
committing it to the codebase.
Thanks,
Om
On Wed, Oct 3, 2012 at 5:56 AM, Franck Wolff <fr...@graniteds.org>wrote:
> The goal is of course to give the validation framework with the less
> possible dependencies. Refactoring is an option but it should be minimal in
> order to preserve the current stability of our code (which is very good so
> far). We don't want to contribute an untested, deeply modified and
> potentially unstable piece of code to Apache.
>
> Franck.
>
> 2012/10/3 Carlos Rovira <ca...@codeoscopic.com>
>
> > Hi Franck,
> >
> > IMHO the only problem I see is that user could end with dependent
> > frameworks that could be removed if some refactor is applyed, in this
> > case with reflect classes from granite and other microframework like
> > swiz, parsley or other.
> >
> > Maybe reflect classes could be cut to the minimun in order to drop
> > weight to minimum. Maybe math classes could be cut in the same way. In
> > both cases event refactored to be plug into other frameworks...
> >
> >
> > 2012/10/3 Franck Wolff <fr...@graniteds.org>:
> > > Hi Carlos,
> > >
> > > math & reflect (I forgot about this one) are mandatory. util &
> > collections
> > > can certainly be refactored in order to lower dependencies. I need to
> > check
> > > about that but, basically, we are ready to contribute all required
> code.
> > >
> > > Thanks for your feedback,
> > > Franck.
> > >
> > > 2012/10/3 Carlos Rovira <ca...@codeoscopic.com>
> > >
> > >> Hi Franck,
> > >>
> > >> I was looking at the validation source in graniteds and I see that
> > >> dependencies are a bit more complex. From what I see those are the
> > >> packages needed:
> > >>
> > >> * math
> > >> * reflect
> > >> * util
> > >> * collections
> > >>
> > >> maybe some other class could be needed...
> > >>
> > >> Maybe some refactor could be done to avoid overhead of classes that
> > >> really are not used/needed
> > >>
> > >> Best,
> > >>
> > >> Carlos
> > >>
> > >>
> > >>
> > >> 2012/10/2 Om <bi...@gmail.com>:
> > >> > Thanks for the detailed responses, Franck. I think this could work
> > and
> > >> > would make a great addition to Flex.
> > >> >
> > >> > PPMC folks, any objections? Or should we take a formal vote on
> this?
> > >> >
> > >> > What should be the next steps?
> > >> >
> > >> > Thanks,
> > >> > Om
> > >> >
> > >> > On Wed, Sep 26, 2012 at 3:07 AM, Franck Wolff <
> > >> franck.wolff@graniteds.org>wrote:
> > >> >
> > >> >> Om,
> > >> >>
> > >> >> 2012/9/25 Om <bi...@gmail.com>
> > >> >>
> > >> >> > Franck,
> > >> >> >
> > >> >> > My initial reaction after reading the documentation is that this
> > would
> > >> >> be a
> > >> >> > great addition to the Flex framework.
> > >> >> >
> > >> >> > If you don't mind, maybe you could address these concerns I have?
> > >> >> >
> > >> >> > 1. Can we make sure that this approach does not tie Flex to
> > specific
> > >> >> > server side solution (Java in this case)?
> > >> >> >
> > >> >>
> > >> >> The validation can be used standalone, without any server-side
> > >> counterpart:
> > >> >> you can manually annotate your AS3 beans and run a pure client-side
> > >> >> validation process. Usually, these annotations are generated by
> Gas3,
> > >> based
> > >> >> on Java annotations you put on your Java entity beans, but this is
> > just
> > >> a
> > >> >> typical JavaEE usage: the framework doesn't depend on any specific
> > >> server
> > >> >> implementation (Java or not).
> > >> >>
> > >> >> However, I realized after sending my last email that the bean
> > validation
> > >> >> framework relies on our BigDecimal implementation: the
> > DecimalMax/Min,
> > >> >> Digits and Max/Min constraints annotations make internal use of
> > >> BigDecimal
> > >> >> values in order to check the validity of a given field (which can
> be
> > a
> > >> >> String, a Number, an int/uint or a BigDecimal). The purpose of this
> > >> >> dependency is to stick, as much as possible, to the JSR-303
> > >> specification
> > >> >> and to make sure that the validation on the Flex side is consistent
> > with
> > >> >> the validation on the Java side. As a result, we must contribute
> both
> > >> the
> > >> >> Bean Validation and Big Numbers implementations... But even with
> this
> > >> >> addition, there is no dependency to GraniteDS.
> > >> >>
> > >> >> To summarize:
> > >> >>
> > >> >> 1. The Bean Validation in AS3 doesn't depend on GraniteDS or any
> > Java
> > >> >> server-side solution: it comes from a specification written for
> > Java
> > >> EE
> > >> >> developers, it is often used with our code generation tool
> (Gas3),
> > >> but
> > >> >> you
> > >> >> can use it without any specific server side solution (it can be
> > PHP
> > >> or
> > >> >> whatever you want).
> > >> >> 2. It does depend on our BigDecimal implementation, which comes
> > >> >> originally from a Java class but serves a general purpose for
> > >> handling
> > >> >> numbers with arbitrary scale and precision. If you don't
> > explicitly
> > >> use
> > >> >> BigDecimal in your code, and more specifically, if you don't try
> > to
> > >> >> serialize this kind of value, there is again no dependency to
> any
> > >> >> specific
> > >> >> server side solution. If you intend to serialize BigDecimal
> > values,
> > >> the
> > >> >> server, whatever it is, has to handle an "externalization" of
> the
> > >> >> BigDecimal value as a String, which is not a big deal and
> follows
> > the
> > >> >> AMF3
> > >> >> specification (ie: org.granite.math.BigDecimal implements
> > >> >> flash.utils.IExternalizable). There is of course a built-in
> > support
> > >> for
> > >> >> that in GraniteDS, but it is just related to a (de)serialization
> > >> which
> > >> >> not
> > >> >> all used in the Bean Validation framework.
> > >> >>
> > >> >>
> > >> >> 2. Do you think this could go in the SDK itself or would it go
> into
> > an
> > >> >> > ancilliary library, but still part of Flex. Can you suggest a
> > >> package
> > >> >> > structure?
> > >> >> >
> > >> >>
> > >> >> Our current packages structure is:
> > >> >>
> > >> >> org.granite.validation (Bean Validation)
> > >> >> org.granite.math (BigDecimal)
> > >> >>
> > >> >> It could be whatever you want. It can go into an ancillary library,
> > but
> > >> it
> > >> >> would be simpler for users to be able to use it without any
> specific
> > >> >> configuration. Again, it's up to you.
> > >> >>
> > >> >>
> > >> >> > 3. What happens to JSR 303 if/when you contribute the AS3
> portion
> > of
> > >> the
> > >> >> > implementation? Obviously we can't guarantee that Apache Flex
> > will
> > >> >> follow
> > >> >> > that standard always.
> > >> >> >
> > >> >>
> > >> >> An implementation of any JSR doesn't have to follow its evolution.
> At
> > >> the
> > >> >> time we wrote this code and because we are from the Java "world",
> we
> > >> tried
> > >> >> to follow the specification as far as possible and to guaranty that
> > the
> > >> >> Java validation would be consistent with the Flex one. It would be
> of
> > >> >> course great to keep this tight compatibility, but the Flex
> > >> implementation
> > >> >> can evolve its own way, by adding specific features or even
> breaking
> > the
> > >> >> requisite of being a "certified" JSR-303 implementation. Any sound
> > >> >> evolution is welcomed, we are not specification fundamentalists ;)
> > >> >>
> > >> >>
> > >> >> > 4. What sort of performance implications can we expect with this
> > >> >> > approach? Also, would it help if we make changes to the Flex
> > >> compiler
> > >> >> for
> > >> >> > this to perform better?
> > >> >> >
> > >> >>
> > >> >> As far as we know from our users, performances are very good. I
> don't
> > >> see
> > >> >> any compiler change that could specifically benefit to this
> > framework:
> > >> the
> > >> >> only performance issue with BigDecimal is that it relies on 32-bits
> > >> >> integers and computations would have been easier to implement and
> > better
> > >> >> performing if we could have used 64-bits long types. But this
> rather
> > a
> > >> >> Flash VM issue than a compiler one if I'm right.
> > >> >>
> > >> >> Thanks a lot for offering to contribute to Apache Flex!
> > >> >> >
> > >> >>
> > >> >> You're welcome, thanks for your interest in our contribution offer.
> > >> >> Franck.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > Regards,
> > >> >> > Om
> > >> >> > On Sep 24, 2012 7:40 AM, "Franck Wolff" <
> > franck.wolff@graniteds.org>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Hi Carlos,
> > >> >> > >
> > >> >> > > 2012/9/24 Carlos Rovira <ca...@codeoscopic.com>
> > >> >> > >
> > >> >> > > > Hi Franck,
> > >> >> > > >
> > >> >> > > > I think it would be great. I was in the way to make some
> > >> >> > > > implementation some time ago since flex view validation is
> > >> >> problematic
> > >> >> > > > when you try to use MVC but I never get to far. In flex the
> > >> problem
> > >> >> is
> > >> >> > > > that validation and view controls are dependent and it would
> be
> > >> great
> > >> >> > > > to have bean validation in order to validate data and have
> real
> > >> >> > > > separation from the view. This brings the problem on how to
> > show
> > >> the
> > >> >> > > > errors in controls to let the user now about a failed
> > validation.
> > >> I
> > >> >> > > > suppose that is solved in GDS.
> > >> >> > > >
> > >> >> > >
> > >> >> > > Yes, we have a specific component called FormValidator which
> > >> displays
> > >> >> > > errors in real-time, based on the user input.
> > >> >> > >
> > >> >> > >
> > >> >> > > > So I think bean validation would be a great improvement in
> flex
> > >> SDK
> > >> >> > > > and annotations would make it more usable.
> > >> >> > > >
> > >> >> > > > For BigDecimal and others classes could be great as well,
> but I
> > >> don't
> > >> >> > > > have clear how could be donate to sdk...maybe it could go to
> an
> > >> >> > > > extension package or something like that and get some
> > >> externalization
> > >> >> > > > base implementation...
> > >> >> > > >
> > >> >> > >
> > >> >> > > An extension package is of course an option.
> > >> >> > >
> > >> >> > > Thanks for your quick feedback,
> > >> >> > > Franck.
> > >> >> > >
> > >> >> > > 2012/9/24 Franck Wolff <fr...@graniteds.org>:
> > >> >> > > > > Hi All,
> > >> >> > > > >
> > >> >> > > > > We, at Granite Data Services <http://www.graniteds.org>,
> are
> > >> >> > > considering
> > >> >> > > > > contributing part of our Flex client code to this Apache
> > >> project.
> > >> >> Our
> > >> >> > > > first
> > >> >> > > > > thought is to contribute our Bean Validation (aka JSR-303)
> > >> >> > > implementation
> > >> >> > > > > in ActionScript3: this framework gives an easy and powerful
> > way
> > >> to
> > >> >> > > > validate
> > >> >> > > > > ActionScript beans based on constraint annotations (see
> > >> >> documentation
> > >> >> > > > > here<
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html
> > >> >> > > > >).
> > >> >> > > > > This framework can be used standalone, with no specific
> > >> dependency
> > >> >> to
> > >> >> > > > rest
> > >> >> > > > > of the GraniteDS platform, but is usually best used
> together
> > >> with
> > >> >> > Gas3
> > >> >> > > > (our
> > >> >> > > > > code generation tool) which replicates Java entities
> > annotated
> > >> with
> > >> >> > > > > constraint annotations in ActionScript3, with the same
> > >> constraints.
> > >> >> > The
> > >> >> > > > > validation process can then be executed on the Flex,
> > replicating
> > >> >> what
> > >> >> > > > Java
> > >> >> > > > > is doing on its part, and can display error messages on the
> > fly,
> > >> >> > while
> > >> >> > > > the
> > >> >> > > > > user is filling out a Flex form.
> > >> >> > > > >
> > >> >> > > > > What do you think about such contribution? We could also
> > >> contribute
> > >> >> > > later
> > >> >> > > > > our Flex implementation of the BigDecimal, BigInteger and
> > Long
> > >> >> > classes
> > >> >> > > > (see
> > >> >> > > > > documentation here<
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.bignumbers.html
> > >> >> > > > >),
> > >> >> > > > > but this implementation has a dependency on some
> > externalization
> > >> >> > > features
> > >> >> > > > > specific to GraniteDS.
> > >> >> > > > >
> > >> >> > > > > Regards,
> > >> >> > > > > --
> > >> >> > > > > Franck Wolff / William Draï
> > >> >> > > > > Granite Data Services
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > --
> > >> >> > > > Carlos Rovira
> > >> >> > > > Director de Tecnología
> > >> >> > > > M: +34 607 22 60 05
> > >> >> > > > F: +34 912 35 57 77
> > >> >> > > > CODEOSCOPIC S.A.
> > >> >> > > > Avd. del General Perón, 32
> > >> >> > > > Planta 10, Puertas P-Q
> > >> >> > > > 28020 Madrid
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > --
> > >> >> > > Franck Wolff
> > >> >> > > Granite Data Services Inc.
> > >> >> > > CEO & Founder
> > >> >> > >
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Franck Wolff
> > >> >> Granite Data Services Inc.
> > >> >> CEO & Founder
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> Director de Tecnología
> > >> M: +34 607 22 60 05
> > >> F: +34 912 35 57 77
> > >> CODEOSCOPIC S.A.
> > >> Avd. del General Perón, 32
> > >> Planta 10, Puertas P-Q
> > >> 28020 Madrid
> > >>
> >
> >
> >
> > --
> > Carlos Rovira
> > Director de Tecnología
> > M: +34 607 22 60 05
> > F: +34 912 35 57 77
> > CODEOSCOPIC S.A.
> > Avd. del General Perón, 32
> > Planta 10, Puertas P-Q
> > 28020 Madrid
> >
>
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
The URL is:
http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/<http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part>
Run the commands in the intro and then go to the section entitled "Step 5:
Validation"
Franck.
2012/11/28 Om <bi...@gmail.com>
> The url you gave does not seem to be working. I tried this:
>
> http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part
> 5:
> Validation)
> and this:
>
> http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part%205:%20Validation)
>
> No luck. Can you please take a look?
>
> On Wed, Nov 28, 2012 at 12:00 PM, Franck Wolff
> <fr...@graniteds.org>wrote:
>
> > Om,
> >
> > Did you find time to play with the tutorial?
> >
> > Franck.
> >
> > 2012/11/14 Franck Wolff <fr...@graniteds.org>
> >
> > > Om,
> > >
> > > That tutorial can certainly help:
> > >
> >
> http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part5:
> Validation)
> > >
> > > Run these commands:
> > >
> > > git clone git://github.com/wdrai/wineshop-admin.git
> > > cd wineshop-admin
> > > mvn clean install
> > > cd webapp
> > > mvn jetty:run-war
> > >
> > > Then look at those source files:
> > >
> > >
> >
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/VineyardBase.as
> > > (constraints annotations such as NotNull, Size, etc.)
> > >
> >
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/WineBase.as
> > > (same thing)
> > > wineshop-admin/flex/src/main/flex/Home.mxml (the two FormValidators)
> > >
> > > In this very basic (and not so pretty) sample application, AS
> constraint
> > > annotations are generated from Java entities, but keep in mind that you
> > can
> > > write them by hand directly in your AS beans.
> > >
> > > Franck.
> > >
> > >
> > > 2012/11/14 Om <bi...@gmail.com>
> > >
> > >> Franck,
> > >>
> > >> The level of detail on this document [1] is really good. Would it be
> > too
> > >> much to ask for a very simple working prototype with 'View Source' so
> > that
> > >> we get a better idea for the evaluation? I am guessing you would want
> > to
> > >> do something similar when the code gets committed and shipped.
> > >>
> > >> Thanks,
> > >> Om
> > >>
> > >> [1]
> > >>
> > >>
> >
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html#validation.gettingstarted
> > >>
> > >>
> > >> On Wed, Nov 14, 2012 at 10:51 AM, Alex Harui <ah...@adobe.com>
> wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> > On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org>
> > wrote:
> > >> >
> > >> > > I would suggest that you make a quick review of the code on Github
> > >> while
> > >> > > I'm reading some ASF documents about committers. If we are both ok
> > >> (you
> > >> > > with the code, me with my obligations), then we can start the all
> > >> > process.
> > >> > >
> > >> > > I can find some time before the end of this week and review the
> > >> > documents.
> > >> > > Can you start reviewing the code on Githud and make sure there is
> no
> > >> > > obvious issue with the contribution?
> > >> > You are on the top of my reading list.
> > >> > >
> > >> > > Thanks for your clear explanations,
> > >> > > Franck.
> > >> > >
> > >> >
> > >> > --
> > >> > Alex Harui
> > >> > Flex SDK Team
> > >> > Adobe Systems, Inc.
> > >> > http://blogs.adobe.com/aharui
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder
Re: Proposal for contributing code from GraniteDS
Posted by Om <bi...@gmail.com>.
The url you gave does not seem to be working. I tried this:
http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part
5:
Validation)
and this:
http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part%205:%20Validation)
No luck. Can you please take a look?
On Wed, Nov 28, 2012 at 12:00 PM, Franck Wolff
<fr...@graniteds.org>wrote:
> Om,
>
> Did you find time to play with the tutorial?
>
> Franck.
>
> 2012/11/14 Franck Wolff <fr...@graniteds.org>
>
> > Om,
> >
> > That tutorial can certainly help:
> >
> http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part5: Validation)
> >
> > Run these commands:
> >
> > git clone git://github.com/wdrai/wineshop-admin.git
> > cd wineshop-admin
> > mvn clean install
> > cd webapp
> > mvn jetty:run-war
> >
> > Then look at those source files:
> >
> >
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/VineyardBase.as
> > (constraints annotations such as NotNull, Size, etc.)
> >
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/WineBase.as
> > (same thing)
> > wineshop-admin/flex/src/main/flex/Home.mxml (the two FormValidators)
> >
> > In this very basic (and not so pretty) sample application, AS constraint
> > annotations are generated from Java entities, but keep in mind that you
> can
> > write them by hand directly in your AS beans.
> >
> > Franck.
> >
> >
> > 2012/11/14 Om <bi...@gmail.com>
> >
> >> Franck,
> >>
> >> The level of detail on this document [1] is really good. Would it be
> too
> >> much to ask for a very simple working prototype with 'View Source' so
> that
> >> we get a better idea for the evaluation? I am guessing you would want
> to
> >> do something similar when the code gets committed and shipped.
> >>
> >> Thanks,
> >> Om
> >>
> >> [1]
> >>
> >>
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html#validation.gettingstarted
> >>
> >>
> >> On Wed, Nov 14, 2012 at 10:51 AM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >> >
> >> >
> >> >
> >> > On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org>
> wrote:
> >> >
> >> > > I would suggest that you make a quick review of the code on Github
> >> while
> >> > > I'm reading some ASF documents about committers. If we are both ok
> >> (you
> >> > > with the code, me with my obligations), then we can start the all
> >> > process.
> >> > >
> >> > > I can find some time before the end of this week and review the
> >> > documents.
> >> > > Can you start reviewing the code on Githud and make sure there is no
> >> > > obvious issue with the contribution?
> >> > You are on the top of my reading list.
> >> > >
> >> > > Thanks for your clear explanations,
> >> > > Franck.
> >> > >
> >> >
> >> > --
> >> > Alex Harui
> >> > Flex SDK Team
> >> > Adobe Systems, Inc.
> >> > http://blogs.adobe.com/aharui
> >> >
> >> >
> >>
> >
> >
>
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
Om,
Did you find time to play with the tutorial?
Franck.
2012/11/14 Franck Wolff <fr...@graniteds.org>
> Om,
>
> That tutorial can certainly help:
> http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part 5: Validation)
>
> Run these commands:
>
> git clone git://github.com/wdrai/wineshop-admin.git
> cd wineshop-admin
> mvn clean install
> cd webapp
> mvn jetty:run-war
>
> Then look at those source files:
>
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/VineyardBase.as
> (constraints annotations such as NotNull, Size, etc.)
> wineshop-admin/flex/target/generated-sources/com/wineshop/entities/WineBase.as
> (same thing)
> wineshop-admin/flex/src/main/flex/Home.mxml (the two FormValidators)
>
> In this very basic (and not so pretty) sample application, AS constraint
> annotations are generated from Java entities, but keep in mind that you can
> write them by hand directly in your AS beans.
>
> Franck.
>
>
> 2012/11/14 Om <bi...@gmail.com>
>
>> Franck,
>>
>> The level of detail on this document [1] is really good. Would it be too
>> much to ask for a very simple working prototype with 'View Source' so that
>> we get a better idea for the evaluation? I am guessing you would want to
>> do something similar when the code gets committed and shipped.
>>
>> Thanks,
>> Om
>>
>> [1]
>>
>> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html#validation.gettingstarted
>>
>>
>> On Wed, Nov 14, 2012 at 10:51 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>> >
>> >
>> >
>> > On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>> >
>> > > I would suggest that you make a quick review of the code on Github
>> while
>> > > I'm reading some ASF documents about committers. If we are both ok
>> (you
>> > > with the code, me with my obligations), then we can start the all
>> > process.
>> > >
>> > > I can find some time before the end of this week and review the
>> > documents.
>> > > Can you start reviewing the code on Githud and make sure there is no
>> > > obvious issue with the contribution?
>> > You are on the top of my reading list.
>> > >
>> > > Thanks for your clear explanations,
>> > > Franck.
>> > >
>> >
>> > --
>> > Alex Harui
>> > Flex SDK Team
>> > Adobe Systems, Inc.
>> > http://blogs.adobe.com/aharui
>> >
>> >
>>
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
Om,
That tutorial can certainly help:
http://granitedataservices.com/blog/2011/12/05/graniteds-data-management-tutorial/(Part
5: Validation)
Run these commands:
git clone git://github.com/wdrai/wineshop-admin.git
cd wineshop-admin
mvn clean install
cd webapp
mvn jetty:run-war
Then look at those source files:
wineshop-admin/flex/target/generated-sources/com/wineshop/entities/VineyardBase.as
(constraints annotations such as NotNull, Size, etc.)
wineshop-admin/flex/target/generated-sources/com/wineshop/entities/WineBase.as
(same thing)
wineshop-admin/flex/src/main/flex/Home.mxml (the two FormValidators)
In this very basic (and not so pretty) sample application, AS constraint
annotations are generated from Java entities, but keep in mind that you can
write them by hand directly in your AS beans.
Franck.
2012/11/14 Om <bi...@gmail.com>
> Franck,
>
> The level of detail on this document [1] is really good. Would it be too
> much to ask for a very simple working prototype with 'View Source' so that
> we get a better idea for the evaluation? I am guessing you would want to
> do something similar when the code gets committed and shipped.
>
> Thanks,
> Om
>
> [1]
>
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html#validation.gettingstarted
>
>
> On Wed, Nov 14, 2012 at 10:51 AM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> >
> > On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> >
> > > I would suggest that you make a quick review of the code on Github
> while
> > > I'm reading some ASF documents about committers. If we are both ok (you
> > > with the code, me with my obligations), then we can start the all
> > process.
> > >
> > > I can find some time before the end of this week and review the
> > documents.
> > > Can you start reviewing the code on Githud and make sure there is no
> > > obvious issue with the contribution?
> > You are on the top of my reading list.
> > >
> > > Thanks for your clear explanations,
> > > Franck.
> > >
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder
Re: Proposal for contributing code from GraniteDS
Posted by Om <bi...@gmail.com>.
Franck,
The level of detail on this document [1] is really good. Would it be too
much to ask for a very simple working prototype with 'View Source' so that
we get a better idea for the evaluation? I am guessing you would want to
do something similar when the code gets committed and shipped.
Thanks,
Om
[1]
http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html#validation.gettingstarted
On Wed, Nov 14, 2012 at 10:51 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > I would suggest that you make a quick review of the code on Github while
> > I'm reading some ASF documents about committers. If we are both ok (you
> > with the code, me with my obligations), then we can start the all
> process.
> >
> > I can find some time before the end of this week and review the
> documents.
> > Can you start reviewing the code on Githud and make sure there is no
> > obvious issue with the contribution?
> You are on the top of my reading list.
> >
> > Thanks for your clear explanations,
> > Franck.
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
Thanks ;)
2012/11/14 Alex Harui <ah...@adobe.com>
>
>
>
> On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > I would suggest that you make a quick review of the code on Github while
> > I'm reading some ASF documents about committers. If we are both ok (you
> > with the code, me with my obligations), then we can start the all
> process.
> >
> > I can find some time before the end of this week and review the
> documents.
> > Can you start reviewing the code on Githud and make sure there is no
> > obvious issue with the contribution?
> You are on the top of my reading list.
> >
> > Thanks for your clear explanations,
> > Franck.
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 11:35 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> 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 <ah...@adobe.com>
>
>>>
>>> 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.
OK, well Copyright is about copying so if there isn't an obvious copy of the
Java code I think we're ok there.
>
>
>>>> 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.
Just pick something for now. We can change it later. We just need to not
use granite.
>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
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 <ah...@adobe.com>
>
>
>
> On 11/14/12 2:57 PM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > Alex,
> >
> > My answers below:
> >
> > 2012/11/14 Alex Harui <ah...@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
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
On 11/14/12 2:57 PM, "Franck Wolff" <fr...@graniteds.org> wrote:
> Alex,
>
> My answers below:
>
> 2012/11/14 Alex Harui <ah...@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.
>
>
>> 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?
>
>
>> 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.
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
Alex,
My answers below:
2012/11/14 Alex Harui <ah...@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?
> 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.
> 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...
> 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.
> Anyway, based on your answers, we should have a brief discussion on the
> destination folder and package names. Then, I would ask you to do the
> following:
>
> A) get the sources for Apache Flex
> B) copy your code into the decided-upon folders
> C) replace all headers with Apache headers
> D) replace package names if necessary
> E) (optional) create a build.xml in your folder and edit the main build
> script so your code actually builds.
>
> It is the zip of the sources in this final folder that should be the actual
> files donated to Apache. We won't pull it from GitHub. You definitely
> have
> the rights to change from GPL to ALv2. There is plenty of precedence for
> this.
>
Ok.
> You may notice that the standard Apache header says that your copyrights
> are
> in a NOTICE file. This is an odd "gotcha" in the donation process. You
> can
> create your own file called NOTICE and move your copyrights there, but
> really, your copyright has to end up in the central NOTICE file. You can
> opt to leave your copyright notice in the files for now and move them once
> in Apache SVN if you want. I think it is pretty much up to you.
>
Ok.
> Thanks again,
> -Alex
You're welcome,
Franck.
>
> On 11/14/12 12:45 PM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > I agree: we are the copyright owners, there is no external contribution
> in
> > that part of our code and we can freely choose the license (LGPL, Apache,
> > commercial, etc.)
> >
> > You could certainly ask some legal guy at the ASF over this potential
> > issue, but I'm pretty sure we have the right to change the license to
> > whatever we want.
> >
> > Franck.
> >
> > 2012/11/14 Justin Mclean <ju...@classsoftware.com>
> >
> >> Hi,
> >>
> >> Only issue I see is the current license which I believe is not
> compatible
> >> with Apache. Given you own the software and can licence it how you see
> fit
> >> I don't see this being an issue.
> >>
> >> Thanks,
> >> Justin
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@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.
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".
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?
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?
Anyway, based on your answers, we should have a brief discussion on the
destination folder and package names. Then, I would ask you to do the
following:
A) get the sources for Apache Flex
B) copy your code into the decided-upon folders
C) replace all headers with Apache headers
D) replace package names if necessary
E) (optional) create a build.xml in your folder and edit the main build
script so your code actually builds.
It is the zip of the sources in this final folder that should be the actual
files donated to Apache. We won't pull it from GitHub. You definitely have
the rights to change from GPL to ALv2. There is plenty of precedence for
this.
You may notice that the standard Apache header says that your copyrights are
in a NOTICE file. This is an odd "gotcha" in the donation process. You can
create your own file called NOTICE and move your copyrights there, but
really, your copyright has to end up in the central NOTICE file. You can
opt to leave your copyright notice in the files for now and move them once
in Apache SVN if you want. I think it is pretty much up to you.
Thanks again,
-Alex
On 11/14/12 12:45 PM, "Franck Wolff" <fr...@graniteds.org> wrote:
> I agree: we are the copyright owners, there is no external contribution in
> that part of our code and we can freely choose the license (LGPL, Apache,
> commercial, etc.)
>
> You could certainly ask some legal guy at the ASF over this potential
> issue, but I'm pretty sure we have the right to change the license to
> whatever we want.
>
> Franck.
>
> 2012/11/14 Justin Mclean <ju...@classsoftware.com>
>
>> Hi,
>>
>> Only issue I see is the current license which I believe is not compatible
>> with Apache. Given you own the software and can licence it how you see fit
>> I don't see this being an issue.
>>
>> Thanks,
>> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
I agree: we are the copyright owners, there is no external contribution in
that part of our code and we can freely choose the license (LGPL, Apache,
commercial, etc.)
You could certainly ask some legal guy at the ASF over this potential
issue, but I'm pretty sure we have the right to change the license to
whatever we want.
Franck.
2012/11/14 Justin Mclean <ju...@classsoftware.com>
> Hi,
>
> Only issue I see is the current license which I believe is not compatible
> with Apache. Given you own the software and can licence it how you see fit
> I don't see this being an issue.
>
> Thanks,
> Justin
Re: Proposal for contributing code from GraniteDS
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Only issue I see is the current license which I believe is not compatible with Apache. Given you own the software and can licence it how you see fit I don't see this being an issue.
Thanks,
Justin
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
On 11/14/12 9:46 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> I would suggest that you make a quick review of the code on Github while
> I'm reading some ASF documents about committers. If we are both ok (you
> with the code, me with my obligations), then we can start the all process.
>
> I can find some time before the end of this week and review the documents.
> Can you start reviewing the code on Githud and make sure there is no
> obvious issue with the contribution?
You are on the top of my reading list.
>
> Thanks for your clear explanations,
> Franck.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
I would suggest that you make a quick review of the code on Github while
I'm reading some ASF documents about committers. If we are both ok (you
with the code, me with my obligations), then we can start the all process.
I can find some time before the end of this week and review the documents.
Can you start reviewing the code on Githud and make sure there is no
obvious issue with the contribution?
Thanks for your clear explanations,
Franck.
2012/11/14 Alex Harui <ah...@adobe.com>
> Almost. It will be more like this (1 & 2 & 3 run in parallel):
>
> 1. You fill out and sign all legal documents
> 2. Some of us will review the code (assuming the Github links are the
> actual
> files you plan to donate). If it looks ok, we will start the committer
> approval process for you. Takes a minimum of 3 business days.
> 3. We discuss where this code should land, the package names, whether it is
> truly part of the SDK release or should have its own release schedule.
> 4. Once the software grant is recorded, someone can check the code into
> SVN.
> That can be you, or it can be one of us, it should probably be you.
> 5. Once it is in, it gets another review as you/we make an Apache
> compatible
> build script for it. This means making sure there are no binaries, that
> the
> headers are correct, that your copyrights (but not any third-party
> copyrights) are moved to the NOTICES file (which must be done by you or
> with
> your explicit permission).
> 6. Based on 3, all kinds of good stuff happens.
>
>
> I would recommend that you take some time to peruse some of the ASF
> documents about committers and how the ASF works. That will explain why we
> don't just hand out write-access to SVN and there is other stuff you may
> need to know because you are planning on becoming a member of a legal
> entity
> with certain by-laws, not just a social group on GitHub.
>
> On 11/14/12 5:17 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > I do have the required authority to sign those documents.
> >
> > To summarize:
> >
> > 1. I fill out and sign all legal documents.
> > 2. We wait for a confirmation from the Apache foundation (is it required?
> > how long does it takes?)
> > 3. You give me a read-write access to the SVN repository.
> > 4. I commit our code somewhere (experimental? org.apache.flex?)
> > 5. You (or we) update the build process so our code is bundled with the
> > rest of the framework.
> > 6. We let people test the new features, give their feedback, etc.
> >
> > Can you comment and confirm?
> >
> > FYI, here is the code on Github:
> >
> >
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/m
> > ath
> >
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/r
> > eflect
> >
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/v
> > alidation
> >
> > Franck.
> >
> >
> > 2012/11/13 Alex Harui <ah...@adobe.com>
> >
> >> Yes, the ICLA is for you personally to make changes to code. You will
> need
> >> this to be allowed to modify the files once they land in Apache SVN.
> The
> >> CCLA says that your corporation understands that you are doing this work
> >> and
> >> is ok with Apache having license to use your changes. And since the
> >> copyright owner is GraniteDS, I think you really do need to do the
> software
> >> grant and someone with the authority to sign legal documents for
> GraniteDS
> >> will need to sign it. For example, I cannot sign the software grants
> for
> >> Adobe, and my manager has to hit up a VP that is two levels above him,
> and
> >> even that VP checks in an SVP before signing the big grants. But the
> CEO
> >> generally isn't involved.
> >>
> >>
> >> On 11/13/12 11:47 AM, "Franck Wolff" <fr...@graniteds.org>
> wrote:
> >>
> >>> The copyright owner is GraniteDS. There is no need to retain any
> software
> >>> revision history and there is no opened bug about this part of our code
> >>> currently (or very very few, I didn't check).
> >>>
> >>> Do I still need to fill out [1] if the code is fully owned by
> GraniteDS?
> >>>
> >>>
> >>> 2012/11/13 Alex Harui <ah...@adobe.com>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org>
> >> wrote:
> >>>>
> >>>>> That's a 86 AS source files and 4 xml files piece of code (dont' ask
> me
> >>>> the
> >>>>> number of lines). I don't know if it's a "lot of code" or no...
> >>>>>
> >>>>> There is no copyright issue about this code (we are the owners and
> >> there
> >>>> is
> >>>>> no external contribution) and there is no dependencies on code
> outside
> >> of
> >>>>> the Flex framework.
> >>>>>
> >>>> Adobe has been making donations of that size via Software Grants.
> >> Also, is
> >>>> the copyright owner people or a business like GraniteDS?
> >>>>
> >>>> More questions: is there important source code revision history you
> >> need to
> >>>> retain? Is there a significant set of bugs in an issue tracker that
> >> needed
> >>>> to be brought over as well?
> >>>>
> >>>> I think steps are to file ICLAs [1], and a CCLA [2] if there is a
> >> corporate
> >>>> entity involved. Then fill out the software grant [3].
> >>>>
> >>>> [1] http://www.apache.org/licenses/icla.txt
> >>>> [2] http://www.apache.org/licenses/cla-corporate.txt
> >>>> [3] http://www.apache.org/licenses/software-grant.txt
> >>>>
> >>>>
> >>>> --
> >>>> Alex Harui
> >>>> Flex SDK Team
> >>>> Adobe Systems, Inc.
> >>>> http://blogs.adobe.com/aharui
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
Almost. It will be more like this (1 & 2 & 3 run in parallel):
1. You fill out and sign all legal documents
2. Some of us will review the code (assuming the Github links are the actual
files you plan to donate). If it looks ok, we will start the committer
approval process for you. Takes a minimum of 3 business days.
3. We discuss where this code should land, the package names, whether it is
truly part of the SDK release or should have its own release schedule.
4. Once the software grant is recorded, someone can check the code into SVN.
That can be you, or it can be one of us, it should probably be you.
5. Once it is in, it gets another review as you/we make an Apache compatible
build script for it. This means making sure there are no binaries, that the
headers are correct, that your copyrights (but not any third-party
copyrights) are moved to the NOTICES file (which must be done by you or with
your explicit permission).
6. Based on 3, all kinds of good stuff happens.
I would recommend that you take some time to peruse some of the ASF
documents about committers and how the ASF works. That will explain why we
don't just hand out write-access to SVN and there is other stuff you may
need to know because you are planning on becoming a member of a legal entity
with certain by-laws, not just a social group on GitHub.
On 11/14/12 5:17 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> I do have the required authority to sign those documents.
>
> To summarize:
>
> 1. I fill out and sign all legal documents.
> 2. We wait for a confirmation from the Apache foundation (is it required?
> how long does it takes?)
> 3. You give me a read-write access to the SVN repository.
> 4. I commit our code somewhere (experimental? org.apache.flex?)
> 5. You (or we) update the build process so our code is bundled with the
> rest of the framework.
> 6. We let people test the new features, give their feedback, etc.
>
> Can you comment and confirm?
>
> FYI, here is the code on Github:
>
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/m
> ath
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/r
> eflect
> https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/v
> alidation
>
> Franck.
>
>
> 2012/11/13 Alex Harui <ah...@adobe.com>
>
>> Yes, the ICLA is for you personally to make changes to code. You will need
>> this to be allowed to modify the files once they land in Apache SVN. The
>> CCLA says that your corporation understands that you are doing this work
>> and
>> is ok with Apache having license to use your changes. And since the
>> copyright owner is GraniteDS, I think you really do need to do the software
>> grant and someone with the authority to sign legal documents for GraniteDS
>> will need to sign it. For example, I cannot sign the software grants for
>> Adobe, and my manager has to hit up a VP that is two levels above him, and
>> even that VP checks in an SVP before signing the big grants. But the CEO
>> generally isn't involved.
>>
>>
>> On 11/13/12 11:47 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>>
>>> The copyright owner is GraniteDS. There is no need to retain any software
>>> revision history and there is no opened bug about this part of our code
>>> currently (or very very few, I didn't check).
>>>
>>> Do I still need to fill out [1] if the code is fully owned by GraniteDS?
>>>
>>>
>>> 2012/11/13 Alex Harui <ah...@adobe.com>
>>>
>>>>
>>>>
>>>>
>>>> On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org>
>> wrote:
>>>>
>>>>> That's a 86 AS source files and 4 xml files piece of code (dont' ask me
>>>> the
>>>>> number of lines). I don't know if it's a "lot of code" or no...
>>>>>
>>>>> There is no copyright issue about this code (we are the owners and
>> there
>>>> is
>>>>> no external contribution) and there is no dependencies on code outside
>> of
>>>>> the Flex framework.
>>>>>
>>>> Adobe has been making donations of that size via Software Grants.
>> Also, is
>>>> the copyright owner people or a business like GraniteDS?
>>>>
>>>> More questions: is there important source code revision history you
>> need to
>>>> retain? Is there a significant set of bugs in an issue tracker that
>> needed
>>>> to be brought over as well?
>>>>
>>>> I think steps are to file ICLAs [1], and a CCLA [2] if there is a
>> corporate
>>>> entity involved. Then fill out the software grant [3].
>>>>
>>>> [1] http://www.apache.org/licenses/icla.txt
>>>> [2] http://www.apache.org/licenses/cla-corporate.txt
>>>> [3] http://www.apache.org/licenses/software-grant.txt
>>>>
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
I do have the required authority to sign those documents.
To summarize:
1. I fill out and sign all legal documents.
2. We wait for a confirmation from the Apache foundation (is it required?
how long does it takes?)
3. You give me a read-write access to the SVN repository.
4. I commit our code somewhere (experimental? org.apache.flex?)
5. You (or we) update the build process so our code is bundled with the
rest of the framework.
6. We let people test the new features, give their feedback, etc.
Can you comment and confirm?
FYI, here is the code on Github:
https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/math
https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/reflect
https://github.com/graniteds/graniteds/tree/master/as3/framework/org/granite/validation
Franck.
2012/11/13 Alex Harui <ah...@adobe.com>
> Yes, the ICLA is for you personally to make changes to code. You will need
> this to be allowed to modify the files once they land in Apache SVN. The
> CCLA says that your corporation understands that you are doing this work
> and
> is ok with Apache having license to use your changes. And since the
> copyright owner is GraniteDS, I think you really do need to do the software
> grant and someone with the authority to sign legal documents for GraniteDS
> will need to sign it. For example, I cannot sign the software grants for
> Adobe, and my manager has to hit up a VP that is two levels above him, and
> even that VP checks in an SVP before signing the big grants. But the CEO
> generally isn't involved.
>
>
> On 11/13/12 11:47 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > The copyright owner is GraniteDS. There is no need to retain any software
> > revision history and there is no opened bug about this part of our code
> > currently (or very very few, I didn't check).
> >
> > Do I still need to fill out [1] if the code is fully owned by GraniteDS?
> >
> >
> > 2012/11/13 Alex Harui <ah...@adobe.com>
> >
> >>
> >>
> >>
> >> On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org>
> wrote:
> >>
> >>> That's a 86 AS source files and 4 xml files piece of code (dont' ask me
> >> the
> >>> number of lines). I don't know if it's a "lot of code" or no...
> >>>
> >>> There is no copyright issue about this code (we are the owners and
> there
> >> is
> >>> no external contribution) and there is no dependencies on code outside
> of
> >>> the Flex framework.
> >>>
> >> Adobe has been making donations of that size via Software Grants.
> Also, is
> >> the copyright owner people or a business like GraniteDS?
> >>
> >> More questions: is there important source code revision history you
> need to
> >> retain? Is there a significant set of bugs in an issue tracker that
> needed
> >> to be brought over as well?
> >>
> >> I think steps are to file ICLAs [1], and a CCLA [2] if there is a
> corporate
> >> entity involved. Then fill out the software grant [3].
> >>
> >> [1] http://www.apache.org/licenses/icla.txt
> >> [2] http://www.apache.org/licenses/cla-corporate.txt
> >> [3] http://www.apache.org/licenses/software-grant.txt
> >>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
Yes, the ICLA is for you personally to make changes to code. You will need
this to be allowed to modify the files once they land in Apache SVN. The
CCLA says that your corporation understands that you are doing this work and
is ok with Apache having license to use your changes. And since the
copyright owner is GraniteDS, I think you really do need to do the software
grant and someone with the authority to sign legal documents for GraniteDS
will need to sign it. For example, I cannot sign the software grants for
Adobe, and my manager has to hit up a VP that is two levels above him, and
even that VP checks in an SVP before signing the big grants. But the CEO
generally isn't involved.
On 11/13/12 11:47 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> The copyright owner is GraniteDS. There is no need to retain any software
> revision history and there is no opened bug about this part of our code
> currently (or very very few, I didn't check).
>
> Do I still need to fill out [1] if the code is fully owned by GraniteDS?
>
>
> 2012/11/13 Alex Harui <ah...@adobe.com>
>
>>
>>
>>
>> On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>>
>>> That's a 86 AS source files and 4 xml files piece of code (dont' ask me
>> the
>>> number of lines). I don't know if it's a "lot of code" or no...
>>>
>>> There is no copyright issue about this code (we are the owners and there
>> is
>>> no external contribution) and there is no dependencies on code outside of
>>> the Flex framework.
>>>
>> Adobe has been making donations of that size via Software Grants. Also, is
>> the copyright owner people or a business like GraniteDS?
>>
>> More questions: is there important source code revision history you need to
>> retain? Is there a significant set of bugs in an issue tracker that needed
>> to be brought over as well?
>>
>> I think steps are to file ICLAs [1], and a CCLA [2] if there is a corporate
>> entity involved. Then fill out the software grant [3].
>>
>> [1] http://www.apache.org/licenses/icla.txt
>> [2] http://www.apache.org/licenses/cla-corporate.txt
>> [3] http://www.apache.org/licenses/software-grant.txt
>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
The copyright owner is GraniteDS. There is no need to retain any software
revision history and there is no opened bug about this part of our code
currently (or very very few, I didn't check).
Do I still need to fill out [1] if the code is fully owned by GraniteDS?
2012/11/13 Alex Harui <ah...@adobe.com>
>
>
>
> On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > That's a 86 AS source files and 4 xml files piece of code (dont' ask me
> the
> > number of lines). I don't know if it's a "lot of code" or no...
> >
> > There is no copyright issue about this code (we are the owners and there
> is
> > no external contribution) and there is no dependencies on code outside of
> > the Flex framework.
> >
> Adobe has been making donations of that size via Software Grants. Also, is
> the copyright owner people or a business like GraniteDS?
>
> More questions: is there important source code revision history you need to
> retain? Is there a significant set of bugs in an issue tracker that needed
> to be brought over as well?
>
> I think steps are to file ICLAs [1], and a CCLA [2] if there is a corporate
> entity involved. Then fill out the software grant [3].
>
> [1] http://www.apache.org/licenses/icla.txt
> [2] http://www.apache.org/licenses/cla-corporate.txt
> [3] http://www.apache.org/licenses/software-grant.txt
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/12 11:17 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> That's a 86 AS source files and 4 xml files piece of code (dont' ask me the
> number of lines). I don't know if it's a "lot of code" or no...
>
> There is no copyright issue about this code (we are the owners and there is
> no external contribution) and there is no dependencies on code outside of
> the Flex framework.
>
Adobe has been making donations of that size via Software Grants. Also, is
the copyright owner people or a business like GraniteDS?
More questions: is there important source code revision history you need to
retain? Is there a significant set of bugs in an issue tracker that needed
to be brought over as well?
I think steps are to file ICLAs [1], and a CCLA [2] if there is a corporate
entity involved. Then fill out the software grant [3].
[1] http://www.apache.org/licenses/icla.txt
[2] http://www.apache.org/licenses/cla-corporate.txt
[3] http://www.apache.org/licenses/software-grant.txt
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
That's a 86 AS source files and 4 xml files piece of code (dont' ask me the
number of lines). I don't know if it's a "lot of code" or no...
There is no copyright issue about this code (we are the owners and there is
no external contribution) and there is no dependencies on code outside of
the Flex framework.
Franck.
2012/11/13 Alex Harui <ah...@adobe.com>
>
>
>
> On 11/13/12 9:49 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
>
> > Om,
> >
> > Yes we are.
> >
> > I think the best would be to commit our sources in the
> > trunk/frameworks/projects/experimental/src/ directory, changing our
> package
> > names to:
> >
> > org.apache.flex.math (BigDecimal implementation)
> > org.apache.flex.reflect (Reflection API)
> > org.apache.flex.validation (Bean Validation implementation)
> >
> > We would also need to change our headers, reflecting the Apache License
> (as
> > well as filling some legal forms I guess).
> >
> > Then, the community could review the new source code and test a build
> > including the experimental new code. I'm not very familiar with the
> Apache
> > vote process but this submission could be accepted (or rejected) through
> a
> > vote and then included into the general framework release.
> >
> > Does it sound reasonable? Would it be possible to get a full SVN access
> > during this process?
> >
> Is this a lot of code? If so, there is a software grant process you have
> to
> execute before donating the code. If not, you can probably just attach the
> source to a JIRA issue for review. You have to be the copyright owner and
> have permission from any other copyright owners in your code base, plus you
> can't have dependencies on code that isn't licensed in an Apache-compatible
> way.
>
> In general, we can't give out SVN access until all of this process is dealt
> with and there is some initial review of the code. But if you are the
> shepherd for a significant donation, you will likely be given access
> quickly.
>
> It is done this way as an extra check to try to make sure some code that
> shouldn't be donated doesn't get into SVN because once it is there, you
> can't really get rid of it.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Proposal for contributing code from GraniteDS
Posted by Alex Harui <ah...@adobe.com>.
On 11/13/12 9:49 AM, "Franck Wolff" <fr...@graniteds.org> wrote:
> Om,
>
> Yes we are.
>
> I think the best would be to commit our sources in the
> trunk/frameworks/projects/experimental/src/ directory, changing our package
> names to:
>
> org.apache.flex.math (BigDecimal implementation)
> org.apache.flex.reflect (Reflection API)
> org.apache.flex.validation (Bean Validation implementation)
>
> We would also need to change our headers, reflecting the Apache License (as
> well as filling some legal forms I guess).
>
> Then, the community could review the new source code and test a build
> including the experimental new code. I'm not very familiar with the Apache
> vote process but this submission could be accepted (or rejected) through a
> vote and then included into the general framework release.
>
> Does it sound reasonable? Would it be possible to get a full SVN access
> during this process?
>
Is this a lot of code? If so, there is a software grant process you have to
execute before donating the code. If not, you can probably just attach the
source to a JIRA issue for review. You have to be the copyright owner and
have permission from any other copyright owners in your code base, plus you
can't have dependencies on code that isn't licensed in an Apache-compatible
way.
In general, we can't give out SVN access until all of this process is dealt
with and there is some initial review of the code. But if you are the
shepherd for a significant donation, you will likely be given access
quickly.
It is done this way as an extra check to try to make sure some code that
shouldn't be donated doesn't get into SVN because once it is there, you
can't really get rid of it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Proposal for contributing code from GraniteDS
Posted by Franck Wolff <fr...@graniteds.org>.
Om,
Yes we are.
I think the best would be to commit our sources in the
trunk/frameworks/projects/experimental/src/ directory, changing our package
names to:
org.apache.flex.math (BigDecimal implementation)
org.apache.flex.reflect (Reflection API)
org.apache.flex.validation (Bean Validation implementation)
We would also need to change our headers, reflecting the Apache License (as
well as filling some legal forms I guess).
Then, the community could review the new source code and test a build
including the experimental new code. I'm not very familiar with the Apache
vote process but this submission could be accepted (or rejected) through a
vote and then included into the general framework release.
Does it sound reasonable? Would it be possible to get a full SVN access
during this process?
Thanks,
Franck.
2012/11/8 Om <bi...@gmail.com>
> Franck,
>
> Sorry it a while for me to respond. I am assuming you are still interested
> in contributing the validation framework to Apache Flex. Please let me
> know how you would like to proceed. I have some free cycles and I can help
> committing it to the codebase.
>
> Thanks,
> Om
>
> On Wed, Oct 3, 2012 at 5:56 AM, Franck Wolff <franck.wolff@graniteds.org
> >wrote:
>
> > The goal is of course to give the validation framework with the less
> > possible dependencies. Refactoring is an option but it should be minimal
> in
> > order to preserve the current stability of our code (which is very good
> so
> > far). We don't want to contribute an untested, deeply modified and
> > potentially unstable piece of code to Apache.
> >
> > Franck.
> >
> > 2012/10/3 Carlos Rovira <ca...@codeoscopic.com>
> >
> > > Hi Franck,
> > >
> > > IMHO the only problem I see is that user could end with dependent
> > > frameworks that could be removed if some refactor is applyed, in this
> > > case with reflect classes from granite and other microframework like
> > > swiz, parsley or other.
> > >
> > > Maybe reflect classes could be cut to the minimun in order to drop
> > > weight to minimum. Maybe math classes could be cut in the same way. In
> > > both cases event refactored to be plug into other frameworks...
> > >
> > >
> > > 2012/10/3 Franck Wolff <fr...@graniteds.org>:
> > > > Hi Carlos,
> > > >
> > > > math & reflect (I forgot about this one) are mandatory. util &
> > > collections
> > > > can certainly be refactored in order to lower dependencies. I need to
> > > check
> > > > about that but, basically, we are ready to contribute all required
> > code.
> > > >
> > > > Thanks for your feedback,
> > > > Franck.
> > > >
> > > > 2012/10/3 Carlos Rovira <ca...@codeoscopic.com>
> > > >
> > > >> Hi Franck,
> > > >>
> > > >> I was looking at the validation source in graniteds and I see that
> > > >> dependencies are a bit more complex. From what I see those are the
> > > >> packages needed:
> > > >>
> > > >> * math
> > > >> * reflect
> > > >> * util
> > > >> * collections
> > > >>
> > > >> maybe some other class could be needed...
> > > >>
> > > >> Maybe some refactor could be done to avoid overhead of classes that
> > > >> really are not used/needed
> > > >>
> > > >> Best,
> > > >>
> > > >> Carlos
> > > >>
> > > >>
> > > >>
> > > >> 2012/10/2 Om <bi...@gmail.com>:
> > > >> > Thanks for the detailed responses, Franck. I think this could
> work
> > > and
> > > >> > would make a great addition to Flex.
> > > >> >
> > > >> > PPMC folks, any objections? Or should we take a formal vote on
> > this?
> > > >> >
> > > >> > What should be the next steps?
> > > >> >
> > > >> > Thanks,
> > > >> > Om
> > > >> >
> > > >> > On Wed, Sep 26, 2012 at 3:07 AM, Franck Wolff <
> > > >> franck.wolff@graniteds.org>wrote:
> > > >> >
> > > >> >> Om,
> > > >> >>
> > > >> >> 2012/9/25 Om <bi...@gmail.com>
> > > >> >>
> > > >> >> > Franck,
> > > >> >> >
> > > >> >> > My initial reaction after reading the documentation is that
> this
> > > would
> > > >> >> be a
> > > >> >> > great addition to the Flex framework.
> > > >> >> >
> > > >> >> > If you don't mind, maybe you could address these concerns I
> have?
> > > >> >> >
> > > >> >> > 1. Can we make sure that this approach does not tie Flex to
> > > specific
> > > >> >> > server side solution (Java in this case)?
> > > >> >> >
> > > >> >>
> > > >> >> The validation can be used standalone, without any server-side
> > > >> counterpart:
> > > >> >> you can manually annotate your AS3 beans and run a pure
> client-side
> > > >> >> validation process. Usually, these annotations are generated by
> > Gas3,
> > > >> based
> > > >> >> on Java annotations you put on your Java entity beans, but this
> is
> > > just
> > > >> a
> > > >> >> typical JavaEE usage: the framework doesn't depend on any
> specific
> > > >> server
> > > >> >> implementation (Java or not).
> > > >> >>
> > > >> >> However, I realized after sending my last email that the bean
> > > validation
> > > >> >> framework relies on our BigDecimal implementation: the
> > > DecimalMax/Min,
> > > >> >> Digits and Max/Min constraints annotations make internal use of
> > > >> BigDecimal
> > > >> >> values in order to check the validity of a given field (which can
> > be
> > > a
> > > >> >> String, a Number, an int/uint or a BigDecimal). The purpose of
> this
> > > >> >> dependency is to stick, as much as possible, to the JSR-303
> > > >> specification
> > > >> >> and to make sure that the validation on the Flex side is
> consistent
> > > with
> > > >> >> the validation on the Java side. As a result, we must contribute
> > both
> > > >> the
> > > >> >> Bean Validation and Big Numbers implementations... But even with
> > this
> > > >> >> addition, there is no dependency to GraniteDS.
> > > >> >>
> > > >> >> To summarize:
> > > >> >>
> > > >> >> 1. The Bean Validation in AS3 doesn't depend on GraniteDS or
> any
> > > Java
> > > >> >> server-side solution: it comes from a specification written
> for
> > > Java
> > > >> EE
> > > >> >> developers, it is often used with our code generation tool
> > (Gas3),
> > > >> but
> > > >> >> you
> > > >> >> can use it without any specific server side solution (it can
> be
> > > PHP
> > > >> or
> > > >> >> whatever you want).
> > > >> >> 2. It does depend on our BigDecimal implementation, which
> comes
> > > >> >> originally from a Java class but serves a general purpose for
> > > >> handling
> > > >> >> numbers with arbitrary scale and precision. If you don't
> > > explicitly
> > > >> use
> > > >> >> BigDecimal in your code, and more specifically, if you don't
> try
> > > to
> > > >> >> serialize this kind of value, there is again no dependency to
> > any
> > > >> >> specific
> > > >> >> server side solution. If you intend to serialize BigDecimal
> > > values,
> > > >> the
> > > >> >> server, whatever it is, has to handle an "externalization" of
> > the
> > > >> >> BigDecimal value as a String, which is not a big deal and
> > follows
> > > the
> > > >> >> AMF3
> > > >> >> specification (ie: org.granite.math.BigDecimal implements
> > > >> >> flash.utils.IExternalizable). There is of course a built-in
> > > support
> > > >> for
> > > >> >> that in GraniteDS, but it is just related to a
> (de)serialization
> > > >> which
> > > >> >> not
> > > >> >> all used in the Bean Validation framework.
> > > >> >>
> > > >> >>
> > > >> >> 2. Do you think this could go in the SDK itself or would it go
> > into
> > > an
> > > >> >> > ancilliary library, but still part of Flex. Can you suggest a
> > > >> package
> > > >> >> > structure?
> > > >> >> >
> > > >> >>
> > > >> >> Our current packages structure is:
> > > >> >>
> > > >> >> org.granite.validation (Bean Validation)
> > > >> >> org.granite.math (BigDecimal)
> > > >> >>
> > > >> >> It could be whatever you want. It can go into an ancillary
> library,
> > > but
> > > >> it
> > > >> >> would be simpler for users to be able to use it without any
> > specific
> > > >> >> configuration. Again, it's up to you.
> > > >> >>
> > > >> >>
> > > >> >> > 3. What happens to JSR 303 if/when you contribute the AS3
> > portion
> > > of
> > > >> the
> > > >> >> > implementation? Obviously we can't guarantee that Apache Flex
> > > will
> > > >> >> follow
> > > >> >> > that standard always.
> > > >> >> >
> > > >> >>
> > > >> >> An implementation of any JSR doesn't have to follow its
> evolution.
> > At
> > > >> the
> > > >> >> time we wrote this code and because we are from the Java "world",
> > we
> > > >> tried
> > > >> >> to follow the specification as far as possible and to guaranty
> that
> > > the
> > > >> >> Java validation would be consistent with the Flex one. It would
> be
> > of
> > > >> >> course great to keep this tight compatibility, but the Flex
> > > >> implementation
> > > >> >> can evolve its own way, by adding specific features or even
> > breaking
> > > the
> > > >> >> requisite of being a "certified" JSR-303 implementation. Any
> sound
> > > >> >> evolution is welcomed, we are not specification fundamentalists
> ;)
> > > >> >>
> > > >> >>
> > > >> >> > 4. What sort of performance implications can we expect with
> this
> > > >> >> > approach? Also, would it help if we make changes to the Flex
> > > >> compiler
> > > >> >> for
> > > >> >> > this to perform better?
> > > >> >> >
> > > >> >>
> > > >> >> As far as we know from our users, performances are very good. I
> > don't
> > > >> see
> > > >> >> any compiler change that could specifically benefit to this
> > > framework:
> > > >> the
> > > >> >> only performance issue with BigDecimal is that it relies on
> 32-bits
> > > >> >> integers and computations would have been easier to implement and
> > > better
> > > >> >> performing if we could have used 64-bits long types. But this
> > rather
> > > a
> > > >> >> Flash VM issue than a compiler one if I'm right.
> > > >> >>
> > > >> >> Thanks a lot for offering to contribute to Apache Flex!
> > > >> >> >
> > > >> >>
> > > >> >> You're welcome, thanks for your interest in our contribution
> offer.
> > > >> >> Franck.
> > > >> >>
> > > >> >>
> > > >> >> >
> > > >> >> > Regards,
> > > >> >> > Om
> > > >> >> > On Sep 24, 2012 7:40 AM, "Franck Wolff" <
> > > franck.wolff@graniteds.org>
> > > >> >> > wrote:
> > > >> >> >
> > > >> >> > > Hi Carlos,
> > > >> >> > >
> > > >> >> > > 2012/9/24 Carlos Rovira <ca...@codeoscopic.com>
> > > >> >> > >
> > > >> >> > > > Hi Franck,
> > > >> >> > > >
> > > >> >> > > > I think it would be great. I was in the way to make some
> > > >> >> > > > implementation some time ago since flex view validation is
> > > >> >> problematic
> > > >> >> > > > when you try to use MVC but I never get to far. In flex the
> > > >> problem
> > > >> >> is
> > > >> >> > > > that validation and view controls are dependent and it
> would
> > be
> > > >> great
> > > >> >> > > > to have bean validation in order to validate data and have
> > real
> > > >> >> > > > separation from the view. This brings the problem on how to
> > > show
> > > >> the
> > > >> >> > > > errors in controls to let the user now about a failed
> > > validation.
> > > >> I
> > > >> >> > > > suppose that is solved in GDS.
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > > Yes, we have a specific component called FormValidator which
> > > >> displays
> > > >> >> > > errors in real-time, based on the user input.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > > So I think bean validation would be a great improvement in
> > flex
> > > >> SDK
> > > >> >> > > > and annotations would make it more usable.
> > > >> >> > > >
> > > >> >> > > > For BigDecimal and others classes could be great as well,
> > but I
> > > >> don't
> > > >> >> > > > have clear how could be donate to sdk...maybe it could go
> to
> > an
> > > >> >> > > > extension package or something like that and get some
> > > >> externalization
> > > >> >> > > > base implementation...
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > > An extension package is of course an option.
> > > >> >> > >
> > > >> >> > > Thanks for your quick feedback,
> > > >> >> > > Franck.
> > > >> >> > >
> > > >> >> > > 2012/9/24 Franck Wolff <fr...@graniteds.org>:
> > > >> >> > > > > Hi All,
> > > >> >> > > > >
> > > >> >> > > > > We, at Granite Data Services <http://www.graniteds.org>,
> > are
> > > >> >> > > considering
> > > >> >> > > > > contributing part of our Flex client code to this Apache
> > > >> project.
> > > >> >> Our
> > > >> >> > > > first
> > > >> >> > > > > thought is to contribute our Bean Validation (aka
> JSR-303)
> > > >> >> > > implementation
> > > >> >> > > > > in ActionScript3: this framework gives an easy and
> powerful
> > > way
> > > >> to
> > > >> >> > > > validate
> > > >> >> > > > > ActionScript beans based on constraint annotations (see
> > > >> >> documentation
> > > >> >> > > > > here<
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html
> > > >> >> > > > >).
> > > >> >> > > > > This framework can be used standalone, with no specific
> > > >> dependency
> > > >> >> to
> > > >> >> > > > rest
> > > >> >> > > > > of the GraniteDS platform, but is usually best used
> > together
> > > >> with
> > > >> >> > Gas3
> > > >> >> > > > (our
> > > >> >> > > > > code generation tool) which replicates Java entities
> > > annotated
> > > >> with
> > > >> >> > > > > constraint annotations in ActionScript3, with the same
> > > >> constraints.
> > > >> >> > The
> > > >> >> > > > > validation process can then be executed on the Flex,
> > > replicating
> > > >> >> what
> > > >> >> > > > Java
> > > >> >> > > > > is doing on its part, and can display error messages on
> the
> > > fly,
> > > >> >> > while
> > > >> >> > > > the
> > > >> >> > > > > user is filling out a Flex form.
> > > >> >> > > > >
> > > >> >> > > > > What do you think about such contribution? We could also
> > > >> contribute
> > > >> >> > > later
> > > >> >> > > > > our Flex implementation of the BigDecimal, BigInteger and
> > > Long
> > > >> >> > classes
> > > >> >> > > > (see
> > > >> >> > > > > documentation here<
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.bignumbers.html
> > > >> >> > > > >),
> > > >> >> > > > > but this implementation has a dependency on some
> > > externalization
> > > >> >> > > features
> > > >> >> > > > > specific to GraniteDS.
> > > >> >> > > > >
> > > >> >> > > > > Regards,
> > > >> >> > > > > --
> > > >> >> > > > > Franck Wolff / William Draï
> > > >> >> > > > > Granite Data Services
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > > --
> > > >> >> > > > Carlos Rovira
> > > >> >> > > > Director de Tecnología
> > > >> >> > > > M: +34 607 22 60 05
> > > >> >> > > > F: +34 912 35 57 77
> > > >> >> > > > CODEOSCOPIC S.A.
> > > >> >> > > > Avd. del General Perón, 32
> > > >> >> > > > Planta 10, Puertas P-Q
> > > >> >> > > > 28020 Madrid
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > --
> > > >> >> > > Franck Wolff
> > > >> >> > > Granite Data Services Inc.
> > > >> >> > > CEO & Founder
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Franck Wolff
> > > >> >> Granite Data Services Inc.
> > > >> >> CEO & Founder
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >> Director de Tecnología
> > > >> M: +34 607 22 60 05
> > > >> F: +34 912 35 57 77
> > > >> CODEOSCOPIC S.A.
> > > >> Avd. del General Perón, 32
> > > >> Planta 10, Puertas P-Q
> > > >> 28020 Madrid
> > > >>
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > Director de Tecnología
> > > M: +34 607 22 60 05
> > > F: +34 912 35 57 77
> > > CODEOSCOPIC S.A.
> > > Avd. del General Perón, 32
> > > Planta 10, Puertas P-Q
> > > 28020 Madrid
> > >
> >
>
--
Franck Wolff
Granite Data Services Inc.
CEO & Founder