Hi Dan, Thanks.
I was able to do the complete build with all the unit tests running successfully. Let me know if you need help in any areas where the design is clear and the changes are clear cut. I can start with some simple things. I have just started to go through the organisation of Isis and its architecture. Thanks & Regards, Mukul On 4 September 2012 05:18, Dan Haywood <d...@haywood-associates.co.uk> wrote: > Hi Mukul, > > per other emails, I've now applied these changes... rev 1380404 ~ 1380408. > > Dan > > > On 31 August 2012 12:28, mukul joshi <mukul.ashok.jo...@gmail.com> wrote: > > > Hi Dan, > > > > Further update. > > > > I was able to solve the issue with the DN enhancer: > > > > [ERROR] Failed to execute goal > > org.datanucleus:maven-datanucleus-plugin:3.1.0-release:enhance (default) > on > > project tck-dom: Error executing DataNucleus tool > > org.datanucleus.enhancer.DataNucleusEnhancer: InvocationTargetException: > > Plugin (Bundle) "org.datanucleus" is already registered. Ensure you dont > > have multiple JAR versions of the same plugin in the classpath. > > > > The resolution is mentioned here: > > > > > http://stackoverflow.com/questions/877949/conflicting-versions-of-datanucleus-enhancer-in-a-maven-google-app-engine-projec > > > > The pom.xml was changed in jdo-applib and tck-dom by adding scope as > > runtime for datanucleus-core as follows: > > > > <dependency> > > <groupId>org.datanucleus</groupId> > > <artifactId>datanucleus-core</artifactId> > > <scope>runtime</scope> > > </dependency> > > > > Also removed the duplicate dependency for jdo-api in the pom.xml in > > jdo-applib. > > > > With these changes was able to go ahead in build. Now will try the build > > for the remaining components. > > > > Thanks & Regards, > > Mukul > > > > > > On 30 August 2012 18:19, mukul joshi <mukul.ashok.jo...@gmail.com> > wrote: > > > > > Thanks Dan. > > > > > > So do we try with Joda localdate? Do we know where all we will have to > > > change or what is the pattern for replacement? > > > > > > Another observation: In the setup of this test class, there is call to > > > Locale.setDefault(Locale.UK) which obviously does not seem to be > > effective > > > as Java still picks up the timezone from the local os setup. > > > > > > While continuing the build there is another issue in the build of > > > jdo-applib: > > > [WARNING] > > > [WARNING] Some problems were encountered while building the effective > > > model for > > > > > > org.apache.isis.runtimes.dflt.objectstores:jdo-applib:jar:0.3.1-incubating-SNAPSHOT > > > [WARNING] > 'dependencies.dependency.(groupId:artifactId:type:classifier)' > > > must be unique: javax.jdo:jdo-api:jar -> duplicate declaration of > version > > > (?) @ line 128, column 21 > > > [WARNING] > > > [WARNING] It is highly recommended to fix these problems because they > > > threaten the stability of your build. > > > [WARNING] > > > [WARNING] For this reason, future Maven versions might no longer > support > > > building such malformed projects. > > > [WARNING] > > > > > > In the pom.xml, the dependency for jdo-api is given twice: > > > <dependency> > > > <groupId>javax.jdo</groupId> > > > <artifactId>jdo-api</artifactId> > > > </dependency> > > > > > > <!-- DataNucleus (horrid, but needed to run the > > > enhancer)--> > > > <dependency> > > > <groupId>javax.jdo</groupId> > > > <artifactId>jdo-api</artifactId> > > > </dependency> > > > > > > And build fails with this error: > > > Error executing DataNucleus tool > > > org.datanucleus.enhancer.DataNucleusEnhancer: > InvocationTargetException: > > > Plugin (Bundle) "org.datanucleus" is already registered. Ensure you > dont > > > have multiple JAR versions of the same plugin in the classpath. > > > > > > Thanks & Regards, > > > Mukul > > > > > > > > > On 30 August 2012 18:05, Dan Haywood <d...@haywood-associates.co.uk> > > wrote: > > > > > >> Thanks for this, Mukul. I'll apply this patch shortly. > > >> > > >> As regards the actual problem, I can tell you that Isis does support > > >> timezones and localization; Rob Matthews did a lot of work on this in > > >> order > > >> to support an internet-hosted app he's built using Isis / Scimpi. So > > >> fundamentally I don't think there's an issue with Isis' design; just > > that > > >> that particular test (and others?) is not written correctly. > > >> > > >> Something else to consider: I'm currently implementing support for > Joda > > >> LocalDate. For many applications, I suspect this will be an > > appropriate > > >> choice. > > >> > > >> Dan > > >> > > >> > > >> On 30 August 2012 13:21, mukul joshi <mukul.ashok.jo...@gmail.com> > > wrote: > > >> > > >> > Hi Dan, > > >> > > > >> > Thanks. > > >> > > > >> > I have raised the JIRA issue: > > >> > ISIS-255<https://issues.apache.org/jira/browse/ISIS-255>and the > > >> > modified ObjectFixtureFilePersistorTest.java as per your suggested > > >> > workaround to skip the test has been attached to the issue. > > >> > > > >> > Let me know if we want to do any changes in the core classes to > handle > > >> the > > >> > TimeZone correctly. Or this will require too many changes? > > >> > > > >> > Thanks & Regards, > > >> > Mukul > > >> > > > >> > On 30 August 2012 13:19, Dan Haywood <d...@haywood-associates.co.uk> > > >> wrote: > > >> > > > >> > > Hi Mukul, > > >> > > > > >> > > Thanks for checking out Isis. > > >> > > > > >> > > Ah, dates ... don't you just love them! I'm afraid you are > > suffering > > >> > from > > >> > > the fact that the main authors of Isis are based in the UK, and so > > we > > >> > > sometimes miss these things. Great thing about Apache is we get > > >> interest > > >> > > world-wide, so it helps flush out these bugs. > > >> > > > > >> > > ~~~ > > >> > > The simplest short-term fix for this defect might be to use > > >> > > assumeThat(...), so that the test is skipped if your timezone is > not > > >> BST. > > >> > > > > >> > > Something like (in pseudo code): > > >> > > > > >> > > assumeThat(TimeZone.currentTimeZone().getName(), is("GMT")); > > >> > > > > >> > > > > >> > > Please raise a JIRA ticket to have this fixed, and - if you have > the > > >> > time - > > >> > > attach the assumeThat(...) workaround as a patch so we could apply > > it. > > >> > > > > >> > > Thx > > >> > > Dan > > >> > > > > >> > > > > >> > > > > >> > > On 29 August 2012 14:23, mukul joshi < > > >> mukul.ashok.jo...@googlemail.com > > >> > > >wrote: > > >> > > > > >> > > > Hi, > > >> > > > > > >> > > > > > >> > > > > > >> > > > I am doing a local build of Apache Isis and I get an error in > the > > >> build > > >> > > of > > >> > > > the testsupport component as follows: > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > loadInstance(org.apache.isis.runtimes.dflt.runtime.fixturedomainservice.ObjectFixtureFilePersistorTest): > > >> > > > expected:<Mon Mar 08 06:30:00 IST 2010> but was:<Mon Mar 08 > > 01:00:00 > > >> > IST > > >> > > > 2010> > > >> > > > > > >> > > > > > >> > > > > > >> > > > This is because my Time Zone is IST. If I set my Time Zone to > GMT > > >> then > > >> > > the > > >> > > > test passes. > > >> > > > > > >> > > > > > >> > > > > > >> > > > The error comes at this line in the class > > >> > ObjectFixtureFilePersistorTest > > >> > > > and method loadInstance(): > > >> > > > > > >> > > > > > >> > > > > > >> > > > Assert.assertEquals(dateFormat.parse("08-Mar-2010 01:00 GMT"), > > >> > > > epv.getDate()); > > >> > > > > > >> > > > > > >> > > > > > >> > > > Here the epv.getData() returns date in IST and the code getting > > >> > executed > > >> > > is > > >> > > > from the SimpleEntity getDate() method > > >> > > > > > >> > > > > > >> > > > > > >> > > > Is there any way to fix this? How do we make the SimpleEntity > use > > >> the > > >> > UTC > > >> > > > time zone instead of IST? > > >> > > > > > >> > > > > > >> > > > > > >> > > > Thanks & Regards, > > >> > > > > > >> > > > Mukul > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
