feat: scope deps#2133
Conversation
| } | ||
|
|
||
| // lazy computed; dont store hashset unless truly needed | ||
| public boolean includeInScope(String scope) { |
There was a problem hiding this comment.
I don't like the word scope - mainly because these aren't actually maven scopes but rather something that gets translated into a scope.
includeInConfig(String config) maybe ? (gradle use configuration as name for different scenarios)
There was a problem hiding this comment.
and it would be defaultConfigs if follow same route.
| } | ||
|
|
||
| @Override | ||
| public boolean equals(Object o) { |
There was a problem hiding this comment.
so first push resulted in funky TestModules errors that was caused by equals method missing on Attributes - which is fair..but reveals a conondrum - how do we define equals for these? i've implemented a few tests (which currently fails) showing situations that we probably want to make equals...which we can by unifing attributes...but should we?
There was a problem hiding this comment.
just did an update where i split it out in a DependencyRequest even though I do thing the other properties makes sense to have on the "thing" that encodes the dependency - but it seems like we have places where we treat MavenCoordinate as absolutes which can be used as keys....that is NOT the case even with these new info because MavenCoordinates can have version ranges defined.
| "}\n"; | ||
|
|
||
| String srcWithVersionRangeDep = "//MODULE testmodule\n" + | ||
| "//DEPS info.picocli:picocli:4.6+\n" + |
There was a problem hiding this comment.
added this test as realized the module support seem to rely on exact string matches rather than understanding of resolved dependencies - is that a known/expected limitation @quintesse ?
There was a problem hiding this comment.
looks like Module generation should only compare on the group + artifict + type ..ignore version range or any properties?
There was a problem hiding this comment.
I'm not sure what you're referring to @maxandersen . What exact string matches? What understanding of resolved dependencies? There's not really a relationship between modules and maven dependencies implemented (at least as far as I remember).
maxandersen
force-pushed
the
scopeddeps
branch
from
1da326f to
bdd4936
Compare
2 participants
this PR will grow to have scope deps.
for now this is just implementing precursor for #2126 as a mechanism to store scopes and possible other attributes on dependency.
Basically can parse a string into a map of key->List to capture any kind of options that we add to a MavenCoordinate as a DependencyAttributes.
With this in place doing additional filtering when resolving becomes somewhat trivial.
We can utilize this notion of attributes on potential anything
Currently implemented syntax is inspired by asciidoc: https://docs.asciidoctor.org/asciidoc/latest/attributes/positional-and-named-attributes/
I initially started with https://github.com/yupiik/tools-maven-plugin/blob/d1e8b97ebcae032684a0fafac426bcc25819089f/asciidoc-java/src/main/java/io/yupiik/asciidoc/parser/Parser.java#L1634 but it was too simple so with a bit a LLM help got something that supports things like:
g:a:vorg:a:v{}-> scope will be build, rung:a:v{build}-> scope will be buildg:a:v{build, boot} -> scope will be build , bootg:a:v{build, scope=boot} -> scope will be build , boot`g:a:v{build, scope=boot,%transitive} -> scope will be build , boot and there will be a "transitive=[true]
...I even allow quotes...
`g:a:v{build, scope=boot,comment="This is probably over kill",%transitive} -> scope will be build , boot and there will be a "transitive=[true] and "comment"=["This is probably over kill"]
...will allow for things like:
g:a:v{build,exclude=org.jreleaser:*}which is pretty nice too imo :)oh...and I converted to assertJ in the tests where I need to...hamcrest need to retire.
...will update this main description as things evolve and this eventually will Fix #2126