You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by "Rade, Joerg / Kuehne + Nagel / Ham GI-PS" <Jo...@Kuehne-Nagel.com> on 2015/10/16 17:13:47 UTC
AW: faster development in eclipse
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:dan@haywood-associates.co.uk]
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 <mg...@apache.org> 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"
> <st...@gmail.com>
> 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 <
> > steve.cameron.62@gmail.com> 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.
Re: faster development in eclipse
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Agree with what's being said here, though I think that there's two separate
threads.
1. yes, TDD is the best way to develop applications. For Isis, I think
that integration tests work best, because it is "outside-in thinking", a la
the GOOS book (well worth a read if you've not come across it). Unit tests
are great for filling in the holes, ie the tricky algorithmic bits of
logic. I like to separate these out into domain services so that they can
be tested in isolation.
2. completely separately, it's also valuable to run up the app, then modify
the production code and see the changes through hot reloading. You might
be changing the production code because you've just written a failing
integration test. Or you might be spiking out/prototyping a new feature
with the end-users, figuring out what the requirements actually are.
There is always a risk that if you are prototyping new features without
tests (just exploring the domain) then you'll forget/not bother to write
any integration tests. The TDD purists would say that you should throw
away any production code not written as a result of a failing tests ("TDD
as if you meant it" [2]) , and that tests alone should drive out the
design.
With Isis though I don't think it's worth being quite so dogmatic.... for
myself I'm happy to put the tests in after. One reason for that is because
the framework provides plenty of feedback already as to whether the
requirements are met. Also, the framework provides some pretty powerful
design tools (such as mixins/contributions and the event bus) that if used
correctly are likely to keep the design clean. A tool such as Structure101
is a good way to ensure that the overall architecture is sound.
My 2c
Cheers
Dan
[1] http://www.growing-object-oriented-software.com/
[2] http://www.infoq.com/presentations/TDD-as-if-You-Meant-It
On 17 October 2015 at 08:43, Óscar Bou - GOVERTIS <o....@govertis.com>
wrote:
> Hi to all.
>
> Just our experience.
>
> We currently have in production an Isis-based system with more than 4.600
> integration tests fully automated through Jenkins, giving us a code
> coverage over the 70% barrier normally used as reference in Silicon Valley.
>
> We currently have “no UI” testing at all, in all those screens
> automatically generated through the Isis meta-model.
> Simply it’s not needed ...
>
> And we have great confidence that every new commit passing successfully
> all integration tests (including the new ones introduced) is
> production-ready, as domain logic has been properly tested and the UI,
> simply, is not needed ...
>
> We cannot envision that in any other platform than Isis.
>
> So yes, please, my advise to all community is to advance on the
> integration tests path.
> We currently have a wonderful platform for that.
>
> Cheers,
>
> Oscar
>
>
>
>
> > El 17 oct 2015, a las 6:30, Stephen Cameron <st...@gmail.com>
> escribió:
> >
> > 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 <
> steve.cameron.62@gmail.com
> >> wrote:
> >
> >>
> >>
> >> On Sat, Oct 17, 2015 at 6:53 AM, Stephen Cameron <
> >> steve.cameron.62@gmail.com> 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
> >>> <Jo...@kuehne-nagel.com> 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:dan@haywood-associates.co.uk]
> >>>> 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 <mg...@apache.org>
> 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"
> >>>>> <st...@gmail.com>
> >>>>> 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 <
> >>>>>> steve.cameron.62@gmail.com> 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.
> >>>>
> >>>
> >>>
> >>
>
>
Re: faster development in eclipse
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi to all.
Just our experience.
We currently have in production an Isis-based system with more than 4.600 integration tests fully automated through Jenkins, giving us a code coverage over the 70% barrier normally used as reference in Silicon Valley.
We currently have “no UI” testing at all, in all those screens automatically generated through the Isis meta-model.
Simply it’s not needed ...
And we have great confidence that every new commit passing successfully all integration tests (including the new ones introduced) is production-ready, as domain logic has been properly tested and the UI, simply, is not needed ...
We cannot envision that in any other platform than Isis.
So yes, please, my advise to all community is to advance on the integration tests path.
We currently have a wonderful platform for that.
Cheers,
Oscar
> El 17 oct 2015, a las 6:30, Stephen Cameron <st...@gmail.com> escribió:
>
> 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 <steve.cameron.62@gmail.com
>> wrote:
>
>>
>>
>> On Sat, Oct 17, 2015 at 6:53 AM, Stephen Cameron <
>> steve.cameron.62@gmail.com> 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
>>> <Jo...@kuehne-nagel.com> 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:dan@haywood-associates.co.uk]
>>>> 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 <mg...@apache.org> 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"
>>>>> <st...@gmail.com>
>>>>> 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 <
>>>>>> steve.cameron.62@gmail.com> 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.
>>>>
>>>
>>>
>>
Re: faster development in eclipse
Posted by Stephen Cameron <st...@gmail.com>.
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 <steve.cameron.62@gmail.com
> wrote:
>
>
> On Sat, Oct 17, 2015 at 6:53 AM, Stephen Cameron <
> steve.cameron.62@gmail.com> 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
>> <Jo...@kuehne-nagel.com> 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:dan@haywood-associates.co.uk]
>>> 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 <mg...@apache.org> 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"
>>> > <st...@gmail.com>
>>> > 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 <
>>> > > steve.cameron.62@gmail.com> 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.
>>>
>>
>>
>
Re: faster development in eclipse
Posted by Stephen Cameron <st...@gmail.com>.
On Sat, Oct 17, 2015 at 6:53 AM, Stephen Cameron <steve.cameron.62@gmail.com
> 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
> <Jo...@kuehne-nagel.com> 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:dan@haywood-associates.co.uk]
>> 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 <mg...@apache.org> 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"
>> > <st...@gmail.com>
>> > 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 <
>> > > steve.cameron.62@gmail.com> 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.
>>
>
>
Re: faster development in eclipse
Posted by Stephen Cameron <st...@gmail.com>.
If you move to TDD and use JMock, which I am trying now, less of your time
is spent testing things in the UI.
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 <
Joerg.Rade@kuehne-nagel.com> 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:dan@haywood-associates.co.uk]
> 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 <mg...@apache.org> 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"
> > <st...@gmail.com>
> > 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 <
> > > steve.cameron.62@gmail.com> 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.
>
Re: faster development in eclipse
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Following on from this, have updated the users' and ref guide with some
info on the upcoming @Mixin annotation...
Cheers
Dan
...
http://isis.apache.org/guides/ug.html#_ug_more-advanced_decoupling_mixins
On 16 October 2015 at 17:08, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi Jörg
>
> within...
>
>
> On 16 October 2015 at 16:13, Rade, Joerg / Kuehne + Nagel / Ham GI-PS <
> Joerg.Rade@kuehne-nagel.com> wrote:
>
>> Hi Dan,
>>
>> changes to non-entity classes could be reloaded?
>> I assume I have to rebuild the war. Correct?
>>
>>
> When running from the IDE we tend to use the org.apache.isis.WebServer
> bootstrapper, which basically runs an embedded Jetty. This saves having to
> do any packaging or deployment, and works fine for both Eclipse and
> IntelliJ.
>
> See the user guide [1] for more on that.
>
>
>
>
>
>> >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?
>>
>>
> I haven't used DCEVM on Eclipse, but it seems that it's easy enough to get
> going, see eg [2].
>
> As it looks like I mentioned before, the main thing that prevents hot
> reloading is the DataNucleus enhancer... any change to entities is going to
> require the entity to be re-enhanced, and the JDO metamodel recreated,
> which usually "stuffs things up".
>
> However, more often than not the structure doesn't change that often,
> however it's the behaviour that you're most likely wanting to change while
> the app is still running. If you move that behaviour out into contributed
> services, then these can be reloaded happily (when running in prototype
> mode). Isis will automatically recreate the portion of the metamodel for
> any domain object when it is rendered.
>
> There's a brief discussion of contributed services in the users' guide
> [3]; you'll find that the various isis addons all use the technique quite
> extensively (eg audit/command contribute to each other via the
> HasTransactionId interface; audit/security/sessionlogger/command contribute
> to each other via the HasUserName interface).
>
> In 1.10.0-SNAPSHOT I've been working on an improved programming model,
> called "mixins", that makes this more overt. The new incode modules [4],
> [5] use this throughout, see eg [6]. It's basically a simplified version
> of the DCI architecture, per Trygve Reenskaug and Jim Coplien.
>
>
> HTH
> Dan
>
>
>
> [1] http://localhost:4000/guides/ug.html#_ug_deployment_cmd-line
> [2]
> http://tirthalpatel.blogspot.co.uk/2014/06/steps-to-setup-hotswap-agent-in-eclipse.html
> [3] http://localhost:4000/guides/ug.html#_ug_how-tos_domain-services
> [4] https://github.com/incodehq/incode-module-note
> [5] https://github.com/incodehq/incode-module-commchannel
> [6]
> https://github.com/incodehq/incode-module-note/blob/master/dom/src/main/java/org/incode/module/note/dom/impl/note/Notable_notes.java#L35
> [7] http://www.artima.com/articles/dci_vision.html
>
>
>
>
>> Thanks in advance
>> Jörg
>> -----Ursprüngliche Nachricht-----
>> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
>> 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 <mg...@apache.org> 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"
>> > <st...@gmail.com>
>> > 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 <
>> > > steve.cameron.62@gmail.com> 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.
>>
>
>
Re: faster development in eclipse
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Jörg
within...
On 16 October 2015 at 16:13, Rade, Joerg / Kuehne + Nagel / Ham GI-PS <
Joerg.Rade@kuehne-nagel.com> wrote:
> Hi Dan,
>
> changes to non-entity classes could be reloaded?
> I assume I have to rebuild the war. Correct?
>
>
When running from the IDE we tend to use the org.apache.isis.WebServer
bootstrapper, which basically runs an embedded Jetty. This saves having to
do any packaging or deployment, and works fine for both Eclipse and
IntelliJ.
See the user guide [1] for more on that.
> >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?
>
>
I haven't used DCEVM on Eclipse, but it seems that it's easy enough to get
going, see eg [2].
As it looks like I mentioned before, the main thing that prevents hot
reloading is the DataNucleus enhancer... any change to entities is going to
require the entity to be re-enhanced, and the JDO metamodel recreated,
which usually "stuffs things up".
However, more often than not the structure doesn't change that often,
however it's the behaviour that you're most likely wanting to change while
the app is still running. If you move that behaviour out into contributed
services, then these can be reloaded happily (when running in prototype
mode). Isis will automatically recreate the portion of the metamodel for
any domain object when it is rendered.
There's a brief discussion of contributed services in the users' guide [3];
you'll find that the various isis addons all use the technique quite
extensively (eg audit/command contribute to each other via the
HasTransactionId interface; audit/security/sessionlogger/command contribute
to each other via the HasUserName interface).
In 1.10.0-SNAPSHOT I've been working on an improved programming model,
called "mixins", that makes this more overt. The new incode modules [4],
[5] use this throughout, see eg [6]. It's basically a simplified version
of the DCI architecture, per Trygve Reenskaug and Jim Coplien.
HTH
Dan
[1] http://localhost:4000/guides/ug.html#_ug_deployment_cmd-line
[2]
http://tirthalpatel.blogspot.co.uk/2014/06/steps-to-setup-hotswap-agent-in-eclipse.html
[3] http://localhost:4000/guides/ug.html#_ug_how-tos_domain-services
[4] https://github.com/incodehq/incode-module-note
[5] https://github.com/incodehq/incode-module-commchannel
[6]
https://github.com/incodehq/incode-module-note/blob/master/dom/src/main/java/org/incode/module/note/dom/impl/note/Notable_notes.java#L35
[7] http://www.artima.com/articles/dci_vision.html
> Thanks in advance
> Jörg
> -----Ursprüngliche Nachricht-----
> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> 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 <mg...@apache.org> 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"
> > <st...@gmail.com>
> > 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 <
> > > steve.cameron.62@gmail.com> 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.
>