Help with maintainance
Closed this issue · 46 comments
Micromata can’t maintain the project actively. But we would love to find someone who is willing to take that over even if this person is only reviewing and merging PRs.
Please ping @micromata/developers in case your are interested.
Thanks in advance 😘
Hi @mischah
it would be nice to have someone to be in charge. I'm not sure if I can be that person, I don't want to take a responsibility I won't be able to fulfill. I'd be happy to help and fix a few bugs as a simple committer.
So, if you want to give me (and anybody who's sent pull requests) committer rights, I'm up for it.
Is anyone out there with a vision of where this project should be?
Should we aim just to fix the remaining bugs and produce a final release?
I can't see the KML standard moving too fast, which is a good thing.
Google Earth is in a state of abandonment unless Google decides to donate it to something like the Apache Foundation (it worked well AFAIK for projects such as SkyMap, MyTracks etc).
So once a new release is ready, would anybody from Micromata be able to push it to the Maven repository?
Pinging @maniksurtani, @SriramMLN, @SriramMLN
Hi @ZiglioNZ,
thanks for your feedback.
This would be one possible approach:
So, if you want to give me (and anybody who's sent pull requests) committer rights, I'm up for it.
So once a new release is ready, would anybody from Micromata be able to push it to the Maven repository?
But the initial idea I discussed with some workmates back February was to »transfer« the whole thing from micromata/javaapiforkml to yourname/javaapiforkml.
The other option needs to be discussed by @micromata/developers and @hthole. Someone will report back into this issue.
Could we get a gradle repository for it also?
Damien
@micromata/jak-dev @mcahornsirup fyi ⬆️
@mischah There are a lot of things to keep in mind... maybe we need to update the foundation itself and start using the official OGC-Dependencies (https://github.com/highsource/ogc-schemas/tree/master/kml) ... As a result, YAK would only be a small wrapper with a nicer syntax due to the builder pattern ...
HI, I'm an experienced java team lead, I can manage this project here: https://github.com/ackdev/javaapiforkml
Hej @ackDev,
thanks for your offer 👌
There is no need to fork the repo. We could either add you as contributor to this repo or transfer the Repo with al its stars, open issues and PRs to your account.
It’s up to @micromata/jak-dev to decide how to proceed.
Hi,
we planed to support this project in the future. But any help is welcome. So, as mischah mentioned you are welcome as a contributor. I'll do a review of the open issues to get an idea about the todos.
Greetings,
Daniel
Hej @ackDev,
just some additional thoughts about the current state of the project and its foundation.
The Java API for KML relies on XML-Schemas used to generate Java-Code... there are official Specifications, XML-Schemas and there are "official" Java-Libs available, too.
OGC-Standards: http://www.opengeospatial.org/standards
Java-Libs: https://github.com/highsource/ogc-schemas.
Maybe it is more suitable to use these, already generated, Java-Libs as a foundation and wrap them with syntactic sugar (builder pattern etc.) => Java API for KML
Happy Coding!
Hi, I think this is a great project and it breaks my heart to see it abandoned. Is it possible just to get its dependencies updated as it is throwing illegal reflective access exceptions with the latest releases of java.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1 (file:/C:/Users/arlin.DESKTOP-AN92BDB/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2/jaxb-impl-2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Check out the KmlDocument class in https://github.com/MKergall/osmbonuspack for a better solution. See my answer at https://stackoverflow.com/questions/15636303/ for more details.
I have a port at https://github.com/urbancamo/javaapiforkml which has been updated to compile and run with Java 11 - Java 17. Regards, Mark.
It is available on mavencentral:
<dependency>
<groupId>uk.m0nom</groupId>
<artifactId>JavaAPIforKml</artifactId>
<version>3.0.1</version>
</dependency>
Hej @urbancamo ,
I’ve just added you as maintainer (outside our GitHub Organization).
Thanks for helping out and keeping this alive 
❤️
Cheers, Michael
cc/ @mcahornsirup @laubfall @micromata/jak-dev
@urbancamo @mischah what exactly is the state of this right now?
A disclaimer was added that the library is back under maintenance, a few small PR's were merged with almost only non-functional changes to documentation or metadata. Either way, there was no new release so whatever changes cannot be used anyway.
And now we're back to 6 months of nothingness, not even an acknowledgement on new issues / new PR's which were specifically created because there was room for maintenance again.
Either this is in maintenance, and some effort needs to be put in, or this goes back to unmaintained, which is totally fine if there is no available time to spend on this. In the end we're all doing this for free.
The point is that this needs clarity, because currently we're in limbo.
You’re right. Let’s give @urbancamo a few days to react over here.
I’ll update the readme, if he ran out of time (or interest) to take (at least a little) care of this.
If somebody else is interested to help keeping this alive: Just say: Hey 👋🏻
Good to hear ❤️
I've implemented this with Github actions for my own repositories, I'm not
sure if there is something similar configured?
Nope. There is CD automation in here for now.
As I said in #29:
I try to get you in contact with someone from our company who can help to get this released …
Hej @urbancamo,
@tuxBurner will help you to get that released. He hopes to find some time in the next couple of days or next week and will contact you.
@urbancamo @tuxBurner @mischah Are there any updates on getting a release done?
Unfortunately I don't have a way to release new versions at the moment. I am hoping that this part of the process will be handed over to me.
I have to admit that I don't have a plan about getting stuff released in the Java Eco system.
A colleague said that it is not necessary to publish that via Maven Central.
I will check again in our company chat who can help out here.
A colleague said that it is not necessary to publish that via Maven Central.
Could you elaborate on what your colleague ment by that and how we're supposed to consume this then?
Could you elaborate on what your colleague ment by that and how we're supposed to consume this then?
I guess a kinda misunderstood what he meant 🙈
Anyway, I’m taking care of this by myself.
According to https://central.sonatype.org/publish/manage-permissions/ permissions to publish to Maven Central are handled by Jira Tickets.
@urbancamo Therefore I need your Username of this Jira instance: https://issues.sonatype.org/
You can create a user if you don't have one yet.
Good morning @mischah Michael.
My username is the same on that site, @urbancamo
I do releases of my own software, so should be able to work this out once I have permissions.
Regards, Mark
I've had several emails about maintenance, and as we've had issues getting maintenance going for the main repo I've decided to move to my fork at https://github.com/urbancamo/javaapiforkml and bring that up to date with all the PRs and bug fix requests. As it stands now the latest version 3.0.2 supports Java 11 although it does need several pull requests to be applied moving forward. You will need to change the name of the package in your pom file, but there should be no compatibility issues, obviously raise any issues on the fork itself. Thanks to the folk at Micromata for open sourcing this library.
Hej @urbancamo, Thanks for your efforts 🙏🏻
Guess that’s the best way to handle it without further frustrations 😔
Another option to avoid confusion would be to transfer this repo micromata/javaapiforkml to urbancmo/javaapiforkml.
This way your repo wouldn’t not only contain the Git history, but also the history of issues and PRs. Plus your repo would be the single source oof truth.
Let me know what you are thinking about this.
Hi @mischah, thanks for the reply. If we can still get access for me to publish from this repo then I'm happy to proceed on that basis, otherwise I'm not sure what the process is for getting the entire repo moved, but I have been able to publish from my fork so at least we have a way forward. Cheers, Mark.
Hej @urbancamo,
otherwise I'm not sure what the process is for getting the entire repo moved
the process ist pretty much straight forward.
Thanks for your patience. As it's not my project, I'm not that committed to taking care of moving things forward. I'm really sorry about that and totally understand the way you handle it. But I’m also happy that you are willig to take care about it 💖
I’m willing to try to get you publish Access. Moving this up on my TODO List. Maybe we should revisited this in 1 Month and decide about the transfer.
Thanks again ❤️ 💯
Cheers, Michael
Hi Michael
Transfer ownership is the way to go I think Michael, if you want to give that a go? Then I don't have to bother you if there are any issues further down the line.
Regards, Mark.
Let’s do it 🥳
Guess you have to (temporarly) rename you existing repo (the fork) to avoid naming conflicts.
Ping me if you’ve done this.
Hope @urbancamo will take care of it and your efforts will be pulled in 👀
BTW... Please consider #35. I did most of the work for you to modernize the build months ago. Thanks, Dan McLaughlin
Hi Dan - noted as I've looked through all the potential PRs, and plan to merge everything sensible in when the repo has stabilized, thanks.
Mark.
Weird 🤪
I’m going to try to transfer it via my userpace to your 🧐
Okay. Guess you have to delete your fork (on github.com)
Ping if this it done. I can transfer the repo afterwards.
👍🏻
It’s on its way 
It’s done:
https://github.com/urbancamo/javaapiforkml
Congrats 🎉
Thanks for taking care of it 🥇
All sorted now! Closing issue