jasig-cas IRC Logs-2011-09-09

Owned by Apereo Infrastructure
Last updated: Sept 09, 2011Version comment
14 min read

[12:56:20 CDT(-0500)] * Ozy_work2 stretches
[12:57:25 CDT(-0500)] <wgthom> sup ozy
[12:58:12 CDT(-0500)] <Ozy_work2> not too much, you?
[12:58:35 CDT(-0500)] <wgthom> hacking away at a cas deployment
[12:59:02 CDT(-0500)] <apetro> checking in
[12:59:28 CDT(-0500)] <serac> howdy
[12:59:30 CDT(-0500)] <wgthom> gettin' in tune
[12:59:38 CDT(-0500)] <Ozy_work2> i wish I was hacking at cas. I'm stuck hacking at things to make time for cas
[13:00:08 CDT(-0500)] <battags> you all checked in a minute early :-p
[13:00:20 CDT(-0500)] <jfritschi> hi everyone
[13:00:34 CDT(-0500)] <wgthom> howdy, jf
[13:01:15 CDT(-0500)] <serac> hi joachim
[13:01:33 CDT(-0500)] <battags> @serac and @jfritschi I set up the cas and phpCAS repositories on GitHub that you will need
[13:01:36 CDT(-0500)] <serac> hey battags
[13:01:41 CDT(-0500)] <battags> hey
[13:01:44 CDT(-0500)] <serac> Thanks.
[13:01:46 CDT(-0500)] <jfritschi> thanks
[13:01:53 CDT(-0500)] <serac> I almost did it yesterday, then hesitated.
[13:02:05 CDT(-0500)] <serac> I was like, "What if someone commits something in there."
[13:02:08 CDT(-0500)] <serac> Stupid, I know.
[13:02:17 CDT(-0500)] <jfritschi> i will wait until the server is over there
[13:02:24 CDT(-0500)] <apetro> agenda bash? github? what else?
[13:02:40 CDT(-0500)] <wgthom> roadmap comes to mind
[13:02:59 CDT(-0500)] <battags> we need to combine the roadmaps
[13:03:00 CDT(-0500)] <serac> I plan on sending GH migration plan to infrastructure. It occurred to me they may not want to help out Sun PM.
[13:03:05 CDT(-0500)] <serac> May update plan accordingly.
[13:03:13 CDT(-0500)] <battags> they probably won't want to help (smile)
[13:03:20 CDT(-0500)] <serac> (wink)
[13:03:20 CDT(-0500)] <apetro> documentation, status of DocBook and partial progress of experimenting with Markdown as alternative.
[13:03:39 CDT(-0500)] <battags> curious as to what Markdown is so yes add that to the agenda
[13:03:41 CDT(-0500)] <serac> You can hate on me for the roadmap stuff.
[13:03:51 CDT(-0500)] <serac> I haven't done what I said I'd do (sad)
[13:04:14 CDT(-0500)] <wgthom> more concerned that we'll on the same page re approach process etc
[13:04:38 CDT(-0500)] <apetro> github, roadmap, cas server manual, what else?
[13:04:47 CDT(-0500)] <battags> that's probably enough
[13:04:56 CDT(-0500)] <battags> we do only have 56 minutes now (wink)
[13:04:56 CDT(-0500)] <wgthom> lppe update
[13:05:23 CDT(-0500)] <apetro> github, roadmap, cas server manual, and lppe. (smile) anything else?
[13:05:51 CDT(-0500)] <battags> versioning (wink)
[13:05:56 CDT(-0500)] <battags> that might fall under roadmap
[13:06:01 CDT(-0500)] <serac> Not like we can't add items as needed.
[13:06:07 CDT(-0500)] <serac> Let's keep this fast and loose.
[13:06:15 CDT(-0500)] <apetro> let's call it an agenda: github, roadmap, manual, lpppe, and misc. and: Go github discussion!
[13:06:22 CDT(-0500)] <serac> haha
[13:06:39 CDT(-0500)] <serac> I've said everything I need to I think.
[13:06:48 CDT(-0500)] <serac> We have a plan that hinges on help from infrastructure.
[13:06:49 CDT(-0500)] <battags> @serac did you see my comment re: maven plugin ?
[13:06:57 CDT(-0500)] <battags> what help do you need from infrastructure?
[13:06:59 CDT(-0500)] <serac> On the wiki? Nope.
[13:07:03 CDT(-0500)] <battags> I have pretty much full access
[13:07:05 CDT(-0500)] <serac> On that thread yesterday, yeah.
[13:07:21 CDT(-0500)] <battags> does our naming convention conform to maven plugin?
[13:07:24 CDT(-0500)] <serac> Great, if you can do what we need it'll be golden.
[13:07:34 CDT(-0500)] <battags> its mostly making things read only, etc.?
[13:07:39 CDT(-0500)] <serac> Correct.
[13:07:43 CDT(-0500)] <serac> Re versioning....
[13:07:53 CDT(-0500)] <serac> It does not conform. The "Git convention" is vM.N.P.
[13:08:01 CDT(-0500)] <battags> what is the maven plugin convention for Git?
[13:08:15 CDT(-0500)] <serac> I'll need to research.
[13:08:31 CDT(-0500)] <serac> I didn't get the problem yesterday, but I'm clear now. Sry I'm dense.
[13:08:41 CDT(-0500)] <serac> Thanks for pointing that out.
[13:08:45 CDT(-0500)] <battags> no worries. Maven release auto generates names
[13:08:47 CDT(-0500)] <battags> not sure if we can override
[13:08:50 CDT(-0500)] <battags> I'll check
[13:08:52 CDT(-0500)] <serac> Exactly.
[13:10:36 CDT(-0500)] <battags> not sure if this will help us: http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#tag
[13:10:41 CDT(-0500)] <battags> we might just need to try it in a fake repo
[13:10:59 CDT(-0500)] <serac> I have a cas repo for testing things like this.
[13:11:09 CDT(-0500)] <serac> Anyway, we can test it.
[13:11:18 CDT(-0500)] <battags> okay we would need to update the scm stuff in the poms
[13:11:22 CDT(-0500)] <battags> and then run the release stuff
[13:11:49 CDT(-0500)] <serac> I can do that this afternoon, evening. I'm hopeful we can solve this problem one way or other.
[13:11:57 CDT(-0500)] <serac> tag property looks promising
[13:12:46 CDT(-0500)] <serac> I think that's enough about GH.
[13:12:48 CDT(-0500)] <serac> Next item?
[13:12:56 CDT(-0500)] <apetro> Roadmap! Go!
[13:13:03 CDT(-0500)] <battags> wait hold on one sec
[13:13:16 CDT(-0500)] <battags> @serac I might not be available exactly at 2100 on Sunday
[13:13:23 CDT(-0500)] <battags> do you want me to make it read only earlier in the day?
[13:13:36 CDT(-0500)] <serac> Only if we agree here that it's no big deal.
[13:13:43 CDT(-0500)] <serac> I didn't want to disrupt anyone.
[13:13:51 CDT(-0500)] <battags> anyone offended if they can't work over the weekend? (wink)
[13:13:55 CDT(-0500)] <serac> haha
[13:14:15 CDT(-0500)] <wgthom> 24 hr window is fine by me.
[13:14:21 CDT(-0500)] <battags> we should all be updating the roadmap anyway
[13:14:24 CDT(-0500)] <battags> :-p
[13:14:34 CDT(-0500)] <serac> dig
[13:14:34 CDT(-0500)] <battags> forcing a transition (wink)
[13:14:39 CDT(-0500)] <serac> Indeed.
[13:14:51 CDT(-0500)] <serac> I'm trying to take a practical approach with the roadmap.
[13:15:22 CDT(-0500)] <battags> well so with roadmap I want to discuss versioning
[13:15:28 CDT(-0500)] <battags> Bill copied in our traditional policy
[13:15:30 CDT(-0500)] <serac> Port over things from https://wiki.jasig.org/pages/viewpage.action?pageId=28574039 onto https://wiki.jasig.org/display/CAS/CAS+Roadmap that I'm willing to work on.
[13:15:36 CDT(-0500)] <battags> which was what uPortal did
[13:15:46 CDT(-0500)] <battags> @serac I thought we were willing to work on everything (wink)
[13:16:04 CDT(-0500)] <battags> I forgot migrate to Scala though
[13:16:17 CDT(-0500)] <serac> We are (smile) Seriously, though, I was trying to be uber-polite and only speak for myself.
[13:16:26 CDT(-0500)] <serac> I expected you to follow suite.
[13:16:27 CDT(-0500)] <serac> suit
[13:16:38 CDT(-0500)] <battags> I will copy everything over that Marvin doesn't (wink)
[13:16:39 CDT(-0500)] <serac> Except that I've been a dud and haven't done anything in like 10 days.
[13:16:43 CDT(-0500)] <serac> haha
[13:17:00 CDT(-0500)] <apetro> willingness and positive, open attitude are great, but in seriousness, there's value in the distinction between wishlist and near-term concrete executable efforts.
[13:17:01 CDT(-0500)] <battags> we should also look at the OAuth stuff
[13:17:10 CDT(-0500)] <battags> we have committed to these things
[13:17:18 CDT(-0500)] <battags> we have implemented a number of them
[13:17:22 CDT(-0500)] <battags> in the CAS4 branch
[13:17:32 CDT(-0500)] <battags> we are trying to get them out
[13:17:32 CDT(-0500)] <battags> this is not a wishlist
[13:17:38 CDT(-0500)] <battags> this is stuff I have been working on
[13:17:40 CDT(-0500)] <serac> +1
[13:17:49 CDT(-0500)] <battags> and Marvin also
[13:17:56 CDT(-0500)] <serac> I think a roadmap also balances practical, executable next steps and long-term vision.
[13:17:58 CDT(-0500)] <battags> I was being polite there and not associating him with any crap (wink)
[13:18:09 CDT(-0500)] <serac> So in my mind there is room for both immediate and hazy future.
[13:18:16 CDT(-0500)] <battags> our 3.5, 3.6 should be pretty specific
[13:18:23 CDT(-0500)] <battags> our 3.7 and beyond less so
[13:18:28 CDT(-0500)] <serac> I would agree with that.
[13:18:36 CDT(-0500)] <battags> depending on how we version things
[13:18:44 CDT(-0500)] <battags> I made up version numbers
[13:18:58 CDT(-0500)] <serac> I'm ok with fuzzy version numbers.
[13:19:10 CDT(-0500)] <serac> Is there consensus on that point?
[13:19:27 CDT(-0500)] <apetro> depends on what is meant by fuzzy version numbers
[13:19:29 CDT(-0500)] <serac> i.e. doesn't matter if JMX management/monitoring make 3.5 or 3.6.
[13:19:41 CDT(-0500)] <serac> Put it for 3.5, push to 3.6 if needed.
[13:19:52 CDT(-0500)] <jfritschi> i personally don't like that saml 2.0 is so far away :/
[13:20:08 CDT(-0500)] <serac> I honestly think it's one of the most important features.
[13:20:14 CDT(-0500)] <serac> And deserves more time/effort.
[13:20:23 CDT(-0500)] <battags> I also meant we should also pick numbers that allow us to release what we need to release
[13:20:40 CDT(-0500)] <serac> I can respect that.
[13:20:42 CDT(-0500)] <battags> if putting in an API change breaks our uPortal numbering convention then we call the next version 4.0
[13:20:47 CDT(-0500)] <apetro> the predictions out into the future are fuzzy? Sure, agreed. JMX comes in when it comes in, never if no one does it.
[13:20:49 CDT(-0500)] <serac> My solution is simply to change the number.
[13:20:50 CDT(-0500)] <battags> we become Firefox
[13:20:57 CDT(-0500)] <apetro> right. that is where I get uncomfortable fast.
[13:21:10 CDT(-0500)] <battags> releasing APIs is uncomfortable?
[13:21:12 CDT(-0500)] <serac> On changing numbering scheme?
[13:21:14 CDT(-0500)] <battags> or the version numbers?
[13:22:03 CDT(-0500)] <apetro> if it's a 4.0 release, one that changes APIs, the benefit needs to justify that revolution.
[13:22:16 CDT(-0500)] <apetro> otherwise I value the constrained terms of engagement in the meaning behind a 3.5 label.
[13:22:35 CDT(-0500)] <battags> not sure I follow
[13:22:39 CDT(-0500)] <battags> are you saying we don't make API changes
[13:22:44 CDT(-0500)] <battags> because you don't like calling it for 4.0?
[13:22:54 CDT(-0500)] <battags> or that you would want to call it 3.5?
[13:22:55 CDT(-0500)] <battags> (wink)
[13:23:20 CDT(-0500)] <apetro> I'm saying that if enough APIs change that it needs to be called 4.0, then it needs to be worth it.
[13:23:32 CDT(-0500)] <apetro> and otherwise, the change should be less disruptive.
[13:23:41 CDT(-0500)] <battags> worth it from whose perspective?
[13:23:53 CDT(-0500)] <wgthom> "make API changes" is too fuzzy…I think need to be more specific
[13:24:06 CDT(-0500)] <battags> there's a list of API changes in the roadmap
[13:24:20 CDT(-0500)] <wgthom> otherwise it's too hard to makes sense of it terms of the release strategey
[13:24:54 CDT(-0500)] <battags> so my question to you is at what point do you see it as actually being useful to update the APIs?
[13:25:06 CDT(-0500)] <battags> because I see pushback every time we mention it
[13:25:09 CDT(-0500)] <battags> not that pushback is bad
[13:25:14 CDT(-0500)] <battags> I'm just not seeing where you are coming from
[13:25:23 CDT(-0500)] <serac> I want to see the SessionStorage API in 3.6.
[13:25:23 CDT(-0500)] <battags> trying to understand your concern
[13:25:42 CDT(-0500)] <battags> I want to see Session Storage released. With whatever version number gets it out
[13:25:43 CDT(-0500)] <serac> Now we can discuss whether that's a major number change. Is that specific enough?
[13:25:58 CDT(-0500)] <wgthom> yes
[13:26:07 CDT(-0500)] <serac> Whew (wink)
[13:26:18 CDT(-0500)] <battags> haha
[13:26:34 CDT(-0500)] <serac> I am sincerely excited by this API change.
[13:26:48 CDT(-0500)] <serac> It promises to facilitate a solution to the JPA deadlock issue.
[13:26:57 CDT(-0500)] <serac> So it's elegant and pretty and all, and immediately practical as well.
[13:27:03 CDT(-0500)] <wgthom> so what's the impact of SS change, the benefit and how does it square with the release strategy?
[13:27:04 CDT(-0500)] <apetro> Session Storage is a modernization of Ticket Registry?
[13:27:04 CDT(-0500)] <battags> it also fixes certain serialization problems
[13:27:13 CDT(-0500)] <battags> yes
[13:27:41 CDT(-0500)] <serac> And it helps move us away from the CAS protocol specifically in the API.
[13:27:54 CDT(-0500)] <serac> Again, pretty API changes, yet practical. Seems like a win/win to me.
[13:28:47 CDT(-0500)] <serac> Honestly I think everyone who isn't reasonably familiar with CAS4 codebase needs to spend at least a day looking at the -api module.
[13:29:15 CDT(-0500)] <apetro> so the right question here is, what, how much pain is this going to inflict on adopters looking to make an upgrade to a CAS release with this new API
[13:29:21 CDT(-0500)] <serac> I've gotta go for now. Sorry.
[13:29:25 CDT(-0500)] <wgthom> later
[13:30:27 CDT(-0500)] <battags> its potentially configuration changes
[13:30:41 CDT(-0500)] <battags> if you wrote your own ticket registry then there is that also
[13:30:41 CDT(-0500)] <apetro> so, what, folks who implemented the EhCacheTicketRegistry extension or otherwise wrote to the TicketRegistry API need to port forward their custom code
[13:31:25 CDT(-0500)] <apetro> folks who implemented a ships-with-CAS registry have new configuration for an equivalent ships-with-CAS SessionStorage impl?
[13:31:31 CDT(-0500)] <battags> not too many people have written their own registries
[13:32:09 CDT(-0500)] <apetro> not too many, no. Looping in an EhCache implementation of SessionStorage would probably scratch the itch of some portion of folks who did
[13:32:35 CDT(-0500)] <battags> you mean https://source.jasig.org/cas3/trunk/cas-server-sessionstorage-ehcache/
[13:33:30 CDT(-0500)] <apetro> it's a significant, core API, though, that's changing. An API enumerated here http://www.jasig.org/cas/public-api . That a big enough change that we feel like it's revolutionary or something that belongs in a minor 3.5 release?
[13:34:48 CDT(-0500)] <battags> I don't care what version number it is. Whichever one gets the code out
[13:35:07 CDT(-0500)] <jfritschi> i personally would not sweat calling this 3.5 if there is a clear upgrade/migration path
[13:37:33 CDT(-0500)] <wgthom> so if this particular change does square with a 3.5 based on a release strategy, then why not just cut 4.0.
[13:37:45 CDT(-0500)] <wgthom> if it is ready
[13:38:04 CDT(-0500)] <wgthom> ?
[13:38:07 CDT(-0500)] <apetro> wgthom, was that sentence missing a negative?
[13:38:16 CDT(-0500)] <wgthom> yes
[13:38:18 CDT(-0500)] <wgthom> sry
[13:38:30 CDT(-0500)] <battags> can you rephrase with missing word? :-p
[13:39:04 CDT(-0500)] <wgthom> point is…why force fit it into the release strategy? nothing wrong with cutting 4.0 if it is ready...no?
[13:39:43 CDT(-0500)] <battags> we have more API changes than just storage in the trunk at the moment
[13:39:47 CDT(-0500)] <wgthom> the point of the release strategy and following the rules is better communication to the adopting community about the change therein
[13:40:02 CDT(-0500)] <battags> I am aware of the point of a release strategy :-p
[13:40:53 CDT(-0500)] <apetro> I guess it depends on whether beyond communicating the amount of change, there's an implied purpose of controlling the frequency of revolutionary change.
[13:41:26 CDT(-0500)] <apetro> Would such a CAS 4.0 containing this session storage API improvement be soon followed by a CAS 5.0 incorporating another API change, and how okay is that.
[13:41:43 CDT(-0500)] <battags> because version numbers are dead if you ask Firefox or Chrome? (wink)
[13:41:53 CDT(-0500)] * jfritschi spanks battags
[13:41:58 CDT(-0500)] <apetro> but you're helping me to care less about that. All of the value here is in the typical adopter, who will use a ships-with storage implementation, avoiding intractable deadlocks.
[13:43:12 CDT(-0500)] <apetro> eh. I really reject the analogy to consumer software. Chrome's versioning scheme isn't very relevant, and GMail's versioning scheme as a versionless SaaS thing isn't very relevant either. this is still enterprise server-side software which is still versioned and boring.
[13:43:13 CDT(-0500)] <battags> I think it comes down to a few things (a) the changes need to make sense or be transparent, (b) where they aren't transparent they need to have enough impact to necessitate the effort to upgrade and © we need to be better about documentation for upgrading/migrating
[13:43:59 CDT(-0500)] <battags> yes because all enterprise versioning makes sense (cough oracle)
[13:44:31 CDT(-0500)] <apetro> perhaps not, but our enterprise versioning should make a reasonable amount of sense, balancing the trouble it is to make it make sense.
[13:45:10 CDT(-0500)] <battags> I'm more concerned about the value we're bringing with our changes than any version number
[13:45:40 CDT(-0500)] <apetro> is there a writeup anywhere of what about the deadlock problem in TicketRegistry is such that an API change is necessary to make it tractable?
[13:46:03 CDT(-0500)] <battags> there's more to the API than the deadlock problem
[13:46:14 CDT(-0500)] <battags> which is in multiple threads on the user lists
[13:47:47 CDT(-0500)] <apetro> alright. circling back to roadmap.
[13:48:29 CDT(-0500)] <apetro> are we coming around to a vision of a 4.0 release incorporating the Session Storage API and the other items that are coming to be grouped under 3.5 here? https://wiki.jasig.org/display/CAS/CAS+Roadmap
[13:48:39 CDT(-0500)] <apetro> such that there isn't a 3.5 release, there's a 4.0 release with those changes?
[13:49:07 CDT(-0500)] <battags> I am leaning towards that I am not sure if you guys are (wink)
[13:49:45 CDT(-0500)] <apetro> I'd roughly like to see a feature release in or before Q1 2012.
[13:49:58 CDT(-0500)] <apetro> calling it 4.0 to communicate including a SessionStorage API change, cool.
[13:50:06 CDT(-0500)] <apetro> Poaching the best of baked other improvements, cool.
[13:50:23 CDT(-0500)] <apetro> Dragging enough into it that it's delayed out too far, less cool. It's been a while since cas-server had a feature release.
[13:52:47 CDT(-0500)] <apetro> running out of time here
[13:53:17 CDT(-0500)] <battags> not sure I follow. Are you saying CAS hasn't been actively releasing stuff?
[13:53:22 CDT(-0500)] <battags> https://issues.jasig.org/browse/CAS#selectedTab=com.atlassian.jira.plugin.system.project:changelog-panel&amp;allVersions=true
[13:53:52 CDT(-0500)] <apetro> this felt like progress. Articulated value in, nature of Session Storage API change, identified that there's this issue of what to call the release but maybe progress toward a shared vision of a modest feature release this winter.
[13:53:52 CDT(-0500)] <wgthom> hx
[13:54:07 CDT(-0500)] <apetro> When i say feature release, I mean a minor release or a major release.
[13:54:17 CDT(-0500)] <apetro> I don't dispute that patch releases of cas-server have value.
[13:54:42 CDT(-0500)] <apetro> I do assert that the amount of additional features and change in those releases is, appropriately, necessarily, and intentionally, constrained and modest.
[13:55:42 CDT(-0500)] <apetro> five minutes
[13:55:46 CDT(-0500)] <apetro> anyone remember the agenda>?
[13:56:12 CDT(-0500)] <battags> markdown
[13:56:26 CDT(-0500)] <Ozy_work2> let's call it an agenda: github, roadmap, manual, lpppe, and misc. and: Go github discussion!
[13:56:40 CDT(-0500)] <apetro> Go Manual!
[13:57:00 CDT(-0500)] <apetro> great. So, existing wiiki manual is here: https://wiki.jasig.org/display/CASUM/Home
[13:57:23 CDT(-0500)] <apetro> problems: this isn't source control, it's not versioned with source control, it's feasible to fork, but it's no fun to merge.
[13:57:36 CDT(-0500)] <apetro> so then there's exploration of / execution on docbook:
[13:57:54 CDT(-0500)] <apetro> http://www.unicon.net/content/early-progress-new-docbookified-jasig-cas-server-manual
[13:58:12 CDT(-0500)] <apetro> advantages: it's source control! it's formal. standard. rigorous.
[13:58:22 CDT(-0500)] <apetro> plugs into the Maven build, perhaps.
[13:58:48 CDT(-0500)] <apetro> Major disadvantage: It's XML. It's not much fun describing XML, documenting XML, in XML, and documenting CAS is a lot of talking about XML.
[13:59:02 CDT(-0500)] <apetro> major learning curve, tooling notwithstanding.
[13:59:08 CDT(-0500)] <apetro> latest exploration: Markdown
[13:59:23 CDT(-0500)] <apetro> https://github.com/apetro/CAS-Documentation/blob/master/en/01-introduction/01-chapter1.markdown
[14:00:10 CDT(-0500)] <apetro> advantages: it's mostly plaintext. It's mostly easy to read and write. And github has some built-in support. Also, this tends to prove that it can build formal manuals: https://github.com/progit
[14:00:26 CDT(-0500)] <apetro> http://progit.org/book/
[14:01:16 CDT(-0500)] <apetro> so, my intent is to finish porting the partial progress that's in DocBook, over to Markdown, and then see what it looks like, and post to cas-dev getting input
[14:01:43 CDT(-0500)] <battags> seems like you could then basically view documentation by tag in GitHub and have it formatted
[14:01:43 CDT(-0500)] <apetro> so far, my impression is that Markdown is going to be more accessible and happier-making, especially given a move to github anyway.
[14:01:57 CDT(-0500)] <battags> saving us from hosting the HTML somewhere else?
[14:02:09 CDT(-0500)] <battags> though we'd probably have to post PDF or something somewhere
[14:02:31 CDT(-0500)] <apetro> somewhat. Certainly github does its best to format it, and even the raw source text is readable, that's the big philosophy of Markdown
[14:03:04 CDT(-0500)] <apetro> I think for maximum quality we'd still want to build to HTML / PDF / mobi / ePub ala what Pro Git is doing.
[14:03:52 CDT(-0500)] <apetro> I mean, this: http://progit.org/book/ is more pleasant than https://github.com/progit/progit/blob/master/en/05-distributed-git/01-chapter5.markdown
[14:04:03 CDT(-0500)] <battags> slighty more (wink)
[14:04:07 CDT(-0500)] <battags> slightly*
[14:04:19 CDT(-0500)] <apetro> so far the big gotcha I haven't figured out yet is including images.
[14:04:49 CDT(-0500)] <apetro> but progit is doing something weird that pulls the images in at build time. Not sure yet if CAS would emulate that or do something else.
[14:05:10 CDT(-0500)] <battags> how is the maven support for markdown?
[14:05:12 CDT(-0500)] <apetro> I don't think it necessarily solves the documentation hosting problem. I do think it's easier to write and to read the source of the documentation, and that that's importnat.
[14:05:25 CDT(-0500)] <battags> we can host them on the jasig site
[14:05:27 CDT(-0500)] <apetro> but I'll be more able to speak intelligently to it when there's a fairer side-by-side
[14:05:55 CDT(-0500)] <battags> http://code.google.com/p/markdown-doclet/issues/detail?id=6
[14:05:57 CDT(-0500)] <apetro> I know nothing about Maven support. the progit scripts are Ruby and heroic invocations of calibre and Latex etc.
[14:06:32 CDT(-0500)] <battags> wait that might be the wrong markdown
[14:06:39 CDT(-0500)] <apetro> eh. That looks like a tweak to JavaDoc syntax.
[14:06:45 CDT(-0500)] <battags> yeah just realized that
[14:06:50 CDT(-0500)] <apetro> http://code.google.com/p/markdown-doclet/
[14:07:01 CDT(-0500)] <apetro> that would actually be kind of really annoying, using non-standard JavaDoc syntax
[14:07:09 CDT(-0500)] <apetro> there's such a thing as going to far in love for a technology
[14:07:43 CDT(-0500)] <apetro> but here's the big stupid detail here: &lt;beans&gt; is just a whole lot less fun to write and read than is <beans>
[14:08:06 CDT(-0500)] <apetro> that docbook makes us do the former feels like it's going to accumulate a lot of pain.
[14:08:21 CDT(-0500)] <battags> unless we auto wire as much as possible (wink)
[14:10:41 CDT(-0500)] <apetro> maybe. I imagine we're going to need to document changes adopters might need to make to web.xml or somesuch. Documentation that talks about XML still feels unavoidable.
[14:11:28 CDT(-0500)] <apetro> anyway, my next step is to finish proving out Markdown equivalent to what's been proven out with Docbook, and then see and share what that looks like and what folks feel like they want to contribute to and consume.
[14:11:53 CDT(-0500)] <apetro> iterating on the agenda queue: wgthom, want to discuss lppe progress?
[14:13:33 CDT(-0500)] <battags> I have to bounce but I'll watch the wiki node that captures this stuff
[14:13:47 CDT(-0500)] <battags> insert comment about thanks for time (wink)
[14:14:44 CDT(-0500)] * apetro expresses regret that his time is up and thanks others for theirs.
[14:15:54 CDT(-0500)] <Ozy_work2> haha
[14:15:58 CDT(-0500)] <Ozy_work2> thanks all