Да я не скажу что я прям не осиливаю Градл, но шишку сегодня набил здоровенную. В мавене даже вначале такого не было, но там и версии зависимостей все всегда прописывают. Вроде можно их размазано ставить, но я ни разу такого не встречал и у самого мысли не возникало так написать.
Что насчет зависимостей. плагинов. По чесноку, я этим в мавене ни разу не пользовался т.к. небыло необходимости. Но, столкнувшись с проблемой я поискал и нашел maven.apache.org/plugins/maven-dependency-plugin/resolve-plugins-mojo.html
Для Градла же я искал и не нашел. Так же предполагал что простой gradle dependecies поможет, но запуская его в корневой проекта мне не вывело вообще ни одной зависимости, запуская в модуле выдало только обычные зависимости (не плагины).
Еще мне очень нравится связка Idea с мавен. Шустро работает, подсказки где надо. Ну, надеюсь, со временем и с Градлом все устаканится.
Ну я бы не сказал что половину не использую. 1/4. Но планирую.
1. Да теперь это понятно. Просто наверняка не я один такой. Вот и хочется либо таких же как я предупредить либо чтоб это как-то побезопасней было реализовано.
2. Спасибо. Я так понял что это команда обнавления всех зависимостей проекта. В данном случае она бы проблему не решила т.к. баг был как раз в последней версии зависимости.
Ну в общем да. Наука — не ставить плюсы. Но я доверился :)
1 и 2 пробовал. На это и потратил столько времени. Я еще пробовал менять 11ю и 12ю версию Градла, Пробовал стирать весь кэш зависимостей.
Вот тут этот баг описывается: code.google.com/p/android/issues/detail?id=72374 Видать он возникает в каких-то специфических случаях.
О «gradlew --stop» не знал, но я убивал в таск менеджере все java процессы и пару раз рестартил комп.
Ошибка была. Но я не сразу понял что дело действительно в Gradle т.к. собиралось все нормально. Не проходил именно запуск приложения на девайс.
UnsupportedMethodException
Unsupported method: AndroidArtifact.getOutputFile().
Я понимал что значит '4.+'. Дело в том, что увидев что такой конфиг выложен в публичный доступ, я и подумать не мог что с этим может быть что-то плохое. Раз человек выкладывал, а другие качали — он знал что делал.
Но как я в кратце описал проблема была не только в этом.
Да конфиг приводить особого смысла не имеет. Из 150ти строк конфига надо было поменять classpath 'com.jakewharton.sdkmanager:gradle-plugin:+' на classpath 'com.jakewharton.sdkmanager:gradle-plugin:0.10.1'
Я думаю что умные дядьки сделали бы так что батарейка тратилась только на перерисовку экрана, на сопутствующую софтварную часть и на телефон в режиме ожидания звонка. Но не надо тратить заряд на основной дисплей. Если я на телефон не смотрю — он живет полтора-два дня. Если же у него включен экран — пол дня максимум.
Насчет разеров — удобно тем, кто часто ездит и читает в общ. транспорте. То есть выходя из дома можно взять только кошелек и телефон, а иначе надо будет еще ридер, да еще сумку для него.
Речь не идет об обычных слушателях. Речь о сотрудниках компании — профессиональных аудиофилах, различающих на слух кодеры (не говоря уж о битрейтах). И вот эти вот сотрудники, ведомые своей филией, хотят отстоять битрейт 320 перекодированный из 256.
Спасибо за работу, давно пользуюсь вашей IDE. Подарил маме лицезию. Будет теперь чем заняться старушке на пенсии.
Ваши последние фичи лично мне нужны не очень, зато сильно не хватает программирования через киннект. Или хотя бы жестами.
Но в общем я вижу плюс, если есть большое желание отделить бизнес логику от контроллеров. На мой взгляд это может пригодиться только если требуется несколько разных внешних интерфейсов, если не хочется каждый из них описывать. У меня такой задачи пока не встречалось.
Я уже мало помню о jax rs, поэтому буду говорить о спринге
1. Контроллеры находятся в spring контексте. Поэтому вызвать можно из любого места где он доступен.
2. Передать объект можно. Причем как json, так и автоматом замапить на какую нибудь сущность.
3. Вроде же можно вернуть статус ошибки вместе с сообщением, в которое можно всунуть код ошибки. Я на счет этого 100% не уверен, но могу поискать инфу.
Что насчет зависимостей. плагинов. По чесноку, я этим в мавене ни разу не пользовался т.к. небыло необходимости. Но, столкнувшись с проблемой я поискал и нашел maven.apache.org/plugins/maven-dependency-plugin/resolve-plugins-mojo.html
Для Градла же я искал и не нашел. Так же предполагал что простой gradle dependecies поможет, но запуская его в корневой проекта мне не вывело вообще ни одной зависимости, запуская в модуле выдало только обычные зависимости (не плагины).
Еще мне очень нравится связка Idea с мавен. Шустро работает, подсказки где надо. Ну, надеюсь, со временем и с Градлом все устаканится.
1. Да теперь это понятно. Просто наверняка не я один такой. Вот и хочется либо таких же как я предупредить либо чтоб это как-то побезопасней было реализовано.
2. Спасибо. Я так понял что это команда обнавления всех зависимостей проекта. В данном случае она бы проблему не решила т.к. баг был как раз в последней версии зависимости.
Ну в общем да. Наука — не ставить плюсы. Но я доверился :)
Вот тут этот баг описывается: code.google.com/p/android/issues/detail?id=72374 Видать он возникает в каких-то специфических случаях.
О «gradlew --stop» не знал, но я убивал в таск менеджере все java процессы и пару раз рестартил комп.
UnsupportedMethodException
Unsupported method: AndroidArtifact.getOutputFile().
Но как я в кратце описал проблема была не только в этом.
Насчет разеров — удобно тем, кто часто ездит и читает в общ. транспорте. То есть выходя из дома можно взять только кошелек и телефон, а иначе надо будет еще ридер, да еще сумку для него.
Ваши последние фичи лично мне нужны не очень, зато сильно не хватает программирования через киннект. Или хотя бы жестами.
1. Контроллеры находятся в spring контексте. Поэтому вызвать можно из любого места где он доступен.
2. Передать объект можно. Причем как json, так и автоматом замапить на какую нибудь сущность.
3. Вроде же можно вернуть статус ошибки вместе с сообщением, в которое можно всунуть код ошибки. Я на счет этого 100% не уверен, но могу поискать инфу.