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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 < >> [email protected] >> > > >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 >> > > > >> > > >> > >> > >
