javaapiforkml
javaapiforkml copied to clipboard
micromata
Help with maintainance
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 :kissing_heart:
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.
@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
Hi Michael,
I'm okay with transferring the repo and have renamed my existing one.
Doesn't seem right to publish to maven under your domain, so I was planning to publish under my domain. I expect it'll be a minor dependency change for users of the library. I don't think transferring the repo will impact your current distributables in the maven repositories, so no existing usages will break.
As there a lot of links to your github project, once the transfer is complete, can you setup a stub project to point to the new url? If not, it's not that big a deal.
Let me know if you have any concerns or suggestions with this approach.
Side note - not sure if intentional or not, however the following receives a 404, do you plan to maintain that or would you like to transfer that to me as well?
<groupId>de.micromata.jak</groupId>
<artifactId>XJCPluginJavaApiforKml</artifactId>
Thanks, Charles
On Mon, Jun 19, 2017 at 5:33 AM, Michael Kühnel [email protected] wrote:
Hej @ackdev https://github.com/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 https://github.com/orgs/micromata/teams/jak-dev to decide how to proceed.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/micromata/javaapiforkml/issues/18#issuecomment-309388579, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVZijBYCVeo6JhSfKOJWzncq7AVYNEFks5sFkCFgaJpZM4He8eB .
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!
Thanks for the pointer, applying same builder constructs you used on 2.2 is a great way to go for 2.3 using ogc's implementation.
On Mon, Jun 19, 2017 at 6:56 AM, Steffen Schuler [email protected] wrote:
Hej @ackdev https://github.com/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 XML-Schemas and there are "official" Java-Libs available, too. 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
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/micromata/javaapiforkml/issues/18#issuecomment-309406724, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVZihbZvKGS2MFB65D8aVY2eYi7aLKzks5sFlPZgaJpZM4He8eB .
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 :octocat:❤️
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 👋🏻
Hi
I'm still here. I am unsure about the release process to get binaries deployed to the maven repo. If someone can point me in the right direction that would be great. I've implemented this with Github actions for my own repositories, I'm not sure if there is something similar configured?
Regards, Mark.
On Thu, 2 Mar 2023 at 12:43, Michael Kühnel @.***> wrote:
You’re right. Let’s give @urbancamo https://github.com/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 👋🏻
— Reply to this email directly, view it on GitHub https://github.com/micromata/javaapiforkml/issues/18#issuecomment-1451810681, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4BSMEDF3ZD7PNWXVVT5TW2CIYVANCNFSM4B33Y6AQ . You are receiving this because you were mentioned.Message ID: @.***>
-- M0NOM/P https://www.qrz.com/db/M0NOM/P ADIF Processor https://bit.ly/adifproc
Good to hear :octocat: ❤️
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.