First of all there's no intention to break other components by using Joda natively. We've added support for Joda in the JDO object store already and I recommend that other object stores and viewers will start supporting Joda types too, it shouldn't be hard to accomplish that. Marking the applib date/time classes being deprecated will hint developers to use Joda over applib but will not break anything. It's up to the community to do a vote on the final removal of the classes but there's no rush to do that.
Your quick fix to expose the underlying Joda classes would IMHO make things more complicated than it should be. One of the drivers to move to Joda is that in the current application we're building we have to do a lot of time and date based calculations and Joda excels in that. A little refactoring should not stop the improvement of the framework but perhaps I'm missing some more relevant. Kind Regards, Jeroen On Tue, Sep 18, 2012 at 7:05 PM, Kevin Meyer - KMZ <[email protected]> wrote: > An immediate quick fix would be to provide a getter on the applib date > classes that exposes the underlying Joda class... then you could get > the full access you want, without affecting any other component (e.g. > the Isis sql object store ;-) ) > > Regards, > Kevin > > On 18 Sep 2012 at 16:50, Jeroen van der Wal wrote: > > > The reason that I use Joda is because I want to access it full > capabilities. > > > > +1 to mark the applib date/times as deprecated and leave it around for a > > while. I'm volunteering to do some refactoring of Isis. > > > > Regards, > > > > Jeroen > > > > > > > > > > On Tue, Sep 18, 2012 at 4:20 PM, Dan Haywood > > <[email protected]>wrote: > > > > > I wonder if we should just get rid of the Isis applib date/times? > It's not > > > like our implementation is in any way superior to Joda (rather: it is > > > substantially inferior). > > > > > > > > > > > > On 18 September 2012 14:54, Kevin Meyer - KMZ <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > > This probably does not have any direct bearing on this discussion, > but > > > > I have converted all Isis date / time variables to (at their core) > use > > > > Joda time instead of Java time classes... the core Joda time property > > > > might not be exposed, though. > > > > > > > > Regards, > > > > Kevin > > > > > > > > On 18 Sep 2012 at 15:38, Jeroen van der Wal wrote: > > > > > > > > > Hi Minto, > > > > > > > > > > 1. UUID is not persisted by default but will be if you mark it with > > > > > @Persistent. Don't know from the top of my head if that's also the > case > > > > for > > > > > the applib.DateTime. As an alternative you can use > > > org.joda.time.DateTime > > > > > (which also must be annotated with @Persistent). See the > Datanucleus > > > > > documentation on Java types[1] for more information. > > > > > > > > > > 2. Collections should be marked with > > > > > @Persistent(mappedBy="<parent class>") for a 1-N relationship. Add > an > > > > > additional @Join to create a separate join table. Again, > Datanucleus > > > > > provides loads of documentation on this topic [2]. > > > > > > > > > > Hope this helps. > > > > > > > > > > Jeroen > > > > > > > > > > [1] http://www.datanucleus.org/products/datanucleus/jdo/types.html > > > > > [2] > > > > > > > > > > > > > http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_set.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jeroen van der Wal > > > > > Stromboli b.v. > > > > > +31 655 874050 > >
