You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <Jo...@Kuehne-Nagel.com> on 2017/09/22 11:19:24 UTC
Kotlin archetye (WAS: AW: Complaints against Lombok?)
Hi,
changing (part of) a development environment is always effort.
For me switching to IntelliJ already pays off and I'll give Kotlin a try too.
I assume mixing languages would be possible as well?
Best regards
Jörg
-----Ursprüngliche Nachricht-----
Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Gesendet: Freitag, 22. September 2017 11:42
An: dev@isis.apache.org
Betreff: Re: Complaints against Lombok?
Hi Kev,
@Dan: Did you consider other helpers? How did you choose Lombok?
(Probably like others), we were looking at how to make the Estatio codebase easier to understand/work with, and I remembered seeing some blog posts about it and decided to check it out. Since it integrates nicely with the IDEs and Maven, it seemed to fit our environment nicely.
To switch topic a little (but not much)... what we all really want is a "better Java", in syntax if nothing else. (Those who know me will know what I'm about to say next ...) there's a good argument to advocating and ultimately switching to use Kotlin. I did manage to port the simpleapp to Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking of adding a new Kotlin archetype, perhaps initially as part of the Incode Platform rather than in Apache Isis proper.
Thoughts?
Cheers
Dan
On Fri, 22 Sep 2017 at 10:30 Chi Cuong Le <ch...@googlemail.com>
wrote:
> Hi all,
>
> from my point of view, choosing Lombok is not bad idea. It reduces a
> lot of code that developers do not want to write.
> yes, a specific Lombok version will only work with few JDKs. But it
> doesn't matter because we do not change our JDK every day. Every time
> when JDK upgrade, we have to adapt not only Lombok but also other
> third party libraries also.
>
> Viele Grüße/Best regards,
> Chi Cuong Le
>
> On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS
> <o....@govertis.com>
> wrote:
>
>>
>>
>> Hi all,
>>
>> I started to love @Getter and @Setter for more thant 1 year ago, and
>> really happy with that ;)
>>
>> Clearer code, with less boilerplate, and more readable Domain Entities.
>>
>> Basically it’s the same C# people is enjoying.
>>
>> Properties have become a first-class citizen on most Java classes.
>> What is surprising is that Java does not directly implement it.
>>
>> Regards,
>>
>> Oscar
>>
>>
>>
>> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham
>> GI-DP < Joerg.Rade@Kuehne-Nagel.com> escribió:
>>
>> Hi,
>>
>> from the user (developer) perspective I love Lombok's @Getter @Setter
>> for making source much more compact and saving me brain dead key presses.
>> Thereby increasing readability and maintainability of code.
>>
>> AFAIK Lombok intercepts somewhere before compile time and IntelliJ
>> even offers menu options for switching back and forth.
>>
>> Since Java 9 can now enforce visibility on a different level a lot of
>> tools will have to adopt (Apache Isis included [1]).
>> AFAIK there will even be a switch to turn this enforcement off ;-)
>>
>> If architects are really concerned with these kinds of issues, they
>> must live in an almost ideal world ;-)
>>
>> My 2c
>> -j
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-1277
>> -----Ursprüngliche Nachricht-----
>> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
>> Gesendet: Freitag, 22. September 2017 09:40
>> An: dev@isis.apache.org
>> Betreff: Re: Complaints against Lombok?
>>
>> Hi Dan,
>>
>> I acknowledge that tech is probably not the biggest take-up challenge
>> we face.
>>
>> However I'd prefer an argument like "we don't use Lombok in Isis
>> sources, only examples, so any other boiler-plate-removal-choice is
>> entirely under use-control" :)
>>
>> As I understand it, it's precisely because of the hacky/private API
>> that the Lombok devs *have to* address breakages when a new JDK comes
>> out. And what about other JDKs? Or are we binding users to Oracle?
>>
>> @Everyone: Any other opinions?
>>
>> @Dan: Did you consider other helpers? How did you choose Lombok?
>>
>> To be clear, I really like the convenience that Lombok provides! I am
>> now just curious about a decision.
>>
>> Cheers,
>> Kevin
>>
>>
>> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>>
>> Hi Kevin,
>>
>>
>> I'd be surprised if Lombok really counts against us ... in terms of
>> technology choices more likely is our use of JDO (I've just started
>> on the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
>> Remember also that Lombok is just a compile-time thing. I see from
>> [4] that the Lombok guys are working on getting Lombok work with the
>> Java 9 compiler, but even then remember that there's nothing to stop
>> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
>> if nec.
>>
>>
>> As we talked about at the mini-conf in Jun, though, [5] I don't think
>> our take up really has very much to do with technology at all.
>> Anyway, our community _does_ continue to grow, and if it grows slowly
>> but steadily, well I'm ok with that.
>>
>> Cheers
>> Dan
>>
>>
>>
>> [4] https://github.com/rzwitserloot/lombok/issues/985
>> [5]
>> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>>
>>
>>
>> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>>
>> Hi,
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the young hotshots" are only interested in the latest shiny
>> catch-phrase technology, but if we're actively using something that
>> has been accused of "bad practices" that's not going to help our case
>> either...
>>
>>
>> Opinions? Impact?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>> yo
>> u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>> Kühne + Nagel (AG & Co.) KG
>> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
>> 812773878.
>> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi
>> (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten,
>> Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
>> 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 Zentral- und Osteuropa: Dr. Hansjörg Rodi
>> (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz,
>> Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>>
>> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
>> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen
>> in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden
>> (§ 431
>> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
>> Transporten unter Einschluss einer Seebeförderung und bei unbekanntem
>> Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33
>> SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5
>> Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg,
>> beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>>
>>
>>
>> Óscar Bou Bou
>> Socio - IT & GRC Management Services Director
>> m: +34 620 267 520 <+34%20620%2026%2075%2020>
>> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>>
>> LinkedIn: https://www.linkedin.com/in/oscarbou
>> Twitter: @oscarbou <https://twitter.com/oscarbou>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted
>> ha recibido este correo por error, tenga la amabilidad de eliminarlo
>> de su sistema y avisar al remitente mediante reenvío a su dirección
>> electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales
>> constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L.
>> cuya finalidad es la de mantener el contacto con Ud. Si quiere saber
>> de qué información disponemos de Ud., modificarla, y en su caso,
>> cancelarla, puede hacerlo enviando un escrito al efecto, acompañado
>> de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS
>> ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015
>> - Valencia
>> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C
>> 2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
>> y Paseo de la Castellana, 153, 28045 - MADRID
>> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>.
>> Asimismo, es su responsabilidad comprobar que este mensaje o sus
>> archivos adjuntos no contengan virus informáticos, y en caso que los
>> tuvieran eliminarlos.
>>
>>
>
Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
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 Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
Re: Kotlin archetye (WAS: AW: Complaints against Lombok?)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Jorg,
it's certainly possible to mix Kotlin and Java, pretty much seamlessly,
even on a file-by-file basis. For anyone not in the know, this is
JetBrains language and so it has had deep integration with the IntelliJ IDE
from the off.
I recommend the Talking Kotlin podcast [1] to learn some more about the
language and how it's being used.
Cheers
Dan
[1] http://talkingkotlin.com/
On Fri, 22 Sep 2017 at 12:19 Rade, Joerg / Kuehne + Nagel / Ham GI-DP <
Joerg.Rade@kuehne-nagel.com> wrote:
> Hi,
>
> changing (part of) a development environment is always effort.
>
> For me switching to IntelliJ already pays off and I'll give Kotlin a try
> too.
>
> I assume mixing languages would be possible as well?
>
> Best regards
> Jörg
> -----Ursprüngliche Nachricht-----
> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Gesendet: Freitag, 22. September 2017 11:42
> An: dev@isis.apache.org
> Betreff: Re: Complaints against Lombok?
>
> Hi Kev,
>
> @Dan: Did you consider other helpers? How did you choose Lombok?
>
> (Probably like others), we were looking at how to make the Estatio
> codebase easier to understand/work with, and I remembered seeing some blog
> posts about it and decided to check it out. Since it integrates nicely
> with the IDEs and Maven, it seemed to fit our environment nicely.
>
> To switch topic a little (but not much)... what we all really want is a
> "better Java", in syntax if nothing else. (Those who know me will know
> what I'm about to say next ...) there's a good argument to advocating and
> ultimately switching to use Kotlin. I did manage to port the simpleapp to
> Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking of
> adding a new Kotlin archetype, perhaps initially as part of the Incode
> Platform rather than in Apache Isis proper.
>
> Thoughts?
>
> Cheers
> Dan
>
>
> On Fri, 22 Sep 2017 at 10:30 Chi Cuong Le <ch...@googlemail.com>
> wrote:
>
> > Hi all,
> >
> > from my point of view, choosing Lombok is not bad idea. It reduces a
> > lot of code that developers do not want to write.
> > yes, a specific Lombok version will only work with few JDKs. But it
> > doesn't matter because we do not change our JDK every day. Every time
> > when JDK upgrade, we have to adapt not only Lombok but also other
> > third party libraries also.
> >
> > Viele Grüße/Best regards,
> > Chi Cuong Le
> >
> > On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS
> > <o....@govertis.com>
> > wrote:
> >
> >>
> >>
> >> Hi all,
> >>
> >> I started to love @Getter and @Setter for more thant 1 year ago, and
> >> really happy with that ;)
> >>
> >> Clearer code, with less boilerplate, and more readable Domain Entities.
> >>
> >> Basically it’s the same C# people is enjoying.
> >>
> >> Properties have become a first-class citizen on most Java classes.
> >> What is surprising is that Java does not directly implement it.
> >>
> >> Regards,
> >>
> >> Oscar
> >>
> >>
> >>
> >> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham
> >> GI-DP < Joerg.Rade@Kuehne-Nagel.com> escribió:
> >>
> >> Hi,
> >>
> >> from the user (developer) perspective I love Lombok's @Getter @Setter
> >> for making source much more compact and saving me brain dead key
> presses.
> >> Thereby increasing readability and maintainability of code.
> >>
> >> AFAIK Lombok intercepts somewhere before compile time and IntelliJ
> >> even offers menu options for switching back and forth.
> >>
> >> Since Java 9 can now enforce visibility on a different level a lot of
> >> tools will have to adopt (Apache Isis included [1]).
> >> AFAIK there will even be a switch to turn this enforcement off ;-)
> >>
> >> If architects are really concerned with these kinds of issues, they
> >> must live in an almost ideal world ;-)
> >>
> >> My 2c
> >> -j
> >>
> >> [1] https://issues.apache.org/jira/browse/ISIS-1277
> >> -----Ursprüngliche Nachricht-----
> >> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
> >> Gesendet: Freitag, 22. September 2017 09:40
> >> An: dev@isis.apache.org
> >> Betreff: Re: Complaints against Lombok?
> >>
> >> Hi Dan,
> >>
> >> I acknowledge that tech is probably not the biggest take-up challenge
> >> we face.
> >>
> >> However I'd prefer an argument like "we don't use Lombok in Isis
> >> sources, only examples, so any other boiler-plate-removal-choice is
> >> entirely under use-control" :)
> >>
> >> As I understand it, it's precisely because of the hacky/private API
> >> that the Lombok devs *have to* address breakages when a new JDK comes
> >> out. And what about other JDKs? Or are we binding users to Oracle?
> >>
> >> @Everyone: Any other opinions?
> >>
> >> @Dan: Did you consider other helpers? How did you choose Lombok?
> >>
> >> To be clear, I really like the convenience that Lombok provides! I am
> >> now just curious about a decision.
> >>
> >> Cheers,
> >> Kevin
> >>
> >>
> >> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
> >>
> >> Hi Kevin,
> >>
> >>
> >> I'd be surprised if Lombok really counts against us ... in terms of
> >> technology choices more likely is our use of JDO (I've just started
> >> on the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
> >> Remember also that Lombok is just a compile-time thing. I see from
> >> [4] that the Lombok guys are working on getting Lombok work with the
> >> Java 9 compiler, but even then remember that there's nothing to stop
> >> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
> >> if nec.
> >>
> >>
> >> As we talked about at the mini-conf in Jun, though, [5] I don't think
> >> our take up really has very much to do with technology at all.
> >> Anyway, our community _does_ continue to grow, and if it grows slowly
> >> but steadily, well I'm ok with that.
> >>
> >> Cheers
> >> Dan
> >>
> >>
> >>
> >> [4] https://github.com/rzwitserloot/lombok/issues/985
> >> [5]
> >> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
> >>
> >>
> >>
> >> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
> >>
> >>
> >> Hi,
> >>
> >>
> >> We use and encourage the use of Lombok[1][2].
> >>
> >>
> >> However, inspired by a conversation I had with one of our architects
> >> the other day, I did a little research and found that people complain
> >> that Lombok is hacky and fragile (uses private Java API) [3].
> >>
> >>
> >> Is any of this really an issue? Are any of the concerns "real"?
> >>
> >>
> >> I'm thinking about the poor take-up of Isis. I know the argument that
> >> "the young hotshots" are only interested in the latest shiny
> >> catch-phrase technology, but if we're actively using something that
> >> has been accused of "bad practices" that's not going to help our case
> >> either...
> >>
> >>
> >> Opinions? Impact?
> >>
> >>
> >> Cheers,
> >> Kevin
> >>
> >>
> >> [1] https://isis.apache.org/guides/rgant/rgant.html
> >> [2] https://isis.apache.org/guides/rgcms/rgcms.html
> >> [3]
> >>
> >>
> >> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
> >> yo
> >> u-guys-using-gwt-with-lombok
> >>
> >> --
> >> Kevin Meyer
> >> Ljubljana, Slovenia
> >>
> >>
> >> --
> >> Kevin Meyer
> >> Ljubljana, Slovenia
> >>
> >>
> >>
> >> Kühne + Nagel (AG & Co.) KG
> >> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> >> 812773878.
> >> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi
> >> (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten,
> >> Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
> >> 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 Zentral- und Osteuropa: Dr. Hansjörg Rodi
> >> (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz,
> >> Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde,
> Mustafa Sener.
> >>
> >> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> >> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen
> >> in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden
> >> (§ 431
> >> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
> >> Transporten unter Einschluss einer Seebeförderung und bei unbekanntem
> >> Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33
> >> SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5
> >> Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg,
> >> beschränken. Die ADSp sind auf unserer Webseite als Download
> erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
> >>
> >>
> >>
> >> Óscar Bou Bou
> >> Socio - IT & GRC Management Services Director
> >> m: +34 620 267 520 <+34%20620%2026%2075%2020>
> <+34%20620%2026%2075%2020>
> >> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
> >>
> >> LinkedIn: https://www.linkedin.com/in/oscarbou
> >> Twitter: @oscarbou <https://twitter.com/oscarbou>
> >>
> >>
> >>
> >> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> >> contienen información reservada que no puede ser difundida. Si usted
> >> ha recibido este correo por error, tenga la amabilidad de eliminarlo
> >> de su sistema y avisar al remitente mediante reenvío a su dirección
> >> electrónica; no deberá copiar el mensaje ni divulgar su contenido a
> ninguna persona.
> >>
> >> Su dirección de correo electrónico junto a sus datos personales
> >> constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L.
> >> cuya finalidad es la de mantener el contacto con Ud. Si quiere saber
> >> de qué información disponemos de Ud., modificarla, y e
> <https://maps.google.com/?q=maci%C3%B3n+disponemos+de+Ud.,+modificarla,+y+e&entry=gmail&source=g>n
> su caso,
> >> cancelarla, puede hacerlo enviando un escrito al efecto, acompañado
> >> de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS
> >> ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015
> >> - Valencia
> >> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C
> >> 2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
> >> y Paseo de la Castellana, 153, 28045 - MADRID
> >> <
> https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g
> >.
> >> Asimismo, es su responsabilidad comprobar que este mensaje o sus
> >> archivos adjuntos no contengan virus informáticos, y en caso que los
> >> tuvieran eliminarlos.
> >>
> >>
> >
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ),
> Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde,
> Michael Nebel, Lars Wedel, Matthias Weiner.
> 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 Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.),
> Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik
> Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in
> Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431
> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten
> unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2
> SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25
> Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis,
> mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite
> als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>