Comments (12)
Hi!
Some kind of configuration option to give the behavior that you want seems reasonable.
I don't think defeats the purpose that much. You would still know which dependencies you have and the versions for all the other dependencies would still be there.
It is probably best to implement it in the same way as useMyVersionFor so that you can have different behavior on different artifacts. Probably not a very common use case that you would want to have different behavior but adding a global option first and then add support for different behavior later would make it messy.
I am not really sure how to repeat it locally and add a test case for it.
Do you know of any publicly available project that publishes SNAPSHOT releases?
I will have a look at adding https://www.mojohaus.org/mrm/mrm-maven-plugin/ which is used by https://github.com/apache/maven-dependency-plugin to be able to write a test.
from dependency-lock-maven-plugin.
Sorry for answering so late, I've been on another task this past month. When you say "Probably not a very common use case" I'm wondering if I explained correctly, since to me this is a very common use case (but I may be wrong of course ;-). Let's say I'm developing an application with several Maven JAR projects, e.g. my-application-commons
and my-application-api
, and my-application-api
has a dependency on my-application-commons
. During the development lifecycle, I'd like to change both:
- update
my-application-commons
mvn clean install my-application-commons
- update
my-application-api
mvn clean install my-application-api
This is working locally because install
creates a -SNAPSHOT
dependency (my-application-commons-0.1.0-SNAPSHOT.jar
) and not a timestamped one like my-application-commons-0.1.0-20220112.144849-6.jar
.
On my CI, I'd like to do this:
- push
my-application-commons
- build and deploy
my-application-commons
which creates a timestamped artifact - push
my-application-api
- build
my-application-api
which is locked on a previous timestamped artifact and so is failing
There is no more uniqueVersion
option in the deploy plugin.
from dependency-lock-maven-plugin.
Sorry for being unclear. What I meant was that having timestamped versions for some artifacts and snapshot version for some in the same project is uncommon. Having timestamp versions for all snapshot artifacts is, as you say, pretty common.
Maybe it would make sense to implement something like <ignore><dependency>com.myproject:application-*</dependency></ignore>
. That might be useful for some other things as well.
<timestampedSnapshots><dependency>com.myproject:application-*</dependency></timestampedSnapshots>
would probably be better for this use case though. Probably relatively simple to implement, but I am not really sure how to test it and I haven't had time to dig deeper into that yet.
from dependency-lock-maven-plugin.
The "same application" dependencies are all declared in the POM as -SNAPSHOT
but that's the deployment to the central repository that adds the timestamp. It's no longer possible to disable this behavior, as stated by Major Version Upgrade to version 3.0.0. So the dependencies are then resolved and downloaded as the timestamped ones.
I also think that ignoreDependencies
should be useful in some cases, but timestampedSnapshots
is more suited for my use case. Thank you for your time.
from dependency-lock-maven-plugin.
allowTimestampedSnapshots is perhaps a better name right? Since sometimes it might actually be 0-SNAPSHOT if you have built the artifacts locally.
from dependency-lock-maven-plugin.
Sorry for late reply.
I am looking into implementing this in a 1.x version.
I will remove the possibility of editing the dependency-lock.json file to add "use-mine". I don't like breaking backwards compatibility, but it is a bad feature and it makes it harder to implement new good features.
from dependency-lock-maven-plugin.
Hi, have you been able to make some progress on this one?
from dependency-lock-maven-plugin.
It was a bit more tricky to implement than I thought initially.
The lock file could contain both 0-SNAPHOT or similar or 0-20220112.144849-6 and it should be able to allow either from either of these. Another problem is related to a feature which I am working on which lets you lock and verify the integrity of the dependencies. The snapshots will probably differ in that regard as well.
I pushed code now that lets you ignore some dependencies completely which would also ignore the checksum of the files.
You should be able to use that for now.
I am working on a 1.0 release but I want some more tests before I release that.
I have released a version 0.0.78f56707b3a1d639c8e769bba1686587e9a89564 that you could try and I am confident that it will be compatible with the 1.0 release, but I am not making any promise about that.
from dependency-lock-maven-plugin.
I have been thinking a bit more now and it would probably be better to do something like:
<dependencySet>
<ignoreVersion>true</ignoreVersion>
<ignoreIntegrity>true</ignoreIntegrity>
<includes>
<include>com.mycompany.something</include>
...
</includes>
</dependencySet>
That way you could configure it to only ignore the version and possibly the integrity if applicable.
It would also be possible to add something like <allowTimestampedSnapshots>
or similar which would be even more specific than ignoring the version completely.
from dependency-lock-maven-plugin.
I wasn't aware that the plugin was checking integrity too ;-) I'm using it only to notice dependencies change. So your last proposal fits me quite well too.
from dependency-lock-maven-plugin.
It isn't checking integrity yet, but it is a feature that I am working on that it will be possible to enable :)
Perhaps even enabled by default in 1.0 release.
from dependency-lock-maven-plugin.
Fixed in master branch.
from dependency-lock-maven-plugin.
Related Issues (9)
- Make it possible to indicate versions that should be the same as project from the POM. HOT 2
- GitHub Releases still indicate that version 0.13 is the latest release HOT 2
- Add dependency checksums HOT 5
- Readme improvements on Dependabot needed HOT 2
- Support patterns for ignore, and my version, lists HOT 8
- Release version 1.0 HOT 3
- dependency-lock-maven-plugin is part of dependencies, security concern
- Exclusion of a dependency from version and integrity check is not working HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dependency-lock-maven-plugin.