I have an opensource project and periodically upload downloads of new versions (the build is with maven). Currently I have a download of jaudiotagger-2.2.4-SNAPSHOT uploaded
https://bitbucket.org/ijabz/jaudiotagger/downloads
and this is a work in progress, Ive made a number of modifications and I want to upload new versions of 2.2.4 so should I just overwrite existing 2.2.4 uploads (this will mean losing download count) or should I timestamp the files so the name dont clash, and if so do I do this by manually modifying the filename or is there a procedure to do this via editing the pom.
You can continue uploading as 2.2.4-SNAPSHOT
When your snapshot artifact is uploaded to the artifact repository, it is timestamped, and all the artifacts that are being uploaded to the same version are not lost. E.g. If you have uploaded 10 snapshot artifacts to 2.2.4, then there will be exactly 10 artifacts in the repository. But when 2.2.4 is being requested, only the latest artifact being uploaded will be returned to the requestor.
Maven versioning follows major.minor.bug, therefore it is advisable to only change a version in response to the change.
For example, if the latest artifact that you have released is 2.2.3-GA, and there is a bug discovered in 2.2.3-GA, then you would start to work on the bug fix as version 2.2.4-SNAPSHOT, and continue uploading to the same version until you are ready to ship it (release it), and then only it becomes 2.2.4-GA.
By the same theory, even though you are not making your artifacts available through an artifact repository such as Sonatype or Artifactory, but via a download page (bitbucket), it makes little reason for you to version your Snapshot artifacts unless it is really meaningful to do so.
Related
My company's admin team have introduced a new restriction on Nexus repository where they do not allow update on same artifact version again. My project has 7 sub-modules (say m1..m7) where all have different versions. They all are independent and kept in the same project to manage them better. Now after this restriction activated, if any of the module's version pre-exist in Nexus, the whole build fails with
"Return code is: 400, ReasonPhrase: Repository does not allow updating assets"
I am OK with that artifact not uploading to Nexus but I want other modules to still carry on uploading. If I made a change to one module (say m4), I want m4 to upload with the new version that I specified but other modules can try the upload and fail. Or maybe skip the upload automatically by checking if the module's version already exists.
I have searched a lot but couldn't find any way to achieve this apart from driving all modules with the same version. Here, I use maven properties to enforce the same version on all submodules, and now even if I make changes in one module, all modules are uploaded to Nexus.
Is there any cleaner way to achieve this like ignoring specific errors from Nexus or check for the existing version and skip upload?
The clean thing is to increase the version (automatically) directly after a release, so if you have build a version 1.0.0, the version in the POM should be changed to 1.0.1-SNAPSHOT.
This way you avoid most problems arising from accidentally releasing things twice.
The Byteman website advertises version 4.0.11 as released: https://byteman.jboss.org/downloads.html
But only some artifact IDs are available on Maven Central: https://search.maven.org/search?q=g:org.jboss.byteman
Did something go wrong during the release? Did artifact IDs change?
Thanks for reporting this. There was no problem reported during the maven build or upload to the Sonatype repo and my release of the artefacts was indicated as successful. However, Sonatype has been rather flaky recently. It seems to have lost many of the artefacts at release (before transfer to Maven Central).
I have hand uploaded all the missing artefacts for 4.0.11 to Sonatype and checked that they are all currently resident in their repo. I also checked and the 3.0.18 artefacts (originally released at the same time) also seem to be present on their site. These all ought to get pushed over to Maven Central soon. If that doesn't happen within a day or two (worst case) then that probably means the Sonatype copying operation is wedged again. Let me know if so and I will raise the transfer problem with them. Let's keep our finger crossed they don't lose the uploads.
We are evaluating bintray and have the following build file
https://github.com/deanhiller/webpieces/blob/evaluateBintray/build.gradle
(not sure the build file matters since it reports that it is uploading each and every artifact correctly). I see stuff like this...
> Task :webserver-plugins:plugin-backend:bintrayUpload
Uploaded to 'https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19-sources.jar'.
Uploading to https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19-javadoc.jar...
Uploaded to 'https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19-javadoc.jar'.
Uploading to https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19.jar...
Uploaded to 'https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19.jar'.
Uploading to https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19.pom...
Uploaded to 'https://api.bintray.com/content/deanhiller/maven/plugin-backend/2.0.19/org/webpieces/plugin-backend/2.0.19/plugin-backend-2.0.19.pom'.
The really weird part though is it would create directories
https://dl.bintray.com/deanhiller/maven/org/webpieces/plugin-backend/2.0.19
but nothing is there until I deploy everything then the files show up. It seems kind of odd that the directories are created but there are no files in the upload phase. Then, my final question is, are these artifacts only available there, or are they published to jcenter or maven central as well. I can't really tell.
We are trying bintray to maybe switch off of sonatype because every time we upload, we get exceptions on sonatype(for last 4 days we have not been able to release). In bintray so far, every single upload has been successful(176 artifacts in one go).
Possibly I need more stuff to get this stuff out to jcenter or maven central?
thanks,
Dean
I do see these files at the moment.
If the artifacts are not published then only authorized users can view and download the content, this means that unauthorized users, such as anonymous, will not see content in your download repository.
Your package is not linked to jcenter therefore they are not automatically published on jcenter.
I would suggest to include your packages to jcenter.
I'm currently setting up revapi-maven-plugin for a project, using latest version (0.7.0), and we want to check on our jenkins that no regression appears in our API during development.
Then for my process I don't want to check the regression between a snapshot and a release but between two snapshots.
Unfortunately (?) we use a different repository for our snapshots and our releases, and apparently revapi-maven-plugin seems not able to get the latest snapshot version from the snapshot repo.
Or is it and I did not understand how to do that?
I already put those value in my configuration but it does not change anything:
<alwaysCheckForReleaseVersion>false</alwaysCheckForReleaseVersion>
<oldVersion>LATEST</oldVersion>
This is supported since the version 0.8.0 of the revapi-maven-plugin.
The documentation of the oldVersion property reads (https://revapi.org/modules/revapi-maven-plugin/check-mojo.html#oldVersion):
If you don't want to compare a different artifact than the one being built, specifying just the old version is simpler way of specifying the old artifact. The default value is "RELEASE" meaning that the old version is the last released version of the artifact being built (either remote or found locally (to account for artifacts installed into the local repo that are not available in some public remote repository)). The version of the compared artifact will be strictly older than the version of the new artifact. If you specify "LATEST", the old version will be resolved to the newest version available remotely, including snapshots (if found in one of the repositories active in the build). The version of the compared artifact will be either older or equal to the version of the new artifact in this case to account for comparing a locally built snapshot against the latest published snapshot.
I have a private repository hosted on bitbucket. Every time I release the latest version of the artefact to Nexus, I have to update the Read me which seems very repetitive.
Is there any way/plugin which can publish the latest version of the artefact directly to my repository's overview page (ReadME.md)?
I am using Maven 3+ for building the artefact using Jenkins which publishes all artefacts to Sonatype Nexus.
You can likely use something akin to this to add the file, likely the attach additional resources example: http://www.mojohaus.org/build-helper-maven-plugin/usage.html