-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dependency notation does not support maven version range syntax containing )
and ,
#166
Comments
Could you point me to some reference docs about dynamic versions? What is the format? Is it "just" about supporting dashes and pluses in the version field of the artifact locator? |
gradle docs are not very helpful: https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:declaring_dependency_with_dynamic_version something else that might be interesting might be dependency locking: https://docs.gradle.org/current/userguide/dependency_locking.html |
Why don't you use jitpack to get temporary artifacts? |
i did that but it kept reusing the same -SNAPSHOT version that maven cached and update that only somewhat randomly jitpack is a nice concept that did not end up working for me sadly |
Indeed for continuous rebuilding it is sometimes a bit sluggish. Coming back to the dynamic dependencies. What is the format? Is it "just" about supporting dashes and pluses in the version field of the artifact locator? In order to support it we would need at least some (unit-)test as the dependency lookup is likely to be replace with a different backend (kotlin-scripting-api, aether from existing PR). |
could this be used ? http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html or apparently maven itself supports a different notation of version ranges
|
Would maven support such versions? Since it is the current resolver backend, it would be hard to implement it if not. Or we would need to change until we change to something like kotlin-main-api or aether (see PR). |
well i have no experience using POMs directly, but i am currently trying to add |
apparently ranges like |
for some reason EDIT: apparently thats the value passed to the regex already, something in the annotation and //DEPS parsing does splitting on |
so spliting versions with PS: the annotation parsing splits on |
disallow `,` in DEPS_COMMENT improve parsing of DEPS_ANNOT assume there is no more `)` after the annotation fixes kscripting#166
Thanks for the PR. I guess we can not simply change the delimiter from , to ; because of backwar compatibility reasons. But do we have to? Can these dynamic versions actually end with a comma? Your examples seem to indicate the opposite? |
well i think not, they need to end in a |
https://github.com/holgerbrandl/kscript/blob/d6104195c86bbeec4bf9ca51022e53efb2f82790/src/main/kotlin/kscript/app/Script.kt#L148-L152
would it be acceptavble to remove that failure case ? |
)
)
)
and ,
which are the lagacy usecases i should test for ? |
You changed the existing tests in your PR which are by design legacy use-cases. They must not be touched, otherwise it may break the tool for other use-cases. |
okay well i will try to design around them..
is not really easy to parse, i could also just ignore it and just fix it for PS: i undid the changes to tests and to the |
so i hjust discovered that idea bootstrapping is also broken forversion ranges, kind of obvious really i wonder if one could just replace + with i hope kotlin's scripting will use ivy version matching though, then the hack can be removed is there any reason why someone would want to have a literal |
improve parsing of DEPS_ANNOTATION assume there is no more `)` after the annotation fixes kscripting#166
+1 It's hard to parse. +1 consistency at this level would be nice, although I'd prefer annotations as well. So if not even idea is supporting them in their gradle/maven sync, does kscript really need/want it? |
i think idea would support it.. i mean kscript does nto let me create the project because it runs through codepaths that are broken because i have a new attempt of just supporting |
@NikkyAI Is is possible that dynamic versions can just be resolved when running kscript (including the patch from above), if at least one version is sitting in the local E.g when using some non-yet- |
... which might be an argument in favor of PR #49 instead of maven? |
Since the PR has been long merged, I'm also closing the corresponding ticket. |
EDIT: Maven supports version ranges natively: examples: http://www.mojohaus.org/versions-maven-plugin/examples/resolve-ranges.html
an it works in kscript once the annotation and comment parsing is not messing up on
,
and)
old issue content:
i am writing a library and tool that i try to make compatilble / consumable by kscript
the versions are pushed to maven by jenkins , each git commit increments the build number
ideally i would like to use
instead of
The text was updated successfully, but these errors were encountered: