I have a jar built with maven, such that the version number included in the name, for example thing-1.0.0.jar.
In IntelliJ 2016, I'm then using a JAR run configuration to run the jar. My run configuration is set up like this:
The problem is that the Path to JAR config points to the exact filename, so every time I bump the version number, and the built jar filename changes, say thing-1.0.0.jar > thing-1.0.1.jar, I have to manually update the run configuration too, to run the newer version.
What I'd like to do instead:
ideally
Put the current version number in using some kind of variable, where the value would be retrieved from the project's pom. This would obviously be a specialised IntelliJ feature, and I'm not sure this exists.
or, good enough
Just match any version number with a regex, since just running whatever the latest built version happens to be solves my problem in practice. I've played around trying to do this in the Path to JAR field, but it just reads my regex as a literal value - if this is indeed a feature, I can't find the right syntax for using it.
So, are either of these solutions possible? Or is there another, better way to achieve this goal with IntelliJ 2016 run configurations? I've googled this in every phrasing I can think of and and have looked at the docs and can't find anything.
Note: I know I could use a maven plugin to handle the running, but I'd prefer to avoid an extra dependency. I want to do this with the integrated IntelliJ tooling, if possible.
Related
I've come back to project after a long diversion, and upgraded tooling. This means Netbeans 12.5, Java 17, Gradle 7.3… at least allegedly. For some reason, despite setting the Gradle version to 7.3, it appears to build with 7.0.
Per the image below, setting the Gradle version to 7.3 doesn't seem to be picked up. (That is immediately after hitting Apply.) It still tries to build with 7.0. And – for some indeterminate reason – it can't.
Restarts don't help; I can't get the configuration to be picked up. (Searches for reference to similar issues provide 5-year-old answers that are no longer relevant.) I've even tried deleting the 7.0 distribution; to no avail, it comes right back.
Can anyone provide guidance on getting this to work properly?
Netbeans 12.6 fully supports Java 17 and Gradle 7.3. Gonfiguring the Gradle wrapper for 7.3 gets picked up correctly, eliminating all errors I was experiencing.
Don't bother with gradle in Netbeans. It's a horrible, buggy disaster and 12.6 just seems to want to up the ante.
Netbeans does NOT support gradle in a meaningful way for normal users.
You now get complex multi-projects whether you want them or not.
When creating a Java Application you don't get a choice at what the Main class is called. It will be App with app.java and you will like it.
If you try to rename app.java to something useful. It will not change "Class App" to "Class Useful" it will instead change it to "ClassUsefulp". It will not rename the test file and you will be left with several syntax errors that you can have fun cleaning up.
No, you cannot rename the subproject itself. That will continue to be the extremely descriptive and useful "app" subproject. The IDE will not provide you a way to rename that.
There is no meaningful, intuitive way to create/delete/modify subprojects.
If your gradle version is somehow out of sync there is still no useful way to reset/recreate the gradle wrapper other than creating a whole new project and moving your source code over to the new project.
Oh, so you gave in and accepted the multi-project structure. You noticed that if you go through the multi-project creator GUI then you can create multiple subprojects. Yeah, good luck with that. They won't have gradle build.scripts or wrappers. You won't be able to build your awesome creation.
Want to use command line arguments? Forget it. There is no "run" element in the project properties. You cannot create different run configurations.
Want dependencies? Or any other project configuration? It's all manual editing of gradle files. There's no GUI to assist non-gradle-wizards.
Yeah. you can probably work around a lot of this by dropping to a command line shell and editing the gradle scripts/files manually and running gradle commands manually. A) you're going to need to be a gradle wizard, and B) why are you using an IDE in the first place? you've got gradle, you've got vi available. Bathe in the nostalgia because you'll have to anyways.
Do you like the idea of gradle? Do you use Netbeans? Stick with Ant, or Maven if you need external dependencies; you'll thank me later.
Currently, every time the source in my ant project is built a java file with a static final variable with the version number is generated. The version number is formatted as yyyyMMdd so that it is always increasing. My problem is that I'm currently checking in the resulting build jar into source control (which I view as a failure, since I don't believe that I should be checking in binaries that are created from the build process).
I was wondering if there was an easy way to generate and write a date based version number to a java file in gradle before compilation, and also if there was a way to somehow only regenerate this version number when I'm building in development and not when someone else is going to rebuild the same version from source. It's a difficult separation of tasks, but I'm hoping someone has had some experience with it before.
You are correct when it comes to not include binaries into source control - of course some type of binaries - I mean, the output of compilation.
Basically modifying sources by build tools is not a good practice, it may cause many problems. Instead, I suggest to add a plain old properties file that will be filtered during build and an entry within it will be substituted with the current date. This file will be included into the binary output of compilation (namely jar file) but can be ignored in source control since it's irrelevant.
What are you asking about can be done in gradle, however it's not a good idea (as I mentioned).
we require the software version number of a maven project both in the java code and in the NSIS installer script. Following the DRY principle, the version number should be stored in the maven pom only. What is the best way to get this version number in the Java code as well as in the NSIS script? Updates on the version number should of course be distributed without the developer having to care about it.
The current approach: Wherever the version number is needed, ${"versionNr"} is inserted as a substitute. Then, during the maven build phase, all java and NSIS source files are filtered and the key is replaced by the version number. To avoid changes in the checked in source code, the filtered files are actually copied to a different location not within the scm. Having the original source and the source filtered by maven causes a lot of confusion, which I would like to avoid.
Any hints?
I typically put the version parameter (like ${project.version}) in a properties-file and only apply filtering on that one file in the maven build. Like
app.version=${project.version}
Then I use this properties file in the code to get the version.
pom.properties gets built into JAR file (to META-INF/maven/<groupId>/<artifactId>/pom.properties) when the project is packaged up. It looks something like:
#Generated by Maven
#Mon Sep 26 09:03:19 EST 2011
version=1.0-SNAPSHOT
groupId=my.project.group.id
artifactId=my-artifactid
You could read this as a resource in your Java code, and use Property API to read the version out.
Not sure whether NSIS scripts can read property files, but according to the source code of the NSIS plugin it creates a few !defines, including PROJECT_VERSION which gets the project version straight from the POM. Maybe you can use this.
I have a Netbeans project with a library defined which includes several JARs. These JARs are versioned like lib\blah\com.blah.wibble.jar_0.6.1.201004161543 . These are nightly builds from another project so that version changes often.
I know I can point NetBeans at the specific JARs with the version name, but this means that every time I get a new version I have to update the NetBeans library.
I can also strip the version name from the JARs, but this makes it hard to track down bugs. "What version of the blah JARs?" is usually the second thing we ask when we find a bug.
Is it possible to tell Netbeans to use included com.blah.wibble.jar_[??????] where ???? is some sort of automatic pointer to use the latest available version?
Consider converting into a maven project and publish new builds into the repository.
Recently logback and other logging frameworks have had added code that adds jar versions to stacktraces based on information in MANIFEST.MF, which is very helpful in reproducing bugs.
For your situation a continous build server might be extremely useful, then you can reproduce exactly those builds reported by users as all information is present in the build server, just by having the build ID from the user.
I'm working in a Java project where the axis 2 library from Apache is being used. The axis 2 library is composed of about 20 jar files and some of these are not used project. What I want to know if there is a method to identify which of those jar files are the unused ones.
I'm using the Eclipse IDE an I thought that one way to solve the problem is to add one jar at time until the I get no error messages about the missing classes. However, I'm not sure if this will work as some of the missing classes errors show up only at runtime.
Does anyone know a better way to solve this problem?
tattletale FTW
http://www.jboss.org/tattletale
JBoss Tattletale is a tool that can help you get an overview of the project you are working on or a product that you depend on.
The tool will provide you with reports that can help you
Identify dependencies between JAR files
Spot if a class is located in multiple JAR files
Spot if the same JAR file is located in multiple locations
With a list of what each JAR file requires and provides
I would follow your original idea of adding one jar at time until it compiles.
You're right that you can still find run-time errors, but unless the application is too big for a good coverage with manual tests, I would simply run and test it to add any missing jars.
I don't think you can reliably remove jars since classes may be resolved at runtime e.g. using
Class.forName(className);
You may be able to determine the class names used for the above, but it's unlikely.
Since classes will be requested/resolved at runtime, you could run your (comprehensive) test suite to determine whether stuff still works. But ultimately I would be very wary of removing jars from a package like Axis. I assume they're there for a purpose. Is the jar file size really a problem ?