I would like to be a maintainer of this project if you leave it (or fork it once again)

PabloThiele commented 3 years ago

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..

nhoughto commented 3 years ago

seems like a fork is the answer

dbwiddis commented 2 years ago

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?

trautonen commented 2 years ago

@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.

jgangemi commented 1 year ago

@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.

PabloThiele commented 1 year ago

@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.

trautonen commented 1 year ago

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.

hazendaz commented 9 months ago

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.

The git submodule usage is bad IMO. Jars can contain configs needed, I've deleted it. I boarded my own parent so it already checks that kind of stuff by default so its not needed. It was breaking ability to even clone it with github desktop - had to do so manually.
I've cleaned up some cruft on this, deleted what I consider junk scripts that overlap maven, bad plugin usage, etc.
I've added my parent which is already in use on probably a dozen maven plugins and in pieces for major projects such as mybatis so it has a much higher track record of just working.
I've updated every single thing library / plugin wise and fixed maven scopes. So its maven 4 compatible now.
I've automated the license application using correct plugin / correct style
I've updated all deprecated mockito code so its using modern that still works with java 8 including making a test that was linux only work cross platform (mac, windows, linux).

Things IMO to still do

Convert tests to junit 5
Cleanup code given lot has occurred in last decade
Decide if we want my hard fork back here or not.
Make samples integration tests and clean them up.
Rewrite httpclient 4 to 5
Cleanup deprecated maven code

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.

hazendaz commented 9 months ago

Confirmed my hard fork works as expected.

PabloThiele commented 9 months ago

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.

hazendaz commented 8 months ago

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 :)

trautonen commented 8 months ago

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. 😄

hazendaz commented 8 months ago

@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.

hazendaz commented 8 months ago

I sent a ticket over to coveralls to have them change the documentation, will see how that goes.

trautonen commented 8 months ago

@hazendaz great, if they check this repo and notice the deprecated note I would assume they to do the link change on their website.

dbwiddis commented 8 months ago

@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.

hazendaz commented 8 months ago

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.

hazendaz commented 8 months ago

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.

trautonen / coveralls-maven-plugin

I would like to be a maintainer of this project if you leave it (or fork it once again) #142