Next Release: placeholder to prevent release
Closed this issue · 6 comments
List of items that MUST be done before release
xml-formatter must be released along with the comment fix that is still pending!! and slf4j api usage. PR for comment usage revelc/xml-formatter#184 needs more review / testing.jsdt must be released. Looking at a few issues there to confirm we are modern there as we conflict with some setup shown on typcho pages like windows still treated as 32bit not 64bit like other platforms.- [defer]
on this project, try our best to get rid of our runtime dependency on plexus utils, review other lib usage, see if we can apply some of the work done for other formatters.
I have moved the mile stone out to mid April, it was a long time overdue. Mid April seems feasible. I plan working on above issues for next few weeks (mostly weekends) to try to square away the issues.
For plexus, only org.codehaus.plexus.util.DirectoryScanner needs converted to Files.DirectoryStream. That is our only runtime dependency left.
notes: To release any downstream projects see issues raised on revelc-parent as well as noted on jsdt-core as it was really complicated to get released for an effective what should be 5 minute process. The problems will persist for all others.
For plexus, only org.codehaus.plexus.util.DirectoryScanner needs converted to Files.DirectoryStream. That is our only runtime dependency left.
I see no need to wait on this as it is an extra effort.
o release any downstream
Worked around this entirely for now by having 2 separate variations of revelc-5 version. One for osgi that additional skips source jars and one for java source that further skips formatting items for both types (sortpom and formatter). That has to do with hard force on LF instead of allowing user system to work properly (ie windows users that use CRLF). Its good enough for now as it is build side only consideration and works fine that way. I'm not sure how to address OSGI well other than add a skip option that can be overridden. The formatters probably should always be off during release as one would expect the formatting happened before a release does. Then it would probably be ok. I'll look to raise some form of PR on that but it doesn't need to hold anything up and its so new that these things should have been expected since a full cycle release had not occurred ;)
While not a hold up at this point, looking to get jsdt-core to be singular release with OP usage that was forking the original work. Due to how many CI systems run, the concerns we had years ago are rather diminished. For the formatter plugin, the binary for javascript is incredibly reduced but its too much for the OSGI usage OP is having. I'm going to continue to work with him but think there is no real reason to hold up release now. However, I'm going to try to include a few more bits of eclipse in that project to see if that can satisfy him before the release. The jar size was ~32mb then about ~6mb currently and OP is ~13mb. There is a sweet point there I think that can be achieved and anything less than original size will be good for CI systems. We do however probably need to look more as on my fork I have a test I ran with modular jars a year ago that fails due to overlapping modules. And the more I look at what I did to reduce the size the more I think we could leverage parts of what was distributed to central that we further already have in formatter and still gain what we need with possibility of dropping some of the OSGI part. Obviously all theory at the current time.
Closing as I think this is good to go. The jsdt part can be addressed more later. For our purpose it seems working well.