Just my 2c. wrt modern impl. of durable TicketRegistry. Given the lightweight, speedy, easy to maintain nature of Redis in conjunction with its native support for keys expiration, looks like it could be a good candidate.
Cheers, D. Sent from my iPhone > On Jun 7, 2014, at 11:53, Misagh Moayyed <[email protected]> wrote: > > Thanks for clarification on the roadmap. > > Notes follow: > > @JPATicketRegistry: > I am not sure if it’s the most widely used one. I’d think the default > in-memory registry is the one that is used most often and works quite well if > one is not after an HA deployment and is the least complex option. After all, > it requires you to do absolutely nothing. The JPA one is attractive because > it provides durable space specially useful for remember-me, but in reality > and my experience, it is first and foremost evaluated by folks to implement > HA with CAS. Nonetheless, I think we can find and agree on better and more > robust alternatives. I don’t have any particular options at hand at the > moment, perhaps a NoSql solution would work better and be easier to set up > and clean…perhaps an in-memory registry that is backed by MongoDb, or > something else…At the very least, I think we should strongly encourage folks > that the JPATicketRegistry should not be considered for HA deployments. > > @Github Issues: > So, we have to do a little bit of work to create some appropriate tags that > correspond to our existing JIRA issue types, but that’s quite simple to do, > takes very little time and the process is in fact quite customizable. Every > issue can be assigned to a milestone, and may be tagged with many other > decorations that JIRA provides. Issues can be assigned to developers, can > have “Affects Version” and “Fixed in Version” and many other tags that we > feel may be more relevant. > > References: > https://github.com/blog/831-issues-2-0-the-next-generation > https://help.github.com/articles/customizing-issue-labels > > Again, it really feels like we are just using JIRA as a task list but there > is just a bit of disconnect. Not everyone, I am not sure, is subscribed to > all JIRA issues that are reported; a separate system requires a separate > account which requires extra cleanup and maintenance. Github issues can take > care of all of this. > > Now, there is a bit of downside, where we lose the ability to create private > issues. I am not sure how that may be implemented, if it can at all. > > @Downloads Link > I think the Jasig website needs to point to a place where folks can download > CAS. But that’s a one time modification. We can simply point the link to the > place where binary downloads are available on Github, and people can choose > which version to download and adopt. > > Reference: https://github.com/blog/1547-release-your-software > > @Release Process > We definitely do need to take some action there. I have considered gradle for > the build and while it works fine, I have not seen any significant > improvements yet. Now, I think the heart of the issue lies with the > maven-release plugin and various problems we have had with git and platform > types. We may want to look into BinTray and see how that helps. It should > sync with maven central, which is what we really care about and does come > with its own set up of plugins that may work better. I am not sure yet, but > it seems like a viable option. > > Reference: https://bintray.com/ > > > From: Jérôme LELEU [mailto:[email protected]] > Sent: Thursday, June 05, 2014 3:06 AM > To: [email protected] > Subject: Re: [cas-dev] CAS 4.1.0 > > Hi, > > > 2014-06-05 3:11 GMT+02:00 Misagh Moayyed <[email protected]>: > …oh, one more thing to consider: > > - Rather than providing binary downloadable artifacts per release on > the jasig website, it seems like the release engineer for a given CAS release > has all the right permissions and tools to take advantage of the Github’s > releases feature, where the binary artifact, cas-webapp as well as release > notes can directly be hosted and uploaded there. The jasig website could then > perhaps just include a link to the latest release, or to the download area. > > If you have to create a link in the Jasig web site, I'm not sure to see the > benefit: using the text editor for the web site is a bit painful, either for > just a link or a more complete description... > > > My objective really is to try and simplify the release process, by keeping > code, docs, and artifacts all close in the same spot and seems like Github > serves this need quite well for the time being. I imagine this would also be > much easier for CAS users as well, where they get the code, docs, and the > downloadable artifact and release notes (Just the piece that is uploaded to > the jasig wiki that is) all from the same place. > > I'm in line with your objective, but we didn't talk about the worse part from > my point of view: the Maven release prepare and perform tasks... > > Best regards, > > -- > Jérôme LELEU > Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
