VasilievAleksey

var isArray = Array.isArray || function (arr) {
  return Object.prototype.toString.call(arr) === "[object Array]";
}

var isObject = function (obj) {
  return Object.prototype.toString.call(obj) === "[object Object]";
}

function three (tr) {
  var paths = [];

  function findPath(branch, str) {
    Object.keys(branch).forEach(function (key) {
      if (isArray(branch[key]) || isObject(branch[key]))
        findPath(branch[key], str ? str + "." + key : key);
      else
        paths.push(str ? str + "." + key : key);
    });    
  }

  findPath(tr, "");
  return paths;
}

Вернет от вашего объекта такое:

[
  "MainService.0.Id", 
  "MainService.0.Name", 
  "MainService.0.MainService.0.Id", 
  "MainService.0.MainService.0.Name", 
  "MainService.0.MainService.0.Service.0.Id", 
  "MainService.0.MainService.0.Service.0.Name"
]

Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 не доступен или не доступна библиотека из его зависимостей.

Смотрите что не так с этим плагином, меняли ли версию, доступна ли она в репе и тд

JPA - это интерфейс языка JAVA, не имеющий реализации в самом языке. Если просто добавить аннотации JPA в свои классы, то не произойдет ровным счетом ничего. Для того, чтобы аннотации начали "работать", следует развернуть и настроить в проекте фреймворк, который "найдет" все классы с JPA-аннотациями и "состыкует" их с сущностями СУБД. Этим фреймворком у вас является Hibernate.

По поводу "работать с hibernate можно и через JPA или отдельно от него" - тут в основном дело вкуса. У вас есть два варианта сообщить Hibernate какие классы "замапить" на таблицы БД:
1. Добавить в классы аннотации JPA
2. Создать XML-файлы, в которых будет описано сопоставление классов объектам БД.

По доступной функциональности оба метода равны между собой, при этом аннотации JPA более современны. Я бы рекомендовал JPA, т.к. при открытии класса сразу будет видно, что он "замаплен", а в случае использования XML, "замапленный" класс визуально неотличим от других классов.

Заказчика лучше удерживать другими способами, например, качеством работы.
По мне так большинство и так достаточно ленивы, чтобы менять исполнителей. Это же каждый раз риск, трата времени.
Кроме того, малоизвестные технологии скорее всего и развиваются медленно, имеют риск умереть. Представляете, как будете оправдываться перед заказчиком, почему не можете сделать ту или иную фишку, которая есть уже у всех его конкурентов. Что Вы ему скажете?

Не все так просто.

Я только начинаю разрабатывать мобильные приложения и для себя выработал несколько приемов, которые подсмотрел в статьях на хабре, ТЕДе и других источниках.

1. Лени не существует. Есть лишь недостаточная заинтересованность. Поэтому, что-то не припомню, чтобы кто-то ленился шпилить в Доту или "таньчики" много часов подряд.

Вот я утром сел за ноут, открыл вкладку на developer.android.com, читаю, параллельно открыт Эклипс с копипастой, потихоньку разбираюсь. И знаете, какое-то ощущение, по-английски anxiety, не знаю, как наиболее точно это будет по-русски. Поэтому легче открыть соцсети, 9gag или вообще читать в ЖЖ всякую никак не относящуюся конкретно ко мне мусорную информацию.

Мною было прочитано множество статей о прокрастинации, мотивации, но в самое яблочко попала вот эта статья - blogs.hbr.org/2014/02/how-to-make-yourself-work-wh... С ходу не мог найти перевод на хабре. Вкратце, если анализировать, как проводят рабочее время успешные люди, то получается, что они реализуют задачи несмотря на "неудобное время", "ой сейчас неохота", а страх облажаться заменяется на страх - "что будет, если я не приступлю к текущей задаче сию же секунду".

А также вот это выступление на Теде. www.ted.com/talks/dan_pink_on_motivation Должны быть русские субтитры. Насчет того, что приемы мотивации 19 века до сих пор широко применяются, несмотря на то, что они утратили свою эффективность. Предлагается новые способы.

2. Нужна стопроцентная железобетонная уверенность в себе и собственных действиях.

3. Смена физической активности. Действительно, поясница, спина, шея начинают ныть после двухчасового кодинга или браузинга. Поэтому важно делать хотя бы трехминутные перерывы, разумеется, программистам нужно несколько часов "полного погружения" в проект, желательно, чтобы их никто не отвлекал, потому что придется потом заново во все вникать и строить в голове архитектуру приложения. Я лично, когда я хочу прочитать книгу по джаве или просто художку, не сижу или лежу, а хожу по комнате, даже сбросил жирок за зиму :-) Интересно было бы измерить активность с помощью шагомера. Разумеется, это надо чтобы никто не раздражался, если вы сидите в офисе или в кабинете с коллегой.

4. Хорошо почитать про "состояние потока", мне лично помогло. Много статей на хабре. Ученый, исследователь этого явления рассказывает - www.ted.com/talks/mihaly_csikszentmihalyi_on_flow

5. Есть много всяких мелких фишек, но они сами органически вырабатываются, когда вы пытаетесь поднять свою продуктивность, главное их записывать где-нибудь и накапливать.

Был рад поделиться личным подходом.