1.2.0 missing release notes and doesn't quite make sense

[hazendaz]

@gnodet and @laeubi

I'm lost, why would I want legacy libraries reintroduced by #71?

I upgraded yuicompressor-maven-plugin project which worked fine with 1.0.0 and 1.1.0 which was simple, then suddenly breaks as seen on hazendaz/yuicompressor-maven-plugin#32.

My original upgrade was here hazendaz/yuicompressor-maven-plugin@cb34d1a.

Maybe I didn't so something right but seems ok to me. Maybe it loses older users, well there is an older plugin and I'm not looking to support anyone before maven 3.9 anyways. Besides fact the old plugin works just with a lot of warnings on maven 3.9.

The default constructor was removed due to the legacy addition and fact it highly relies on legacy now. Now somehow legacy must be injected. How? There are no unit tests that show even how that works. Instead some tests were deleted. The heavy reliance on legacy now IMO means I stay on 1.1.0 as 1.2.0 is IMO again broken in a different way.

How is this supposed to work now that legacy is the constructor and used throughout the class? Can we not have two classes? One with reliance on legacy and one not. I'm only using it in a unit test and for me, it seems a lot of extra hoops to jump to just get what worked to stay working. Have I lost support for maven before 3.9? That is ok to me.

Anyway, I pull request over my direction to help me out here would be much appreciated and/or possibly restoring so the new and old both can work in some way.

[laeubi]

@hazendaz thanks for your report, I'll try to address the mentioned thing below:

1. about the failure you rely on the instantiation of an object that is otherwise injected in your testcase for example here:
   https://github.com/hazendaz/yuicompressor-maven-plugin/blob/dc87f1a6ef7e4c5bc82e65e8f6291879363c192d/src/test/java/net/alchim31/maven/yuicompressor/AggregationTestCase.java#L47
   If you want something for a test, the best is to mock it (e.g. with mockito) or have an own TestBuildContext implementing BuildContext with anything suitable for your test. This is exactly why we also removed other classes (the "tests") because they actually don't test anything, they where just implementation of the API supposed to used in test, if you think they help you feel free to copy the code to your repository, but maintaining them here without clear use-cases is not really planned right now because usually the demands for projects how such "TestContext" behaves / looks like are different and mocking is considered the most usual way these days.
2. about working upgrade it depends a bit of the definition of "working", if you mean it does compile, yes that works. But the default DefaultBuildContext is effectively a no-op implementation that kicks in if no implementation is provided otherwise, that means you will never get any delta processing! That is only performed by the implementation, where the only one known to me is m2eclipse that currently only supports the old way, what means with upgrading to 1.0.0 or 1.1.0 you effectively break this and will always get the no-op implementation, because maven itself doe not support this in any way (mvnd potentially could as it could know what files have changed between two builds)!
3. about the legacy this simply enables users to upgrade to the new API and benefit from some smaller improvements but still get a working state, this might mean you get the same warning as with the old, but if you stay at the old this won't be different and otherwise you loose the incremental feature at all. So the new approach is exactly what you requested here, to work with the old and the new way (but you might need to adjust your code if you are using "internal" classes instead of the API (what is BuildContext), it might be good to use ApiGuardian here to make it more clear, if you like you can open a PR for that, DefaultBuildContext is actually not for public use.

My main goal is to split the current implementation into smaller parts (e.g. one for adding markers and one for asking for incremental file changes) and then support the new API in m2eclipse, at this point it might no longer be required but this is a longer process because all of this is done mostly in my freetime.

[hazendaz]

@laeubi Thanks for such a quick response. I understand the direction and since I opened this, I put coveralls on the project as I know it was not really testing maven, I had also tried mockito but wasn't having much luck yet. At any rate, it has an abysmal 10% coverage so the original authors really never tested it that well. That could mostly be seen by the trouble it took to get it working on github otherwise under linux, mac, and windows. As I'm already 8 months into trying to restore this I sort of expected no change here or even if one would be a while so I have already cut a first milestone release. My main goal is to not have builds stuck at work so we can migrate to newer maven versions day 1 rather than months or years down the road.

Thanks for all the details here. With that info and fact this was hitting internals and what turned out a serious lack of coverage, I'll go ahead and close this. Thank you!