[00:18:03] *** stuartdouglas_ has joined #seam-dev
[01:05:06] <bleathem> clerum cool, I wouldn't mind seeing what the code looks like. do you have a github link?
[01:31:11] *** stuartdouglas_ has quit IRC
[01:38:06] <clerum> works for now - https://github.com/seam/mail/blob/master/impl-velocity/src/main/java/org/jboss/seam/mail/templating/velocity/VelocityClassPathTemplate.java
[01:38:19] <clerum> seems like there should be a shorter way
[01:43:16] <jbossbot> git [mail] push master b69c57f.. Cody Lerum use BeanManagerAware interface
[01:43:16] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/6f70057...b69c57f
[03:20:16] *** lincolnthree has joined #seam-dev
[03:42:51] *** johnament has joined #seam-dev
[03:43:45] *** gastaldi has joined #seam-dev
[03:43:51] <gastaldi> hey all !!
[03:44:08] <gastaldi> Hello sbryzak, johnament !
[03:44:11] <johnament> gastaldi: hi
[03:44:55] 
[03:45:54] <johnament> gastaldi: i always leave it up as busy.  it's only ever on on my phone
[03:46:32] <johnament> gastaldi: i'm also traveling this weekend, but wanted to try to get the answers to your questions.
[03:49:52] *** gastaldi has quit IRC
[03:55:25] *** johnament has quit IRC
[04:00:10] *** gastaldi has joined #seam-dev
[04:00:15] <gastaldi> Hello again
[04:00:48] 
[04:03:14] <gastaldi> sbryzak: You were saying that a GIT repository could be created based on current modules.
[04:04:21] <gastaldi> sbryzak: About a new Seam JCR Module
[04:07:16] *** johnament has joined #seam-dev
[04:07:36] <gastaldi> welcome back johnament
[04:08:04] <johnament> gastaldi: cruddy access in the hotel.
[04:09:36] <gastaldi> I guess sbryzak is sleeping now
[04:10:44] <gastaldi> johnament: Do u have anything implemented on GIT ?
[04:10:49] <johnament> he seems to keep weird hours.
[04:10:53] <gastaldi> about the new CDI module proposal ?
[04:11:02] <johnament> gastaldi: no, when I get home I'll dump the code
[04:11:07] <gastaldi> oh, ok
[04:11:13] <johnament> gastaldi: probably tuesday
[04:11:18] <gastaldi> nop
[04:11:46] <johnament> gastaldi: the code as of now can do basic object injection (session primarily) and the bootstrapping using factory pattern.
[04:11:53] <gastaldi> great
[04:11:58] <johnament> gastaldi: there's also some code that handles the security context binding
[04:12:40] <johnament> gastaldi: there is one item that I think we need to pitch to sbryzak & stuartdouglas which would be moving SeamManaged into solder, since we need to use the same idea in JCR.
[04:12:49] <gastaldi> I was thinking about the possibility to inject Repositories based on BindingType also: Ex: @Repository @MyWorkspace Repository repo;
[04:13:17] <johnament> gastaldi: right now, I use a generic @NamedRepository that maps back to a single repository that was configured.
[04:13:31] <johnament> gastaldi: e.g. @NamedRepository("MyWorkspace")
[04:13:48] *** lincolnthree has left #seam-dev
[04:14:03] <johnament> gastaldi: which would be the underlying pattern for @MyWorkspace (which would be app developer specific)
[04:14:59] <johnament> gastaldi: the problem you'll probably run into, which I ran into early last year, has to do with not creating too many connections within a single request.
[04:15:18] <gastaldi> I see
[04:15:36] <gastaldi> MyWorkspace as a BindingType to avoid string usage
[04:15:41] <johnament> gastaldi: it works, but it ends up being too slow.  but it does depend on how you're configured
[04:15:50] <johnament> gastaldi: right, but the API won't know about it.
[04:16:09] <johnament> gastaldi: the API has to remain agnostic to underlying configuration.
[04:16:20] <gastaldi> johnament: sure thing
[04:16:52] <johnament> gastaldi: you would likely define @MyWorkspace by including the @Qualifier in the binding type, and also @NamedRepository("MyWorkspace")
[04:17:04] <johnament> gastaldi: and that would be how you bridge from application to api.
[04:17:14] <gastaldi> johnament: agreed
[04:17:51] <gastaldi> Just to clarify my mind: @NamedRepository injects a Repository object ?
[04:18:25] <gastaldi> Why not keep to a single repository ?
[04:18:38] <gastaldi> I mean, using only @Repository and @Session for instance
[04:18:41] <johnament> gastaldi: the impl provides a @Produces @NamedRepository public Repository create
[04:18:50] <johnament> gastaldi: why would you limit what the app developer can do?
[04:19:13] <gastaldi> let me check the JCR 2.0 api..
[04:19:13] <johnament> gastaldi: AFAIK, neither modeshape nor jackrabbit restrict to a single repository
[04:20:23] <gastaldi> Oh, I see, that depends on RepositoryFactory implementation
[04:20:39] <gastaldi> I mean, a RepositoryFactory may create multiple Repositories
[04:21:30] <gastaldi> But configuring each RepositoryFactory is implementation-dependent
[04:21:58] 
[04:23:05] 
[04:23:35] <gastaldi> @Workspace may sound better
[04:24:04] <gastaldi> Just brainstorming in here..
[04:24:51] <johnament> gastaldi: my api includes workspace & repo as separate annotations.
[04:25:20] <johnament> gastaldi: i figure, we need app to provide the impl of @Produces Map<String,String> getRepositoryProperties() that we can provide back to the factory
[04:25:22] <gastaldi> ok
[04:25:41] <gastaldi> We may need a qualifier for that also
[04:25:51] <johnament> @JcrConfiguration ?
[04:26:23] <gastaldi> Is there something alike in seam-persistence ?
[04:26:58] <johnament> for config?
[04:27:29] <johnament> i mentioned @SeamManaged because it matches the same thread local pattern we would want to look at.
[04:27:51] <gastaldi> hum.
[04:28:19] <johnament> I think the qualifier for the config should be specific to JCR
[04:28:47] <gastaldi> yeah, I agree to that too
[04:29:47] <gastaldi> If only existed a XML descriptor for configuring repositories ...
[04:29:58] <johnament> ?
[04:30:09] <gastaldi> Then the configuration would be out of the scope of this module
[04:30:30] <johnament> well, nothings stopping us from recommending that they use seam-config-xml to create a virtual producer
[04:31:00] <johnament> or even just configure up the property on the bean class.
[04:31:07] <gastaldi> yeah
[04:31:31] <gastaldi> @JcrConfiguration could be nice for instance
[04:31:50] <johnament> e.g. <jcr:JcrConfiguration><jcr:configSettings><map><entry><key>org.modeshape.config.URL</key><value>file://path/to/modeshape.xml</value></entry></map></...
[04:32:09] 
[04:32:28] <johnament> gastaldi: i figure, the main bootstrapping has to happen in an application scoped bean, we don't want to create multiple per app.
[04:32:28] <gastaldi> keeping separated from the code
[04:32:35] <gastaldi> agreed
[04:32:55] <gastaldi> Normally it would be managed by the AS
[04:33:05] <johnament> gastaldi: in that scenario, we provide APIs that support that structure.  e.g. there would be a class JcrConfiguration (not qualifier) that has a property configSettings that is a Map<String,String>
[04:33:06] <gastaldi> In CDI as a Application Scoped bean, allright
[04:33:10] *** daniel_hinojosa has quit IRC
[04:33:25] <johnament> AppServer?
[04:33:36] <gastaldi> yeah
[04:33:51] <gastaldi> registered as a JNDI binding
[04:34:03] <gastaldi> Application Scoped in CDI language
[04:34:22] *** daniel_hinojosa has joined #seam-dev
[04:34:25] <johnament> well, I ran the configuration stuff in front of Randall (modeshape project lead).  ModeShape accepts a single config option for the factory, which reprsents the URL describing the config
[04:34:54] <johnament> that url can be JNDI style or classpath/file path that generates a JcrEngine
[04:35:03] <johnament> (ModeShape class for managing the life cycle)
[04:35:26] <johnament> that's where the repositories come from
[04:35:30] <gastaldi> ok, jackrabbit just need to tell where the XML configuration resides
[04:36:12] <johnament> in the config options?
[04:36:15] <johnament> for the factory?
[04:36:26] <gastaldi> as I can recall, yes
[04:36:26] <johnament> i haven't done much with jackrabbit
[04:36:46] <johnament> that's essentially what modeshape is doing.
[04:37:28] <gastaldi> Do you think that this module should be tested primarily on modeshape or jackrabbit also ?
[04:37:53] <johnament> we should have profiles that test both
[04:38:07] <gastaldi> ok
[04:38:16] <johnament> should we only support JCR 2.0?
[04:38:37] <johnament> e.g. modeshape 2.4 and jackrabbit 2.2.4
[04:39:00] <gastaldi> I think so
[04:39:11] <gastaldi> JCR 1.0 was very limited
[04:39:22] <johnament> well it has no bootstrap consistency
[04:39:35] <johnament> so bootstrapping would be platform dependent.
[04:39:49] <johnament> so we would end up with both API & IMPL that are platform dependet
[04:39:51] <johnament> dependent
[04:40:12] <gastaldi> That would complex things up
[04:40:39] <gastaldi> But bootstraping in JCR 2.0 is limited only in the properties
[04:41:01] <gastaldi> I mean, a JCrConfiguration bean in ApplicationScope with a Map on it will serve
[04:41:41] <gastaldi> At least for a 1.0 version
[04:42:14] <johnament> my only concern is that we should also provide a solution for someone who doesn't want to use seam-config-xml
[04:42:44] <gastaldi> Then those could @Specialize that bean
[04:43:15] <gastaldi> wdyt ?
[04:44:07] <johnament> you mean CDI-91 ?
[04:44:09] <jbossbot> jira [CDI-91] Allow a producer to specialize a regular bean [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-91
[04:45:12] <gastaldi> yeah
[04:45:36] 
[04:45:59] <gastaldi> How would you use this new module ?
[04:46:38] <gastaldi> I would use it to inject Repositories and Sessions for instance
[04:46:48] <johnament> right
[04:47:50] <gastaldi> Ok, then, having a @Produces @JcrConfiguration Map<String,String> createMap() would suffice this requirement, right ?
[04:47:55] <johnament> the problem though is in order to create those, the api needs to own the factory
[04:48:40] <gastaldi> Maybe Map<String,String> createConfiguration() would be an interface
[04:48:45] <johnament> well, my point is that the class that has the configuration can be configured via seam-config-xml or you can inject into it.
[04:48:47] <gastaldi> that MUST be implemented
[04:49:09] <johnament> I don't like that idea
[04:49:24] <gastaldi> why not ?
[04:49:31] <johnament> it doesn't seem very CDI oriented
[04:49:35] <gastaldi> humm
[04:49:52] 
[04:50:02] <johnament> well, I think we've gotten it listed.
[04:50:34] <johnament> either you define a producer that is qualified a certain way or you specialize the bean in XML
[04:50:59] <johnament> when you specialize in XML, it removes the injection point dependency
[04:51:15] <johnament> or you can do a virtual producer.
[04:51:29] <johnament> i would prefer a virtual producer, since it allows us to separate API and IMPL cleanly
[04:51:40] <johnament> but i don't think we have to restrict from those 3 options
[04:51:52] <johnament> all three can exist simultaneous
[04:52:44] <johnament> i don't think we should require the app developer to implement an interface, especially when they can just produce
[04:53:07] <gastaldi> Ok, so a @Kc
[04:53:09] <gastaldi> sorry
[04:53:19] <gastaldi> @JcrConfiguration qualifier
[04:53:28] <johnament> or similar
[04:53:36] <gastaldi> in a Map<String,String>
[04:54:01] <johnament> so the injection point in the bean would be @Inject @JcrConfiguration Map<String,String> configSettings;
[04:54:17] <gastaldi> Or the app developer could produce the Repository itself
[04:54:25] <gastaldi> by looking up the JNDI tree
[04:54:40] <johnament> in ModeShape, it's not required to put the repository in JNDI
[04:55:05] 
[04:55:14] <johnament> likewise
[04:55:23] <johnament> but we shouldn't require it to be in JNDI to make it all work.
[04:55:27] <gastaldi> sure
[04:55:32] <johnament> we could add support for JNDI lookup to be easier.
[04:55:54] <johnament> e.g. @Inject @JNDIRepository("jcr/MyRepo") Repository repo;
[04:56:16] <gastaldi> maybe that would be part of RepositoryFactory impl also
[04:56:21] <johnament> possibly.
[04:56:39] <johnament> but i gotta run for the night.  need sleep.  email me, we'll figure out more stuff.
[04:56:44] <gastaldi> ok, me too
[04:56:49] <johnament> i think we made some good progress here.
[04:56:53] <gastaldi> Talk to ya tomorrow.
[04:56:56] <gastaldi> sure thing
[04:57:19] <gastaldi> see ya
[04:57:24] <johnament> see ya
[04:57:36] *** gastaldi has quit IRC
[04:57:39] *** johnament has quit IRC
[04:58:08] *** daniel_hinojosa has quit IRC
[06:32:59] *** daniel_hinojosa has joined #seam-dev
[07:04:29] *** daniel_hinojosa has quit IRC
[07:23:35] *** lukaszlenart has joined #seam-dev
[07:32:24] *** daniel_hinojosa has joined #seam-dev
[08:09:10] *** jharting has joined #seam-dev
[08:13:37] *** oskutka has joined #seam-dev
[08:33:09] *** marekn has joined #seam-dev
[08:50:47] *** mgencur has joined #seam-dev
[08:53:43] *** maschmid has joined #seam-dev
[08:56:04] *** oskutka1 has joined #seam-dev
[08:57:59] *** oskutka has quit IRC
[08:58:54] *** oskutka1 is now known as oskutka
[09:17:50] *** maschmid_ has joined #seam-dev
[09:18:25] *** maschmid has quit IRC
[09:26:33] *** maschmid_ is now known as maschmid
[09:31:27] *** daniel_hinojosa has quit IRC
[09:41:20] *** shervin_a has joined #seam-dev
[10:17:23] *** oskutka has quit IRC
[10:21:47] *** koentsje has joined #seam-dev
[10:34:22] *** oskutka has joined #seam-dev
[10:54:32] *** alesj has joined #seam-dev
[12:01:13] *** kpiwko has joined #seam-dev
[12:13:50] *** sannegrinovero has joined #seam-dev
[12:45:44] <jbossbot> git [rest] push master e806ca3.. Jozef Hartinger Added default build profile
[12:45:45] <jbossbot> git [rest] push master b3b56cd.. Jozef Hartinger whitespace
[12:45:45] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/8165e4e...b3b56cd
[13:31:01] *** emmanuel has joined #seam-dev
[13:38:05] *** rruss has joined #seam-dev
[13:38:18] *** rruss has quit IRC
[13:48:50] *** emmanuel has quit IRC
[14:05:54] *** oskutka has quit IRC
[14:14:35] *** emmanuel has joined #seam-dev
[14:31:18] *** jharting has quit IRC
[14:31:39] *** jose_freitas has joined #seam-dev
[15:02:14] *** tsurdilo has joined #seam-dev
[15:05:50] *** lincolnthree1 has joined #seam-dev
[15:16:46] <jose_freitas> where's the link for the new naming conventions used by seam?
[15:31:08] <lincolnthree1> jose_freitas: which naming conventions?
[15:31:15] <lincolnthree1> class & variables?
[15:31:23] *** lukaszlenart has left #seam-dev
[15:37:10] <lincolnthree1> http://seamframework.org/Seam3/DevelopmentGuidelines
[15:38:39] *** emmanuel has quit IRC
[15:44:54] *** epbernard has joined #seam-dev
[15:44:54] *** epbernard is now known as emmanuel
[15:47:14] <jose_freitas> thanks lincolnthree1
[15:55:11] *** emmanuel has quit IRC
[15:59:39] *** marekn has quit IRC
[16:09:41] *** balunasj has joined #seam-dev
[16:16:39] <clerum>  lincolnthree1: ping
[16:16:42] *** tsurdilo has quit IRC
[16:16:45] <lincolnthree1> clerum: pong
[16:17:00] *** tsurdilo has joined #seam-dev
[16:19:06] <clerum> so I worked on the email attachment via interface
[16:19:09] <clerum> https://gist.github.com/926b945eda871ad3f102
[16:19:26] <clerum> is that what you were thinking on that?
[16:19:46] <lincolnthree1> Yeah! That looks good. I might tweak the names slightly
[16:19:55] <clerum> yeah I was going to ask about that
[16:19:58] <lincolnthree1> ClassPathEmailAttachment
[16:20:01] <lincolnthree1> FileEmailAttachment
[16:20:03] <clerum> I'm not happy with the names
[16:20:05] <lincolnthree1> URLEmailAttachment
[16:20:23] <clerum> cool. wasn't sure if the classes should stay together when listed
[16:20:31] <clerum> for ease of finding
[16:20:37] <clerum> but thats what javadocs are for
[16:20:43] <lincolnthree1> SimpleEmailAttachment (for people who just want to set the bytes themselves?)
[16:20:50] <lincolnthree1> Yeah that's always a concern I have
[16:21:12] <lincolnthree1> Thought about InputStreamEmailAttachment ?
[16:21:15] <clerum> right now they all extend base
[16:21:18] <clerum> BaseEmailAttachment
[16:21:20] <lincolnthree1> Okay great
[16:21:23] <clerum> which is backed by bytes
[16:21:30] <clerum> which they all are acutally buidling
[16:21:37] <lincolnthree1> perfect
[16:21:46] <clerum> the constuctors of each are just converting what you pass in into bytes
[16:22:04] <clerum> yeah I acutally like that because I can easily add InputStreamFileAttachment
[16:22:21] <clerum> without adding more methods to the MailMessage api
[16:22:55] <lincolnthree1> :-D
[16:23:15] <clerum> I have an entity in my seam2 app called FileMeta and I could write my own FileMetaEmailAttachment
[16:23:24] <clerum> so yeah you convinced me :-)
[16:23:45] <lincolnthree1> woot, yeah. i think you could still do the same thing your way, but it would be a little less clear
[16:23:51] <lincolnthree1> you'd have to extend the class
[16:23:55] <lincolnthree1> which is always risky
[16:24:14] <clerum> would have been a pain
[16:24:45] *** balunasj is now known as balunasj_busy
[16:24:48] <lincolnthree1> what did you think about having the MailMessage itself responsible for unique attachment IDs?
[16:24:51] <clerum> doing this - https://github.com/seam/mail/blob/master/api-base/src/main/java/org/jboss/seam/mail/core/EmailContact.java and this https://github.com/seam/mail/blob/master/examples/sendmail/src/main/java/org/jboss/seam/mail/example/Person.java
[16:25:03] <clerum> made a huge diff in my personal app
[16:25:11] <lincolnthree1> Yeah!
[16:25:14] <clerum> being able to use my own user entities
[16:25:22] <lincolnthree1> That's huge
[16:25:34] <clerum> and not having to translate them each time into InternetAddress
[16:25:59] <clerum> not following on the attachment id's
[16:26:29] <lincolnthree1> right now each EmailAttachment is responsible for having a unique ID, right?
[16:26:34] <clerum> correct
[16:26:37] <lincolnthree1> that's why you do the UUID stuff
[16:26:39] *** adamw1pl has joined #seam-dev
[16:26:47] <lincolnthree1> do you think it makes sense for the attachments to know their own IDs?
[16:26:55] <lincolnthree1> or should MailMessage know the IDs for them?
[16:27:06] <lincolnthree1> Since MailMessage is really the one that cares, right?
[16:27:15] <lincolnthree1> Just a thought I had.
[16:27:26] <clerum> refreshing my memory....one sec
[16:27:52] <clerum> it has to do with having inline attachments being used as <img src="..."> in html emails
[16:27:59] <clerum> the src is the uuid
[16:28:11] <lincolnthree1> ah, okay
[16:29:07] <lincolnthree1> But yeah, I would definitely put
[16:29:16] <clerum> attachments end up in a map
[16:29:26] <lincolnthree1>  @see org.jboss.seam.mail.api.FileEmailMessage
[16:29:27] <clerum> so users can look them up by "seamlogo.png" when templating
[16:29:32] <lincolnthree1>  @see org.jboss.seam.mail.api.InputStreamEmailMessage
[16:29:44] <lincolnthree1> in the EmailMessage Interface Javadoc
[16:29:50] <clerum> then I just insert the uuid into the html
[16:29:56] <lincolnthree1> ok
[16:29:58] <lincolnthree1> so what I am asking is
[16:30:09] <lincolnthree1> should the attachments really be responsible for generating a UUID?
[16:30:35] <lincolnthree1> don't they have to have unique filenames anyway?
[16:31:06] <clerum> I suppose. I'll have to read the rfc again
[16:31:15] <lincolnthree1> sorry, just curious :)
[16:31:20] <clerum> I have never seen the cid  be anything but hashes
[16:31:26] <lincolnthree1> hmmm
[16:31:32] <clerum> could be a hash of the filename too I suppose
[16:31:46] <clerum> oh and filename can be null
[16:31:48] <clerum> :-)
[16:31:56] <clerum> ical invites have a null filename
[16:32:04] <lincolnthree1> ah hm
[16:32:13] <lincolnthree1> so that brings me back to the original question
[16:32:45] <lincolnthree1> which is if .addAttachment( myAttachment ) should be responsible for generating the unique IDs
[16:33:25] <clerum> I would expect an unique id in myAttachment
[16:33:50] <clerum> right now the myAttachment is getting added to a backing object called EmailMessage
[16:34:22] <clerum> https://github.com/seam/mail/blob/master/api-base/src/main/java/org/jboss/seam/mail/core/EmailMessage.java
[16:34:47] <clerum> which is what stores all the info about the message right up until the point it is end
[16:34:49] <clerum> sent
[16:35:13] <clerum> so if you don't pass something in with a unique contentId
[16:35:38] *** epbernard has joined #seam-dev
[16:35:38] *** epbernard is now known as emmanuel
[16:35:40] <clerum> then before templating I would have to rip through all those Attachments and set a cid
[16:36:02] <clerum> or add in the MailMessageImpl
[16:36:09] <clerum> I could do it there I guess
[16:36:33] <clerum> the interface would just have expose a setContentId
[16:36:38] <lincolnthree1> what if private Collection<EmailAttachment> attachments = new ArrayList<EmailAttachment>(); were a map?
[16:36:48] <lincolnthree1> the key being the EmailAttachment, the value being the UUID hash
[16:37:03] <lincolnthree1> ah, but i see your issue
[16:37:16] <clerum> I was just thiking about switching it to a map
[16:37:23] <clerum> but fileName as key and EmailAttachment as value
[16:37:26] <lincolnthree1> you get the list of emails as a Collection
[16:37:48] <lincolnthree1> so there's no way to associate the UUID with the message unless you return the map
[16:37:54] <lincolnthree1> (a map)
[16:38:15] <lincolnthree1> So it comes down to this.
[16:38:27] <lincolnthree1> Is centralizing the UUIDs going to make life simpler for developers in any way?
[16:38:38] <lincolnthree1> Is it going to be easier to change later?
[16:40:52] <clerum> so I could do this
[16:41:26] <clerum> the EmailAttachment interface would have to implement get/set ContentId
[16:41:32] <clerum> then on the impl I can do
[16:42:25] <clerum> https://gist.github.com/9519fcd7d7f7f05b6730
[16:42:58] <clerum> or I can have a different object acutally storing the attachment in the EmailMessage
[16:43:05] <lincolnthree1> hm. I'm not sure that's better
[16:43:11] <lincolnthree1> I think it's probably ok the way it is
[16:43:12] <clerum> and just eliminate the contentId
[16:43:21] <lincolnthree1> that would be a way to go
[16:43:40] <lincolnthree1> AttachedAttachment, lol
[16:43:53] <clerum> yeah just wondering it using the memory to create those new objects was worth the saving of hiding the content id
[16:44:00] <lincolnthree1> Objects are cheap
[16:44:27] <clerum> the other concern was that in the user was then looking at the EmailMessage object
[16:44:35] <clerum> the Attachments are now in a different form
[16:44:39] *** emmanuel has quit IRC
[16:44:55] <lincolnthree1> Question
[16:45:06] <lincolnthree1> is there any reason for a developer to know the contentId of an email attachment?
[16:45:32] <lincolnthree1> or is it an implementation detail?
[16:45:40] <clerum> impl detail really
[16:46:07] <lincolnthree1> ok, so is it possible the contentId could be stored internally until it is needed?
[16:46:40] <lincolnthree1> What consumes it?
[16:47:03] <clerum> it's required for all attachments in the acutal message
[16:47:08] <clerum> MimeMessage
[16:47:13] <clerum> and during templating
[16:47:22] <clerum> for inline attachments in html
[16:47:30] <lincolnthree1> So other internal APIs need to be able to access the ContentId
[16:47:48] <clerum> yes
[16:48:28] <lincolnthree1> is it possible that MailMessage, or another centralized class, could have an extra utility method:
[16:48:36] <lincolnthree1> .getContentId( emailAttachment );
[16:48:43] <clerum> has to be set on the Attachment before templating (if any) and when building the acutal MultipartMimeMessage
[16:48:50] <lincolnthree1> Ah.
[16:49:12] <clerum> if it was only needed right at the very end then yeah it would be easy to just set on the fly
[16:49:29] <clerum> but you really can run templating and then message with the message more
[16:49:40] <clerum> mess with the message more
[16:49:40] <lincolnthree1> I'm leaning toward your API is good the way it is
[16:49:52] <clerum> I see where you are going with it
[16:50:03] *** pmuir has joined #seam-dev
[16:50:03] <clerum> I'll keep it in mind and look for an opening that makes sense
[16:50:16] <lincolnthree1> :) nice job on this stuff Cody!
[16:50:20] <lincolnthree1> seriously
[16:50:22] <lincolnthree1> it looks great
[16:50:28] <lincolnthree1> oh
[16:50:32] <lincolnthree1> I had one more thought just now
[16:50:36] <clerum> k
[16:50:57] <lincolnthree1> I'd want to hear shane or dan's opinion first, but
[16:51:00] <lincolnthree1> 1 sec
[16:51:26] <clerum> np I'll be around
[16:51:45] <lincolnthree1> what's the difference between:
[16:51:48] <lincolnthree1> org.jboss.seam.mail.api
[16:51:50] <lincolnthree1> and
[16:51:54] <lincolnthree1> org.jboss.seam.mail.core
[16:52:25] <clerum> nothing really. I was going to try and snag dan or someone to go through the whole thing before alpha
[16:52:35] <clerum> and figure out what belongs in each package and more importantly
[16:52:44] <clerum> what belongs in api and what belongs in impl
[16:53:00] <lincolnthree1> I'd say you can alpha before figuring that out
[16:53:04] <lincolnthree1> api can still change :)
[16:53:13] <clerum> although I do have a second internal seam 2 impl
[16:53:23] <clerum> and the current api makes sense considering that
[16:53:41] <lincolnthree1> I think anything a developer could/would need to reference should be in API
[16:53:50] <lincolnthree1> anything they should not or would not, should be in impl
[16:54:21] <clerum> so for example
[16:54:27] <clerum> EmailAttachmentFromClassPath
[16:54:31] <clerum> api or impl
[16:54:34] <lincolnthree1> api
[16:54:40] <lincolnthree1> because it's something they will want to use
[16:55:10] <clerum> interfaces in api and impls in impl
[16:55:13] <lincolnthree1> same with BaseEmailAttachment
[16:55:29] <clerum> so if they didn't want to use my implmeneations of the interfaces they didn't have to
[16:55:42] <lincolnthree1> in theory
[16:55:51] <lincolnthree1> but it's not always just a class/interface split
[16:55:57] <lincolnthree1> like your EmailAttachment & impls example
[16:56:00] <clerum> right but in practive 99.9% of people are doing to use both impl and api of this
[16:56:09] <clerum> practive
[16:56:11] <lincolnthree1> the provided convenience impls should still go in the API even though they are concrete classes
[16:56:13] <lincolnthree1> right
[16:56:13] <clerum> practice
[16:57:13] <lincolnthree1> but that's just my perspective
[16:57:16] <lincolnthree1> others might feel differently
[16:57:22] <lincolnthree1> so it should be asked :)
[16:57:40] <clerum> if I do that then api needs to have solder as a dep
[16:57:55] <lincolnthree1> really? for email attachments?
[16:58:03] <clerum> for the impl
[16:58:10] <lincolnthree1> how come?
[16:58:18] <clerum> using ResourceProvider to lookup files on the classpath
[16:58:21] <clerum> only reason
[16:58:35] <clerum> and also guava
[16:58:51] <clerum> for transforming Files and stuch to byte[]
[16:59:40] <lincolnthree1> Those can probably be done with a little utility code if needed. but let's ask the team
[17:00:56] <lincolnthree1> breakfast time
[17:01:41] <clerum> ugh
[17:01:53] <clerum> isn't that the point of guava and commons
[17:02:11] <clerum> so that we don't have to each write a util to convert file to byte[]
[17:09:40] *** balunasj_busy has quit IRC
[17:14:40] *** rruss has joined #seam-dev
[17:22:10] <lincolnthree1> clerum: yeah, but I'll pull a page out of pmuir's playbook. we're writing frameworks, and that means we need to do our best to limit library and depenency explosion
[17:22:27] <lincolnthree1> it doesn't mean we can't pick and choose some good ones, and in this case, maybe it's the case
[17:22:36] <lincolnthree1> but it's something that should be considered carefully
[17:22:45] *** kpiwko has quit IRC
[17:23:18] <lincolnthree1> say you use guava-1.8 and my framework requires quava-1.6, which is no longer compatible (unlikely, but the point stands)
[17:23:21] <lincolnthree1> now we have a problem
[17:23:47] <pmuir> lincolnthree1: :-)
[17:24:13] <pmuir> rule is you need to use at least 20% of the func of a library to make it worthwhile depending on it, not just copying code
[17:24:52] <lincolnthree1> right, so if you're using 2 methods out of Guava, then you could just copy the code and keep licence headers in tact
[17:24:58] <clerum> solder should be fine?
[17:25:01] <lincolnthree1> or whatever is required by the license
[17:25:13] <clerum> plush I think we are bringing solder into guava
[17:25:19] <clerum> plus
[17:25:24] <lincolnthree1> guava into solder?
[17:25:34] <clerum> brain not working today
[17:25:38] <clerum> guava into solder
[17:25:38] <lincolnthree1> :-p
[17:25:48] <clerum> as you can tell from my typing
[17:26:10] <clerum> so api would have a dep on solder
[17:26:15] <clerum> impl already does
[17:26:45] <lincolnthree1> my forge API depends on Solder
[17:26:50] <lincolnthree1> but that's a little different
[17:27:56] *** balunasj has joined #seam-dev
[17:28:26] *** balunasj is now known as balunasj_busy
[17:39:03] <jbossbot> git [mail] push master 9fb8f4f.. Cody Lerum implement EmailAttachment as interface
[17:39:03] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/b69c57f...9fb8f4f
[17:43:40] *** mgencur has left #seam-dev
[17:50:18] *** lukaszlenart has joined #seam-dev
[17:57:50] *** lukaszlenart_ has joined #seam-dev
[17:58:53] *** lukaszlenart has quit IRC
[17:58:53] *** lukaszlenart_ is now known as lukaszlenart
[17:58:57] *** maschmid has quit IRC
[18:09:08] *** lukaszlenart_ has joined #seam-dev
[18:09:42] *** lukaszlenart has quit IRC
[18:09:43] *** lukaszlenart_ is now known as lukaszlenart
[18:13:19] *** lukaszlenart has left #seam-dev
[18:21:18] *** cbrock has joined #seam-dev
[18:28:44] *** adamw1pl has quit IRC
[18:32:47] *** daniel_hinojosa has joined #seam-dev
[18:39:27] *** lightguard_jp has joined #seam-dev
[18:39:43] *** lightguard_jp has quit IRC
[18:40:02] *** lightguard_jp has joined #seam-dev
[18:40:23] *** alesj has quit IRC
[19:39:57] *** alesj has joined #seam-dev
[19:51:04] *** daniel_hinojosa has quit IRC
[20:15:39] *** mgencur has joined #seam-dev
[20:15:51] *** mgencur has left #seam-dev
[20:39:10] *** cbrock has quit IRC
[20:39:24] *** cbrock has joined #seam-dev
[20:39:24] *** cbrock has quit IRC
[20:39:24] *** cbrock has joined #seam-dev
[20:41:50] *** bleathem has quit IRC
[20:45:35] *** sannegrinovero has quit IRC
[20:50:57] *** lukaszlenart has joined #seam-dev
[20:55:42] *** cbrock has quit IRC
[21:09:37] <jbossbot> git [mail] push master 262275f.. Cody Lerum refactor project into core/api core/impl velocity/api velocity/impl
[21:09:37] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/9fb8f4f...262275f
[21:17:56] *** cbrock has joined #seam-dev
[21:17:56] *** cbrock has quit IRC
[21:17:56] *** cbrock has joined #seam-dev
[21:25:22] <jbossbot> git [mail] push master 72d21eb.. Cody Lerum update example readme.txt
[21:25:22] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/262275f...72d21eb
[21:27:05] *** pmuir has quit IRC
[21:36:00] *** daniel_hinojosa has joined #seam-dev
[21:36:25] *** lukaszlenart has left #seam-dev
[21:47:28] <jbossbot> git [forge] push master 10c1038.. Lincoln Baxter, III split mvn command into the mvn shell passthrough and the 'maven' utilities plugin
[21:47:28] <jbossbot> git [forge] push master 6bd6fb5.. Lincoln Baxter, III updated Imports to be type-agnostic
[21:47:28] <jbossbot> git [forge] push master c4b739d.. Lincoln Baxter, III fixed erroneous list-commands plugin
[21:47:28] <jbossbot> git [forge] push master 5658868.. Lincoln Baxter, III added 'java list-imports' command, and fixed bad web.xml generation
[21:47:28] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/bcd6132...5658868
[22:38:45] <jbossbot> git [examples] push master 8527690.. Dan Allen repo defs in parent; revert version to snapshot
[22:38:45] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/ed26d5f...8527690
[23:19:24] *** cbrock_ has joined #seam-dev
[23:19:24] *** cbrock_ has quit IRC
[23:19:24] *** cbrock_ has joined #seam-dev
[23:21:15] *** cbrock has quit IRC
[23:21:15] *** cbrock_ is now known as cbrock
[23:39:34] <jbossbot> git [mail] push master 405f1fb.. Cody Lerum rename EmailAttachment impls...
[23:39:34] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/72d21eb...405f1fb
[23:40:07] <lightguard_jp> Cool, like seeing commits :)
[23:48:08] *** cbrock has quit IRC
[23:49:02] <clerum> been awhile for me
[23:49:26] <lightguard_jp> Been a while for Dan too
[23:58:01] <lightguard_jp> sbryzak: We need to send an email to the dev list about the next couple of versions.
[23:58:21] <lightguard_jp> You'd said in a blog (I think) we were going to do another CR for Seam, then I assume final, but we don't have dates for those
[23:58:37] <lightguard_jp> If you have them we need to communicate what they are so it doesn't surprise people.
[23:58:39] <sbryzak> lightguard_jp: it's a bit hard to plan past the next release ;)
[23:58:56] <lightguard_jp> We have a target date in mind for final at least, don't we?
[23:59:04] <sbryzak> CR2 is mainly for adding Forge
[23:59:25] <lightguard_jp> Okay, so there may not be any other versions for modules
[23:59:30] <lightguard_jp> I guess if you need it
[23:59:31] <sbryzak> not really, the final is based on how many issues are found with the CR
[23:59:49] <lightguard_jp> I thought we were targeting something like mid or late March
[23:59:56] <sbryzak> the modules don't need to release anything for CR2





top