We use it production and development across a total if 6 independent CAS deployments with various permissions to each. While we could manage JSON files via Puppet, ideally the UI would remain.
On 06/09/2014 10:00 AM, Jérôme LELEU wrote: > 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 > <http://www.casinthecloud.com> | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> | > Creator of pac4j: www.pac4j.org <http://www.pac4j.org> > > > 2014-06-09 16:39 GMT+02:00 Scott Battaglia <[email protected] > <mailto:[email protected]>>: > > How did we determine "rarely used" ? > > > On Mon, Jun 9, 2014 at 10:14 AM, Jérôme LELEU <[email protected] > <mailto:[email protected]>> 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 > <http://www.casinthecloud.com> | Twitter: @leleuj > Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> > | Creator of pac4j: www.pac4j.org <http://www.pac4j.org> > > > 2014-06-07 17:53 GMT+02:00 Misagh Moayyed <[email protected] > <mailto:[email protected]>>: > > 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] > <mailto:[email protected]>] > *Sent:* Thursday, June 05, 2014 3:06 AM > *To:* [email protected] <mailto:[email protected]> > *Subject:* Re: [cas-dev] CAS 4.1.0 > > Hi, > > 2014-06-05 3:11 GMT+02:00 Misagh Moayyed > <[email protected] <mailto:[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 > <http://www.casinthecloud.com> | Twitter: @leleuj > > Chairman of CAS: www.jasig.org/cas > <http://www.jasig.org/cas> | Creator of pac4j: > www.pac4j.org <http://www.pac4j.org> > > > > -- > > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed [email protected] > <mailto:[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
