[00:02:24] *** mbg has quit IRC
[00:04:01] *** aslak has quit IRC
[00:06:55] *** kevinpollet has joined #seam-dev
[00:15:27] <hannelita> lightguard_jp: ping
[00:24:43] *** kevinpollet has quit IRC
[00:25:30] <lightguard_jp> hannelita: I'm here
[00:32:25] <hannelita> lightguard_jp: could I change the import.mysql file into confbuzz for a populateDB class?
[00:32:54] <hannelita> lightguard_jp: I mean, I think it would be easier to make a tutorial explaining all those stuff
[00:33:00] <lightguard_jp> hannelita: What will you be adding? Care to gist / pastie it?
[00:36:28] <hannelita> lightguard_jp: http://pastie.org/2494181
[00:37:37] *** iphands_ has joined #seam-dev
[00:38:25] <lightguard_jp> Yes, I think doing that in the import.sql is a better idea.
[00:38:34] <lightguard_jp> sbryzak: any comment? ^^
[00:39:33] <lightguard_jp> hannelita: Feel free to use my full name: Jason Porter. Fake email is probably the best (even though that's not my redhat email you have listed)
[00:40:13] *** cbrock has quit IRC
[00:40:28] <hannelita> lightguard_jp: All fake example data... hehe
[00:40:42] <sbryzak> just reading the backlog...
[00:40:43] <hannelita> lightguard_jp: so do you prefer the import.sql?
[00:41:03] <sbryzak> ah, apparently the import.sql isn't portable
[00:41:11] <sbryzak> so it's better to have a class that populates the db
[00:41:29] <sbryzak> i actually went through this just last night with seam university
[00:41:34] *** iphands has quit IRC
[00:41:44] <sbryzak> in fact, i think it would be a great feature for seam persistence
[00:41:46] *** iphands__ has joined #seam-dev
[00:41:55] <hannelita> in fact, I think that if we have a class populating db its easier to explain stuff
[00:42:27] <hannelita> for example, ppl might be a little scared woth all those *Identity*.java classes
[00:42:28] <sbryzak> hannelita: agreed, and i think that import.sql is a bit "hidden"
[00:42:35] <sbryzak> a class is out in the open for the developer to see
[00:43:08] <hannelita> and ppl need to understand when and why we have all those Identity*.java classes
[00:43:23] <lightguard_jp> hannelita: If we go with the programming route of seeding the data, we should make use of the action classes in Seam Security.
[00:43:29] <hannelita> so I think a PopulateDB.class is a good way to show them how to use that
[00:43:47] <lightguard_jp> They're "hidden" right now because they're not documented, but it's a much safer and eaiser way to go.
[00:44:26] *** cbrock has joined #seam-dev
[00:44:27] *** iphands_ has quit IRC
[00:45:02] <sbryzak> hannelita: good idea, but i would recommend actually using the picketlink api to populate the default users, roles and groups
[00:45:31] <lightguard_jp> sbryzak: Isn't that what the action classes are designed to do?
[00:45:58] <sbryzak> the action classes are designed as a gateway to interact with the idm api via the user interface
[00:45:59] <lightguard_jp> I fought with things for a few hours last week in an arquillian test until I used the action class, then things worked well.
[00:46:05] *** akazakov_afk is now known as akazakov
[00:46:27] <sbryzak> if you want to create users programamtically, you use the IDM api directly
[00:46:37] *** tsurdilo has quit IRC
[00:47:32] <lightguard_jp> Ah, which the pastie you put up hannelita, is not doing.
[00:47:32] <hannelita> hmmm.... i'll take a look into picketlink api then. Thanks a lot :)
[00:47:40] <lightguard_jp> It's not too terrible to use.
[00:48:07] *** tsurdilo has joined #seam-dev
[00:48:31] <lightguard_jp> Because we're this is using the servlet events we'll have to include the transaction interceptor, looks like you got that though, good.
[00:49:11] <lightguard_jp> @PersistenceContext isn't what we should be using though. We should use the Seam managed version instead.
[00:49:24] <sbryzak> lightguard_jp: i was just about to mention that
[00:49:33] <sbryzak> we can't use the seam managed one, because there's no conversation context
[00:49:46] <lightguard_jp> Yeah, thought about that.
[00:50:06] <lightguard_jp> It's a bit of a problem. Use this way of doing things... unless ...
[00:50:26] <lightguard_jp> Maybe create another producer? Hm, that probably won't work though.
[00:50:28] <hannelita> I think we could create an EMFactory and annotate it with @ConversationScoped
[00:50:28] <lightguard_jp> Snap
[00:50:39] <lightguard_jp> gr
[00:50:52] <lightguard_jp> hannelita: There won't be a conversation started, it'll blow up.
[00:50:58] <lightguard_jp> There won't even be a request.
[00:51:00] <lightguard_jp> or a session.
[00:51:07] <hannelita> hmmm
[00:51:10] <lightguard_jp> The only thing that would be started is @ApplicationScoped
[00:51:14] <lightguard_jp> Which we certainly don't want.
[00:52:16] <hannelita> well... forget about this PopulateDB class then :P
[00:52:17] <lightguard_jp> It may be possible to have a @TransactionScoped EM and add the qualifier to the injection.
[00:52:19] <sbryzak> there's no harm in using @PErsistenceContext
[00:52:36] <lightguard_jp> Have to make the PopuplateDB an EJB though
[00:52:48] <sbryzak> no, i'm doing it in a pojo
[00:52:51] <lightguard_jp> stuartdouglas: can we create a @TransactionScoped EM?
[00:52:53] <sbryzak> using @PersistenceContext
[00:52:55] <lightguard_jp> Oh.
[00:52:58] <sbryzak> and it works just fine
[00:53:06] <lightguard_jp> Interesting, that must have changed in EE6 and I missed it.
[00:53:08] <hannelita> lightguard_jp: I dont think this must be an EJB to work
[00:53:12] <hannelita> its working here
[00:53:14] <stuartdouglas> just use @PersistenceContext
[00:53:18] <lightguard_jp> Okay
[00:53:32] <stuartdouglas> I think the transaction scoped em fails if you are using entity transaction
[00:53:39] <stuartdouglas> as it goes into a loop
[00:53:54] <lightguard_jp> Ah
[00:56:10] *** pmuir has quit IRC
[00:59:04] <hannelita> I was just trying to find a way to have a simple example of how to use Seam Security Identity*.java entities.... but idk if this populateDB file would help after this discussion about @PersistenceContext
[00:59:14] <hannelita> anyway, thanks guys :)
[01:07:34] *** ssachtleben has quit IRC
[01:09:49] *** lightguard_jp has quit IRC
[01:09:53] <johnament> lightguard_jp sbryzak you should really push for CDI support for injecting entity manager, emf at the JPA level
[01:10:08] <johnament> ah
[01:11:18] <sbryzak> johnament: that's what seam persistence provides ;)
[01:11:47] <johnament> sbryzak, it would be better if JPA supported it
[01:12:10] <sbryzak> ah, i doubt that would happen though
[01:12:48] <sbryzak> and i think there's too many configuration possibilities to standardise it like that
[01:22:36] *** tsurdilo has quit IRC
[01:27:13] <johnament> nah, just turn @PersistenceContext into a qualifier and shove @Inject in front, you're done.
[01:29:09] *** mateus has quit IRC
[01:30:23] *** kenfinnigan has joined #seam-dev
[01:32:04] <sbryzak> hey ken, do we have the meeting now?
[01:32:13] <kenfinnigan> should do
[01:32:21] <sbryzak> jason was around
[01:32:25] <kenfinnigan> I know Dan can't make it
[01:32:32] <sbryzak> he should be back shortly i hope
[01:32:40] <kenfinnigan> thought Jason could, but he doesn't appear to be on
[01:32:52] <sbryzak> who is this meeting for exactly? can other people join?
[01:32:58] <kenfinnigan> George was meant to be there too
[01:33:09] <sbryzak> john is here
[01:33:30] <sbryzak> i guess we wait a minute for other people to turn up
[01:33:32] *** kenfinnigan_ has joined #seam-dev
[01:33:52] <kenfinnigan_> sorry, session died on me
[01:34:09] <kenfinnigan_> it's for the DWG members, but if others have an opinion they can join in
[01:34:50] <johnament> i've asked repeatedly what the dwg is, and never receive an answer :/
[01:35:03] <sbryzak> don't worry john, i'm not absolutely clear on it myself ;)
[01:35:19] *** kenfinnigan has quit IRC
[01:35:26] <sbryzak> feel free to jump onto teamspeak if you want to join in
[01:35:28] *** kenfinnigan_ is now known as kenfinnigan
[01:35:38] <johnament> i do however think i found a bug in weld or arquillian
[01:35:46] <johnament> trying to make tests work.
[01:35:55] <sbryzak> what's the bug?
[01:35:58] <johnament> does anyone know much about specializes?
[01:36:10] <sbryzak> enough to be dangerous
[01:36:17] <johnament> ok hold on
[01:36:33] <johnament> so i have this impl class in my test cases: https://github.com/johnament/seam-jms/blob/develop/impl/src/test/java/org/jboss/seam/jms/test/HornetQConnectionFactoryProducer.java
[01:36:36] <kenfinnigan> sbryzak: is there anyone else in TS yet?
[01:36:42] <johnament> and here's the base impl https://github.com/johnament/seam-jms/blob/develop/api/src/main/java/org/jboss/seam/jms/inject/JmsConnectionFactoryProducer.java
[01:36:48] <sbryzak> kenfinnigan: not yet
[01:36:53] <johnament> both end up in the bean archive during deployment, but whenever the tests run it's trying to use the producer from JmsConnectionFactoryProducer
[01:37:09] <johnament> sbryzak, all that is what i sent to pete earlier, and he didn't see anything wrong.
[01:38:06] <kenfinnigan> is @Specializes CDI 1.1?
[01:38:09] <sbryzak> hmm
[01:38:13] <johnament> kenfinnigan, no, cdi 1.0
[01:38:16] <sbryzak> no, it's always been there
[01:38:44] <johnament> kenfinnigan, the idea is that @Specializes on a bean or a producer, replaces the underlying.  it's used in cases where you extend a base class.
[01:38:57] <johnament> in this case, i have a base class that handles JMS connection factories in an EE environment.
[01:39:11] <kenfinnigan> ok, I know I've used the specialized stuff in Seam Config before
[01:39:22] <johnament> but then i have an SE style connection factory managed by HornetQConnectionFactoryProducer
[01:39:36] <johnament> hmmm
[01:39:37] *** cbrock has quit IRC
[01:39:37] <sbryzak> johnament: hmm, your code looks ok to me
[01:40:04] <johnament> sbryzak, i tried it a few ways, with and without annotations
[01:40:34] <johnament> kenfinnigan, is specializes in seam-config the same as the cdi specializes?
[01:40:37] *** hannelita has quit IRC
[01:41:43] <kenfinnigan> it might use it under the hood, never checked
[01:43:08] *** rruss has quit IRC
[01:45:03] *** lightguard_jp has joined #seam-dev
[01:48:40] <johnament> hmmmm
[01:48:53] <johnament> why don't I have access to an injection point in @RequestScoped?
[01:49:31] *** lightguard_jp has quit IRC
[01:50:23] *** lightguard_jp has joined #seam-dev
[01:52:10] <johnament> i need a red bull and voka
[01:52:12] <johnament> vodka
[01:53:20] <stuartdouglas> johnament: because a request scoped bean can be injected into may different injection points
[01:54:48] <johnament> stuartdouglas, but if it has a qualifier, i should be able to use that qualifier to provide different instances, and if the same qualifier is used within the request scope, it should be given the same instance, rather than a separate one
[01:54:59] <johnament> stuartdouglas, especially if the fields are nonbinding
[01:55:20] <stuartdouglas> It does not work like that
[01:57:14] <johnament> i know it doesn't.
[01:57:33] <johnament> stuartdouglas, but i'd really like it if it could
[02:26:55] *** tkimura has joined #seam-dev
[02:27:10] *** hannelita has joined #seam-dev
[02:27:36] *** kenfinnigan has quit IRC
[02:28:52] *** akazakov has quit IRC
[02:36:31] *** jamezp is now known as jamezp_afk
[02:44:26] *** johnament has quit IRC
[03:08:28] *** sannegrinovero has quit IRC
[03:34:04] *** hannelita has quit IRC
[03:57:32] *** sgilda has quit IRC
[03:57:33] *** jbossbot has quit IRC
[03:57:33] *** PeteRoyle has quit IRC
[03:59:32] *** sgilda has joined #seam-dev
[03:59:32] *** jbossbot has joined #seam-dev
[03:59:32] *** PeteRoyle has joined #seam-dev
[04:37:55] <lightguard_jp> sbryzak: You have JCP on the agenda?
[04:37:57] *** sbryzak_ has joined #seam-dev
[04:38:23] *** sbryzak has quit IRC
[04:38:24] *** sbryzak_ has quit IRC
[04:38:46] *** sbryzak has joined #seam-dev
[04:38:46] *** sbryzak has quit IRC
[04:38:46] *** sbryzak has joined #seam-dev
[04:47:03] <lightguard_jp> sbryzak: need to add jcp to the schedule
[04:47:22] <sbryzak> sure, what's the exact topic?
[04:49:57] <lightguard_jp> sbryzak: thought I had you on the cc, let me forward
[04:50:50] <lightguard_jp> sbryzak: rh email
[04:51:33] <sbryzak> so we're going to conference in scott stark for that?
[04:52:42] <lightguard_jp> I sent him an email, haven't heard back yet though
[04:52:53] <sbryzak> np, i've put it in first thing thursday
[04:52:55] <lightguard_jp> We'd like to
[04:53:02] <sbryzak> i guess it concerns all teams
[04:53:09] <lightguard_jp> 9:30?
[04:53:25] <sbryzak> yep
[04:53:41] <lightguard_jp> That'll be 6:30 AM for him
[04:53:59] <sbryzak> ah, which timezone is he in?
[04:54:15] <lightguard_jp> US Pacific
[04:54:27] <lightguard_jp> UCT - 7 currently
[04:54:32] <sbryzak> ok, we could bump it till after lunch
[04:54:44] <sbryzak> 1.30pm ok?
[04:54:57] <lightguard_jp> wow. I can see your edits real time
[04:55:09] <lightguard_jp> Should be
[04:55:12] <sbryzak> could you pls e-mail him
[04:55:18] <sbryzak> ask if he'd be available at that time
[04:55:22] <sbryzak> yeah, google docs is cool
[04:57:08] *** sgilda has quit IRC
[04:57:10] <lightguard_jp> sent
[04:57:33] <lightguard_jp> hard to type with a sleeping 5 mo old :)
[05:00:04] *** hannelita has joined #seam-dev
[05:06:54] <lightguard_jp> hannelita: Evening
[05:07:08] <hannelita> lightguard_jp: evening :)
[05:08:51] <lightguard_jp> Doh, another person in Europe to try and coordinate with, doh :( Hardest timeslot for me
[05:21:48] *** hannelita has quit IRC
[05:22:33] *** hannelita has joined #seam-dev
[05:23:33] <hannelita> lightguard_jp: Ping. Added seam servlet stuff to confbuzz pom. Are you ok with that?
[05:23:47] <lightguard_jp> Yeah, that's fine.
[05:24:29] <hannelita> comitting and pull requesting, take a look when you have some time :) thanks
[05:25:33] <lightguard_jp> hannelita: Excellent, thanks
[05:29:59] <hannelita> lightguard_jp: pull requested
[06:05:27] *** bleathem_away is now known as bleathem
[06:05:41] <bleathem> Seam Faces jira triage time!
[06:06:27] <Diablo-D3> hey guys
[06:06:52] <Diablo-D3> is there any reason why I shouldnt chose ASL2 for a C library that I want picked up by commercial/closed source software?
[06:07:10] <Diablo-D3> as opposed to 2/3 clause BSD, ISC, MIT, etc
[06:07:21] <Diablo-D3> (or any other BSDey Im forgetting)
[06:12:54] *** hannelita has quit IRC
[06:24:06] <bleathem> IANAL
[06:24:29] <Diablo-D3> I didnt ask for a lawyer
[06:24:37] <Diablo-D3> I asked in a room full of coders for a reason
[06:42:27] <jbossbot> git [core] push master d89476f.. Lincoln Baxter, III scaffold now respects JSF servlet mappings
[06:42:27] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/65522dd...d89476f
[06:46:08] <Diablo-D3> aaand no responses
[07:02:27] *** rruss has joined #seam-dev
[07:10:31] *** oskutka has joined #seam-dev
[07:13:16] <bleathem> huh, SEAMFACES-15 is news to me
[07:13:18] <jbossbot> jira [SEAMFACES-15] Warnings should be issued when @Dependent scoped Validators and Converters are registered [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-15
[07:13:46] <bleathem> So, to use @Inject in a validator or converter, it can't be @Dependent scoped?
[07:14:20] <bleathem> lightguard_jp: does that ever come up on the forums (^^)
[07:16:05] *** kpiwko has joined #seam-dev
[07:19:17] <lightguard_jp> bleathem: No
[07:19:26] <bleathem> I wonder why
[07:19:31] <bleathem> maybe it's no longer required
[07:19:31] <Diablo-D3> oh come on damnit
[07:19:38] <lightguard_jp> Could be
[07:19:41] <Diablo-D3> bleathem, lightguard_jp: YOUR OPINIONS, GIVE THEM TO ME
[07:19:43] <bleathem> I'll have to check with lincoln
[07:19:51] <lightguard_jp> It's minor
[07:19:53] <bleathem> Diablo-D3: not everyone is a license expert
[07:20:01] <bleathem> Diablo-D3: I told you already I don't know
[07:20:05] <Diablo-D3> would you use a C lib if it was ASL2?
[07:20:25] <Diablo-D3> would you go OH MAN, IT USES ASL2, ILL USE SOMETHING ELSE?
[07:21:09] <lightguard_jp> bleathem: Why log a warning? Why not just add @RequestScoped to it if it's dependent scoped?
[07:21:16] <lightguard_jp> When we add it to the BM
[07:21:18] <bleathem> Diablo-D3: I'll use whatever OSS I can that is compatible with my license.
[07:21:31] <Diablo-D3> bleathem: so thats a yes?
[07:21:32] <bleathem> lightguard_jp: I don't know, that kind of changes the seamantics
[07:21:43] <bleathem> Diablo-D3: interpret how you will
[07:21:50] <bleathem> lightguard_jp: ^ semantics
[07:22:43] <bleathem> lightguard_jp: meh, good discussion point for the hack night
[07:23:04] <bleathem> lightguard_jp: if you have some time Wed or Thur, we should go over the Seam Faces hack night stuff
[07:23:21] <bleathem> lightguard_jp: I'll be away for a good portion of it, as my son has a soccer practice that night
[07:23:44] <lightguard_jp> Diablo-D3: I prefer ASL to GPL
[07:24:03] <lightguard_jp> If you want it used in commercial / closed you're better off using ASL IMO
[07:24:21] <lightguard_jp> That way they're not "forced" into being open
[07:24:43] <lightguard_jp> And ASL is more likely to be compat with other licenses
[07:25:54] <lightguard_jp> bleathem: Okay. Just as long as there's a list of JIRAs I can go from it shouldn't be a problem
[07:26:18] <bleathem> lightguard_jp: I'm assigning them to a version called 3.1.0.Tracking
[07:26:34] <lightguard_jp> bleathem: Okay, that works
[07:26:34] <Diablo-D3> lightguard_jp: hrm, okay
[07:26:37] <bleathem> they are the interesting/relevant/feasible issues
[07:26:43] <Diablo-D3> lightguard_jp: that seems to be along the lines of what I was thinking
[07:26:58] <bleathem> stuff in the version f.Future is also up for grabs, but is a bit less well defined
[07:27:12] <bleathem> and stuff in "Future" is just out there, yet still useful
[07:29:51] <lightguard_jp> Diablo-D3: What else were you considering?
[07:30:08] <Diablo-D3> probably ISC (aka 2 clause BSD with saner writing)
[07:30:14] <Diablo-D3> but I want patent backstab language
[07:30:47] <lightguard_jp> ASL2 and GPL3 have patent language
[07:31:27] <Diablo-D3> yes, but GPL3 basically closes the door on commercial adoption
[07:32:49] <lightguard_jp> Yep
[07:34:36] <lightguard_jp> Diablo-D3: http://en.wikipedia.org/wiki/WTFPL ?
[07:35:19] *** kpiwko1 has joined #seam-dev
[07:36:25] <Diablo-D3> yeah, thats TOO broad
[07:36:42] <Diablo-D3> although Ive considered it just for the lulz
[07:38:28] <lightguard_jp> Diablo-D3: Yeah, stick with ASL2
[07:39:09] *** kpiwko has quit IRC
[07:41:02] <Diablo-D3> lightguard_jp: ASL2 is really common in javaland
[07:41:03] <Diablo-D3> but
[07:41:12] <Diablo-D3> does anyone use it for C outside of apache?
[07:41:19] <Diablo-D3> I think even apache doesnt use it for a lot of their shit
[07:43:49] <Diablo-D3> because if what I was intending this for was java, I probably wouldnt have even thought twice
[07:44:49] *** kpiwko1 is now known as kpiwko
[07:44:55] *** jharting has joined #seam-dev
[07:45:24] <bleathem> lightguard_jp: any idea if SEAMFACES-98 is still relevent?
[07:45:26] <jbossbot> jira [SEAMFACES-98] Align with the new transaction package in Seam Persistence [Open (Unresolved) Library Upgrade, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-98
[07:45:45] <lightguard_jp> Diablo-D3: http://projects.apache.org/indexes/language.html#C I clicked on 9 of them, they all said ASl2
[07:45:51] <lightguard_jp> Including httpd
[07:46:30] <Diablo-D3> ....
[07:46:32] <Diablo-D3> ASL2 it is
[07:46:41] <lightguard_jp> bleathem: not sure, have to check where it's being used. My guess is this has been fixed.
[07:47:10] <Diablo-D3> lightguard_jp++
[07:47:13] <bleathem> I'll do a quick grep
[07:47:48] <bleathem> lightguard_jp: looks like it's done
[07:49:48] <bleathem> hmmm, SEAMFACES-108
[07:49:50] <jbossbot> jira [SEAMFACES-108] Add producer for UIViewRoot [Open (Unresolved) Feature Request, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-108
[07:50:21] <bleathem> Given that the ViewRoot lifetime is shorter than a request, I would think that would be a bad idea
[07:50:38] <bleathem> since @RequestScoped is the shortest of all the scopes
[07:51:13] <bleathem> lightguard_jp: @Dependent scope means the injected bean adopts the scope of the bean into which it's injected, correct?
[07:51:51] <bleathem> so If I inject an @Dependent scope into an @Application scoped bean, the injected bean would then be @Application scoped, right?
[07:54:29] <lightguard_jp> bleathem: Correct
[07:54:37] <lightguard_jp> Well, not exactly.
[07:54:49] <bleathem> "It is instantiated when the object it belongs to is created, and destroyed when the object it belongs to is destroyed."
[07:54:50] <lightguard_jp> That means it would live as long as the container
[07:54:56] <lightguard_jp> Yes.
[07:55:09] <bleathem> Added a comment to SF-108
[07:55:09] <lightguard_jp> So it doesn't "become" that scope
[07:55:15] <bleathem> I wonder if I should just reject it
[07:55:30] <bleathem> yeah, "become" was a bad choise of words
[07:55:51] <lightguard_jp> But it lives inside of it. @DependentScoped acts the exact same as standard java object creation / destruction and GC
[07:57:26] <lightguard_jp> Now, using Instance would be different
[07:57:44] <lightguard_jp> I still have a hard time understanding a use case for this.
[07:57:50] <lightguard_jp> You can get it from the FacesContext
[07:58:24] <bleathem> imagin injecting the UIViewRoot into a SessionScoped bean
[07:58:34] <bleathem> after the first navigation, the injected value would be stale
[07:59:16] <lightguard_jp> Yep
[08:06:22] *** lightguard_jp has quit IRC
[08:06:48] *** lightguard_jp has joined #seam-dev
[08:09:27] <bleathem> ugh
[08:09:39] <bleathem> halfway through the unscheduled jiras
[08:21:19] <bleathem> lightguard_jp: Seam Faces 3.1.0.Tracking has 23 issues in it, more than enough for the hack night I imagine
[08:21:40] <lightguard_jp> Probably
[08:21:42] <bleathem> lightguard_jp: https://issues.jboss.org/browse/SEAMFACES/fixforversion/12318074
[08:24:24] *** msmigielski has joined #seam-dev
[08:31:26] *** msmigielski has quit IRC
[08:32:36] *** pchowaniec has joined #seam-dev
[08:40:09] *** maschmid has joined #seam-dev
[08:52:57] *** marekn has joined #seam-dev
[08:53:00] *** koentsje has joined #seam-dev
[08:57:57] *** mathieuancelin has joined #seam-dev
[09:02:11] *** mathieuancelin has quit IRC
[09:05:11] *** chkal has joined #seam-dev
[09:15:39] *** mathieuancelin has joined #seam-dev
[09:17:30] *** mkouba has joined #seam-dev
[09:25:54] *** clerum has quit IRC
[09:32:12] *** msmigielski has joined #seam-dev
[09:34:37] *** lightguard_jp has quit IRC
[09:36:07] *** emmanuel has joined #seam-dev
[09:36:11] *** emmanuel has quit IRC
[09:36:11] *** emmanuel has joined #seam-dev
[09:38:34] *** jharting has quit IRC
[09:41:54] *** mgoldmann has joined #seam-dev
[10:13:40] *** rruss has quit IRC
[10:24:42] *** msmigielski has quit IRC
[10:33:46] *** sbryzak has quit IRC
[10:35:42] *** sbryzak has joined #seam-dev
[10:42:31] *** sannegrinovero has joined #seam-dev
[10:50:55] *** msmigielski has joined #seam-dev
[10:57:24] *** alesj has joined #seam-dev
[11:18:07] *** aslak has joined #seam-dev
[11:18:07] *** aslak has quit IRC
[11:18:07] *** aslak has joined #seam-dev
[11:29:55] *** tkimura has quit IRC
[11:48:04] *** emmanuel has quit IRC
[11:54:00] *** ssachtleben has joined #seam-dev
[11:55:45] *** epbernard has joined #seam-dev
[11:55:45] *** epbernard is now known as emmanuel
[12:00:21] *** rmartinelli has joined #seam-dev
[12:08:00] *** msmigielski has quit IRC
[12:27:41] *** ssachtleben has quit IRC
[12:33:27] *** jharting has joined #seam-dev
[12:37:07] *** pchowaniec has left #seam-dev
[12:41:51] *** aslak has quit IRC
[12:48:12] *** msmigielski has joined #seam-dev
[12:52:21] *** tsurdilo has joined #seam-dev
[13:16:17] *** sgilda has joined #seam-dev
[13:31:49] *** aslak has joined #seam-dev
[13:57:23] *** mkouba has quit IRC
[13:58:46] *** mkouba has joined #seam-dev
[13:58:49] *** mkouba has quit IRC
[14:06:26] *** mkouba has joined #seam-dev
[14:15:51] *** aslak has quit IRC
[14:18:31] *** koentsje has quit IRC
[14:35:45] *** emmanuel has quit IRC
[14:57:22] *** jose_freitas has joined #seam-dev
[15:01:24] *** mgoldmann has quit IRC
[15:02:11] *** mgoldmann has joined #seam-dev
[15:03:27] *** msmigielski has quit IRC
[15:16:28] *** sbryzak has quit IRC
[15:21:34] <jbossbot> git [xwidgets] push master 94c511b.. Shane Bryzak hopefully this will fix the NPE...
[15:21:35] <jbossbot> git [xwidgets] push master URL: http://github.com/seam/xwidgets/compare/f64003e...94c511b
[15:22:36] <jose_freitas> loled @ "hopefully this will fix..."
[15:23:56] *** rruss has joined #seam-dev
[15:24:50] <jbossbot> git [university] push master 3eea7fb.. Shane Bryzak implemented content preview
[15:24:51] <jbossbot> git [university] push master URL: http://github.com/seam/university/compare/169dc12...3eea7fb
[15:27:55] *** sbryzak has joined #seam-dev
[15:27:55] *** sbryzak has quit IRC
[15:27:55] *** sbryzak has joined #seam-dev
[15:28:35] *** sbryzak_ has joined #seam-dev
[15:40:01] *** epbernard has joined #seam-dev
[15:40:01] *** epbernard is now known as emmanuel
[15:51:26] *** aslak has joined #seam-dev
[16:06:16] *** clerum has joined #seam-dev
[16:11:49] *** clerum1 has joined #seam-dev
[16:11:49] *** clerum has quit IRC
[16:29:05] *** marekn has quit IRC
[16:29:43] *** marekn has joined #seam-dev
[16:37:29] *** marekn has quit IRC
[16:48:30] *** koentsje has joined #seam-dev
[16:48:37] *** chkal has quit IRC
[16:52:32] *** lincolnthree has joined #seam-dev
[16:52:54] <lincolnthree> hey sbryzak, around>
[16:52:55] <lincolnthree> ?
[16:54:16] *** edburns_away is now known as edburns
[17:01:16] *** mkouba has quit IRC
[17:01:33] *** balunasj has joined #seam-dev
[17:09:15] *** rmartinelli has quit IRC
[17:09:23] *** msmigielski has joined #seam-dev
[17:12:05] *** rmartinelli has joined #seam-dev
[17:13:11] *** jharting has quit IRC
[17:13:59] *** msmigielski has quit IRC
[17:20:15] *** oskutka has quit IRC
[17:22:54] *** cbrock has joined #seam-dev
[17:29:00] *** msmigielski has joined #seam-dev
[17:31:27] *** jamezp_afk is now known as jamezp
[17:31:58] *** bleathem1 has joined #seam-dev
[17:33:22] *** bleathem has quit IRC
[17:33:54] *** bleathem1 is now known as bleathem
[17:38:20] *** maschmid has quit IRC
[17:44:27] *** bleathem has quit IRC
[17:49:21] *** ssachtleben has joined #seam-dev
[17:51:56] *** bleathem has joined #seam-dev
[17:54:28] *** msmigielski has quit IRC
[18:02:04] *** akazakov has joined #seam-dev
[18:06:59] <jbossbot> git [core] push master 1e42083.. Lincoln Baxter, III Upgraded to SWD 1.0.0-alpha5
[18:07:00] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/d89476f...1e42083
[18:13:20] *** Diablo-D3 has quit IRC
[18:13:38] <lincolnthree> hey bleathem
[18:13:51] <lincolnthree> nm
[18:13:53] <lincolnthree> sorry
[18:13:55] <bleathem> hey lincolnthree
[18:14:00] <lincolnthree> bleathem: hey
[18:14:07] <lincolnthree> have you looked at typesafe navigation for JSF?
[18:14:24] <bleathem> .. i think we have a jira for it ..
[18:14:39] <bleathem> I've thought about doing it with enums
[18:14:43] <bleathem> and integrating it with the view config
[18:14:47] <bleathem> but not much more than that
[18:15:02] <bleathem> basically, if we use a viewconfig enum
[18:15:02] <lincolnthree> just wondering if you'd figured out any ways to get a handle on the object return result
[18:15:26] <bleathem> you mean the string returned from action methods?
[18:15:30] <lincolnthree> yeah
[18:15:43] <bleathem> I was just going to return an enum
[18:15:46] <lincolnthree> if you return an object, does it get stringified?
[18:15:51] <bleathem> oic
[18:15:55] <bleathem> good question
[18:16:00] <bleathem> dind't think that far into it
[18:16:05] <bleathem> we may have to intercept that
[18:16:18] <lincolnthree> nowhere to intercept really, except with a CDI extension perhaps
[18:16:22] <lincolnthree> literally an interceptor
[18:16:35] <bleathem> hmmm
[18:16:42] <lincolnthree> but that means you'd need to know which methods are action methods or not
[18:16:50] <bleathem> annotate them?
[18:16:53] <lincolnthree> ugly :/
[18:16:55] <bleathem> that's gross
[18:16:56] <lincolnthree> more verbosity
[18:16:56] <bleathem> yeah
[18:17:22] <bleathem> we can't do this with a custom navigation handler?
[18:17:40] <bleathem> I guess the nav handler wants strings
[18:17:45] <bleathem> looking at the api
[18:18:05] <lincolnthree> havigationhandler only takes string
[18:19:51] <lincolnthree> so maybe you could do something like:
[18:20:06] <lincolnthree> FacesNavigation.perform(MyTypeSafeThing.class);
[18:20:14] <lincolnthree> return FacesNavigation.perform(MyTypeSafeThing.class);
[18:20:30] <lincolnthree> which returns a string, but which is a serialized representation of MyTypeSafeThing.class
[18:20:51] <lincolnthree> so that it could be constructed into a valid NavigationCase by the NavigationHandler implementation we provide
[18:21:06] <bleathem> what if we extended navigation handler...
[18:21:09] <lincolnthree> That's probably cleaner, wdyt?
[18:21:11] <bleathem> right, what you said
[18:21:28] <bleathem> I think that's similar to what I was thinking
[18:21:37] <lincolnthree> so you'd have to call that utility in every case where you want to do that
[18:21:40] <bleathem> a custom nav handler that takes enums as arguments
[18:21:43] <lincolnthree> no
[18:21:46] <lincolnthree> that won't work
[18:21:50] <bleathem> and spits out string navigations
[18:21:56] <lincolnthree> Oh, you mean utility
[18:21:58] <lincolnthree> not navhandler
[18:21:59] <lincolnthree> right
[18:22:00] <lincolnthree> yes
[18:22:14] <bleathem> why a utility?
[18:22:23] *** msmigielski has joined #seam-dev
[18:22:33] <lincolnthree> I think we're miscommunicating
[18:22:38] <lincolnthree> when I think NavHandler
[18:22:39] *** mathieuancelin has left #seam-dev
[18:22:47] <lincolnthree> I think the JSF NavigationHandler interface
[18:23:08] <bleathem> yes
[18:23:22] <lincolnthree> you can't change what kind of arguments that takes
[18:23:24] <lincolnthree> it takes strings
[18:23:48] <bleathem> you sure?
[18:24:14] <lincolnthree> yes
[18:24:16] <lincolnthree> it's an interface
[18:24:23] <lincolnthree> you can't change that
[18:24:37] <bleathem> yeah, we can't change the interface....
[18:24:55] <bleathem> sorry if I sound difficult, I'm just trying to fully understand where we are limited
[18:25:08] <lincolnthree> np
[18:25:37] <bleathem> ok, so the utlity method takes our enum, and converts it to a string
[18:25:37] <ssachtleben> hack sun git server and change the interface :p
[18:25:50] <lincolnthree> ignoring ssachtleben, lol
[18:25:54] <bleathem> lol
[18:25:57] <lincolnthree> bleathem: yea, something like that
[18:25:59] <bleathem> JSF = JBoss Server Faces
[18:26:04] <lincolnthree> or maybe to be more "CDI-like"
[18:26:16] <lincolnthree> we could @Inject NavUtility nav;
[18:26:21] <lincolnthree> then you just:
[18:26:27] <ssachtleben> oh well :D
[18:26:30] <lincolnthree> return nav.redirect(Outcome.class);
[18:26:50] <lincolnthree> I think that's pretty clean
[18:27:00] <lincolnthree> you could also have things like:
[18:27:07] <lincolnthree> return nav.refresh();
[18:27:08] <bleathem> we could have different methods to add different query strings
[18:27:17] <lincolnthree> return nav.forward(Outcome.class);
[18:27:19] <lincolnthree> or yea
[18:27:24] <bleathem> nav.redirect would add redirect=true
[18:27:35] <bleathem> or maybe chain them
[18:28:08] <lincolnthree> AH!
[18:28:14] <bleathem> nav.navigate(EnumValue).redirect().viewParam(..)
[18:28:15] <lincolnthree> I think I know.
[18:28:30] <lincolnthree> Hang on let me try something.
[18:28:43] *** msmigielski has quit IRC
[18:29:37] <bleathem> I like this idea lincoln
[18:30:01] <lincolnthree> no, you can't extend String :(
[18:30:03] <lincolnthree> that would be nice
[18:30:05] <lincolnthree> make this very easy
[18:30:18] <bleathem> String is final?
[18:30:20] <lincolnthree> yep
[18:30:34] <bleathem> bummer
[18:30:42] <lincolnthree> so we'll need to do something like:
[18:31:27] <lincolnthree> nav.redirect(Outcome.class/Enum).addParameter("p", myValue).perform();
[18:31:49] <bleathem> I don't like the redirect word
[18:31:50] <lincolnthree> note the .perform()
[18:32:02] <lincolnthree> it's accurate
[18:32:04] <bleathem> unless you mean actually to do a faces-redirect
[18:32:08] <lincolnthree> ye
[18:32:08] <lincolnthree> s
[18:32:25] <bleathem> so the .perform gives the resulting string
[18:32:35] <bleathem> that we return
[18:32:52] <lincolnthree> right
[18:32:55] <lincolnthree> or
[18:32:56] <lincolnthree> or
[18:32:57] <lincolnthree> or
[18:33:02] <lincolnthree> we could make it better
[18:33:32] <lincolnthree> nav.perform(Enum).addParameter(p, value).redirect();
[18:33:44] <lincolnthree> where the redirect word becomes the final command that does the stringification
[18:33:49] <lincolnthree> so you could do
[18:33:51] <lincolnthree> .redirect()
[18:33:59] <lincolnthree> .navigate();
[18:34:04] <lincolnthree> etc
[18:34:12] <lincolnthree> where redirect does a faces-redirect
[18:34:16] <lincolnthree> and .navigate() does not
[18:34:34] <bleathem> nav.view(Enum).AddParameter(p,value).navigate()
[18:34:55] <lincolnthree> nav.toView(...)
[18:35:01] <bleathem> yes!
[18:35:10] <lincolnthree> where is the issue for this?
[18:35:18] <bleathem> 1 sec
[18:35:57] *** alesj has quit IRC
[18:35:59] <lincolnthree> Ok, and get this!
[18:36:03] <lincolnthree> Enums can impement interfaces
[18:36:19] <bleathem> SEAMFACES-122
[18:36:20] <lincolnthree> so all we have to do is define an interface like: NavigationControl
[18:36:20] <jbossbot> jira [SEAMFACES-122] Find a way to use the @ViewConfig enums to provide type-safe navigation rules [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-122
[18:36:21] <lincolnthree> or whatever
[18:36:29] <lincolnthree> and then we can leave ourselves open to extension
[18:36:55] <bleathem> care to write this up?
[18:37:03] <lincolnthree> yep, s'why i wanted the issue :)
[18:37:05] <bleathem> would be a good candidate for the hack fest tomorrow
[18:39:27] <bleathem> I filed a couple of spec issues after our web.xml debacle yesterday
[18:39:50] <bleathem> and pete said he would bring it up at the EE eg
[18:40:31] <lincolnthree> awesome
[18:40:56] <bleathem> the only thing I don't like about this
[18:41:02] <bleathem> is that the simple case is verbose
[18:41:13] <bleathem> maybe we could overload the last methods to take an parameter
[18:41:15] <bleathem> so you could do
[18:41:20] <bleathem> nav.navigate(myEnum)
[18:41:24] <lincolnthree> nav.redirect(enum)
[18:41:25] <bleathem> as a shortcut
[18:41:25] <lincolnthree> yeah
[18:41:28] <lincolnthree> i like it
[18:41:33] <lincolnthree> whereas the longhand gives you the builder
[18:41:40] <bleathem> right
[18:41:47] *** jamezp is now known as jamezp_afk
[18:41:55] <lincolnthree> nav.redirectTo(enum);
[18:42:05] <bleathem> right, add the To
[18:42:16] <bleathem> API desing is fun - just need someont to do the impl ;)
[18:42:41] * bleathem is still full of typos in IRC
[18:43:01] <lincolnthree> ;)
[18:43:06] <lincolnthree> fortunately this one is pretty easy
[18:43:11] <lincolnthree> aside from teh serialization algorithm
[18:43:57] <lincolnthree> what about nav.sendTo(...)
[18:43:59] <lincolnthree> for navigate
[18:44:09] <lincolnthree> navigate is such a generic word
[18:44:22] <lincolnthree> or maybe
[18:44:42] <lincolnthree> nav.to(...)
[18:44:48] <lincolnthree> and nav.redirectTo(...)
[18:44:57] <lincolnthree> wdyt?
[18:45:21] <clerum1> redirectTo includes the faces-redirect?
[18:45:25] <lincolnthree> yes
[18:45:29] <clerum1> makes sense then
[18:45:39] <bleathem> I like navigate
[18:45:44] <bleathem> it's what it is
[18:45:49] <lincolnthree> ok
[18:45:53] <bleathem> maybe .to()
[18:46:01] *** aslak has quit IRC
[18:46:04] <bleathem> but that would look funny in the builder pattern
[18:46:10] <lincolnthree> yeah
[18:46:27] <bleathem> the tricky piece, for integrating this with the viewconfig
[18:46:34] <clerum1> so have one end redirect() and one navigate()
[18:46:36] <bleathem> is getting the @ViewPattern out of the enum
[18:46:50] *** msmigielski has joined #seam-dev
[18:46:51] <clerum1> one that adds the faces-redirect and one that doesn;t
[18:47:01] <bleathem> clerum1: right, but lincolnthree is asking for alternatives to the word navigate()
[18:47:27] <clerum1> is navigate taking the viewId
[18:47:34] <clerum1> or is it the end of the builder?
[18:47:35] <bleathem> we also need a method in the builder for includeViewParams
[18:47:40] <bleathem> clerum1: both
[18:48:02] <bleathem> clerum1: taking the view enum as a parameter is a shortcut
[18:49:02] <clerum1> similar to what I was talking about with navigation handler  - navigationHelper.viewId(EntityType.BANK_SWEEP.getViewId()).param("oid", query.substring(1)).endConversation().redirect();
[18:49:06] <bleathem> so long form: nav.toView(enum).redirect()
[18:49:07] <bleathem> short form: nav.redirectTo(num)
[18:49:10] <clerum1> but taking an enum instead of a string viewid
[18:49:31] <bleathem> clerum1: right, we were talking aout that before!
[18:49:35] <bleathem> what's the issue for that?
[18:49:37] <clerum1> err navigation helper
[18:50:23] *** balunasj has quit IRC
[18:50:38] <clerum1> it's caught in between two right now
[18:50:55] <clerum1> https://issues.jboss.org/browse/SEAMSERVLET-44
[18:50:57] <jbossbot> jira [SEAMSERVLET-44] Support for Conversation in RedirectBuilder [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMSERVLET-44
[18:51:00] <clerum1> https://issues.jboss.org/browse/SEAMFACES-196
[18:51:01] <jbossbot> jira [SEAMFACES-196] Support for FacesManager [Resolved (Done) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-196
[18:51:17] <clerum1> I think it ends to end up in seam faces as NavigationHelper
[18:51:29] <clerum1> probably using Seam Servlet to do the heavy lifting
[18:51:44] <bleathem> so what we are discussing now if leveraging the JSF navigation
[18:52:00] <bleathem> what the SeamServlet piece does it do a pure http redirect
[18:52:14] <bleathem> afk for 1 sec, brb
[18:52:17] <clerum1> k
[18:52:18] <lincolnthree> https://issues.jboss.org/browse/SEAMFACES-122?focusedCommentId=12626896#comment-12626896
[18:52:21] <jbossbot> jira [SEAMFACES-122] Find a way to use the @ViewConfig enums to provide type-safe navigation rules [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-122
[18:53:36] <clerum1> lincolnthree: that would work perfect if it support string based view id's as well and also support for ending the conversation
[18:53:45] <lincolnthree> Add a comment :)
[18:53:48] <lincolnthree> I agree
[18:54:44] <clerum1> probably endConversation() and maybe continueConversation()
[18:54:56] <clerum1> continue adding the cid
[18:55:01] <bleathem> lincolnthree: not sure why we need a nav handler
[18:55:08] <bleathem> the builder returns a string
[18:55:14] <lincolnthree> bleathem: ah true
[18:55:15] <bleathem> which regular JSF can handler
[18:55:16] <lincolnthree> good point
[18:55:27] <lincolnthree> very good point
[18:55:27] <bleathem> makes it even simpler :)
[18:55:30] <lincolnthree> all we need is the utility!
[18:55:31] <lincolnthree> yay!
[18:55:33] <clerum1> so all we are doing is creating a string?
[18:55:40] <lincolnthree> clerum1: basically :p
[18:55:44] <bleathem> but how to get the view id from the viewconfig enum?
[18:55:44] <clerum1> the viewid with the params
[18:55:53] <bleathem> reflection I guess?
[18:55:59] <lincolnthree> bleathem: how do you get it now?
[18:56:02] <clerum1> can we end conversations then? cid=none?
[18:56:06] <clerum1> thought I saw somethign on that
[18:56:15] <lincolnthree> clerum1: good question
[18:56:20] <lincolnthree> the nav handler would be the place to end the conversation
[18:56:22] <lincolnthree> not the builder
[18:56:27] <bleathem> the utility mehtod could inject the converstaion
[18:56:33] <bleathem> and end it
[18:56:37] <bleathem> programtically
[18:56:39] <lincolnthree> you don't want to change the state of the system in a builder IMO
[18:56:42] <bleathem> before returning the string
[18:56:45] <bleathem> right!
[18:56:55] <bleathem> hmmm
[18:57:11] <bleathem> but in the .naviagte() method we could
[18:57:17] <bleathem> when the builder is "executed"
[18:57:28] <lincolnthree> i don't think we should, unless we explicitly also call the navigation handler
[18:57:33] <lincolnthree> in which case, we don't need to return anything
[18:57:34] * bleathem not really liking that approach
[18:57:37] <lincolnthree> and we just perform the navigation
[18:57:46] <lincolnthree> so instead of returning, you just call this anywhere in the app
[18:57:49] <lincolnthree> i actually like that
[18:57:53] <bleathem> that doesn't feel like it "plays well"
[18:58:06] <lincolnthree> it's more universally useful though
[18:58:15] <bleathem> one might be doing things with the returned sting in the facelet
[18:58:18] <lincolnthree> we could provide two finalizers
[18:58:21] <bleathem> or with other nav handlers
[18:58:23] <lincolnthree> .navigate();
[18:58:28] <lincolnthree> and .getNavigationString();
[18:58:31] <lincolnthree> or
[18:58:33] <lincolnthree> .redirect()
[18:58:39] <lincolnthree> and .getRedirectString();
[18:58:43] <lincolnthree> etc
[18:58:44] <bleathem> hmmm
[18:58:54] <bleathem> .doRedirect()
[18:59:00] <lincolnthree> getRedirect()
[18:59:06] <lincolnthree> that could work
[18:59:25] <clerum1> gives you a little more flexablity
[18:59:31] <lincolnthree> yeah
[18:59:37] <bleathem> we could address terminating conversations with a custom nav handler
[18:59:41] <lincolnthree> we definitely need a way to invoke navigation more simply in other places too
[18:59:48] <lincolnthree> bleathem: yes, i think that's what we need to do
[18:59:48] <bleathem> inspect for a cid=null paramter or somehting
[18:59:50] <lincolnthree> yes
[19:00:02] <lincolnthree> i'd say just:
[19:00:04] <lincolnthree> cid=
[19:00:07] <lincolnthree> that's null
[19:00:11] <lincolnthree> or even
[19:00:12] <lincolnthree> ?cid
[19:00:17] <bleathem> doesn't weld do that itself?
[19:00:17] <lincolnthree> that's truly null
[19:00:21] <lincolnthree> cid= is empty string
[19:00:32] <lincolnthree> bleathem: this is for telling the navhandler to end the conv
[19:00:35] <lincolnthree> not for the actual redirect
[19:01:02] <bleathem> you mean not for the http (non-jsf) redirect that clerum1is after
[19:01:26] <lincolnthree> not for either
[19:01:31] <bleathem> oh
[19:01:44] <lincolnthree> we're just talking about a way to inform the custom NavigationHandlerImpl to call conversation.end()
[19:01:48] <bleathem> right
[19:01:56] <lincolnthree> before it passes the navigation string on to the default JSF nav handler
[19:02:06] <bleathem> how about for the clerum redirect? where the conversation isn't invoked?
[19:02:18] <bleathem> it would have to be done by whatever did the redirct
[19:02:27] <bleathem> the piece that delegated to Seam Servlet
[19:02:32] <bleathem> this is all coming together nicely
[19:02:35] <clerum1> https://issues.jboss.org/browse/WELD-919
[19:02:36] <jbossbot> jira [WELD-919] Conversation propagation token that negates the "cid" parameter [Resolved (Done) Feature Request, Major, Ales Justin] https://issues.jboss.org/browse/WELD-919
[19:02:48] <lincolnthree> that's weld though, not CDI spec
[19:02:53] <lincolnthree> not portable
[19:03:25] <clerum1> ah good point - https://issues.jboss.org/browse/CDI-135
[19:03:26] <jbossbot> jira [CDI-135] Request parameter for terminating cid propagation [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-135
[19:03:27] <bleathem> we should use the same terminology
[19:04:13] *** kevinpollet has joined #seam-dev
[19:04:32] <lincolnthree> if we wanted to be really anal
[19:04:38] <bleathem> and we do...
[19:04:45] <lincolnthree> we could implement a servlet filter or some such that provided the same functionality
[19:04:50] <lincolnthree> for terminating conversation propagation
[19:04:53] <bleathem> right
[19:04:54] <lincolnthree> with a request parameter
[19:05:00] <bleathem> this is the SeamServlet delegation part
[19:05:03] <lincolnthree> right
[19:05:17] <bleathem> where's that jira
[19:05:52] <bleathem> SEAMSERVLET-44
[19:05:53] <jbossbot> jira [SEAMSERVLET-44] Support for Conversation in RedirectBuilder [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMSERVLET-44
[19:06:03] *** hannelita has joined #seam-dev
[19:06:27] *** lukaszkaleta has joined #seam-dev
[19:06:46] <lukaszkaleta> Hi
[19:06:47] <bleathem> let's start simply though
[19:06:55] <bleathem> leave out conversation support, to get this thing prototyped
[19:07:05] <bleathem> then add it later with a custom nav handler
[19:07:09] <bleathem> they really are different issues
[19:07:17] <lukaszkaleta>  I have a question about CDI:
[19:07:17] <lukaszkaleta> I have a interface:
[19:07:17] <lukaszkaleta> public interface X {
[19:07:17] <lukaszkaleta> }
[19:07:17] <lukaszkaleta> and three implementations:
[19:07:18] <lukaszkaleta> @Special(type = SpecialType.SPECIAL_1)
[19:07:20] <lukaszkaleta> public class Xspacial1 implemenst X {}
[19:07:22] <lukaszkaleta> @Special(type = SpecialType.SPECIAL_2)
[19:07:24] <lukaszkaleta> public class Xspacial2 implemenst X {}
[19:07:26] <lukaszkaleta> @Default
[19:07:28] <lukaszkaleta> public class Xdefault implemenst X {}
[19:07:30] <lukaszkaleta> then I would like to inject it
[19:07:32] <lukaszkaleta> @Inject Instance<X> xInstance
[19:07:34] <lukaszkaleta> Do you know how can I get from instance Xspecial1 implementation of x ?
[19:07:36] <lukaszkaleta> I know how to do it when @Special is without enum, but when @Special annotation is with enum I do not know.
[19:08:13] <bleathem> You can use a producer, and inject the @InjectionPoint, to inspect the tpye you are trying to inject (i think)
[19:08:27] <bleathem> inject the @InjectionPoint into the producer
[19:08:55] <bleathem> I think we do that in Faces with the X-field validation stuff
[19:10:55] <lincolnthree> ok, so bleathem clerum1 if you guys wanna add your comments to SEAMFACES-122, we can do this at the hack night (i may miss again)
[19:10:57] <jbossbot> jira [SEAMFACES-122] Find a way to use the @ViewConfig enums to provide type-safe navigation rules [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-122
[19:11:17] <bleathem> I'll add some comments for sure
[19:11:31] <lincolnthree> kk
[19:17:36] <ssachtleben> ken on vacation?
[19:21:25] <bleathem> lukaszkaleta: have a look at https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/component/FormValidationFieldProducer.java#L71
[19:21:35] <bleathem> that should be very similar to what you are trying to achieve
[19:27:38] *** msmigielski has quit IRC
[19:27:43] *** kevinpollet has quit IRC
[19:28:02] <bleathem> not sure what comments I have to add to 122
[19:28:11] <bleathem> I'll have to review the IRC conversation...
[19:28:22] *** daniel_hinojosa has joined #seam-dev
[19:28:25] <lincolnthree> :) we could post a link to the logs for this discussion too
[19:35:10] <bleathem> ok, I added some comments
[19:35:18] <bleathem> to first order, this should be really quick to build
[19:35:44] <bleathem> I wonder how it compares to the CODI type-safe navigation
[19:36:30] <lincolnthree> Codi is SUPER complicated
[19:36:35] <lincolnthree> really not friendly imo
[19:36:43] <lincolnthree> Take a look
[19:39:12] *** bleathem1 has joined #seam-dev
[19:40:14] *** bleathem has quit IRC
[19:40:33] *** bleathem1 is now known as bleathem
[19:40:46] <bleathem> I think their (CODI) type safe navigation involves classes, rather than enums
[19:53:13] *** lightguard_jp has joined #seam-dev
[20:03:31] *** daniel_hinojosa has quit IRC
[20:09:47] *** emmanuel has quit IRC
[20:12:32] *** mbg has joined #seam-dev
[20:17:09] *** lightguard_jp is now known as lightguard_jp_aw
[20:18:21] *** daniel_hinojosa has joined #seam-dev
[20:19:29] *** nilian has joined #seam-dev
[20:31:27] *** mgoldmann has quit IRC
[20:37:25] <jbossbot> git [mail] push develop e1cc538.. Shane Bryzak removed repository config from pom
[20:37:25] <jbossbot> git [mail] push develop 45aa4a4.. Cody Lerum fix example pom...
[20:37:25] <jbossbot> git [mail] push develop 497e67c.. Cody Lerum merge
[20:37:25] <jbossbot> git [mail] push develop URL: http://github.com/seam/mail/compare/05e4247...497e67c
[20:41:11] *** cbrock has quit IRC
[20:48:56] *** kevinpollet has joined #seam-dev
[20:49:33] *** kpiwko has quit IRC
[20:57:52] *** lightguard_jp_aw is now known as lightguard_jp
[21:05:15] *** hannelita has quit IRC
[21:08:35] <lightguard_jp> lincolnthree: A full time job to create a tutorial, yeah I can attest to that.
[21:08:41] <lincolnthree> yeah...
[21:08:49] <lincolnthree> were there responses?
[21:09:23] *** msmigielski has joined #seam-dev
[21:09:35] <lightguard_jp> Some
[21:09:51] <lightguard_jp> Newton basically suggested we do it.
[21:10:44] <lightguard_jp> lincolnthree: Burke called you out and asked for specifics (I guess your examples weren't enough)
[21:11:05] <lightguard_jp> I'll respond as well.
[21:12:31] <lincolnthree> i think he misread what I said
[21:13:00] *** daniel_hinojosa has quit IRC
[21:16:48] *** hannelita has joined #seam-dev
[21:22:25] *** msmigielski has quit IRC
[21:27:12] <bleathem> lightguard_jp: I'm looking through the chanser man page you shared with me a while back
[21:27:27] <bleathem> lightguard_jp: but it's still not clear to me what jay needs to do to add other channel moderators
[21:27:46] <lightguard_jp> Is Jay around?
[21:27:56] <bleathem> yes, but a bit swamped
[21:28:11] <bleathem> I'd like to relay a simple command for him to run
[21:28:40] <bleathem> /msg ChanServ ACCESS #foo ADD bleathem OP
[21:28:43] <bleathem> would that do it?
[21:28:47] <bleathem> what's "OP" ?
[21:29:02] <bleathem> err s/foo/richfaces/
[21:29:23] <bleathem> /msg ChanServ ACCESS #richfaces ADD bleathem OP
[21:31:20] <lightguard_jp> bleathem: http://freenode.net/group_registration.shtml#groupcontacts
[21:31:29] <lightguard_jp> bleathem: http://blog.freenode.net/2008/04/registering-a-channel-on-freenode/
[21:31:32] <lightguard_jp> Those should help
[21:31:44] <bleathem> ok, thanks lightguard_jp!
[21:32:28] <lincolnthree> bleathem: you can auto-add yourself
[21:32:37] <bleathem> oh?
[21:32:46] <lincolnthree> with: /msg ChanServe flags #richfaces +A bleathem
[21:32:56] <lincolnthree> if you have access to do that that is
[21:33:06] <lightguard_jp> lincolnthree: That's the problem, only Jay has access
[21:33:17] <bleathem> doesn't work
[21:33:27] <bleathem> I really don't want to know any more about IRC
[21:34:05] <bleathem> it's useful, but too cryptic for me
[21:35:47] <lincolnthree> you need jay :)
[21:35:57] <lincolnthree> bleathem: i feel the same way
[21:37:08] <bleathem> turns out it's not a 2-minute task - making creating an action item to address it later
[21:37:09] *** msmigielski has joined #seam-dev
[21:37:12] <bleathem> thanks!
[21:39:14] <lightguard_jp> lincolnthree: Any idea which plugins for Forge have been updated past Beta1?
[21:39:23] <lincolnthree> arquillian
[21:39:27] <lincolnthree> pauls plugins
[21:39:42] <lightguard_jp> What exactly does it do?
[21:39:49] <lincolnthree> lets you set up arquillian
[21:39:53] <lincolnthree> and create test classes for beans
[21:40:11] *** jamezp_afk is now known as jamezp
[21:40:12] <lightguard_jp> Okay, that part may help me then.
[21:40:43] <lightguard_jp> Setting up a test for owb to support wars (which it currently doesn't, but should).
[21:48:20] <hannelita> lightguard_jp: ping - I saw commit comments, I'll fix them asap
[21:51:08] <lightguard_jp> hannelita: Sure, no problem
[21:52:43] <hannelita> lightguard_jp: about you comment info faces-cfg... what do you mean by "using seam 3 standarts"? I mean, I copied this form idmconsole example :P
[21:53:13] <lightguard_jp> https://github.com/seam/build/blob/master/eclipse-jboss-community-formatter.xml
[21:55:48] <hannelita> oic IDE profiler
[21:56:12] *** msmigielski has quit IRC
[21:56:35] <hannelita> I think I caused some problems with whitespaces because I dont always use IDEs.... sometimes I write code into vim pr sublime
[21:56:56] <hannelita> this might have caused whitespace problems
[21:57:00] <lightguard_jp> I do a bunch of code in vim as well.
[21:57:18] <lightguard_jp> I try to run code through the formatter before I commit though, if I'm new to the formatting.
[21:57:31] <lightguard_jp> The JBoss Community standard isn't hard to remember though :)
[21:57:38] <lightguard_jp> Pretty much the Sun standard
[21:57:49] <lincolnthree> every time I see the word "Pretty" i get excited
[21:57:53] <lightguard_jp> w/ 128 right margin, spaces instead of tabs. 4 space indent.
[21:57:54] <lincolnthree> quit it
[21:57:56] <lincolnthree> ;)
[21:57:57] <lightguard_jp> I think those are the main ones.
[21:58:11] <hannelita> ok, sorry about that
[21:58:58] <lightguard_jp> hannelita: No problem
[21:59:32] <lightguard_jp> lincolnthree: I'm thinking I shouldn't probe further into that statement, probably get myself into trouble.
[21:59:43] <lincolnthree> lol
[22:00:33] <lightguard_jp> SASS is awesome: http://jaredhardy.com/sassy-buttons/
[22:01:23] <lincolnthree> what is SASS?
[22:01:44] <lightguard_jp> http://sass-lang.com/
[22:02:10] <lincolnthree> is it  javascript CSS library?
[22:02:16] <lightguard_jp> No, that's LESS
[22:02:21] <lightguard_jp> This is done in Ruby.
[22:02:27] <lightguard_jp> hannelita: I'm sure you know about SASS
[22:02:33] <lincolnthree> so you need to run ruby to use it?
[22:02:42] <lightguard_jp> lincolnthree: It's a css preprocessor
[22:02:48] <hannelita> lightguard_jp: yup, its very common into ruby projects
[22:02:55] <lincolnthree> So part of  the build?
[22:03:01] <lightguard_jp> lincolnthree: Yeah
[22:03:12] <lincolnthree> Would be nice to be able to use that.
[22:03:14] <lightguard_jp> lincolnthree: take a look at the examples on the site.
[22:04:18] <hannelita> lincolnthree lightguard_jp: Its like a haml for css
[22:04:32] <lightguard_jp> hannelita: I don't think lincolnthree knows what haml is
[22:05:30] <lincolnthree> i do
[22:05:41] <lightguard_jp> Okay, then, yes think of sass as haml for css
[22:05:48] <lightguard_jp> But that's only part of the story
[22:06:12] <lightguard_jp> You can define variables, create mixins, extract reusable bits of css into files and combine them all later, etc
[22:07:07] <hannelita> the best way to "feel" sass is trying the online editor, I think
[22:07:31] <lincolnthree> would be cool to build that into a web-framework
[22:07:50] <lincolnthree> imagine, a forge plugin to add SASSY to your java web project
[22:08:05] <lincolnthree> wonder if it runs on JRUBY
[22:08:06] <lightguard_jp> Yeah, adding sass wouldn't be too hard.
[22:08:08] <hannelita> or haml
[22:08:12] *** msmigielski has joined #seam-dev
[22:08:15] <lincolnthree> and if JRUBY could be invoked from a java app
[22:08:19] <lightguard_jp> lincolnthree: It's straight ruby, it works fine with jruby.
[22:08:19] <hannelita> yes, it runs on jruby
[22:08:27] <lightguard_jp> lincolnthree: Yep, that can be done too.
[22:09:54] <lincolnthree> this is what CSS *should be*
[22:11:14] <lightguard_jp> lincolnthree: exactly
[22:11:59] <lightguard_jp> lincolnthree: Can you create pom profiles with forge?
[22:13:17] <lincolnthree> lightguard_jp: not sure, i think there is an API for that
[22:13:20] <lincolnthree> not sure if there is a plugin
[22:13:56] <lincolnthree> no plugin yet afaik
[22:14:07] <lincolnthree> but there is an API
[22:15:19] *** alesj has joined #seam-dev
[22:17:32] *** msmigielski has quit IRC
[22:28:05] <lightguard_jp> hannelita: Which ruby version control did you end up using? rvm or the other one?
[22:28:21] <hannelita> lightguard_jp:  rvm
[22:28:44] <lightguard_jp> hannelita: What are you running on, Mac or a linux flavor?
[22:28:44] *** aslak has joined #seam-dev
[22:28:44] *** aslak has quit IRC
[22:28:44] *** aslak has joined #seam-dev
[22:29:09] <hannelita> lightguard_jp: I use both, mac and linux
[22:29:23] <lightguard_jp> Which linux distro?
[22:30:26] <hannelita> lightguard_jp: ubuntu 10.10
[22:30:49] <hannelita> lightguard_jp: But also works fine with fedora
[22:31:19] <clerum1> I'll be about 10 min late for the meeting fyi
[22:31:31] <clerum1> I'll catch up once I stumble in
[22:31:35] <lightguard_jp> hannelita: Oh, I know, I'm running it on FC15, was just curious what you were using
[22:31:38] <lightguard_jp> clerum1: no problem.
[22:33:04] *** koentsje has quit IRC
[22:33:42] *** mathieuancelin has joined #seam-dev
[22:37:18] *** maschmid has joined #seam-dev
[22:37:19] *** msmigielski has joined #seam-dev
[22:39:37] *** nilian has quit IRC
[22:44:29] *** kevinpollet has quit IRC
[22:44:53] *** msmigielski has quit IRC
[22:45:58] *** mathieuancelin has quit IRC
[22:46:06] <hannelita> Im wondering if there is any forge pugin to create  a torquebox project....
[22:46:13] <hannelita> *plugin
[22:46:19] <lincolnthree> not yet that i know of
[22:46:20] <lincolnthree> that would be cool
[22:47:14] <hannelita> hmmm....... Would be nice. When I get 72-hour-days and if none have implemented that I'll do it :P Would be really really useful
[22:55:58] <lightguard_jp> hannelita: I think you just volunteered.
[22:57:09] <hannelita> lightguard_jp: I always want to help :P but sometimes I feel bad because i dont have much time [sad] I really wish I could write much more code for confbuzz app, or more blog posts too :(
[22:57:44] <lightguard_jp> hannelita: Yeah, tell me about it. It isn't any better being a RHT employee
[22:58:07] *** aslak has quit IRC
[22:59:44] <hannelita> lightguard_jp: :( need 72-hour-days hehehe
[23:01:41] <lightguard_jp> hannelita: Nah, just got to shuffle things around
[23:01:52] <lightguard_jp> Shall we wait for Cody and others?
[23:02:24] *** ChanServ sets mode: +o lightguard_jp
[23:02:28] *** lightguard_jp sets mode: +o jbott
[23:03:17] *** jose_freitas has quit IRC
[23:03:51] *** lincolnthree has quit IRC
[23:06:15] *** mojavelinux has joined #seam-dev
[23:06:59] *** lincolnthree has joined #seam-dev
[23:07:09] <lightguard_jp> Welcome everyone!
[23:07:21] <lightguard_jp> I know we're missing a few people, but we'll continue anyway.
[23:07:26] <rruss> thx
[23:07:41] <lightguard_jp> #topic Follow up from the last meeting
[23:07:57] <lightguard_jp> The first on the list is Cloudbees.
[23:08:30] <lightguard_jp> #info I've opened a ticket to upgrade our account to FOSS Professional, however, it seems we're waiting for them to fix something on their end so we can do it ourselves
[23:08:51] <lightguard_jp> That was as of yesterday. Seeing how it's been over a week, I doubt anything has changed
[23:09:28] <lightguard_jp> Yes, no change
[23:09:46] <lightguard_jp> Next up is docs
[23:09:56] <lightguard_jp> #info I haven't been able to the Report docs
[23:10:05] <lightguard_jp> I also haven't seen George for a while.
[23:10:09] <lightguard_jp> hannelita: Have you talked to him lately?
[23:10:17] <hannelita> lightguard_jp: Its holiday here today
[23:10:27] <lightguard_jp> Okay, that may be why then.
[23:10:36] <lightguard_jp> #info I think JMS had some doc issues too.
[23:11:04] <lightguard_jp> Shane also put out a question about modules and ids for the combined doc build. Does anyone have anything to report or questions about this?
[23:11:59] <mojavelinux> ah, perhaps we should add the CI build as a topic to the f2f meeting
[23:12:06] <lightguard_jp> Oh, snap, forgot to start the meeting.
[23:12:07] <lightguard_jp> Shoot
[23:12:09] <lightguard_jp> #startmeeting
[23:12:10] <jbott> Meeting started Wed Sep  7 21:10:43 2011 UTC.  The chair is lightguard_jp. Information about MeetBot at http://wiki.debian.org/MeetBot.
[23:12:10] <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
[23:12:23] <lightguard_jp> don't mind me, just going to replay things
[23:12:24] <lightguard_jp> #topic Follow up from the last meeting
[23:12:25] *** jbott changes topic to "Follow up from the last meeting"
[23:12:39] <mojavelinux> moving to FOSS Professional is the right step if we continue to use CloudBees, but I think in parallel we need to make it very clear what our requirements are if we are to return to the JBoss infrastructure
[23:12:56] <lightguard_jp> #info I've opened a ticket to upgrade our account to FOSS Professional, however, it seems we're waiting for them to fix something on their end so we can do it ourselves
[23:12:59] <mojavelinux> that allows Rodney et al to negotiate if necessary the terms
[23:13:14] <lightguard_jp> #info I haven't been able to the Report docs
[23:13:23] <lightguard_jp> #info I think JMS had some doc issues too.
[23:13:40] <lightguard_jp> mojavelinux: Yes, we need to open up that discussion with Tobias
[23:14:09] <lightguard_jp> I know Burr me about Cloudbees and I told him we'd like to run on Openshift, but he didn't respond
[23:14:38] <lightguard_jp> We should probably enumerate those in the minutes
[23:14:44] <sbryzak> gooood morning
[23:14:48] <lightguard_jp> sbryzak: morning
[23:14:52] <lincolnthree> morning
[23:14:59] <sbryzak> oh my doppleganger is still here
[23:15:12] <lightguard_jp> Well, maybe we don't have to, I think the core RHT employees know what they are.
[23:15:20] <lightguard_jp> sbryzak: Want me to kick him?
[23:15:27] <sbryzak> if i suddenly disconnect it's because i killed the wrong rogue process
[23:15:33] <lightguard_jp> haha
[23:15:35] *** sbryzak_ has quit IRC
[23:15:42] <sbryzak> phew, cut the right wire
[23:16:18] <lightguard_jp> sbryzak: Since you're here, do you have update on the combined doc and id issues?
[23:16:26] *** jose_freitas has joined #seam-dev
[23:17:02] <sbryzak> you mean the docbook element ids?
[23:17:06] <lightguard_jp> Yes
[23:17:17] <sbryzak> well, i've fixed up the conflicting ones
[23:17:27] <sbryzak> it doesn't mean that the docs are perfect though
[23:17:47] <sbryzak> i'm sure that there's still plenty of chapter and section ids that aren't prefixed with the module code
[23:18:05] <sbryzak> but it's not a high priority issue to fix right now
[23:18:21] <lightguard_jp> We could go over it at the F2F
[23:18:52] <sbryzak> sure, we already have a documentation review
[23:18:55] <lightguard_jp> Yep
[23:19:15] *** rmartinelli has quit IRC
[23:20:01] <clerum1> here now
[23:20:10] <lightguard_jp> Great.
[23:20:15] *** ssachtleben has quit IRC
[23:20:17] <lightguard_jp> Next is the mail tests
[23:20:32] <lightguard_jp> clerum1: I think there was a pull request that went through about that, wasn't there?
[23:20:58] <clerum1> was just fixing an error in the example pom
[23:21:09] <lightguard_jp> #info sbryzak was going to help out with the mail tests, I think that's been figured out.
[23:21:17] <lightguard_jp> sbryzak: clerum1 Is that a correct statement? ^^
[23:21:19] <clerum1> that was keeping anything from running
[23:21:31] <lightguard_jp> gotta love maven
[23:21:31] <clerum1> it still quite broken
[23:21:37] <lightguard_jp> Okay.
[23:21:44] <sbryzak> i haven't looked at the mail tests yet
[23:21:46] <lightguard_jp> Sounds like it's still an action item then
[23:21:50] <sbryzak> we do have the testsuite sorted out though
[23:21:52] <lightguard_jp> Okay.
[23:22:01] <lightguard_jp> #action lightguard_jp Still needs to create the Report docs
[23:22:07] <sbryzak> so it's just a matter of updating mail with the new testsuite structure
[23:22:22] <lightguard_jp> #action sbryzak will continue to help with mail tests
[23:22:34] <lightguard_jp> there may be more to it than that though.
[23:22:43] <clerum1> it's probably simple and I'm working on porting over my main app to seam 3 and will need mail so I have more real time I can devote to it
[23:23:05] <lightguard_jp> great!
[23:23:06] <clerum1> but if someone and help me get it to a stable state with the build
[23:23:10] <clerum1> I can take over from there
[23:23:26] <clerum1> I'm still over my head when it comes to maven and arquillian
[23:23:29] <lightguard_jp> clerum1: I think Shane is your go to for that one.
[23:23:32] <clerum1> k
[23:23:44] <lightguard_jp> #topic Giving module leads "voice" in the channel.
[23:23:45] *** jbott changes topic to "Giving module leads "voice" in the channel."
[23:23:52] <lightguard_jp> lincolnthree: Would you like to talk about this?
[23:23:54] <lincolnthree> Sure
[23:24:11] <lincolnthree> So I had the idea that we could give all module-leads "voice" in the channel
[23:24:27] <lincolnthree> which basically means that they will show up at the top of the attendee list
[23:24:33] <lincolnthree> and have a "special" icon
[23:24:45] <lincolnthree> so that people can tell who to talk to when they have problems
[23:24:50] <lincolnthree> or who to start with
[23:24:56] <lincolnthree> when they join the channel for the first time
[23:24:57] <lincolnthree> etc
[23:25:07] <lincolnthree> it doesn't really do anything other than that
[23:25:12] <lincolnthree> it just makes module leads look cool
[23:25:42] <lightguard_jp> Anyone have any problems with that?
[23:25:48] <lincolnthree> i suppose that could be expanded from module lead to "initiative lead"
[23:25:54] <lincolnthree> so george is the community integrator
[23:26:00] <lincolnthree> and I believe hannelita is leading the docs initiative
[23:26:25] <lightguard_jp> Yeah
[23:26:59] <lightguard_jp> I don't hear anyone against it
[23:27:18] <lincolnthree> motion passes!!!
[23:27:20] <lincolnthree> ;)
[23:27:27] <lightguard_jp> #action lightguard_jp and mojavelinux will give "initative leads" auto voice in the channel.
[23:27:40] <lightguard_jp> #topic Next Hack Night
[23:27:41] *** jbott changes topic to "Next Hack Night"
[23:27:43] <hannelita> :)
[23:28:05] <lightguard_jp> We've dropped the ball again making noise about this, but we will be hacking on Faces tomorrow.
[23:28:19] <lightguard_jp> #info I have a list of JIRAs to look at
[23:28:35] <hannelita> I will write a blog post and tweet today then
[23:28:49] <lightguard_jp> https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SEAMFACES+AND+fixVersion+%3D+%223.1.0.Tracking%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide
[23:29:01] <lightguard_jp> For those interested in things that Brian would like fixed
[23:29:16] <lightguard_jp> bleathem: If you're here, anything you'd like to add?
[23:29:21] *** edburns is now known as edburns_away
[23:30:12] <lightguard_jp> Guess not :)
[23:30:27] <lightguard_jp> Regardless, I'll be here hacking on stuff, please come join
[23:30:45] <sbryzak> when does the hack night start?
[23:30:51] <sbryzak> is it today?
[23:30:56] <lightguard_jp> sbryzak: tomorrow.
[23:31:02] <sbryzak> ah, no problem
[23:31:08] <lightguard_jp> about 30 from the current time.
[23:31:29] <lightguard_jp> #info the hack nights are in the jboss.org calendar and also in the seam-dev google calendar
[23:31:52] <lightguard_jp> #topic Next Seam 3 release.
[23:31:52] *** jbott changes topic to "Next Seam 3 release."
[23:32:07] <lightguard_jp> sbryzak: Would you like to comment on the next release, if it'll be another beta or CR?
[23:32:16] <sbryzak> sure
[23:32:20] <sbryzak> the next release will be CR1
[23:32:39] <rruss> brevity is the soul of wit :)
[23:32:46] <sbryzak> the biggest thing to get finished for it is the testsuite overhaul
[23:32:52] <sbryzak> rruss: i'm not finished yet ;p
[23:33:09] <sbryzak> so maschmid has done a great job at refactoring the testsuite
[23:33:32] <sbryzak> we still have a couple of minor todo items to finish up on it
[23:33:39] <sbryzak> like adding code coverage, etc
[23:33:44] <sbryzak> but they aren't show stoppers for CR1
[23:34:08] <sbryzak> so as soon as we propogate the current structure to all other modules, we can think about doing the CR1 release
[23:34:26] <sbryzak> there's a few other things i'd like to see addressed too
[23:34:44] <sbryzak> i want to get jason's getting started guide into the ref docs
[23:34:54] <sbryzak> and we also need to review and update the examples
[23:35:03] <sbryzak> both of those things i'm sure we can address next week
[23:35:32] <sbryzak> oh, and i'll be pinging the module leads on seam-dev to find out if there's any blockers
[23:35:43] <sbryzak> but i anticipate the answer will be no
[23:36:41] <mojavelinux> I'm fine with the getting started guide in the ref docs, but recall that the primary purpose of this guide is to be on the project website
[23:36:43] <mojavelinux> front and center
[23:36:56] <lightguard_jp> sbryzak: Do we have a planned date for this release?
[23:37:31] <sbryzak> mojavelinux: that's fine, but it has to be in the docs also
[23:37:39] <sbryzak> that will be the first point of contact for many new users
[23:37:40] <mojavelinux> basically, I want the getting started guide cleanly integrated into the website, a native part of it. I want to avoid "linking out" to the documentation for them to get that information
[23:37:45] <mojavelinux> yep, that's fine
[23:38:00] <mojavelinux> I don't want the first point of contact to be the docs, though
[23:38:00] <sbryzak> lightguard_jp: no date, we can nail that down next week
[23:38:08] <lightguard_jp> Okay
[23:38:09] <mojavelinux> that's not what the industry has proved works for adoption
[23:38:18] <lincolnthree> mojavelinux: agreed
[23:38:26] <lightguard_jp> #info Keep an ear out next week for a date for CR1
[23:38:30] <mojavelinux> frameworks like play, rails, etc have proved that the integrated guide on the website is the key to success
[23:38:31] <lincolnthree> We just need to remember that this tutorial is for our web users
[23:38:37] <lincolnthree> first
[23:38:49] <mojavelinux> I hate to use one example so much, but basically play proves what works
[23:38:57] <lincolnthree> yep
[23:38:58] <sbryzak> i agree with that, but for a lot of users the first point of contact will be the docs and we can't change that
[23:39:08] <sbryzak> they'll download the seam distribution, and start reading the reference guide
[23:39:13] <mojavelinux> I still don't agree with that, not to say that they aren't important
[23:39:16] <mojavelinux> I don't think people start with the docs
[23:39:22] <mojavelinux> that's not been my experience talking to people
[23:39:23] <lincolnthree> sbryzak: do we have metrics on that?
[23:39:33] <mojavelinux> people rarely start with the docs...they start with the easy to get info on the website
[23:39:34] <sbryzak> many of the complaints on the forums are because of that exact issue
[23:39:43] <mojavelinux> docs are important though
[23:39:53] <lincolnthree> I'd like to add an action item
[23:39:59] <sbryzak> lincolnthree: metrics are people complaining on the forums
[23:40:00] <lincolnthree> add google analytics tracking to our docs
[23:40:06] <mojavelinux> I'm not saying they aren't, just that the website needs to be informative and bring them up to speed
[23:40:26] <lightguard_jp> lincolnthree: on the new site or the current one?
[23:40:29] <sbryzak> i agree, but i think the web site needs an overhaul first
[23:40:43] <mojavelinux> keep in mind, the forums are often people who are already partially adopting seam...i'm really talking about the people who don't even know about it yet, just discovering it
[23:40:50] <lincolnthree> ok, let's not get too far off track
[23:41:00] <lincolnthree> the stuff jason is working on is for our new audience
[23:41:03] <mojavelinux> the current site is dead to me, whenever I say website, I'm not referring to the current site
[23:41:04] <lincolnthree> the people who have never used it before
[23:41:30] <lincolnthree> the people who haven't even downloaded it yet :)
[23:41:30] <mojavelinux> keep in mind, the people who haven't used seam are a massively huge pool of people compared to those who have
[23:41:36] <mojavelinux> like 100,000 : 1
[23:42:00] <hannelita> IMHO there are some points that ppl get scared abou seam - like maven
[23:42:24] <sbryzak> hannelita: are you saying that people are scared of maven in general?
[23:42:29] <mojavelinux> yep, and the getting started guide should allow them to either not really think much about maven
[23:42:30] <hannelita> Seam is not like rails, where you type sudo gem install rails and go on using it
[23:42:37] <lightguard_jp> sbryzak: Yeah, I've done some Maven 101 on the forums
[23:42:44] <mojavelinux> or to make it seem not scary (even though maven is always a little scary hehe)
[23:42:49] <lightguard_jp> But on the forums it hasn't come up that often
[23:42:51] <lincolnthree> hannelita: it should be with Forge, but that requires an install itself
[23:42:55] <lightguard_jp> maybe hannelita has more people talking to her.
[23:43:00] <hannelita> I mean that you must have a big tech skill set to start using seam
[23:43:10] <sbryzak> hmm, perhaps we should have a basic maven guide in the docs
[23:43:12] <mojavelinux> true, thought I think a guide can lower that barrier
[23:43:20] <mojavelinux> I'd rather maven be transparent
[23:43:34] <mojavelinux> we just have to make it that way, at least for them to get an app running
[23:43:34] <lincolnthree> hannelita: you're exactly right
[23:43:43] <lincolnthree> there is no good way to "get started fast" with Seam 3 atm
[23:43:45] <hannelita> I just said maven as an example
[23:43:47] <mojavelinux> and, btw, I would like a branch of this getting started guide to use forge
[23:43:53] <mojavelinux> I think it should have like two "tracks"
[23:44:02] <lincolnthree> mojavelinux: yes, completely
[23:44:06] <mojavelinux> forge needs to be part of this guide in some way (though not the first cut)
[23:44:19] <lincolnthree> which again, means we will need plugins to be written to make that easier
[23:44:20] <sbryzak> ah, i thought it was already
[23:44:23] <lightguard_jp> mojavelinux: lincolnthree the current source should allow for that
[23:44:32] <lightguard_jp> using jquery to hide / show a track / section
[23:44:47] <hannelita> I'll write some point about ppl's problems to lear seam after the meeting
[23:45:04] <mojavelinux> I think the guide needs to have two "looks", one without forge and one with it...because like it or not, some people will want to take the 100% manual approach...and we can also get "seam requires forge" complaints if we don't show both approaches
[23:45:12] <lightguard_jp> the current docs in git are fairly polished, I think. But it will probably always be a moving work in progress.
[23:45:24] <mojavelinux> yes, it should be organic
[23:45:34] <mojavelinux> and we should solicit a lot of feedback on it
[23:45:52] <lightguard_jp> I think we should probably pick this up next week at the f2f. Probably a lot of discussion to go on this.
[23:46:03] <mojavelinux> definitely
[23:46:55] <lightguard_jp> Are there other questions about the CR1 release?
[23:47:03] <sbryzak> would we write that as two separate versions of the guide?
[23:47:11] <sbryzak> or would they be combined
[23:47:18] <mojavelinux> and, btw, hanneli, i'm really interested in any feedback or perspective you can give...I know getting started is tough, and we want to do anything we can to reduce that barrier, make it pleasant
[23:47:37] <lincolnthree> sbryzak: each step should probably have a "with forge" and "without forge" track
[23:47:53] <mojavelinux> sbryzak: I think w/ a little jquery magic we can have them share the same space
[23:47:57] <lightguard_jp> lincolnthree: sbryzak that was what I had envisioned
[23:47:58] <mojavelinux> a toggle
[23:48:06] <mojavelinux> yep
[23:48:14] <lincolnthree> that would be perfect
[23:48:14] <sbryzak> sounds good
[23:48:18] <mojavelinux> and w/ awestruct, doing that jquery would be so possible
[23:48:29] <mojavelinux> this is what such a tool unlocks
[23:48:38] <lightguard_jp> mojavelinux: If you'd like to take a look at the source that I have I think you can see what I was thinking.
[23:48:56] <hannelita> mojavelinux: Ok, ill send community feddback i receive on my blog
[23:49:01] <mojavelinux> yep, I plan to when I sit down to review it, hopefully before the meeting
[23:49:30] <mojavelinux> hanneli great, we are ready for the news, good or bad :)
[23:49:36] <lightguard_jp> Shall we move on to the last topic?
[23:49:52] <lightguard_jp> hannelita: We can take any bad news, we've certainly had a lot of it the past year.
[23:50:09] <lincolnthree> lightguard_jp: ;)
[23:50:34] *** mbg has quit IRC
[23:50:35] <lightguard_jp> #topic Next week's meeting
[23:50:36] <hannelita> lightguard_jp: Ok, I'll show you some feedback right after the meeting
[23:50:36] *** jbott changes topic to "Next week's meeting"
[23:50:47] <lightguard_jp> Do we want to hold a meeting next week?
[23:50:57] <lightguard_jp> The core RHT devs will all be in Toronto
[23:51:10] <sbryzak> let's skip next week's meeting
[23:51:17] <mojavelinux> I think that's the right choice
[23:51:23] <lightguard_jp> Okay then :)
[23:51:37] <lightguard_jp> #agreed Next week's meeting will be skipped
[23:51:41] <rruss> just means more for the following week
[23:51:43] <mojavelinux> having to worry about the meeting while we are in the f2f might really break the flow...better for us to summarize what ideas we worked out the following week
[23:52:24] <rruss> that's a good point, mojavelinux ... how should we disseminate some of the decisions from the meeting?
[23:52:30] <mojavelinux> because by wednesday, we'll only have half the story, and it may even change by the end of the week...what we should focus on is taking good notes and make it easy to share them
[23:52:53] *** oskutka has joined #seam-dev
[23:52:57] <mojavelinux> at the unconference community leadership summit, we always had a designated note taker in any roundtable
[23:53:08] <lightguard_jp> I think if there are major decisions an email at the end of the would be good to get the word out to the rest of the community.
[23:53:09] <mojavelinux> then we posted those notes on a wiki (we can use our own wiki of course)
[23:53:29] <mojavelinux> we can always take those and distill them into something more concise, the important part is capturing
[23:53:35] <lightguard_jp> Or we could do a sticky post on the forums maybe
[23:53:40] <rruss> ah, there we go ... post the notes on a wiki
[23:53:43] <mojavelinux> I think we should also try to record any organized discussion...any Android or iPhone can do it
[23:54:04] <rruss> via ustream?
[23:54:13] *** oskutka has quit IRC
[23:54:17] <lightguard_jp> I think mojavelinux was just thinking of the audio
[23:54:19] <mojavelinux> I wouldn't publish the audio publically, just because we want to speak freely, but it can be an excellent backup for revising the notes
[23:54:33] <rruss> ah, right
[23:55:13] <mojavelinux> so the audio would be something the note taker would capture...so for each segment on the meeting agenda, we should have someone setup to take notes...it is usually different than the person leading the discussion (you can't do both)
[23:55:36] <mojavelinux> we should also have apps ready for recording audio on the phones...I've got a voice recorder from the android market on my phone
[23:55:53] <lincolnthree> i have one too
[23:55:56] <lightguard_jp> iPhone comes with one
[23:56:04] <lincolnthree> iphone sucks
[23:56:06] <lightguard_jp> I think we're covered for recording
[23:56:09] <mojavelinux> yeah, because otherwise you would have to pay for it :)
[23:56:19] <mojavelinux> hahaha, j/k
[23:56:21] <lincolnthree> brevity
[23:56:22] <lincolnthree> ;)
[23:56:25] <lightguard_jp> lincolnthree: I'm not taking the bait
[23:56:28] <lincolnthree> haha
[23:56:33] <lightguard_jp> That's all I had for the meeting.
[23:56:39] <mojavelinux> cool
[23:56:43] <lightguard_jp> Does anyone have any other topics they'd like to discuss?
[23:57:26] <lightguard_jp> Sounds like a no
[23:57:37] <lightguard_jp> I think that wraps it up for this week's meeting
[23:57:44] <lightguard_jp> Thanks everyone for attending!
[23:58:01] <rruss> thx lightguard_jp :)
[23:58:03] <lightguard_jp> #endmeeting
[23:58:13] <mojavelinux> thanks jason
[23:58:18] *** jbott changes topic to "Seam 3.0.0.Final has been released! Development discussions for Seam (seamframework.org). Join #seam for user discussions.  See http://seamframework.org/Seam3/Chat for logs and more info.  TeamSpeak 3 server is available for Seam devs at 216.6.228.98:10024, password: seam-dev"
[23:58:18] <jbott> Meeting ended Wed Sep  7 21:56:38 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[23:58:18] <jbott> Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-09-07-21.10.html
[23:58:18] <jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-09-07-21.10.txt
[23:58:18] <jbott> Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-09-07-21.10.log.html
[23:58:32] <mojavelinux> docs.google.com 404 not found
[23:58:34] <mojavelinux> #fail
[23:58:43] *** daniel_hinojosa has joined #seam-dev
[23:58:48] <lincolnthree> yea i noticed that earlier today
[23:59:02] *** maschmid has quit IRC





top