grails-shiro support for grails 3.0.x

[beneo]

When will it be ready for support grails 3.0.x ??

thx in advance

Great minds think alike :-) I just reached out to Peter Ledbrook and Peter McNeil - looks like a tentative game plan is in the works sometime very soon. This is a blocker for me so I am interested in seeing this go through.

[pmcneil]

Yep it shouldn't take too much to get it going. Hey either of you like doing doco ;-)

Sure, whatever is needed, just let me know and I'll happily oblige.

Also @pmcneil is this the best forum for detailed discussion/planning? I'm happy to use it but not sure if its the best format; does GitHub have a chat-type feature? IRC? If you'd like me to work on documentation (Groovy Docs, README, Grails plugin docs, etc.) I have quite a number of suggestions/ideas to bounce off of you.

[pmcneil]

This is as good as any, you can always email me if you like.

[pmcneil]

Looking at Grails 3.0 features it might be time to revisit the plugins features, e.g. with regard to

• the scripts going from Gant to Gradle.
• the potential of adding security traits since groovy 2.4 is in there
• using interceptors in stead of filters?
• profiles?
  We should also update to Shiro 1.2.3 from 1.2.2
  We also need to look at how we handle backwards compatibility - probably just branch the current release and upgrade to Shiro 1.2.3 for now (but then we need to clearly document the release versions and how to upgrade your application.)

[pmcneil]

Hmm, looking at the upgrade procedure we might be better off creating a new repo instead of a branch. maybe?

[pmcneil]

Re: new repo project thoughts -
Pros:

• A new Repo might be cleaner since the update process involves creating a whole new grails project and copying across files to new locations and changing where configuration is done. This has the potential to be a bit of a mess, and it also provides the opportunity to clean out any cruft and re-organise tests etc.
• I want to be able to cleanly support the older version of the plugin with back ports and updates of Shiro itself. Branching means if you switch branches, with so many changes including grails version, gradle build etc., the IDE will have a small fit keeping up :-)

Of course you'd keep checked out branches in separate directories with associated IDE project files... but if you do switch branches it could get messy.

Cons:

• Making a new project Repo may mean a new plugin, since the source repo would be different.
• You lose the history.
• back porting is not a merge - mind you it would not be a simple merge anyway.

Current thinking:

• it's probably better to branch the 2.x code and try to do the upgrade in the current repo and capture the moving of files - which will be interesting, if not fun.

I agree with a branch over a new repo, although I see what you are talking about. Like you said, I think it might make sense to use semver and release this new grails-shiro as 2.0 and then make it patently obvious in the docs that if clients are running Grails 1.x or 2.x, that they need to use a 1.x version of grails-shiro.

[pledbrook]

You can push your own copy of the repo to a new GitHub account/repo while retaining history. In other words, "new repo" doesn't necessarily mean losing history.

I also don't think merging is the right way to do a back port. It's easy enough to create a patch from one repo that can be applied to the other, or at least no more difficult than a merge between branches 😄

[pmcneil]

In case you're wondering what's happening... been busy at work. Also been trying to get all the original tests working again before porting. (just dependency manager and webdriver issues)

[pmcneil]

@pledbrook by new repo I meant starting a new git project root, thus losing the history. Tracking the moves in the upgrade to 3.0, and perhaps switching branches may cause a bit/lot of confusion (and re-indexing in IDEs...) anyway I'll suck it and see :-)

[emacadie]

Has any progress been made on this?