Use relative paths in classpath to shorten execution line on large apps

[bekoenig]

Hej samskivert,

our app has more than 250 libs (please don't ask why) and will be placed at %APPDATA%/myapp with code-cache enabled. So the final execution line has a very long argument for classpath, which results in an error at launch on windows (see string limitations for cmd). I noticed that the working dir will be set to the app-dir in getdown, so in my opinion absolute paths are unnecessary on classpath.

With the change to relative paths, our fat-app is starting! Check my changes and I'm looking forward to hearing from you.

Greetings from Germany (Münster), Ben

[bekoenig]

Hej @samskivert, it's a little bit sad, that this project will maybe die due open issues and unmerged improvements. I like the simplicity of the codebase and the customizability. With my experience in this project, which I take from work, I think I would like to mantain it in feature. Would you add me as contributor, so I can continue development? Or should I better start a new fork with your wiki-content too? Greetz Ben

[samskivert]

Thanks Ben,

Sorry merging took a long time. I have many other responsibilities these days and don't use Java or Getdown for any of them. I would be happy to add you as a contributor, but to publish new Getdown releases you would need your own credentials for publishing to Maven Central, which I wouldn't really want to do under the old Getdown Maven coordinates (since they are from my old company Three Rings, which is long defunct).

So if you really do want to take over maintenance, it might be better if you fork the project and then start to do Maven releases from coordinates that make sense for the forked repo (your personal domain or your company's). I think that would help people to understand how things had changed.

I would be happy to then update the README on the main Github page here to point to your fork. And you're certainly welcome to use everything from the current repo as a starting point.

Thanks! Michael

[bekoenig]

Hi Michael,

thank you very much for your work!

My project in my company is completed and getdown is an important part of a big solution to ship clients with over 400 MB on thousands of clientsystems with over 50 releases per year. We have hundreds of devs and testers which use a different environment to start test-clients over a dashboard. This is done by a mix of patching, extra-file and explicit app-args. I used near every feature of getdown and implemented some tooling around it, to solve special usecases, which are not target of getdown. So I can hook in the lifecycle of getdown and hack some functions. This is done by wrapping getdown-core and -launcher in a spring-boot CLI, which is shipped by traditional update mechanism. Our server side uses getdown-core for dynamic generating of metafiles and patches. The isolation between our apps and getdown is clear and important to maintenance the software.

The new solution will be supported for almost 10 years. So continue getdown is important for us. After this project I have a lot of knowledge to do it on my own. Specially I get some slack time, so I can do it as my private opensource contribution on work time. The next big steps are to implement support for java-21, logging with slf4j and replace some custom implementations with apache-libs.

Next days I want to order a new domain and start the fork with the first release for the last merged pull-requests.

But before I start, I have some questions:

1. Can I copy your wiki too?
2. Should I continue with the current 2-Clause BSD License?
3. Do you want a pull-request for the readme with details to my new fork?

Best wishes, Ben

[samskivert]

Hi Ben,

That's great news that you'll have the time to shepherd Getdown. I haven't had the time to manage it properly for many years, so it's been on minimal life support. Unfortunately even doing Maven releases with other people's pull requests has become a process of whack-a-mole as JVM updates and Maven plugin updates and Maven Central changes all conspire to make new things break every time I try to do a release. I haven't done any development in Java for over ten years, so I have not kept up with the various changes in the tooling and ecosystem.

You are welcome to copy anything that is useful, including the wiki, and you're welcome to choose any license that works well for your circumstances. We used the BSD license because it's very flexible, but that flexibility includes you choosing to continue development under whatever license you like. :)

I am also happy to redirect from this project to your new project, so feel free to send a pull request for that, thanks!

Thanks again for your work on Getdown, it's great to see the project still delivering value after so many years. I'll do what I can to support your efforts with what time I have, so feel free to shoot me questions if anything comes up that you think my (increasingly aging) knowledge might help with.

Cheers, Michael

[bekoenig]

Hi Michael,

I'm glad you are happy!

As first starting point I posted a discussion to draw attention to my work.

I think it takes some time to push the codebase to java-8 and the new ecosystem, in particular when I don't want to break thinks :+1:. This is only possible when I extract the right codeblocks and add tests. At the moment my work has no pressure, but the vulnerability of old dependencies and the wish to update to newer java versions will be more important in this year.

I'll get in touch when the final release is pushed!

Thank you for your work, Ben