Open PabloThiele opened 3 years ago
seems like a fork is the answer
Here we are a year later.
This is a great project that needs occasional updates that community members are happy to take over if @trautonen does not have the time.
@trautonen can you please grant commit privileges to this repo or redirect us to a fork?
@dbwiddis yea, sorry for being a bit slow on this. @PabloThiele is now a contributor in this project and will be doing the updates. I will help him out with the release process.
@trautonen / @PabloThiele
it's now march of 2023 and it doesn't look like there has been any action here. can i throw my hat into the ring? i've already got a couple of open source projects of my own, so i can jump right in on some of this stuff. i'd love to official support going for github actions right off the bat.
@jgangemi I would say that the problematic situation is the lack of maven integration and the real data to continue the same project information. If we can just re-do this entirely would be simpler since I had no complete handover in the end. :D Tons of PRs opened are just waiting for merges but need the maven config to generate and push it nicely.
PS: I changed countries and jobs in between and had no real chance to work deeply on this at free time.
Hi, chiming in... Sadly I haven't had time to look into this, but maybe I could try spending couple of days setting up github actions for automatic releases and such. (Hopefully I can still find my PGP keys for maven central somewhere). I haven't also worked with Java for couple of years now which is why this has been left pretty much as is.
After three years this is clearly moving too slow. In that time, https://github.com/dogeared/coveralls-maven-plugin added clover support and https://github.com/jwtk/coveralls-maven-plugin turned around and released that. Now I'm not familiar with clover but at least in all my usage because other library / plugins were updated, I migrated over and use it extensively for coveralls with maven projects (many large projects too such as mybatis).
Currently there is a perceived problem because the 2016 release and the fork from 2021 both rely on jakarta bind api for javax namespace. I see the master here removed that dependency by changing libraries but its still extremely out of date on most everything.
So given I'm trying to jakarta a few projects I don't care to keep seeing the bind api override against javax namespace. So I took time to review the forks. I've forked this main repo and then applied the other work to it. At the moment, the clover support is probably broken and test is skipped as code otherwise changed since. The rest was rather simple.
Given @trautonen has noted lack of time for this, I think understands travis ci must be dropped, GHA is probably somewhat new, etc.
Here is the deal though on other items which I've addressed or I'm noting.
Things IMO to still do
Given all that, I've released a milestone at 4.5.0-M2 (4.5.0-M1 also released but had issue releasing site to gh-pages). You can find my code here https://github.com/hazendaz/coveralls-maven-plugin and the site here https://hazendaz.github.io/coveralls-maven-plugin/. As well I opened draft PR #150
I have not done a more formal test yet but will in coming days.
Confirmed my hard fork works as expected.
Amazing contribution @hazendaz since I really have no other way to generate the original Maven new versions of this project. What do you think to enter in contact with coveralls and offer your project instead? So it would end up https://docs.coveralls.io/java It's sad that even merging here, I still not capable of produce nice packages at maven repo properly.
I can offer some time at your fork as well, but the big thing is really the publishing part.
Hi @PabloThiele Thanks for support and kind words. Do you know how to get this updated at coveralls? I've already been rolling this out in usage now. Its working out great :)
Sorry for being inactive. I don't sadly have time and interest to maintain this anymore so I appreciate your work @hazendaz. I added a deprecation note to the readme and a link to your fork.
You are free to change the Maven name for the new project to publish it in Maven Central. I still own the eluder.org domain and use it for other purposes too so can't provide too much help with the current name.
I think I got this project listed in Coveralls by some random tweet. Never actually asked them to list it in the docs. 😄
@trautonen Thanks! I had gotten it released already under 'com.github.hazendaz.maven' so all good there. Guess I failed to note the GAV, Here it is!
<plugin>
<groupId>com.github.hazendaz.maven</groupId>
<artifactId>coveralls-maven-plugin</artifactId>
<version>4.5.0-M2</version>
</plugin>
Listed milestone mainly to confirm it worked first which it does for whats in this project but maybe not what was in a separately released fork. I don't mind carrying the torch from this point as I already release a good set of plugins and that continues to grow. Will try to figure out how to get coveralls to list it.
I sent a ticket over to coveralls to have them change the documentation, will see how that goes.
@hazendaz great, if they check this repo and notice the deprecated note I would assume they to do the link change on their website.
@trautonen one other thing you might consider is to publish a relocation POM. It's basically a release consisting only of a POM (and signature and checksums) pointing to the new coordinates. Here's an example of one I did many years ago:
https://repo1.maven.org/maven2/com/github/dblock/oshi-parent/3.4.0/
Docs are here and there's a step-by-step Stack Overflow answer here.
This is optional, of course, but some automated dependency update mechanisms might pick it up.
In doing a release with redirection even if those tools don't suggest it, it does help warn users when running builds that it changed.
Coveralls is now updated to point to the fork https://docs.coveralls.io/java. They have also suggested using their new Coverage Reporter which supports the items currently supported as well as others. At this point anyone that wants to come over to my fork an start helping improve there would be much appreciated. If anyone wants to see the email they sent and details, just let me know and I'll forward it over with hopes one of us can address those adjustments.
Hello @trautonen
I would like to contact with you in any possible way that I found to have your agreement on the statement above.
We have here already few really nice PRs that could help the project to grow and thrive even more.
If you have no more chance to continue, please grant the Git privileges to someone that you trust then.
I'm offering to take care as well, my main concern is the hard requirement that GIT repo folder is required during the process and it could be also optional with some more configs dynamically changed..