I'm currently working on a Spigot plugin and have never bothered updating the version number as my plugins have always been private. However I've been wondering if there was a way that does this for me automagically.
I know it's possible using Ant but the answers I've seen so far require an external file in which the actual version is stored, and still requires manual actions.
For those not familiar with Bukkit/Spigot, a plugin.yml looks like this:
name: PluginName
author: Author
version: 1.0
main: path.to.main.Class
So I'm looking for a solution which gets the current version from the file and increments the minor version by 1 and if possible the major by 1 if minor is > 9.
Update the plugin.yml for many reasons (i have many private plugins)
Get into the habit of version-ing your work. What is there to differ your old "changes" to your new ones? Not only that but, that version number can be used through the plugin manager.
Lets say you need to get that version (or some other plugin does) in the future. The ONLY way (besides an MD5 check) to get the version of your plugin, which 9 times out of 10 is to differentiate it from another version of that same plugin.
If your adding it to a server, how do you know which version you are running? For example version 1.1 contains a new command, but version 1.0 does not. You cannot check that if the version was never changed.
You dont HAVE to change it. There is no reason to be required to, but its good to practice development with version numbers like almost all other developers.
However, to answer the automated incremental version, no. You cant modify that compiled jar (unless you get down and dirty with another plugin BEFORE your plugin is loaded). Possibly, you could make some sort of plugin to your IDE to automatically increment it? But do you see where this ends up? Just change it when you feel that you have made progress towards some feature.
Related
I have builds like: 1.0.0-9, 1.0.0-10, 1.0.0-11, 1.0.0-12, etc.
I've configured my dependency like:
[1.0.0,)
Which means that it should use the latest version from the existing ones (ofc which starts with 1.0.0), but instead of using the 1.0.0-12 it used the 1.0.0-9. I think that it's because the 9 is grater then the 1.
Firstly I would like to force the maven to use truly my latest builds.
I can also have 1.0.0-LOCAL build (which is a local build on the developer's PC). I would like to force the maven to use the 1.0.0-LOCAL instead any other builds if it's available.
I don't know exactly how I could do these, maybe somehow with the settings.xml configuration file which is located on the build machine and on the developer's PC as well.
If I would have a any other way to do this please let me know.
Have a good day,
Arnold Robert Turdean
Update:
It turned out that the Maven Version Range - downloads all the available versions not just the latest one was the original problem.
Which maven version do you use? From Maven point of view all of those given versions are releases? The question is if it wouldn't be better to use a SNAPSHOT version instead?
Furthermore to check if the ordering of your artifacts is correct or work like you expect this can be checked by using this:
java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 1.0.0-12 1.0.0-9
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0-12 == 1-12
1.0.0-12 > 1.0.0-9
2. 1.0.0-9 == 1-9
which shows correctly that 1.0.0-12 is greater than 1.0.0-9. So the question is also if you are using a repository manager etc. ? Do you do only a mvn install ?
What I don't understand is your statement about `1.0.0-LOCAL' ?
Apart from that I would suggest to prevent using of version ranges cause they make you build non reproducible.
In maven, dependency hierarchy is so important. Make sure that you don't have other dependencies which added before, into other pom's.
(In hierarchy, maven cares latest dependency.). Dependency 1.0.0-LOCAL must be the latest one.
I suggest to you, while the local developing time use generic -SNAPSHOT, use numbers when you start packaging .
I'm working on a project that has a version checker to see if it's up to date. The way I do it is by including the version in the source code of the main class and in my Github repository, I have a file that just includes the latest version.
Whenever I push to the repository, I have to increment both the version file and field in the source. Unfortunately, I'm incredibly forgetful and always forget to increment at least one of them.
A little information, I'm working in Eclipse on a Java applet. I'm not entirely sure what you'd call it but the version file is adjacent to the src/ directory (I guess the project root). I should also note that I'm a total noob with git and have absolutely no idea what I'm doing so examples would be appreciated.
Is there anyway I can easily manage the version that will guarantee that both change?
With Git you could write a commit hook which increases that number. I would set a beginning and an end marker and have the number between them. A pre-commit-hook would increment and replace that number.
More info at the git book.
I work on a big legacy project and I've noticed that in the project root pom we explicitly forced certain maven plugin versions.
I've read about the 'maven way' and it seems to me that this is a violation of this way - forcing versions instead of inheriting them from the superpom. Here's an example of what we have in the project pom:
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>...</configuration>
</plugin>
My question is - what are the valid reasons (if any) to force plugin versions like that. I wonder because often times I find code that was written without any clear purpose and I do wonder if this is such a case, and if I should just drop the version from the project root pom.
Afterthought: On this site they say:
When declaring a "normal" version such as 3.8.2 for Junit, internally
this is represented as "allow anything, but prefer 3.8.2." This means
that when a conflict is detected, Maven is allowed to use the conflict
algorithms to choose the best version. If you specify [3.8.2], it
means that only 3.8.2 will be used and nothing else.
So this means, if you force the version to ensure stability, then you should also use [] otherwise maven is free to ignore your forced version.
The best is to define plugins versions only in a corporate pom and of course mainain this corporate pom over the time which means update the plugins versions from time to time.
This means in consequence that in no other project it is needed or better should be prevented to use a different versions of plugins (except there are very good reasons for this bugs in plugins).
Furthermore the excerpt you have given is an example of bad practice cause plugins and/or their configuration should be defined by using pluginManagement instead.
So if a project needs an older version of a maven plugin there should be at least a comment in the pom which describes why it's using not the inherited version. May be with a link to an appropriate JIRA issue...
what are the valid reasons (if any) to force plugin versions like that.
A valid reason is to keep a build repeatable, especially if there are known problems with a later version of the plugin. This ensures that the specific version is used, rather than a later version from an organisational parent pom (or, worse, from the default with no version specified anywhere).
I wonder because often times I find code that was written without any clear purpose and I do wonder if this is such a case
It's very possible, in a large code base, that this is exactly the case. The plugin configuration could have been copied from somewhere else and the version included without a good reason.
and if I should just drop the version from the project root pom.
If there is no reason given, either in a comment or a commit message, and if the same plugin has a version specified in the parent pom and if the build still works perfectly without it, then you should drop that version.
If it doesn't work, you should either fix the build or add a comment explaining exactly why this version is necessary.
As has already been stated, this can be because of corporate reasons - using new versions of plugins can break tests, functionality or even a whole product itself; new versions have to be tested thoroughly, advanced teams even need to discuss them because it can change the product in many ways.
Not forcing versions will create some kind of unstable situation during the next big build - which is always unwanted, developers dont like randomness :).
If your POM only describes a small, private project or maybe even a small community project you may very well let maven do all the version-management but thats pretty much a no-go for professional products which are worth .... say hundreds of thousands or even millions of currency units.
I was just curious to know this, when i give mvn install without doing 'clean', maven compiles only the modified java files. How does maven identify a java file is modified or not? I believe it is not using the last modified property of the file.
Reason for my belief: I had a module, after merging a change from svn, i gave mvn install and it didn't compile the modified file and when i looked at the change i saw that 'long' were modified to 'Long' in getters and setters.
So i just want to know how maven identifies if a java file has changed or not?
(P.S I'm using Apache Maven 3.0.3, if that matters)
I believe the Maven compiler plugin uses last modified dates on the source and class files to determine whether recompilation is necessary.
The compiler website is rather short on information, but the compiler:compile goal page has information on the following attribute, which finely tunes the staleness calculations: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#staleMillis. That's about the only official statement regarding staleness.
Without knowing much about maven, I can tell you that generally speaking, "make"-like tools use the "last changed" timestamp, which would explain the issue you had with svn ( see Wikipedia on Subversion's weaknesses.
Robert Scholte's comment at https://issues.apache.org/jira/browse/MCOMPILER-205 explains the process. It depends on the "useIncrementalCompilation" option of the "maven-compiler-plugin" (and on the version of it btw, I've only managed to have "useIncrementalCompilation" work with 3.1, not 3.0):
I see there's some confusion, so something needs to be changed, maybe
improving documentation is good enough. Looking at the code, you'll
see that non-incremental will only look at changed sourcefiles.
Incremental will also verifies if dependencies have changed and if
files have been added or removed. If it has changed, it'll remove the
complete classes-directory. The reason is that the default java
compiler is quite fast, likely much faster than analyzing per file
what to do with it. IIUC the eclipse compiler is a real incremental
compiler, so we could decide that based that based on the used
compiler not to drop the classes directory.
I want to rebuild JDK1.6 after some changes in currency.java in the java.util package. so how can I do it? is there any compiler or builder to make a custom version of JDK?
I try $ javac src/java/util/currency.java but it did not work.
You should not build the whole JDK. Only thing you need is compile your class, put it into a .jar and place it in endorsed folder of a JRE.
I found these build instructions for OpenJDK 6 in the source code repository:
OpenJDK 6 Build README
UPDATE - revisiting this after a couple of years, I came across the following useful blog entry that has links to "Build README" files for a number of Java versions:
https://blogs.oracle.com/kto/entry/jdk_build_readme_collection
Lets hope it stays there, and stays current!
But yea ... if you have just changed one class, then the "endorsed directory" approach is a better idea; see #kan's answer.
Finally, it is generally a bad idea / undesirable to modify the standard class libraries to make your application work:
Your code is immediately non-portable. It will only work on your private flavor of Java.
Each time you upgrade your Java version you have to resync the sources and rebuild. (The "endorsed" approach is simpler, but you still have work to do on each Java update.)
There might be legal issues with redistribution of your modified Java. Talk to an IP lawyer ...