yes, I assume so, they get enhanced only when I use a maven goal, my use of JUnit/JMock is just within Eclipse and no so DN enhancement is is occurring. Obviously I need to go another step and do integration testing using enhanced classes too, and I will get to that very soon.
If Naked Objects as a paradigm has merit, then the UI development, including testing via the UI should, to my mind, be a minor part of the process. l am finding things 'blowing up' in the UI, but those issues will mostly be caught with integration tests I feel. I particular a kind of error that appears to be a complex interaction between wicket, the Isis meta-model and DataNucleus that can take some sorting out, its the 'array index out of bounds' error. [also, my idea of separating into data and behaviour classes using inheritance won't work, I should try to get better sleep!] On Sat, Oct 17, 2015 at 7:04 AM, Stephen Cameron <[email protected] > wrote: > > > On Sat, Oct 17, 2015 at 6:53 AM, Stephen Cameron < > [email protected]> wrote: > >> >> >> If you move to TDD and use JMock, which I am trying now, less of your >> time is spent testing things in the UI. >> > and you are testing with unenhanced classes. > >> >> So far my thoughts of prototyping in real time have not happened, maybe >> one day. >> >> So class reloading is now less of an issue for me, but DCEVM sounds good. >> >> It seems to me that putting behaviour in services is moving away from >> (Naked) Objects towards procedural code, that services are essentially >> modules of procedures. I am not against this outright, quite the contrary, >> but maybe there are downsides to consider? >> >> Another option is to split classes into an abstract data-model parent and >> a concrete behaviour-model child using inheritance. Could this alleviate >> the need for DN enhancement with each change issue? >> >> Steve >> >> On Sat, Oct 17, 2015 at 2:13 AM, Rade, Joerg / Kuehne + Nagel / Ham GI-PS >> <[email protected]> wrote: >> >>> Hi Dan, >>> >>> changes to non-entity classes could be reloaded? >>> I assume I have to rebuild the war. Correct? >>> >>> >One reasonable workaround is to use contributed actions, and/or event >>> bus, >>> >and have them in essence "decorate" the class. As your app gets larger >>> you'll >>> >probably want to be using these anyway. And the contributing services >>> can be >>> >reloaded by DCEVM without requiring any enhancing going on. >>> >>> Can you point me to an example? Or give more details? >>> >>> Thanks in advance >>> Jörg >>> -----Ursprüngliche Nachricht----- >>> Von: Dan Haywood [mailto:[email protected]] >>> Gesendet: Freitag, 31. Juli 2015 13:13 >>> An: users >>> Betreff: Re: faster development in eclipse >>> >>> I've been meaning to do add some docs and a quick screencast about DCEVM >>> for a while; maybe this weekend.. >>> >>> To answer Martin's question: in fact, if running in prototype mode, then >>> the Wicket viewer automatically invalidates the metamodel of the (class of >>> the) displayed object... this is why editing the .layout.json file and >>> reloading changes causes updates to be picked up automatically. >>> >>> What is more tricky is if the entity is changed itself, ie its >>> structure/method signatures. If the internals are changed then regular >>> Java Hotspot can mostly cope, and I suspect that DCEVM would make that more >>> reliable still. But if the entity has changed then the class needs >>> re-enhancing. Unfortunately DN doesn't provide any easy way to do that, so >>> there's little point in Isis providing an API to invalidate a class if the >>> underlying DN metamodel hasn't also been updated. >>> >>> One reasonable workaround is to use contributed actions, and/or event >>> bus, and have them in essence "decorate" the class. As your app gets >>> larger you'll probably want to be using these anyway. And the contributing >>> services can be reloaded by DCEVM without requiring any enhancing going on. >>> >>> ~~~ >>> Alternatively you could dust off the JRebel plugin that I worked on >>> [1]. I did get this working reasonably well for me, though I'm not sure if >>> anyone else did. (And, having said that I haven't found myself reaching >>> for it, but partly because I switch context between projects all the time). >>> Anyway, perhaps worth checking out. >>> >>> HTH >>> Dan >>> >>> >>> [1] https://github.com/isisaddons/isis-jrebel-plugin >>> >>> >>> >>> On 31 July 2015 at 09:03, Martin Grigorov <[email protected]> wrote: >>> >>> > Hi, >>> > >>> > I use DCEVM for code reloading. It is free and there is nothing to >>> learn. >>> > But it doesn't help with updating Isis meta model. >>> > It would be nice if Isis exposes REST/JMX/... interface that triggers >>> > rebuild of the model. >>> > @Dan: is this possible with the code of isis-mavel-plugin? >>> > On Jul 31, 2015 7:45 AM, "Stephen Cameron" >>> > <[email protected]> >>> > wrote: >>> > >>> > > Hi again, >>> > > >>> > > After playing around with options I now think there isn't much >>> > opportunity >>> > > to speed things up, other than to use JRebel or change the way I >>> > > develop (not start the webapp so much). The webapp project looks for >>> > > jars in the maven repository not the war, so I only need to do maven >>> > > install on the >>> > dom >>> > > project when I change a dom class. That should have been apparent >>> > > sooner >>> > :( >>> > > >>> > > Bottomline: the webapp takes some time to start, but that is fine. >>> > > >>> > > >>> > > >>> > > On Fri, Jul 31, 2015 at 11:27 AM, Stephen Cameron < >>> > > [email protected]> wrote: >>> > > >>> > > > Hi, >>> > > > >>> > > > I would greatly appreciate some advice on speeding up development >>> > > > in Eclipse. Using the simpleapp project with separate dom, >>> > > > fixture, >>> > > integtest >>> > > > and webapp subprojects. >>> > > > >>> > > > I'd at least like the webserver (jetty,tomcat) to restart when I >>> > modify a >>> > > > dom class. This is what I am used to with Dynamic Web Projects, >>> > > > however after a bit of trying today I still cannot get that to >>> > > > work, using >>> > > Tomcat. >>> > > > >>> > > > It seems most are using JRebel with IntelliJ, but I am not so keen >>> > > > to >>> > go >>> > > > there yet as I am (re)learning on many fronts at present. >>> > > > >>> > > > The issue with Tomcat is a jetty dependancy, this was noted >>> > > > previously [1], but I could not get around it by removing >>> > > > jetty-all-9.2.11.v20150529.jar as suggested, I then got a >>> > > > null-pointer exception. >>> > > > >>> > > > At the moment I have to rebuild the whole project after a class >>> > > > change >>> > in >>> > > > the dom-project then restart the server to see the change. Is the >>> > because >>> > > > the .war has to be rebuilt for mvn jetty:run to use the new >>> > > > version of >>> > > the >>> > > > class file? >>> > > > >>> > > > I've just tried to use the eclipse jetty plugin but that is >>> > > > telling me that the dom classes have not been enhanced by >>> datanucleus. >>> > > > >>> > > > Hoping for some insights. >>> > > > >>> > > > Thanks >>> > > > Steve C >>> > > > >>> > > > >>> > > > [1] >>> > > http://permalink.gmane.org/gmane.comp.apache.incubator.isis.devel/99 >>> > > 31 >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > >>> >>> Kühne + Nagel (AG & Co.) KG >>> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE >>> 812773878. >>> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), >>> Dirk Blesius, Martin Brinkmann, Matthias Heimbach, Jan-Hendrik >>> Köstergarten, Nicholas Minde, Lars Wedel, Jens Wollesen. >>> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: >>> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, >>> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. >>> Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Richard Huhn, >>> Björn Johansson, Jan Kunze, Bruno Mang, Stefan Paul, Holger Ketz, Dominic >>> Edmonds. >>> >>> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen >>> Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen >>> insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von >>> Ziffer 23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen >>> gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com >>> einsehen. Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen >>> internationaler Übereinkommen weder unsere Haftung noch die Zurechnung des >>> Verschuldens von Leuten und sonstigen Dritten zu Gunsten des Auftraggebers >>> erweitert, und (2) wir in den im deutschen Seehandelsrecht aufgeführten >>> Fällen des nautischen Verschuldens oder Feuer an Bord nur für eigenes >>> Verschulden und (3) im Sinne der CMNI genannten Voraussetzungen nicht für >>> nautisches Verschulden, Feuer an Bord oder Mängel des Schiffes haften. >>> >> >> >
