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. >> > >
