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

Reply via email to