My use case is completely "contract-first" and nothing else. However, I
need to provide a client API based on the JAXB generated bindings that
need to keep track of modified state of JAXB generated bindings. This
seems to be something the bindings should be able to keep track of
themselves by injecting some code into setter methods to mark an entity
as being modified.
I do not see this as a "contract-first" vs. "code-first" issue or
distinction.
Felipe Gaścho wrote:
> sorry, I couldn't understand very well the scenario where your feature
> can aggregate better value...
>
>
>> "whether it has been modified since it was created or no"
>>
>
> ok, it can be too much purism, but in my humble opinion JAXB is best
> useful in case of contract-first development, and to suppose a
> generated class can be modified is to assume you are
> half-contract-first-half-code-first :(
>
> ok, if you are talking code-first only, perhaps it can be useful ..
> but for contract-first does not make sense........
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com