Conversation
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
See https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/index.html and https://maven.apache.org/plugin-developers/cookbook/plexus-plugin-upgrade.html. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Many, many dependencies were added somewhere along the line, but are not actually needed. Let's get rid of them, and actually depend on maven-core proper. We have to add JUnit directly now because it was only a transitive dependency. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's not get stuck with obsolete API; we will need some rather powerful things out of the Maven 3 API for the upcoming 'bump' mojo. To stay compatible with the maven-plugin-annotations dependency, we only bump to 3.0, not 3.0.4 (the maven-enforcer-plugin would point out an incompatibility there). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This will come in real handy for the upcoming "bump" mojo to bump versions in POMs. The job of mojo was previously performed by SciJava scripts' bump-version-in-pom.sh script. The most important part is that we modify the file contents as little as possible, to avoid hiding the real changes between unsubstantial formatting changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... so it can warn properly... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The procedure established in the SciJava project (which serves as a guinea pig of robust, collaborative development of scientific software) is to define dependencies' versions as properties and then use those properties in the dependencyMangement section for maximal convenience of consumers of those POMs. As a consequence, the SciJava project needs tooling to adjust the properties defining dependency versions every once in a while, and the upcoming 'bump' mojo of the scijava-maven-plugin is intended to fulfill that purpose. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It's really good to reduce repeated code because copied code tends to diverge (read: accumulate separate sets of bugs) which is not good. Hence: Don't Repeat Yourself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Its purpose is to help SciJava projects maintain parent POMs, i.e. POMs listing projects' current versions. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Unfortunately, the enforcer plugin – which is now active thanks to the new parent version – identifies a couple of upstream problems we need to ignore because we cannot fix them here. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
|
Thanks for your efforts on this front! Definitely will be really handy. After an Any ideas? |
Contributor
Author
|
Hmm. I have |
Member
|
Looks like a variation of the AetherClassNotFound problem. The fix is apparently to upgrade to the latest versions of certain affected plugins. Trying now... |
Member
|
Upon further testing, I fear there may be issues with my machine's Maven installation, or even problems with newer versions of Maven in general. E.g.: Which has nothing to do with I'll test the |
Member
|
All is well with Maven 3.0.4 on Linux! Still problems with Maven 3.2.3 installed via Homebrew on OS X. But having this goal is better than not having it. And most importantly, Jenkins will be able to use it now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The idea of the 'bump' mojo is that calling
in the top-level directory of parent POMs (such as
pom-scijavaorpom-imagej) will adjust all of the dependency versions defined in the<properties>section to the current release versions.This job is currently performed by the
bump-versions-in-pom.shscript. The fact that this is a shell script starts to limit what we can do with it, though: it requires indentation with tabs to work, it has no idea about the XML layout of thepom.xmlfiles, and therefore cannot use, say, XPath queries, and the shell script has no idea about Maven, of course, relying on a very stringent deployment process that is tightly bound to the ImageJ Maven repository that has been configured specifically to support the shell script.Hence the drive to support the bump action as part of a proper Maven plugin.