Merging wicket-jquery-ui into wicketstuff core

[reckart]

wicket-jquery-ui has not seen a release for quite some time, but it is still a useful library and it is in principle ready to be release for Wicket 10. I have been offered the opportunity to run such a release.

However, I would propose to instead prepare a PR to merge wicket-jquery-ui into WicketStuff Core. That would save the work for a release cycle. And I would offer to help out a bit with wicketstuff itself (including the merged wicket-jquery-ui) then, so there is one shoulder more to back the project.

WDYT?

[reiern70]

+1 for this. We are also using this library

[martin-g]

+1

[bitstorm]

+1

…

On Mon, Mar 25, 2024 at 8:41 AM Martin Grigorov ***@***.***> wrote: +1 — Reply to this email directly, view it on GitHub <#850 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEDCUFA2XWSDCZ756OTBVLYZ7II5AVCNFSM6AAAAABFEPYLPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJXGM4TGOJXGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Andrea Del Bene. Apache Wicket committer.

[solomax]

@sebfz1 WDYT? :)))

[sebfz1]

Thanks Maxim, I didn't noticed this issue was opened.
I will be more than happy to transfer the project to wicket-stuff, thank you for accepting it! As discussed offline with Richard and Martin, I unfortunately don't have time to maintain it...
I believe we need to upgrade the packages first, before releasing the version 10 as it's a breaking change. It would not make sense to have "com.googlecode" in the wicket-stuff repo. In another hand, wicket-stuff 10 is already released so I'm not sure what to do. Shall I change the packages and release to the current maven GAV? WDYT?

[sebfz1]

Also... Wicket Kendo UI provides the integration for the free components (ASF licensed), but also some of the pro components. There's a reference to "kendo-full.js" kendo's CDN (if I recollect the name correctly) for the demo app to run for those pro widgets. From my understanding reading the license, it's ok, no issues. And as long as it was my project/repo, it's not a big deal even if my understanding was incorrect. Now that the project is about to join the ASF repo, better to quickly double check on this I think...

[reckart]

@sebfz1 Wicketstuff is not an ASF repo.

[solomax]

@sebfz1 I believe transfer to wicketstuff can be very much transparent :)
KendoUI can live as-is, due to there are no strict license limitations :)

9.x should have original package names to be backward compatible
10.x packages will be renamed

I can handle it later this week :) (or someone else can do it)

[reckart]

@sebfz1 in principle, we have a Wicket 10 compatible Wicket Kendo milestone release that could be used / tested. The parts I have tested so far worked with Wicket 10. So if that is enough for everybody until the code has been merged into Wicketstuff and another Wicketstuff 10.x release has been cut, we may not need another immediate Wicket Kendo release.

I'd say as part of the merge, the GAV and package names of the code would indeed change. That would happen on the PR that merges the Wicket Kendo Repo into this Repo. So while this would be a breaking change for users and a bit of effort to upgrade in their code, I think it is ok given the "major" release of the code from 9 to 10 and given that it moves to another hopefully long-time home. Since the API will very likely not change other than the rename, it should be a global search/replace thing for people to fix their code.

[reckart]

Btw. I think it would be good to prepare the PR in such a way that it merges the entire Kendo Wicket history as well (at least of the branch(s) being merged) and not just be a code-dump of the current state. WDYT?

[solomax]

Btw. I think it would be good to prepare the PR in such a way that it merges the entire Kendo Wicket history as well (at least of the branch(s) being merged) and not just be a code-dump of the current state. WDYT?

I would move everything in one commit (with reference to original repo in README ....)
Not sure if we need all history ...

[reckart]

In case you ever need to trace the provenance of code or have to go back and read commit comments in order to reproduce what somebody was thinking when they wrote a particular part of the code, having the history is essential. In my personal experience, I have to do this quite regularly - in particular when taking over code from another maintainer. Having to have to switch to a different repo to "git blame" would be annoying.

[solomax]

make sense :)

[sebfz1]

Oh, I forgot wicket-stuff was not an ASF repo!
I'm fine with the approach. I thought I was a git expert... But I didn't know it was possible to keep the history in such a move! I'm interested to know if you are using a particular command or kind of a trick like you rebase from the next target and the PR will contain all commits since day 1...

[reckart]

@sebfz1 the parameter is --allow-unrelated-histories - I have done that a couple of times in the past in order to merge repos. No rebase - that would change the commit hashes. The idea is to keep the history intact and the hashes the same. Essentially, the idea is to do the opposite of a fork - a merge ;) Just a merge across repos and histories.

[reckart]

The process for merging two repos is approximately as follows:

• Create a merge-preparation branch in repo 1
• Move all data in repo 1 into subfolders to ensure that there is no overlap between the files/folders of repo 1 and repo 2. The folders in repo 1 must have different names than the ones in repo 2.
• Add a second remote to your local clone of repo 1, namely repo 2 and fetch
• merge the main branch of repo 2 into your merge-preparation branch using --allow-unrelated-histories
• push the branch into repo 2 (and create a PR)
• now continue to refactor the branch until all modules/packages have proper names, tests run, build completes, etc.
• once everything is done, merge the PR

[reckart]

I'm looking into preparing a PR...

[reckart]

I have opened a PR here: #856

I think it would be good if somebody could have a first look whether this is going into a good direction and if/which wicketstuff conventions should be observed that I may not be aware of.