Issue #850: Merging wicket jquery UI into wicketstuff core (10.x)

[reckart]

• [x] Moved Wicket JQuery / Kendo into subfolders
• [x] Integrated Wicket JQuery / Kendo modules into the build process
• [x] Remove redundancies from the wicket-jquery-ui-parent pom - everything necessary should be in the wicketstuff parent POM already
• [x] Change groupIds to match wicketstuff
• [x] Change artifactIds to match wicketstuff conventions
• [x] Change module names to match wicketstuff conventions
• [x] Change package names to match wicketstuff
• [x] Ensure the demo app is running

[reckart]

@reiern70 How about you test your application against this branch?

I think before merging, we should at least rename the packages to org.wicketstuff... and adjust the artifact IDs to wicketstuff-xxx because those would be breaking changes if we did them later.

[reiern70]

@reiern70 How about you test your application against this branch?

I think before merging, we should at least rename the packages to org.wicketstuff... and adjust the artifact IDs to wicketstuff-xxx because those would be breaking changes if we did them later.

I would not rename packages, because then people would have to migrate applications. I can't fully try application because we do not have the infrastructure to deploy jars, thus our Jenkins uses published versions

[reckart]

I may be wrong, but I believe all the packages currently in wicketstuff-core start with org.wicketstuff and that IMHO it should continue in that way if we merge Wicket JQueryUI / Kendo in here as well. Yes, it means that people need to migrate their code. But they need to do that anyway for jakarta when moving to Wicket 10 - so a bit more migration shouldn't hurt too much.

[solomax]

great job @reckart ! I doubt someone can review 1300 commits and 5k files changed :( wicket-j-u doesn't have tests :( so the only way to test - is to check examples ...

@reiern70 I believe package names shouldn't be changed (yet) I would merge as-is, so we can cherry-pick this to wicket-9.x branch

and later refactor packages in master, WDYT?

[reckart]

@solomax I expected we only merge this for Wicket 10 and leave people still using Wicket 9 to the original repo. If we cherry-pick this to Wicket 9, then we again will loose all the history. So if we want to have this in Wicket 9, the sensible thing would be to re-do this branch against Wicket 9 and then merge it up into Wicket 10.

[reiern70]

@solomax I expected we only merge this for Wicket 10 and leave people still using Wicket 9 to the original repo. If we cherry-pick this to Wicket 9, then we again will loose all the history. So if we want to have this in Wicket 9, the sensible thing would be to re-do this branch against Wicket 9 and then merge it up into Wicket 10.

@reckart Thanks for good work.

1. I would not rename package names
2. I would also cherry pick this to 9x branch because then users will benefit from new versions too as wicket-stuff is regularly released

[reckart]

As I said: cherry-picking this to the 9.x branch would defy the idea of having the history still available and of git blame being able to work because cherry-picking does not preserve history.

If it is consensus to have Wicket JQuery/Kendo available in wicketstuff 9.x, then we should create a second PR that merges the respective 9.x branch from Wicket JQuery/Kendo into the 9.x branch of wicketstuff core.

[solomax]

@reckart IMO we should have both 9.x and 10.x+ versions, this way we will have regular releases

As I wrote before I would rename packages/maven coordinates for 10.x+ only 9.x should be backward compatible :)

[reiern70]

@reckart IMO we should have both 9.x and 10.x+ versions, this way we will have regular releases

As I wrote before I would rename packages/maven coordinates for 10.x+ only 9.x should be backward compatible :)

To be honest I do not see what we gain with renaming packages, except this is some kind of requirement for being part of wicket-stuff. This will force user to rewrite code, while keeping packages names not.

[reckart]

Consistency. Wicketstuff is a different organization that owns a different namespace. GroupIDs and ArtifactIDs should be updated to reflect that and also package names. Having inconsistency will lead to confusion and headaches further down the road.

With the switch to Wicket 10, there is a switch from javax to jakarta anyway. That is a good place to also make an additional switch for the JQuery/Kendo UI.

[solomax]

there is good example: https://github.com/wicketstuff/core/tree/master/wicket-datetime-parent It was moved from the Wicket main repo to wicketstuff :)

[reckart]

Ok, we have another PR for the 9.x branch as well now: https://github.com/wicketstuff/core/pull/861

[reckart]

@sebfz1 where do the theme files come from?

[reckart]

Any objections against merging this one?

[solomax]

Please merge if you feel it's ready :)

[solomax]

I'd like to add FullCalendar v6 support for wicket-jquery-ui

Shall I create it side-by-side for 10.x (as I did here: https://github.com/sebfz1/wicket-jquery-ui/pull/363)

Or maybe I can just upgrade FullCalendar?

[martin-g]

Side-by-side sounds more safe and easy for the users to upgrade.