Hi, I've never used it in production, nor have Unicon (Bill's feedback). Hence the "rarely used" and the idea that maybe we could deprecate the management webapp and save a lot of work here. Some powerful tools seem to be emerging as replacement (I'm thinking of the JSON registries started by Unicon and MArvin...)
Though, it's not a decision, it's a proposal and if the assumption is false, I'm sure that people interested in this UI will manifest themselves enough, so that we keep it... 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 2014-06-09 16:39 GMT+02:00 Scott Battaglia <scott.battag...@gmail.com>: > How did we determine "rarely used" ? > > > On Mon, Jun 9, 2014 at 10:14 AM, Jérôme LELEU <lel...@gmail.com> wrote: > >> Hi, >> >> For deprecation, per our discussion on >> https://github.com/Jasig/cas/pull/439, I'd like to propose to deprecate >> the management UI which is pretty complex to maintain to match all the >> capabilities provided by the CAS server and which seems to be rarely used. >> I admit that it seems to be a rather drastic choice. >> 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 >> >> >> 2014-06-07 17:53 GMT+02:00 Misagh Moayyed <mmoay...@unicon.net>: >> >>> 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: lel...@gmail.com >>> >>> 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: >> scott.battag...@gmail.com >> 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: lel...@gmail.com > 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
