Versions Compared

Old Version 103

changes.mady.by.user Apereo Infrastructure

Saved on

compared with

New Version 104

changes.mady.by.user Apereo Infrastructure

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

[12:29:42 CDT(-0500)] <beav_> Hello - Is there anyone able to give me a hand with an issue I'm having with CAS?
[12:29:52 CDT(-0500)] <serac> We'll try.
[12:30:15 CDT(-0500)] <beav_> It is much appreciated.
[12:32:41 CDT(-0500)] <beav_> I am trying to utilized the mysql capability in cas however when I edit the deployerConfigContext.xml to utilized I receive the following error when tomcat is fired up: The prefix "tx" for element "tx:annotation-driven" is not bound
[12:33:18 CDT(-0500)] <beav_> I should say that I am new to this. As far as I can tell my syntax is correct according to the wiki documentation.
[12:33:32 CDT(-0500)] <serac> You're missing a namespace declaration in the root element.
[12:34:13 CDT(-0500)] <beav_> Would this not suffice?
[12:34:15 CDT(-0500)] <serac> Here's a valid beans element:
[12:34:16 CDT(-0500)] <serac> <beans xmlns="http://www.springframework.org/schema/beans&#034;
[12:34:17 CDT(-0500)] <serac> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&#034;
[12:34:17 CDT(-0500)] <serac> xmlns(tongue)="http://www.springframework.org/schema/p&#034;
[12:34:17 CDT(-0500)] <serac> xmlns:tx="http://www.springframework.org/schema/tx&#034;
[12:34:17 CDT(-0500)] <serac> xmlns:util="http://www.springframework.org/schema/util&#034;
[12:34:17 CDT(-0500)] <serac> xsi:schemaLocation="
[12:34:17 CDT(-0500)] <serac> http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
[12:34:18 CDT(-0500)] <beav_> <beans xmlns="http://www.springframework.org/schema/beans&#034; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&#034; xmlns(tongue)="http://www.springframework.org/schema/p&#034; xmlns:tx="http://www.springframework.org/schema/tx&#034; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframew ork.org/schema/tx http://www.spring
[12:34:18 CDT(-0500)] <serac> http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
[12:34:18 CDT(-0500)] <serac> http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd">
[12:34:42 CDT(-0500)] <beav_> sorry - I think I put up my post the same time as yours.
[12:35:21 CDT(-0500)] <beav_> so these declarations will not work? I will list below:
[12:35:23 CDT(-0500)] <serac> What you posted looks right.
[12:35:37 CDT(-0500)] <serac> Are you sure it's coming from deployerConfigContext?
[12:35:49 CDT(-0500)] <beav_> Let me double check.
[12:36:18 CDT(-0500)] <beav_> 2011-06-17 11:01:20,327 FATAL [org.jasig.cas.web.init.SafeContextLoaderListener] - SafeContextLoaderListener: The Spring ContextLoaderListener we wrap threw on contextInitialized. But for our having caught this error, the web application context would not have initialized. org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 206 in XML document from ServletContext resource [/WEB-INF/deployerConfigContext.xml]
[12:37:00 CDT(-0500)] <beav_> the rest of it: The prefix "tx" for element "tx:annotation-driven" is not bound.
[12:37:44 CDT(-0500)] <serac> Double check your namespace declarations.
[12:38:14 CDT(-0500)] <serac> In the snippet you posted, looks like you have an extra space in the schemaLocations attribute for the tx namespace.
[12:38:32 CDT(-0500)] <serac> http://www.springframew ork.org/schema/tx
[12:38:36 CDT(-0500)] <serac> w_ord
[12:38:38 CDT(-0500)] <serac> w_ork
[12:39:24 CDT(-0500)] <serac> You're from Algonquin College?
[12:39:32 CDT(-0500)] <beav_> I am.
[12:39:39 CDT(-0500)] <serac> Good to know who's using CAS.
[12:39:45 CDT(-0500)] <serac> Or at least trying (smile)
[12:39:52 CDT(-0500)] <beav_> We are trying. :o)
[12:40:19 CDT(-0500)] <beav_> I should say I am not a Java developer - just a unix admin who know a bit about Tomcat.
[12:40:35 CDT(-0500)] <serac> Perfectly fine – we get lots of those.
[12:40:43 CDT(-0500)] <beav_> Good to hear.
[12:40:48 CDT(-0500)] <serac> And we can admit our deployment model isn't suited to you folks very well.
[12:41:11 CDT(-0500)] <beav_> It has been a fun learning experience thus far.
[12:41:45 CDT(-0500)] <apetro> serac, speak for yourself, I expect beav_ will find stacked Maven overlays eminently well-suited. (smile)
[12:43:02 CDT(-0500)] <serac> I think I'll let him speak for ease of deployment (wink)
[12:43:05 CDT(-0500)] <beav_> Is there anyway to break up this line from one continous line to a multi line entry?
[12:43:10 CDT(-0500)] <beav_> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframew ork.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">
[12:43:46 CDT(-0500)] <serac> You can use anywhitespace separator between namespaces and ns URIs.
[12:43:59 CDT(-0500)] <serac> so s/\n/\t/ and you're good
[12:44:10 CDT(-0500)] <beav_> Thank you.
[12:44:11 CDT(-0500)] <serac> or s/ /\n/ rather
[12:44:17 CDT(-0500)] <beav_> gotcha
[12:44:21 CDT(-0500)] <apetro> but seriously, is it worth shipping deployerConfigContext.xml with that tx namespace declaration already in place ready to rock and roll? Seems harmless to include even if folks don't end up needing it.
[12:44:25 CDT(-0500)] <serac> I typically put each one on a separate line.
[12:44:43 CDT(-0500)] <serac> I thought it was there by default.
[12:44:47 CDT(-0500)] <serac> Checking...
[12:44:55 CDT(-0500)] <apetro> https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml
[12:45:02 CDT(-0500)] <apetro> that's a no, unless I'm missing something.
[12:45:15 CDT(-0500)] <serac> You're right, not there.
[12:45:33 CDT(-0500)] <serac> It should be there by default.
[12:45:43 CDT(-0500)] <apetro> JIRAing...
[12:45:44 CDT(-0500)] <serac> I feel a Jira issue coming...
[12:45:46 CDT(-0500)] <serac> (wink)
[12:46:15 CDT(-0500)] <serac> beav_ – it's probably that space I mentioned in the tx namespace.
[12:46:33 CDT(-0500)] <serac> Fix that and hopefully you'll be good to go.
[12:46:57 CDT(-0500)] <beav_> I think that it was my IRC client that inserted that space - I am using vi and I don't see any spaced at all in the declarations...
[12:47:19 CDT(-0500)] <serac> Ok. Chat is bad for quoting source.
[12:47:48 CDT(-0500)] <apetro> https://issues.jasig.org/browse/CAS-989
[12:48:02 CDT(-0500)] <serac> Can you post the file to pastebin or something so I can review it in its entirety? Or you can post it to cas-user and we'll continue there.
[12:48:28 CDT(-0500)] <serac> apetro wins the prize for most jira issues created in a fortnight.
[12:48:49 CDT(-0500)] <beav_> Sure thing. Will do.
[12:48:53 CDT(-0500)] <apetro> ah, but who wins the price for most JIRA issues usefully resolved in a fortnight?
[12:49:43 CDT(-0500)] <apetro> would it be a stupid question for me to ask what you're doing, beav_ , in deployerConfigContext.xml that needs the tx: namespace?
[12:50:10 CDT(-0500)] <serac> JpaTicketRegistry used @Transactional.
[12:50:19 CDT(-0500)] <serac> uses
[12:50:49 CDT(-0500)] <serac> Gotta have the annotation-driven directive to scan classes for that and instrument properly.
[12:51:08 CDT(-0500)] <apetro> eh
[12:51:19 CDT(-0500)] <apetro> ticketRegistry is declared here: https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketRegistry.xml isn't it?
[12:51:24 CDT(-0500)] <apetro> not in deployerConfigContext.xml?
[12:51:31 CDT(-0500)] <beav_> I believe (I say that because I am not sure - just going off examples in docs) - I need to have the ability to utilize mysql for the ticket registry as well as service registry?
[12:51:53 CDT(-0500)] <serac> That's the high-level reason. I'm giving specifics.
[12:52:52 CDT(-0500)] <beav_> I am following the example in this doc: https://wiki.jasig.org/display/CASUM/End-to-end+Windows+Example
[12:53:06 CDT(-0500)] <apetro> ok. Services registry DAO impl declared in deployerConfigContext.xml . May (will, in JPA case) need transaction aspects. Got it.
[12:53:25 CDT(-0500)] <apetro> suggests ticketRegistry.xml similarly would benefit from tx: namespace declared by default.
[12:54:04 CDT(-0500)] <apetro> hmm.
[12:54:24 CDT(-0500)] <serac> It only needs to be in one place. I commented on the issue you opened that it should be in some reasonable place by default.
[12:54:51 CDT(-0500)] <serac> applicationContext.xml is best IMO, but I don't care that much as long as it's there.
[12:54:53 CDT(-0500)] <apetro> oh, interesting
[12:55:04 CDT(-0500)] <apetro> so the "right" answer is to include it in applicationContext.xml?
[12:55:18 CDT(-0500)] <serac> Right to me, Scott may feel otherwise.
[12:58:19 CDT(-0500)] <serac> The @Transactional is a special case of Aspects, and the aop stuff is in applicationContext.xml, so I think that's suitable justification.
[12:58:33 CDT(-0500)] <serac> And now Scott can comment (smile)
[13:01:22 CDT(-0500)] <battags> what am I commenting on
[13:01:26 CDT(-0500)] <battags> lol
[13:02:03 CDT(-0500)] <serac> We're helping beav_ with a spring tx namespace declaration.
[13:02:14 CDT(-0500)] <serac> Andrew suggested it tx:annotation-driven should be in there by default.
[13:02:36 CDT(-0500)] <serac> I seconded and https://issues.jasig.org/browse/CAS-989 was born.
[13:02:58 CDT(-0500)] <serac> I believe applicationContext.xml is the best place.
[13:03:24 CDT(-0500)] <serac> And now you can comment.
[13:03:28 CDT(-0500)] <serac> (wink)
[13:06:07 CDT(-0500)] <beav_> http://pastebin.com/XBkQmHMC
[13:06:18 CDT(-0500)] <beav_> I'll send it to the list in a sec.
[13:06:59 CDT(-0500)] <beav_> sorry - that is my deployerConfigContext.xml
[13:07:13 CDT(-0500)] <serac> That's what I wanted. Let's discuss further on list.
[13:07:24 CDT(-0500)] <beav_> I am sure I am doing something wrong somewhere :o)
[13:07:25 CDT(-0500)] <beav_> Ok
[13:08:25 CDT(-0500)] <serac> You need to sanitize your configs of passwords before you post anywhere. Better change that mysql pass.
[13:08:46 CDT(-0500)] <serac> (It's easy to do – most of us have done it at some point.)
[13:09:13 CDT(-0500)] <apetro> heh. And I was just going to compliment on having sanitized of the LDAP password, which usually is overlooked.
[13:09:33 CDT(-0500)] <beav_> :o)
[13:09:58 CDT(-0500)] <battags> is the jar htat includes the transaction stuff been included?
[13:10:05 CDT(-0500)] <battags> i.e. spring-orm or spring-tx whatever its name was
[13:10:37 CDT(-0500)] <beav_> I hope that is not directed at me because I haven't the foggiest. :o)
[13:11:09 CDT(-0500)] <serac> You're going to need additional components to get this to work.
[13:11:12 CDT(-0500)] <beav_> Please assume that you must talk to me like a 5 year old.
[13:11:32 CDT(-0500)] <serac> I'm thinking at this point we should discuss Maven overlay.
[13:11:33 CDT(-0500)] <battags> I prefer to talk to you as an adult who isn't familiar with Spring and Maven :-p
[13:11:53 CDT(-0500)] <battags> unless you are actually a 5 year old deploying CAS!
[13:12:00 CDT(-0500)] <serac> If you don't know what components you need to include by some manual process, then Maven is your friend.
[13:12:21 CDT(-0500)] <beav_> I need some juice a cookies...
[13:12:30 CDT(-0500)] <serac> https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
[13:12:41 CDT(-0500)] <apetro> should we skip to the part where we talk about the uber-war?
[13:12:52 CDT(-0500)] <serac> Haha.
[13:12:55 CDT(-0500)] <serac> Probably.
[13:13:01 CDT(-0500)] <apetro> semi-serious
[13:13:12 CDT(-0500)] <apetro> this feels like a need to, like, start from more stuff.
[13:13:18 CDT(-0500)] <apetro> that's what uber-war does, right?
[13:13:36 CDT(-0500)] <battags> Uber-War is for those who don't want to deal with Maven (wink)
[13:13:49 CDT(-0500)] <serac> beav_, did you get to the maven overlay part?
[13:13:54 CDT(-0500)] <serac> Of https://wiki.jasig.org/display/CASUM/End-to-end+Windows+Example.
[13:13:57 CDT(-0500)] <battags> and for defense contractors who may or may not want to put it in for certification
[13:14:03 CDT(-0500)] <apetro> is that really so, battags? I've grossly misunderstood uber-war?
[13:14:55 CDT(-0500)] <battags> which part of my statement are you questioning?
[13:15:00 CDT(-0500)] <serac> I think that's right. It's got common components turn on so you don't have to do an overlay, but you could if you needed additional stuff.
[13:15:01 CDT(-0500)] <battags> just so I answer the right question
[13:15:11 CDT(-0500)] <battags> or maybe Marvin just answered it
[13:15:22 CDT(-0500)] <beav_> I did use Maven to build the war file - however I didn't modify any files under the spring-config directory..
[13:15:50 CDT(-0500)] <serac> You've most likely got the right java libraries (spring-orm, spring-tx, etc).
[13:15:50 CDT(-0500)] <wgthom> checking in
[13:15:54 CDT(-0500)] <apetro> congratulations on not modifying files under spring-config dir. That's really for the best.
[13:15:56 CDT(-0500)] <serac> Maven does that for you.
[13:16:13 CDT(-0500)] <serac> Hey wgthom.
[13:16:21 CDT(-0500)] <battags> hey bill!
[13:16:21 CDT(-0500)] <beav_> I put several entries in the pom.xml for mysql interop.
[13:16:33 CDT(-0500)] <serac> beav_ – Can we continue this support on list?
[13:16:39 CDT(-0500)] <serac> We're into our 2-3 Friday dev chat.
[13:16:50 CDT(-0500)] <serac> Now that wgthom is here, we should discuss ClearPass.
[13:16:55 CDT(-0500)] <beav_> Sure - whatever help I can get is greatly appreciated.
[13:17:03 CDT(-0500)] <serac> We'll set you straight, np.
[13:17:18 CDT(-0500)] <beav_> Much appreciated folks. Thanks very much.
[13:17:30 CDT(-0500)] <serac> So ClearPass...
[13:17:41 CDT(-0500)] <apetro> heh. I expect beav_ will help set us developers straight about what we can do to make this easier to adopt.
[13:17:43 CDT(-0500)] <serac> Two divergent options: integrate or decouple.
[13:17:44 CDT(-0500)] <wgthom> the feature everyone loves to hate (smile)
[13:17:50 CDT(-0500)] <apetro> but yes, beav_ , look forward to continuing on-list.
[13:17:56 CDT(-0500)] <serac> I want to know how/why it's coupled in the first place.
[13:18:03 CDT(-0500)] <wgthom> me too
[13:18:13 CDT(-0500)] <serac> Oh, I thought I was just ignorant.
[13:18:15 CDT(-0500)] <apetro> sure
[13:18:27 CDT(-0500)] <wgthom> is it must the maven business?
[13:18:29 CDT(-0500)] <apetro> so, clearpass produces a .war
[13:18:44 CDT(-0500)] <apetro> the happiest deployers then overlay their local changes on that .war
[13:18:51 CDT(-0500)] <apetro> ala how you overlay changes on the basic CAS .war, after all
[13:19:05 CDT(-0500)] <apetro> the way clearpass produces a .war
[13:19:08 CDT(-0500)] <apetro> is to overlay on CAS
[13:19:14 CDT(-0500)] <apetro> to do that, it has to overlay on some specific version
[13:19:35 CDT(-0500)] <apetro> and, tada, clearpass depends on, and entails, some underlying version of CAS
[13:19:59 CDT(-0500)] <apetro> battags, that a useful first order summary?
[13:20:13 CDT(-0500)] <serac> But just because you need to specify some version isn't to say you have to rev them in parallel necessarily.
[13:20:20 CDT(-0500)] <battags> the war is a convenience
[13:20:22 CDT(-0500)] <battags> to make overlay easier
[13:20:30 CDT(-0500)] <apetro> https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketRegistry.xml
[13:20:35 CDT(-0500)] <battags> you could pull all the stuff in on your own
[13:20:47 CDT(-0500)] <apetro> sorry, meant to post this link: https://source.jasig.org/cas-extensions/clearpass/tags/clearpass-1.0.7.GA/pom.xml
[13:21:04 CDT(-0500)] <apetro> eh, you could pull in the stuff on your own, but it would be no fun
[13:21:13 CDT(-0500)] <battags> to produce a WAR we need to depend on some version of CAS
[13:21:19 CDT(-0500)] <wgthom> is there a path to make CPE a dep like any other rather than incorporation via overlay
[13:21:29 CDT(-0500)] <battags> there is XML config
[13:21:31 CDT(-0500)] <battags> which is all the WAR does
[13:21:32 CDT(-0500)] <apetro> right
[13:21:41 CDT(-0500)] <apetro> it's more than a .jar, unfortunately
[13:21:45 CDT(-0500)] <apetro> it touches web-stuff
[13:21:50 CDT(-0500)] <apetro> adding both XML and JSPs
[13:21:51 CDT(-0500)] <battags> so I could re-look at it
[13:21:57 CDT(-0500)] <battags> and see if there is anything we can auto-wire
[13:22:36 CDT(-0500)] <apetro> you could, but why are we resisting including well-established features in CAS-server war?
[13:22:42 CDT(-0500)] <serac> Do most/all folks do overlay with CPE anyway?
[13:22:56 CDT(-0500)] <serac> I'd imagine yes.
[13:23:01 CDT(-0500)] <apetro> autowiring would at best make this no less complicated. Including as a feature in CAS war has potential to make this fewer modules and less complicated.
[13:23:16 CDT(-0500)] <wgthom> out of necessity...
[13:23:17 CDT(-0500)] <apetro> I imagine all ClearPass adopters locally do Maven overlay over ClearPass, yes.
[13:23:27 CDT(-0500)] <battags> actually autowiring would make it less complicated
[13:23:32 CDT(-0500)] <battags> since there would be no XML config
[13:23:35 CDT(-0500)] <battags> if done right
[13:23:59 CDT(-0500)] <battags> I don't really have a strong desire to include something that stores passwords in CAS proper
[13:24:01 CDT(-0500)] <battags> call me crazy :-p
[13:24:05 CDT(-0500)] <serac> +1
[13:24:13 CDT(-0500)] <battags> are you +1 calling me crazy?
[13:24:14 CDT(-0500)] <battags> ha
[13:24:29 CDT(-0500)] <serac> +1 in favor of your concerns (wink)
[13:24:50 CDT(-0500)] <serac> How much change happens to CP for each CAS rev?
[13:24:53 CDT(-0500)] <wgthom> the problem is it already is a well-know community feature
[13:24:55 CDT(-0500)] <serac> Some, lots, none? In practice.
[13:25:13 CDT(-0500)] <serac> Is it just a version number bump in the poms?
[13:25:13 CDT(-0500)] <wgthom> i haven't been invovled in a deployment that hasn't needed it...including RU
[13:25:14 CDT(-0500)] <battags> fyi I posted some download stats in the ticket Andrew created
[13:25:18 CDT(-0500)] <battags> its like 4% of the total CAs downloads
[13:25:20 CDT(-0500)] <apetro> in practice, the pom.xml changes to declare the correct CAS server version
[13:25:43 CDT(-0500)] <battags> for the most part its the pom.xml changes and then a sanity check to ensure dup dependencies weren't pulled into the WAR
[13:25:51 CDT(-0500)] <apetro> oh, right
[13:25:55 CDT(-0500)] <apetro> that's a very important point
[13:25:59 CDT(-0500)] <apetro> duplicated dependencies are a major pain
[13:26:12 CDT(-0500)] <serac> That is frequently an issue with overlays in general tho.
[13:26:18 CDT(-0500)] <apetro> yes
[13:26:22 CDT(-0500)] <serac> At least for non-trivial ones.
[13:26:22 CDT(-0500)] <battags> so basically I change the version, build it, go "yep no crazy dependencies" and then tag it and release it
[13:26:27 CDT(-0500)] <apetro> but pulling it into CAS itself would be one fewer layer of overlays (smile)
[13:27:09 CDT(-0500)] <battags> so would not having ClearPass :-p
[13:27:10 CDT(-0500)] <battags> j/k
[13:27:20 CDT(-0500)] <battags> though I live for a day where password replay is not requied
[13:27:22 CDT(-0500)] <battags> required*
[13:27:27 CDT(-0500)] <wgthom> what does it look like to safely have it off my default, but included in the core?
[13:27:30 CDT(-0500)] <serac> Right on.
[13:27:43 CDT(-0500)] <battags> so having it off but in
[13:27:52 CDT(-0500)] <battags> just means putting those XML files in the spring-config dumping ground
[13:28:02 CDT(-0500)] <battags> that is not enabled by default
[13:28:10 CDT(-0500)] <battags> then a deployer has to copy them somewhere useful
[13:28:15 CDT(-0500)] <serac> I'm just concerned about signficantly increasing the scope of the product. These are 3 non-trivial but coupled modules.
[13:28:28 CDT(-0500)] <wgthom> 3?
[13:28:52 CDT(-0500)] <serac> <module>clearpass-core</module>
[13:28:52 CDT(-0500)] <serac> <module>clearpass-webapp</module>
[13:28:52 CDT(-0500)] <serac> <module>clearpass-integration-uportal</module>
[13:28:59 CDT(-0500)] <serac> Maven modules is the sense here.
[13:29:15 CDT(-0500)] <apetro> right
[13:29:18 CDT(-0500)] <apetro> two of those disappear
[13:29:24 CDT(-0500)] <apetro> merged into the corresponding cas-serer modules
[13:29:25 CDT(-0500)] <wgthom> "increasing the scope of the product." ... like multi-protocol support? lol.
[13:29:35 CDT(-0500)] <serac> touche
[13:29:46 CDT(-0500)] <battags> whoa wait merged in?
[13:29:47 CDT(-0500)] <apetro> I'd prefer to think of it as refactoring the current scope of the product.
[13:30:15 CDT(-0500)] <battags> I was lukewarm about a clearpass-module
[13:30:28 CDT(-0500)] <battags> but less ok with actually putting it in cas-server-core
[13:30:33 CDT(-0500)] <serac> We are discussing making these modules under cas-server.
[13:30:48 CDT(-0500)] <serac> Not in core, per se.
[13:30:50 CDT(-0500)] <apetro> alright
[13:31:03 CDT(-0500)] <apetro> agreed on clearpass-core not merge into cas-server-core
[13:31:10 CDT(-0500)] <apetro> fine precedent for cas-server-support-clearpass, or so
[13:31:11 CDT(-0500)] <serac> I thought andrew meant the one to go away was clearpass-webapp
[13:31:19 CDT(-0500)] <apetro> right
[13:31:25 CDT(-0500)] <apetro> one goes away.
[13:31:31 CDT(-0500)] <battags> I would think clearpass-webapp goes away
[13:31:37 CDT(-0500)] <battags> can the uportal one merge into uPortal then? (wink)
[13:31:44 CDT(-0500)] <serac> haha
[13:31:55 CDT(-0500)] <apetro> it's a decent idea
[13:31:59 CDT(-0500)] <apetro> it is uPortal specific
[13:32:10 CDT(-0500)] <apetro> uPortal ships with CAS
[13:32:13 CDT(-0500)] <battags> otherwise we could fold it into the CAs client
[13:32:19 CDT(-0500)] <apetro> might as well ship with ready to rock and roll ClearPass integration with that CAS
[13:32:21 CDT(-0500)] <battags> since it relies on the Java CAS Client
[13:32:26 CDT(-0500)] <apetro> right
[13:32:29 CDT(-0500)] <apetro> part of it does that
[13:32:39 CDT(-0500)] <apetro> and in theory one might use parts of it in, gag me, other portals
[13:32:49 CDT(-0500)] <battags> there are other portals that people use?
[13:33:15 CDT(-0500)] <apetro> well, our very own wgthom implemented ClearPass integration for Liferay, did you not?
[13:33:37 CDT(-0500)] <wgthom> i did
[13:33:40 CDT(-0500)] <wgthom> 5.2
[13:33:40 CDT(-0500)] <battags> I think I can kick people out of this chat right...
[13:33:41 CDT(-0500)] <battags> (wink)
[13:33:42 CDT(-0500)] <apetro> any insights for what Java libraries for making use of ClearPass out of that experience?
[13:34:37 CDT(-0500)] <wgthom> https://github.com/wgthom/Cas3Liferay5
[13:38:19 CDT(-0500)] <wgthom> no
[13:38:21 CDT(-0500)] <wgthom> lol
[13:38:34 CDT(-0500)] <wgthom> was just look over the src...been awhile.
[13:38:42 CDT(-0500)] <apetro> tactically, could first pull that up-integration module into uP
[13:38:52 CDT(-0500)] <apetro> that's a fine spot for it. It currently embraces uPortal-specificness
[13:39:00 CDT(-0500)] <apetro> could then revisit from there whether and what is worth factoring out where.
[13:39:39 CDT(-0500)] <serac> I just want to take care here about where we put integration components.
[13:40:19 CDT(-0500)] <serac> We still want to maintain the "lean, mean, machine" reputation of CAS. Code bloat hurts that.
[13:41:35 CDT(-0500)] <apetro> k
[13:41:43 CDT(-0500)] <apetro> supposing we're getting consensus on this
[13:41:47 CDT(-0500)] <battags> well right now we have the lean, mean, machine + a lot of XML
[13:41:48 CDT(-0500)] <battags> (smile)
[13:41:56 CDT(-0500)] <apetro> SVN branch for accomplishing this?
[13:42:09 CDT(-0500)] <apetro> I suggest not 3-4-patches, since this isn't a bugfix
[13:42:23 CDT(-0500)] <apetro> I suggest this is a "new feature" from cas-server perspective, a fine impetus for a 3.5 release.
[13:42:44 CDT(-0500)] <wgthom> agreed could be targeted at 3.5
[13:42:46 CDT(-0500)] <serac> And a good time to clear up that 3.4_maint branch.
[13:42:48 CDT(-0500)] <apetro> That blow our roadmap to heck? But in a good way?
[13:42:57 CDT(-0500)] <serac> Needs cleaning up anyway.
[13:43:14 CDT(-0500)] <battags> it really bothers you guys that much that there is one extra directory?
[13:43:25 CDT(-0500)] <wgthom> yes
[13:43:31 CDT(-0500)] <apetro> bothers a lot, yes
[13:43:54 CDT(-0500)] <wgthom> sloppy....not the kind of thing you like to see in a security product
[13:43:57 CDT(-0500)] <serac> Only a little here. Half is the _maint suffix.
[13:44:03 CDT(-0500)] <serac> (sad)
[13:44:25 CDT(-0500)] <apetro> it's a big poke in the eye to principle of least surprise as regards where to find the maintenance branch, and, quite unintentionally I'm sure, signals lack of value of the maintenance effort.
[13:44:27 CDT(-0500)] <battags> but you expect to see storing passwords in a security product?
[13:44:27 CDT(-0500)] <wgthom> not to mention it's just confusing to potential collaborators
[13:44:42 CDT(-0500)] <battags> but an extra directory is horrendous?
[13:45:09 CDT(-0500)] <serac> Not horrendous, just ugly.
[13:45:24 CDT(-0500)] <wgthom> securely, yes
[13:45:26 CDT(-0500)] <serac> Anyway, we should actually focus on what to do about cas3/4.
[13:45:46 CDT(-0500)] <serac> Then long-lived branches are a non-issue.
[13:46:07 CDT(-0500)] <serac> cas3 is turning out to be a lot longer-lived than anticipated.
[13:46:39 CDT(-0500)] <wgthom> i image cas3 may be a lot longer-lived even than that
[13:46:45 CDT(-0500)] <serac> We should probably discuss moving cas3/trunk code into cas4 asap and simply swapping out trunk with 3.4.x branch.
[13:47:11 CDT(-0500)] <serac> I had a concern about losing repo history in that transition.
[13:47:16 CDT(-0500)] <wgthom> +1
[13:47:36 CDT(-0500)] <serac> Are there any svn hacks anyone knows for transporting history between repos?
[13:47:43 CDT(-0500)] <apetro> repo history preservable via move to a /cas3/branches/cas4trunk
[13:47:54 CDT(-0500)] <apetro> I don't know of hacks, but I expect they must exist.
[13:47:56 CDT(-0500)] <serac> IIRC you dan do this via svnadmin.
[13:47:59 CDT(-0500)] <wgthom> can't we just move current trunk (cas4) into a branch into cas3 repo
[13:48:12 CDT(-0500)] <apetro> indeed
[13:48:16 CDT(-0500)] <serac> Same issue.
[13:48:30 CDT(-0500)] <wgthom> how so?
[13:48:39 CDT(-0500)] <apetro> serac , I don't get it. How does copy to a branch have any issue wrt preserving history?
[13:48:51 CDT(-0500)] <serac> Oh, misunderstood.
[13:49:07 CDT(-0500)] <serac> svn cp cas3/trunk cas3/branches/cas4 – gotcha
[13:49:10 CDT(-0500)] <wgthom> yeah, keep in the cas3 repo...just move it (cas4) out of trunk
[13:49:16 CDT(-0500)] <wgthom> yep
[13:49:18 CDT(-0500)] <apetro> However, does this merely delay dealing with the /cas3 name? I s it going to be okay for CAS 4 to eventually be in a repo named /cas3 ?
[13:49:36 CDT(-0500)] <serac> I'd agree you're just delaying the inevitable.
[13:49:38 CDT(-0500)] <wgthom> yes, delays...but in a good way
[13:49:46 CDT(-0500)] <serac> If the repo is cas, then it's a non-issue.
[13:49:47 CDT(-0500)] <apetro> Would hate to wait to accumulate more and better history, and then lose all that too (smile)
[13:49:51 CDT(-0500)] <serac> But it's not.
[13:50:02 CDT(-0500)] <wgthom> aprtro...good point
[13:50:07 CDT(-0500)] <serac> +1
[13:50:19 CDT(-0500)] <serac> That is exactly why we should act on this asap.
[13:50:21 CDT(-0500)] <apetro> I value the present history very little
[13:50:26 CDT(-0500)] <serac> World keeps on moving.
[13:50:32 CDT(-0500)] <apetro> the history becomes much, much more important to me from the first GA release forward
[13:50:56 CDT(-0500)] <serac> It's value is a function of closeness to 1.0 version.
[13:51:03 CDT(-0500)] <serac> 4.0 in this case
[13:51:33 CDT(-0500)] <wgthom> keep current history in cas3 repo in /branches/cas4
[13:51:44 CDT(-0500)] <wgthom> start fresh cas repo for cas4 going forward
[13:51:52 CDT(-0500)] <apetro> since it's less valuable now than it will ever be in the future, now's the right time to incur the loss of history?
[13:52:06 CDT(-0500)] <serac> If, in fact, it's necessary.
[13:52:10 CDT(-0500)] <battags> can we just put CAS4 on GitHub? (smile)
[13:52:15 CDT(-0500)] <serac> Haha.
[13:52:20 CDT(-0500)] <wgthom> no loss of history...just harder to get at
[13:52:27 CDT(-0500)] <wgthom> +1 for github
[13:52:32 CDT(-0500)] <serac> We'd still have the history loss problem.
[13:52:46 CDT(-0500)] <battags> history of CAS4 is relatively useless
[13:52:55 CDT(-0500)] <battags> at this point
[13:53:00 CDT(-0500)] <serac> Agreed.
[13:53:02 CDT(-0500)] <battags> in general its useful
[13:53:03 CDT(-0500)] <battags> (smile)
[13:53:23 CDT(-0500)] <wgthom> cas4 trunk is just battags scratch at this point?
[13:53:38 CDT(-0500)] <battags> so the history behind that
[13:53:40 CDT(-0500)] <serac> I'd call it more than scratch.
[13:53:55 CDT(-0500)] <battags> originally we started in CAS4 because it was rather disruptive
[13:53:57 CDT(-0500)] <serac> But it's mostly a sandbox.
[13:54:08 CDT(-0500)] <battags> then we moved to cas3 when we though we were doing 3.5 - 3.9 releases
[13:54:14 CDT(-0500)] <battags> most stuff has been migrated to cas3
[13:54:15 CDT(-0500)] <serac> (is a sandbox scratch space – guess so)
[13:54:28 CDT(-0500)] <battags> cas4 exists at this point in case there's some major insight we neglected to migrate
[13:54:49 CDT(-0500)] <apetro> preserving the history of the history? (smile)
[13:55:02 CDT(-0500)] <serac> Only you would know if we missed something.
[13:55:22 CDT(-0500)] <serac> Proposal time:
[13:55:23 CDT(-0500)] <apetro> Oh, I assure you, I won't know.
[13:55:35 CDT(-0500)] <serac> meant that for battags (wink)
[13:55:45 CDT(-0500)] <serac> move cas3/trunk to cas4/trunk asap
[13:56:00 CDT(-0500)] <serac> cp cas3/branches/3.4.x branch to cas3/trunk
[13:56:08 CDT(-0500)] <serac> Proceed as usual.
[13:56:13 CDT(-0500)] <battags> if we're moving cas3 to cas4 can we seriously host it on GitHub
[13:56:32 CDT(-0500)] <battags> and then copy the 3.4.x branch to cas3/trunk
[13:56:38 CDT(-0500)] <wgthom> sounds good to me
[13:56:43 CDT(-0500)] <apetro> I'm +1 for github.
[13:56:43 CDT(-0500)] <battags> or does anyone have strong feelings on keeping it in SVN
[13:57:04 CDT(-0500)] <apetro> I don't particularly value the history, so if github turns out to be some disaster, it can be migrated back into Jasig SVN (smile)
[13:57:07 CDT(-0500)] <serac> I have strong feelings that I need to fully evaluate my dev tools for Git support.
[13:57:16 CDT(-0500)] <serac> Before I'd be comfortable +1.
[13:57:22 CDT(-0500)] <battags> IntelliJ has pretty good support
[13:57:30 CDT(-0500)] <battags> don't know off the top of my head about Eclipse
[13:57:57 CDT(-0500)] <apetro> I'd say working out more confidently that github is working should be a BLOCKER on an actual CAS 4 GA release from the github hosted code
[13:58:05 CDT(-0500)] <apetro> as in, we're doing something that feels a little weird
[13:58:34 CDT(-0500)] <apetro> but it's not a lot weird. Sakai is doing it. Jasig should probably be doing it. These seems like a totally reasonable way to explore it on the most radical thing we're doing in CAS.
[13:59:01 CDT(-0500)] <serac> That's a strategically fine point.
[13:59:37 CDT(-0500)] <apetro> Yeah. I'm +1 for github with the commitment to work that stuff out. Politics shouldn't block doing the technically compelling thing.
[13:59:37 CDT(-0500)] <battags> it sounds good to me
[13:59:40 CDT(-0500)] <serac> But without having ever done serious dev against git, I can't say that's a good practical way to do.
[13:59:59 CDT(-0500)] <battags> Marvin, you've committed Inspektr patches (wink)
[14:00:00 CDT(-0500)] <battags> err contributed
[14:00:23 CDT(-0500)] <apetro> uPortal is also at least loosely vaguely exploring git
[14:00:26 CDT(-0500)] <serac> That's a far cry from doing regular dev on a biggish codebase.
[14:00:38 CDT(-0500)] <serac> Eclipse is my tool, for better or worse.
[14:01:01 CDT(-0500)] <apetro> I'm taking up a collection at next Jasig conference to get you an IntelliJ license
[14:01:11 CDT(-0500)] <wgthom> free for open source work!
[14:01:24 CDT(-0500)] <serac> Dude, Scott sent me the license for the opensource.
[14:01:31 CDT(-0500)] <battags> the license expired
[14:01:32 CDT(-0500)] <apetro> indeed. Free as in cheapness but not free as in freedom unfortunately.
[14:01:34 CDT(-0500)] <serac> version
[14:01:35 CDT(-0500)] <serac> haha
[14:01:35 CDT(-0500)] <battags> we need to get a new one
[14:01:52 CDT(-0500)] <serac> I downloaded the trial version and decided pretty quickly, I don't have time to learn another IDE.
[14:01:53 CDT(-0500)] <apetro> this was productive
[14:01:58 CDT(-0500)] <serac> I'd rather write code.
[14:02:03 CDT(-0500)] <apetro> battags, do you own executing on these source repo tasks?
[14:02:22 CDT(-0500)] <serac> Hold on a sec.
[14:02:36 CDT(-0500)] <serac> So we're moving cas4 to github?
[14:02:47 CDT(-0500)] <battags> we should probably make sure we don't raise major alarms on dev list
[14:02:59 CDT(-0500)] <serac> We should absolutely do that first, yes.
[14:03:24 CDT(-0500)] <battags> in parallel I can look into how one migrates
[14:03:45 CDT(-0500)] <apetro> alright
[14:03:56 CDT(-0500)] <battags> though first I have a bunch of bugs to fix tonight
[14:03:58 CDT(-0500)] <apetro> how are roadmap docos coming?
[14:04:05 CDT(-0500)] <battags> someone named apetro keeps opening new improvements (wink)
[14:04:13 CDT(-0500)] <apetro> I think there's a CASST JIRA to clean roadmapness up
[14:04:23 CDT(-0500)] <apetro> but specifically, need to update that with a CAS 3.5 entry
[14:04:24 CDT(-0500)] <serac> Yes.
[14:04:27 CDT(-0500)] <apetro> major feature is shipping ClearPass
[14:04:28 CDT(-0500)] <serac> Haven't started it yet.
[14:04:49 CDT(-0500)] <apetro> maybe we can make a very short list of other changes/fixes and start marching towards cutting that?
[14:04:58 CDT(-0500)] <serac> Let's treat the roadmap on the CAS space as the authoritative document.
[14:05:12 CDT(-0500)] <apetro> it's a highlander thing. There must only be one.
[14:05:18 CDT(-0500)] <serac> Indeed.
[14:05:37 CDT(-0500)] <battags> wait we all +1 on actually putting ClearPass in CAS 3.5?
[14:05:52 CDT(-0500)] <battags> I thought it was a if we did it how would it work
[14:06:03 CDT(-0500)] <apetro> I'm thinking ClearPass, the ServicesRegistry UI mods I'm sitting on supposing everyone likes them (you will)
[14:06:18 CDT(-0500)] <apetro> okay. Now that we know how we'd do it if we were to do it
[14:06:26 CDT(-0500)] <apetro> Shall we do it? I say yes. (smile)
[14:06:35 CDT(-0500)] <wgthom> +1
[14:06:49 CDT(-0500)] <battags> I'm -.9 or whatever it is
[14:06:57 CDT(-0500)] <battags> that says I don't really like this but I won't throw a hissy fit
[14:07:12 CDT(-0500)] <serac> Man, this is a tough vote.
[14:07:28 CDT(-0500)] <serac> -1 for increasing the codebase
[14:07:35 CDT(-0500)] <serac> +1 for simplifying deployment
[14:07:39 CDT(-0500)] <battags> any change we can explore using autowiring to remove the webapp?
[14:07:46 CDT(-0500)] <battags> before deciding on whether we need to merge the module in?
[14:07:57 CDT(-0500)] <battags> Marvin, its actually not that much code surprisingly
[14:08:07 CDT(-0500)] <battags> though you are right it is more code
[14:08:19 CDT(-0500)] <battags> that should read "any chance"
[14:08:41 CDT(-0500)] <apetro> refactoring seems entirely appropriate in a part-of-cas-3.5-release
[14:08:53 CDT(-0500)] <apetro> that's what X.Y releases are for, after all. (smile)
[14:10:08 CDT(-0500)] <battags> also I am concerned about support for ClearPass once its in the server
[14:10:09 CDT(-0500)] <serac> +1 for exploring this integration and see what shakes out
[14:10:22 CDT(-0500)] <battags> right now ClearPass is essentially "owned" by Cooperative Support
[14:10:39 CDT(-0500)] <wgthom> already is
[14:11:10 CDT(-0500)] <battags> so pretty much all Clearpass related work is sponsored by Unicon
[14:11:12 CDT(-0500)] <battags> which is awesome
[14:11:15 CDT(-0500)] <battags> and I'm not complaining
[14:11:25 CDT(-0500)] <battags> but CAS Server is sometimes sponsored by Cooperative Support
[14:11:26 CDT(-0500)] <battags> and sometimes not
[14:11:35 CDT(-0500)] <apetro> Unicon's been a decent citizen as regards supporting this component, not least by engaging your services. I think we can expect that support to continue.
[14:11:36 CDT(-0500)] <wgthom> what I meant is that moving it doesn't change much in terms of support
[14:11:53 CDT(-0500)] <serac> Sounds right.
[14:12:17 CDT(-0500)] <serac> Except for cases where increased integration causes additional headaches for cas-server.
[14:12:28 CDT(-0500)] <wgthom> except maybe it makes it better because it's not easier to deal with
[14:12:31 CDT(-0500)] <serac> That is purely hypothetical I must admit.
[14:12:38 CDT(-0500)] <battags> but now a CAS server release will include a module supported mostly by Cooperative Support
[14:12:43 CDT(-0500)] <battags> but the server release itself might not be
[14:12:47 CDT(-0500)] <apetro> moving it doesn't change anything in terms of support, except I do hope it makes our lives less complicated in fewer things to version.
[14:12:51 CDT(-0500)] <wgthom> meant easier to deal with...
[14:13:26 CDT(-0500)] <apetro> eh. I'm not buying the concern. cas-server currently ships with some cruft not supported by anybody. Which should be deprecated and removed.
[14:13:41 CDT(-0500)] <serac> No argument there.
[14:13:42 CDT(-0500)] <apetro> and the stuff that's being well-supported and lovingly maintained should be pulled in. That's what this is all about, as I see it.
[14:14:03 CDT(-0500)] <battags> I'm not debating whether cruft should be removed
[14:14:21 CDT(-0500)] <serac> apetro's point is valid
[14:15:18 CDT(-0500)] <apetro> it's certainly a concern ongoingly, as much as it's a concern for any other contribution to cas-server
[14:15:49 CDT(-0500)] <apetro> Unicon could hypothetically Go Evil or at least Go Apathetic and the feature becomes abandonware.
[14:15:59 CDT(-0500)] <apetro> I think there's much less concern about that in the specifics here.
[14:16:11 CDT(-0500)] <battags> I'm not saying you guys will go evil
[14:16:18 CDT(-0500)] <apetro> it's adopted enough that others would step up; others in essence have already stepped up, choosing to route that stepping through Unicon
[14:16:32 CDT(-0500)] <battags> stepped up the same way we have SPNEGO sponsors?
[14:17:02 CDT(-0500)] <apetro> but hey, if all support for this dries up, then it goes on the list of stuff that's abandonware cruft that needs dropped.
[14:17:11 CDT(-0500)] <apetro> not sure how to read the SPNEGO mention
[14:17:30 CDT(-0500)] <apetro> SPNEGO support in CAS is a mess and if Unicon's got any blame for that, shame on us.
[14:17:39 CDT(-0500)] <battags> no it was a blame on Unicon
[14:17:49 CDT(-0500)] <battags> it was a comment on if people adopt it they'll support it
[14:17:57 CDT(-0500)] <apetro> yeah
[14:18:09 CDT(-0500)] <battags> we've got people who depend on SPNEGO but no one has stepped up to maintain it
[14:18:14 CDT(-0500)] <apetro> we're off on a tangent that I'm not sure I want permanently archived
[14:18:31 CDT(-0500)] <serac> We really need to get serious about dropping support for stuff that's not used, and possibly stuff we can't reasonably support.
[14:18:39 CDT(-0500)] <battags> sorry that was supposed to read wasn't a blame on Unicon
[14:18:40 CDT(-0500)] <apetro> but yes, that SPNEGO module is in the set of stuff Unicon will support through our support offering, and no, contrastingly to ClearPass, our subscribers haven't driven investment in making that better.
[14:18:44 CDT(-0500)] <battags> my keyboard sucks
[14:19:09 CDT(-0500)] <serac> What module are we dropping as we bring CP in?
[14:19:22 CDT(-0500)] <serac> I'd be psyched for a zero net change.
[14:19:26 CDT(-0500)] <apetro> BerkelyDB? SNPEGO?
[14:19:35 CDT(-0500)] <serac> BDB +1
[14:19:46 CDT(-0500)] <battags> @apetro apologies some letter's got dropped in my comment and didn't realize it (to be clear: there was no blame on Unicon)
[14:19:55 CDT(-0500)] <battags> we were supposed to drop BerkeleyDB
[14:20:01 CDT(-0500)] <serac> Then let's do it.
[14:20:06 CDT(-0500)] <battags> it was contributed by Sony
[14:20:13 CDT(-0500)] <wgthom> any module that doesn't have a recognized maintainer should be free game to move to contrib
[14:20:13 CDT(-0500)] <serac> We should also issue a call to support SPNEGO.
[14:20:26 CDT(-0500)] <serac> If no one answers, consider seriously dropping it.
[14:20:32 CDT(-0500)] <apetro> battags , that's fine. Hey, I'll accept some blame. It would be better to better maintain all this stuff. But I think we've got a demonstrated success momentum on ClearPass that justifies running with that module.
[14:20:52 CDT(-0500)] <serac> I don't think anyone's arguing otherwise.
[14:20:58 CDT(-0500)] <serac> It's adopted and supported.
[14:21:04 CDT(-0500)] <serac> And suitable for inclusion.
[14:21:04 CDT(-0500)] <battags> my concern with SPNEGO
[14:21:11 CDT(-0500)] <battags> is it a compelling feature
[14:21:21 CDT(-0500)] <serac> And lots of folks appear to be using it.
[14:21:25 CDT(-0500)] <battags> one that people actually seem to choose CAS for in some instances
[14:21:28 CDT(-0500)] <battags> and its got no support
[14:21:35 CDT(-0500)] <battags> I'm just as likely to break something
[14:21:36 CDT(-0500)] <serac> So someone should step up ans support it.
[14:21:39 CDT(-0500)] <battags> as I am to fix it
[14:21:48 CDT(-0500)] <battags> and if they don't we lose a compelling feature
[14:22:33 CDT(-0500)] <serac> There's no harm issuing a call to support with a threaten to drop.
[14:22:44 CDT(-0500)] <serac> We can always decide not to drop later.
[14:22:55 CDT(-0500)] <serac> But let's get serious about having adequate support.
[14:23:06 CDT(-0500)] <serac> There are SPNEGO folks out there.
[14:23:13 CDT(-0500)] <serac> Maybe approach them directly?
[14:23:25 CDT(-0500)] <battags> its worth a try
[14:23:29 CDT(-0500)] <battags> though we have done it in the past
[14:23:59 CDT(-0500)] <serac> Have we approached Pavel Tavoda?
[14:24:20 CDT(-0500)] <battags> my track record with volunteers stepping up other than who we've got now makes me fear bringing more things into the code base that Marvin and I don't really feel passionate about
[14:24:31 CDT(-0500)] <battags> Pavel?
[14:24:44 CDT(-0500)] <serac> That dude has answered a lot of SPNEGO questions.
[14:24:54 CDT(-0500)] <battags> let's get him then
[14:25:00 CDT(-0500)] <battags> restore my faith in humanity
[14:25:07 CDT(-0500)] <battags> (smile)
[14:25:08 CDT(-0500)] <serac> hahah
[14:25:27 CDT(-0500)] <serac> I'll contact him cc casst if it goes anywhere.
[14:26:12 CDT(-0500)] <battags> did we ever post the "maintainer" list that we came up with from the meet up?
[14:26:23 CDT(-0500)] <battags> I think you did, Andrew?
[14:26:32 CDT(-0500)] <apetro> I forget, but whatever I had, I posted.
[14:26:32 CDT(-0500)] <wgthom> when is the summer nyc meetup?
[14:26:47 CDT(-0500)] <serac> Late July or early Aug.
[14:27:02 CDT(-0500)] <serac> If I have any say, that is.
[14:27:12 CDT(-0500)] <battags> I think we should pull that list somewhere useful
[14:27:16 CDT(-0500)] <serac> Developer Summit/NYC Meetup #2.
[14:27:19 CDT(-0500)] <battags> i.e. into the CAs documentation?
[14:27:19 CDT(-0500)] <wgthom> works for me
[14:27:35 CDT(-0500)] <serac> I'm willing to drive to NYC, but someone please have mercy on me and put me up.
[14:27:41 CDT(-0500)] <serac> I'll be coming on my own nickel.
[14:28:09 CDT(-0500)] <battags> we just moved in so I can't promise a guest room will be ready
[14:28:10 CDT(-0500)] <wgthom> always room in Phillipsburg.
[14:28:14 CDT(-0500)] <battags> but if it is you can come lol
[14:28:28 CDT(-0500)] <serac> I can sleep on the basement on the floor.
[14:28:32 CDT(-0500)] <serac> I like camping (wink)
[14:29:29 CDT(-0500)] <serac> We should get serious about the NYC thing, tho, soon.
[14:30:01 CDT(-0500)] <serac> I'm hopeful it's where CAS4 gets in M1 or M2 state.
[14:30:22 CDT(-0500)] <apetro> yeah
[14:30:37 CDT(-0500)] <apetro> maybe beyond the previous meetup concept, we need to be scheduling into this some collab time
[14:30:57 CDT(-0500)] <serac> Yeah, I'm picturing a different format.
[14:31:25 CDT(-0500)] <serac> The Shib guys did this for the 2.0 IdP, called it Developer Summit, so I'm just stealing their lingo.
[14:31:41 CDT(-0500)] <battags> I think it should just be focused on development/documentation
[14:31:54 CDT(-0500)] <serac> +1
[14:32:43 CDT(-0500)] <serac> We should brainstorm further on next casst call.
[14:33:10 CDT(-0500)] <serac> We never finished repo move tasks.
[14:33:33 CDT(-0500)] <serac> 1. move cas 3.4.x branch to trunk
[14:33:49 CDT(-0500)] <serac> 2. move cas3/trunk to github
[14:33:59 CDT(-0500)] <battags> you probably want to reverse that order (smile)
[14:34:10 CDT(-0500)] <serac> Realized that after wrote #1 (wink)
[14:34:35 CDT(-0500)] <serac> I'm +1 on both provided I can bitch later if I can't get my dev tools to place nicely with git.
[14:34:39 CDT(-0500)] <serac> (but it's doubtful)
[14:36:11 CDT(-0500)] <serac> apetro, wgthom ?
[14:37:50 CDT(-0500)] <battags> can we proxy them?
[14:37:52 CDT(-0500)] <battags> (smile)
[14:38:18 CDT(-0500)] <serac> I think they already gave a +1 but want to be clear what we're voting for.
[14:44:22 CDT(-0500)] <apetro> wandered off to deal with local issues. What's up?
[14:44:31 CDT(-0500)] <serac> Voting on repo moves.
[14:44:36 CDT(-0500)] <serac> ^^^^
[14:45:11 CDT(-0500)] <apetro> ah
[14:45:35 CDT(-0500)] <apetro> +1 on moving cas3/trunk to github (preferably) or to anywhere else in Jasig SVN as fallback
[14:45:50 CDT(-0500)] <apetro> +1 on then moving cas 3.4 maintenance branch into trunk as cas3 trunk marching towards 3.5
[14:46:25 CDT(-0500)] <serac> Sounds good battags?
[14:46:40 CDT(-0500)] <apetro> would prefer that github risk not delay these activities too long – if we're entering weeks of discussion of merits of git, let's move current cas3/trunk out of way to a branch first to unblock cas3/trunk for march towards cas3.5
[14:47:02 CDT(-0500)] <serac> Shouldn't take long.
[14:47:21 CDT(-0500)] <apetro> and +1 on serac camping on basement floors
[14:47:31 CDT(-0500)] <apetro> I understand such adversity is good for capacity to cope with SAML
[14:47:33 CDT(-0500)] <apetro> so I hear.
[14:48:05 CDT(-0500)] <serac> Indeed.
[14:52:28 CDT(-0500)] <serac> I think we've got consensus on this.
[14:52:55 CDT(-0500)] <serac> I'm going to post the plan to cas-dev for feedback, but I expect we'll move forward and assign tasks out of the list thread.