b
можно сюда https://mymavenrepo.com/
Size: a a a
2020 December 15
VP
Vadzim Iaaaay
если я добавляю в spring boot gradle app dependency на модуль (не gradle), получаю такую ошибку: Could not determine the dependencies of task ':compileJava'.
> Could not resolve all task dependencies for configuration ':compileClasspath'.
> Could not resolve project :utils.
Required by:
project :
> No matching configuration of project :utils was found. The consumer was configured to find an API of a library compatible with Java 11, preferably in the form of class files, and its dependencies declared externally but:
- None of the consumable configurations have attributes.
> Could not resolve all task dependencies for configuration ':compileClasspath'.
> Could not resolve project :utils.
Required by:
project :
> No matching configuration of project :utils was found. The consumer was configured to find an API of a library compatible with Java 11, preferably in the form of class files, and its dependencies declared externally but:
- None of the consumable configurations have attributes.
> dependency на модуль (не gradle)
Это как?
Это как?
VI
> dependency на модуль (не gradle)
Это как?
Это как?
есть spring boot app, ему нужно брать методы и классы из utils.
Utils можно собрать в jar. Но utils не собран ни мавеном, ни градлом.
Utils можно собрать в jar. Но utils не собран ни мавеном, ни градлом.
VP
Vadzim Iaaaay
есть spring boot app, ему нужно брать методы и классы из utils.
Utils можно собрать в jar. Но utils не собран ни мавеном, ни градлом.
Utils можно собрать в jar. Но utils не собран ни мавеном, ни градлом.
То есть это каталог с исходниками, которые можно какой-то командой собрать в jar, так?
D𝔇
Vadzim Iaaaay
спасибо, но если не особо хочется шарить код с этим репозиторием?
В свой локальный мавен задеплоить
VI
То есть это каталог с исходниками, которые можно какой-то командой собрать в jar, так?
да
D𝔇
Ну или собрать в жар, положить куда-то в свой проект и прописать зависимость(дальше гугл)
EF
кто сходу может сказать/объяснить почему в java при реализации continuation пошли по пути манипуляции со стеком, тогда как в kotlin реализовали state machine. в чем преимущества того или иного подхода?
VI
Ну или собрать в жар, положить куда-то в свой проект и прописать зависимость(дальше гугл)
спасибо. Буду пробовать.
EF
кто сходу может сказать/объяснить почему в java при реализации continuation пошли по пути манипуляции со стеком, тогда как в kotlin реализовали state machine. в чем преимущества того или иного подхода?
при этом никто не сомневается в том что реализации continuation в loom'e определено лучше. какие основания так полагать?
VP
Vadzim Iaaaay
да
Ну либо собрать заранее и положить рядом или в репозиторий, либо объяснить грейдлу, что jar надо собирать вызовом команды. Но это будет не зависимость на модуль (его же нет), а именно зависимость на jar.
Ещё вариант (самый нормальный) всё-таки собирать эти исходники тоже грейдлом.
Ещё вариант (самый нормальный) всё-таки собирать эти исходники тоже грейдлом.
VI
Ну либо собрать заранее и положить рядом или в репозиторий, либо объяснить грейдлу, что jar надо собирать вызовом команды. Но это будет не зависимость на модуль (его же нет), а именно зависимость на jar.
Ещё вариант (самый нормальный) всё-таки собирать эти исходники тоже грейдлом.
Ещё вариант (самый нормальный) всё-таки собирать эти исходники тоже грейдлом.
спасибо!
IP
Переслано от Iaroslav Postovalov
это из @jvmchat. я, кстати, не знаю, что там накостылили в луме. моя гипотеза - лум может в изменения вм, а kotlin.coroutines могут генерироваться только в 50.0 байткод
D
при этом никто не сомневается в том что реализации continuation в loom'e определено лучше. какие основания так полагать?
ну в котлине континуации проставляет компилятор, а ты в коде размечаешь все suspend
EF
как ты думаешь, это лучше, чем писать привычный код, который умеет приостанавливаться и возобновляться за счет обновления VM?
вопрос выглядит риторическим, но мне все равно неочевидно почему манипуляции со стеком лучше чем простая кодогенерация, это даже звучит сложнее и дороже
EF
Переслано от Iaroslav Postovalov
это из @jvmchat. я, кстати, не знаю, что там накостылили в луме. моя гипотеза - лум может в изменения вм, а kotlin.coroutines могут генерироваться только в 50.0 байткод
это один из аргументов
IP
как ты думаешь, это лучше, чем писать привычный код, который умеет приостанавливаться и возобновляться за счет обновления VM?
она по перфомансу будет хуже