Well, if using a home brew solution, I may rely on the hidden gem of:
MyClass.class.getPackage().getImplementationVersion()
If you provide a nice MANIFEST.MF with your jar that should work.
The original problem would still persist, in that case you need to
configure your build system.
If that would happen to be Gradle then:
tasks.named("jar") {
manifest {
attributes("Implementation-Title": project.name,
"Implementation-Version": "1.0",
"Main-Class": application.mainClass,
)
}
}
tasks.named("run") {
classpath = files(tasks.jar)
}
On 9/19/23 10:26, Thomas Wolf wrote:
Hi Laszlo,
My J2SE application is installed by a jpackage-created installer on
mac/linux/windows and can be either a client or a server. The application,
upon startup, checks if there’s a new version of the app jar available on a
server instance and, if so, downloads it so the next time the application
starts up, the new jar is used. If one assumes the jar has no external
dependencies that might break as a result of moving to a newer version, I don’t
think this method leads to added brittleness in the application. But maybe I’m
missing something? I’d love to hear your perspective.
In answer to your question, the high level problem I’m trying to solve with
this is the avoidance of our user having to re-install our application - or
even having to update it manually. I looked into using jdeploy, but we (i.e.
our company) don’t want our code accessible in a public repository like npmjs
or GitHub. So I’m kind of forced to ‘roll my own’. Using the build date of
the jar is just my first, crude step in doing this because it is easiest to
implement.
If you have any suggestions on how I can get NB to use the jar when running the
application rather than the classes/ directory, I’d love to hear it. It would
make my debugging easier.
Thanks,
Tom
On Sep 19, 2023, at 12:05 PM, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote:
You probably do not want to do such a thing. Is there a more high level of use
case why you would get the date of a jar?
Usually depending on file dates would make you application very brittle, which
would work on development, but when put into production, could lead hours of
debugging, whit somebody screaming at the end.
On 9/19/23 07:38, Thomas Wolf wrote:
Hi,
My application has a bit of code that tries to do something based on the build
date of the jar file. To get the jar file, it does something like this:
File jarFile = new
File(Startup.class.getProtectionDomain().getCodeSource().getLocation().toURI());
This works fine when the application is run outside of NB, but when debugging
inside NB, the File that gets pointed to is the
$HOME/NetBeansProjects/myproject//build/classes/ directory. Is there a way to
config the NB project to use the jar file that it generates - i.e.
$HOME/NetBeansProjects/myproject/dist/app.jar ?
Any info is much appreciated,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists