microsoft
Is it possible to ignore the version of a dependency and use it directly if present in VSCode ?
Suggestion
Hello I do not know if it's already possible in VSCode so I ask here. Imagine I have 2 Maven projects in the IDE: aaa in v1 bbb in v1
if aaa references bbb v1 in its pom, it's ok: a code update in bbb will be 'seen' when executing aaa. Now, I would like code updates in bbb to be also 'seen' by aaa even if aaa reference bbb V1 while bbb being V2 in VSCode.
Is is possible ?
Use Cases
My use case is related to having multiple git repositories each having projects in different versions. I would like to avoid having to change the poms (in fact, the grand scheme is related to CIFriendly behavior but I prefer to focus on the simple subject mentioned abvove)
Examples
Is is possible ?
No. There would be ambiguity. How does the extension know whether you want to update bbb's version in project aaa or not?
I would like to avoid having to change the poms
dependencyManagement is designed for it, where you can manage dependency versions in a single place.
Hello Eskibear, thanks for the reply
No. There would be ambiguity. How does the extension know whether you want to update bbb's version in project aaa or not?
the extension would not know. It would be a on/off setting. If 'on', the rationale would be "if I have added a folder to the workspace, it's because I WANT to use the code in this folder, whatever the version. So just ignore the version mismatch if the option is 'on' and use this code.
dependencyManagement is designed to allow to avoid changing the code
Not really, changing dependencyManagement IS changing the pom. In my view, the real version, including the gitbranch as a suffix, is deterrmined by the CI and dynamically passed. The flaten plugin then will deploy poms containing this real version to the shared repository. I'd like the devs working on 2 different git repos to be able to work simultaneously on both codebase, to be able to debug directly from within the IDE even if the versions are not the same because he knows in the end the versions will be the same when set by the CI.
In my naive (!) opinion, it would not be really difficult to ignore the version when resolving. It would save so much time by making Maven both CIFriendly AND debuggable n the IDE.
to ignore the version when resolving. It would save so much time by making Maven both CIFriendly AND debuggable n the IDE.
I don't think it's a common use case given my knowledge of Maven. In my opinion, for CI pipelines you can have scripts to set corresponding "real version", and so for your dev environment.
For your use case, AFAIK in Maven's spec you cannot define a relativePath for a dependency node, but maybe you can make its scope as "provided" and provide the systemPath pointing to bbb's artifact path, which is relatively stable.
The fact is I do not want to change the pom files. Nor any other file. I would risk to commit them by mistake.
It clearly not a common use-case for little self-sufficient Maven Project, but as soon as you start work accross multiple git repositories each contaning multi-modules Maven projects you feel the pain.
Technically, would it be difficult to implement ?
Complexity of implementation is not the first thing to consider. The most important thing is, whether it's common/recommended practice of developing Maven projects, whether it's a valid feature request for a Maven extension on VS Code that benefits a large group of developers. In another word, do you know if there's any other IDE covering your use case? If so, that can put more weight on implementing such feature here.
I totally understand your point. To my knowledge, no other IDE offers this feature (I have opened a feature request at Eclipse's m2e). But this is a so much valid use case that people working on Maven 4 are putting a lot of effort in being CI-friendly (single location for definition of version, convention for parent pom location allowing to bypass version declaration, etc...). This is not a feature that Maven can implement, because Maven's scope is a single project's tree (multi-module or not). So Maven itself does not have this problem. This is a problem that can be seen (and solved!) only in the IDEs because in the IDE you can import multiple project trees. And usually, if you import multiple projects, you expect them to be synch or at least have a way for them to be synched.