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:lel...@gmail.com] Sent: Thursday, June 05, 2014 3:06 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] CAS 4.1.0 Hi, 2014-06-05 3:11 GMT+02:00 Misagh Moayyed <mmoay...@unicon.net>: ???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 cas-dev@lists.jasig.org as: mmoay...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
