[11:01:27 EST(-0500)] * esm (n=esm@207-53-192-205.dynamic-dsl.qis.net) has joined ##uportal
[11:16:42 EST(-0500)] * esm_ (n=esm@207-53-192-205.dynamic-dsl.qis.net) has joined ##uportal
[13:42:57 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal
[13:43:14 EST(-0500)] <EricDalquist> hey there esm_ ... you actually around?
[13:43:27 EST(-0500)] <esm_> yeah
[13:43:30 EST(-0500)] <esm_> unfortunately
[13:43:31 EST(-0500)] <esm_> hehe
[13:43:33 EST(-0500)] <EricDalquist>
[13:43:41 EST(-0500)] <esm_> pluto release?
[13:43:53 EST(-0500)] <EricDalquist> well I have other fixes
[13:43:58 EST(-0500)] <EricDalquist> so no need for a release yet
[13:44:05 EST(-0500)] <esm_> ok cool what's up?
[13:44:15 EST(-0500)] <EricDalquist> actually a maven plugin dev question
[13:44:40 EST(-0500)] <EricDalquist> I was looking into how we package uportal more and realized the overlay feature of the war plugin would be quite handy
[13:45:21 EST(-0500)] <EricDalquist> my idea was to create a uportal-portlets sub-project that is a parent to a bunch of war overlay projects
[13:45:29 EST(-0500)] <esm_> cool yeah I know a couple of projects who are trying to use the overlay feature
[13:45:59 EST(-0500)] <EricDalquist> and the uportal-portlets project would have the pluto assembler configured so when the overlay WARs are created the assembly is done
[13:46:14 EST(-0500)] <EricDalquist> the problem is the web.xml doesn't appear until the package phase
[13:46:30 EST(-0500)] <EricDalquist> well the web.xml and portlet.xml
[13:46:41 EST(-0500)] <EricDalquist> so getting the assembler to work with the web.xml doesn't work
[13:47:21 EST(-0500)] <esm_> do you have the pluto:assembly execution bound to the package phase?
[13:47:44 EST(-0500)] <EricDalquist> heh
[13:47:48 EST(-0500)] <EricDalquist> so it is this nasty catch
[13:47:50 EST(-0500)] <esm_> or rather how do you have the pluto assemlby configured in uportal-portlets
[13:48:02 EST(-0500)] <EricDalquist> the war plugin package phase needs the pluto assembled web.xml
[13:48:35 EST(-0500)] <EricDalquist> but the web.xml and portlet.xml don't appear (overlayed war getting extracted) until the package phase
[13:49:05 EST(-0500)] <EricDalquist> looking at it I really think I need maven 2.1 (I tried using prepare-package)
[13:49:13 EST(-0500)] <EricDalquist> but the war plugin just uses the package phase
[13:49:41 EST(-0500)] <EricDalquist> I'm tempted to try extending/patching the war plugin to do the overlay extraction in prepare-package
[13:50:07 EST(-0500)] <esm_> so can you bind pluto assembly to an earlier phase?
[13:50:37 EST(-0500)] <EricDalquist> nope since the assembly needs files that are extracted during the package phase
[13:50:49 EST(-0500)] <EricDalquist> It works if I make local copies of web.xml and portlet.xml
[13:50:53 EST(-0500)] <esm_> oh i see.
[13:51:20 EST(-0500)] <EricDalquist> part of my question is from your experience how open to patches are the maven devs?
[13:51:53 EST(-0500)] <esm_> open. It depends on who gets your patch i guess. My experience has been positive
[13:51:59 EST(-0500)] <EricDalquist> if I do the work to make the war mojo trunk code take advantage of the prepare-package phase in the 2.1 code would that be considered as a patch?
[13:52:10 EST(-0500)] <esm_> but i've never submitted patches against "big" plugins
[13:52:13 EST(-0500)] <EricDalquist> and also do you have any feeling from them on when 2.1 is getting released?
[13:52:16 EST(-0500)] <EricDalquist> ah
[13:52:38 EST(-0500)] <esm_> i have no idea re 2.1.
[13:52:39 EST(-0500)] <esm_> hmm
[13:52:51 EST(-0500)] <esm_> uportal can use its own war plugin
[13:52:56 EST(-0500)] <EricDalquist> yeah
[13:53:00 EST(-0500)] <EricDalquist> I think that may be the need
[13:53:12 EST(-0500)] <EricDalquist> though using 2.1 would making doing our own war plugin much easier
[13:53:26 EST(-0500)] <esm_> hm let me check nabble
[13:53:30 EST(-0500)] <EricDalquist> since that prepare-package phase would be the perfect place to do the war overlay extraction
[13:53:40 EST(-0500)] <EricDalquist> and then I could attach the pluto assembler to the package phase
[13:53:53 EST(-0500)] <esm_> right
[13:54:00 EST(-0500)] <esm_> i'm sure they would be open to that patch
[13:54:46 EST(-0500)] <EricDalquist> and so what is the best approach to extending a plugin and using our 'own' version?
[13:56:13 EST(-0500)] <esm_> hmm
[13:56:17 EST(-0500)] <esm_> well one ohter question first
[13:56:31 EST(-0500)] <esm_> can you bind pluto assembly to later, say the verify phase?
[13:56:41 EST(-0500)] <EricDalquist> hrm
[13:56:43 EST(-0500)] <esm_> the pluto assemlber can take a war
[13:56:49 EST(-0500)] <EricDalquist> that could work too
[13:56:57 EST(-0500)] <esm_> it isn't ideal from a performance point of view
[13:57:05 EST(-0500)] <esm_> as it reads in the war and spits it out again
[13:58:07 EST(-0500)] <esm_> someone published the pluto site adn broke links
[13:58:22 EST(-0500)] <EricDalquist> lol
[13:59:13 EST(-0500)] <EricDalquist> oh and I have another patch for 1.1.5 I'll create a jira issue for today
[13:59:27 EST(-0500)] <esm_> cool nice
[13:59:37 EST(-0500)] <esm_> ok let me put up the maven plugin docs on the pluto wiki
[14:03:47 EST(-0500)] <esm_> ugh. pastebin is down
[14:04:23 EST(-0500)] <esm_> http://rafb.net/p/UewOmL57.html
[14:04:37 EST(-0500)] <esm_> instead of binding ot package bind to verify (or any phase after package)
[14:04:42 EST(-0500)] <esm_> ok hm
[14:05:41 EST(-0500)] <esm_> sigh. I can't fix the pluto site easily
[14:05:54 EST(-0500)] <EricDalquist> no permissions?
[14:05:59 EST(-0500)] <esm_> i'm definitly going to peg the plugin versions in the next pluto pom
[14:06:08 EST(-0500)] <esm_> i think the site plugin has changed. perhaps. i don't know.
[14:06:16 EST(-0500)] <esm_> i dn't have time to really look into that now
[14:06:16 EST(-0500)] <esm_> but
[14:06:21 EST(-0500)] <esm_> anyway on the wiki it goes
[14:06:27 EST(-0500)] <EricDalquist> so that works
[14:06:46 EST(-0500)] <EricDalquist> but I'm not sure about depending on that artifact
[14:06:54 EST(-0500)] <EricDalquist> since the result .war ends up in a different location
[14:07:15 EST(-0500)] <esm_> i think if you leave out a dest dir it will replace the original
[14:08:10 EST(-0500)] <EricDalquist> nope :/
[14:08:19 EST(-0500)] * esm_ checks
[14:08:32 EST(-0500)] <EricDalquist> ends up in pluto-assembled-wars
[14:10:08 EST(-0500)] <esm_> yeah it defaults to that so even if you leave it out it will be 'pluto-assembled-wars'
[14:10:28 EST(-0500)] <EricDalquist> hrm
[14:10:29 EST(-0500)]

<esm_> try just specifying $

Unknown macro: {project.build.directory}

[14:10:38 EST(-0500)] <esm_> er the directory that the war artifacts normally appear in
[14:11:23 EST(-0500)] <EricDalquist> that worked

[14:11:26 EST(-0500)] <EricDalquist> sweet
[14:11:29 EST(-0500)] * esm_ cheers
[14:11:41 EST(-0500)] <esm_> ok so there is a hacky workaround.
[14:11:49 EST(-0500)] <EricDalquist> yup
[14:12:00 EST(-0500)] <EricDalquist> oh so the other patches ... there is https://issues.apache.org/jira/browse/PLUTO-452
[14:12:21 EST(-0500)] <EricDalquist> and I have a patch locally that needs to have an issue created
[14:12:38 EST(-0500)] <EricDalquist> that lets the assembler write out valid servlet 2.4 web.xml files
[14:12:48 EST(-0500)] <EricDalquist> though castor still doesn't indent the servlet 2.4 files ...
[14:12:52 EST(-0500)] <esm_> hmm it should already
[14:12:53 EST(-0500)] <EricDalquist> but I'm going to look into that
[14:13:06 EST(-0500)] <esm_> the assembler should always output valid xml
[14:13:12 EST(-0500)] <EricDalquist> nope ... it strips out the schema
[14:13:17 EST(-0500)] <esm_> it may not be pretty-printed...
[14:13:29 EST(-0500)] <esm_> well its valid

[14:13:31 EST(-0500)] <esm_> hm
[14:14:02 EST(-0500)] <EricDalquist> it is an easy fix
[14:14:06 EST(-0500)] <EricDalquist> I have the patch locally
[14:14:13 EST(-0500)] <esm_> cool yah throw that in
[14:14:22 EST(-0500)] <EricDalquist> I'll also look into adding 2.5 support
[14:14:51 EST(-0500)] <esm_> nice - just make those two seperate issues - 2.4 schema and 2.5 support
[14:14:56 EST(-0500)] <EricDalquist> ol
[14:14:58 EST(-0500)] <EricDalquist> ok
[14:16:29 EST(-0500)] <EricDalquist> this will be great
[14:16:41 EST(-0500)] <EricDalquist> we won't need ear assembly support now
[14:16:52 EST(-0500)] <EricDalquist> and I can tweak the portlets we're using via the overlays
[14:17:15 EST(-0500)] <esm_> that's good. thought hte assembler should be able to do an ear (slowly)
[14:17:22 EST(-0500)] <EricDalquist> yeah
[14:17:26 EST(-0500)] <esm_> the overlays sound like a good way to go
[14:17:27 EST(-0500)] <EricDalquist> it does
[14:17:39 EST(-0500)] <EricDalquist> but doing it this way should be faster and the overlays will be nice
[14:17:48 EST(-0500)] <EricDalquist> it should also be a good example for schools
[14:17:58 EST(-0500)] <EricDalquist> we've been talking about how to use maven for our build system
[14:18:00 EST(-0500)] * esm_ nods
[14:18:07 EST(-0500)] <EricDalquist> and dealing with environment specific configs
[14:18:14 EST(-0500)] <EricDalquist> and we're really looking into using overlays
[14:18:21 EST(-0500)] <EricDalquist> so our devs can just package generic WARs
[14:18:35 EST(-0500)] <EricDalquist> and then we can overlay the logging/db/etc configs
[14:19:01 EST(-0500)] <EricDalquist> so we would have a sparse overlay project per environment
[14:19:29 EST(-0500)] <esm_> yes yes very nice

[14:19:49 EST(-0500)] <esm_> totally on board. another project i'm working with is going the same way
[14:19:57 EST(-0500)] <esm_> not sure they ahve the kinks all worked out
[14:20:01 EST(-0500)] <esm_> but they are working on it
[14:20:15 EST(-0500)] <EricDalquist> maven 2.1 will sure help with that prepare-package phase
[14:20:26 EST(-0500)] <esm_> yeah it looks like 2.1 is still a ways of
[14:20:27 EST(-0500)] <esm_> off
[14:20:36 EST(-0500)] <esm_> if their roadmap is to be believed
[14:20:45 EST(-0500)] <EricDalquist>

[14:20:52 EST(-0500)] <esm_> last email i saw on nabble re 2.1 was on 8/30
[14:21:07 EST(-0500)] <EricDalquist> wow
[14:23:01 EST(-0500)] <esm_> welll, i'lls pend some time on the pluto stuff this evening, if my wife will let me

[14:23:13 EST(-0500)] <esm_> get the website ironed out, and prep for the next release
[14:23:19 EST(-0500)] <EricDalquist> thats fine
[14:24:14 EST(-0500)] <EricDalquist> I'm thinking again that I need to look into being a pluto committer

[14:24:32 EST(-0500)] <esm_> yes with these patches you are providing i'll propose a vote
[14:25:00 EST(-0500)] <esm_> or call a vote rather
[14:25:10 EST(-0500)] <EricDalquist> I'm thinking it would be a good idea once uportal 3 is out and we are really on pluto 1.1 and looking at 2.0
[14:25:21 EST(-0500)] <EricDalquist> since it seems like we're exercising it more than a few others
[14:27:26 EST(-0500)] <esm_> yeah
[14:27:34 EST(-0500)] <EricDalquist> so hows things at JHU?
[14:27:57 EST(-0500)] <esm_> ok busy. I'm on project right now working on some really awful code.
[14:28:06 EST(-0500)] <EricDalquist> :/
[14:28:11 EST(-0500)] <esm_> and a milestone/deadline Jan 2

[14:28:12 EST(-0500)] <esm_> so
[14:28:13 EST(-0500)] <esm_> yeah
[14:28:22 EST(-0500)] <EricDalquist> hg
[14:29:43 EST(-0500)] <esm_> i am working with some very cool software written on top of cocoon
[14:29:56 EST(-0500)] <EricDalquist> sounds interesting
[14:30:01 EST(-0500)] <esm_> its very nice, and fast.
[14:30:07 EST(-0500)] <EricDalquist> that project sure has been around a while
[14:30:35 EST(-0500)] <esm_> yeah, and it is still under dev - they are moving to Spring from Avalon (an older IoC framework)
[14:30:55 EST(-0500)] <EricDalquist> interesting
[14:32:13 EST(-0500)] <esm_> this project has an XML document for the view model, and they manipulate it with either XSL or custom cocoon transformers.
[14:32:37 EST(-0500)] <esm_> there's a structural transform, "aspect" transforms, and finally theme transforms
[14:32:48 EST(-0500)] <esm_> so it's pretty easy to customize
[14:51:38 EST(-0500)] <EricDalquist> castor is weird
[14:51:52 EST(-0500)] <EricDalquist> indentation is working with a 2.3 servlet.xml
[14:51:56 EST(-0500)] <EricDalquist> with a dtd
[14:52:08 EST(-0500)] <EricDalquist> it is not working with a 2.4 servlet xml
[14:52:10 EST(-0500)] <EricDalquist> with a schema
[14:52:12 EST(-0500)] <EricDalquist> weird
[14:53:09 EST(-0500)] <esm_> hm.
[14:53:15 EST(-0500)] <esm_> where are you playing with the indent property?
[14:53:23 EST(-0500)] <esm_> is it a castor.properties switch or are you doing it in code
[14:53:40 EST(-0500)] <EricDalquist> the current code does it in the java code
[14:53:55 EST(-0500)] <esm_> yeah
[14:54:01 EST(-0500)] <EricDalquist> it is the exact same code running (this is the pluto descriptor impl)
[14:54:41 EST(-0500)] <esm_> AbstractCastorDescriptorService?
[14:54:58 EST(-0500)] <EricDalquist> yup
[14:55:34 EST(-0500)] <EricDalquist> the patch really just adds a elseif in WebAppDescriptorServiceImpl.setCastorMarchallerOptions
[14:55:41 EST(-0500)] <EricDalquist> it isn't a big deal
[14:55:44 EST(-0500)] <EricDalquist> just weird
[14:58:09 EST(-0500)] <esm_> yeah that's wierd. what happens if you set the indent property after setCastorMarshallerOptions instead of before.
[14:58:20 EST(-0500)] <EricDalquist> no change
[14:58:28 EST(-0500)] <EricDalquist> and I tried setting it on the OutputFormat object
[14:58:36 EST(-0500)] <EricDalquist> xml serialization in java is always just weird
[15:00:33 EST(-0500)] <esm_> it must be a castor weirdness
[15:00:40 EST(-0500)] <EricDalquist> yup
[15:00:43 EST(-0500)] <EricDalquist> oh well

[15:17:43 EST(-0500)] * esm (n=esm@207-53-193-160.dynamic-dsl.qis.net) has joined ##uportal
[15:22:16 EST(-0500)] <EricDalquist> hrm
[15:22:28 EST(-0500)] <esm> sounds like you're having as much fun as i am
[15:22:37 EST(-0500)] <esm> i'm having fun with non-reentrant method calls
[15:22:46 EST(-0500)] <EricDalquist> working on getting castor to write out the correct namspace for the web.xml
[15:22:59 EST(-0500)] <EricDalquist> to get the default xmlns set I have to specific the namespace in the mapping file
[15:23:08 EST(-0500)] <EricDalquist> and I need to make sure that is going to work for 2.4 and 2.5
[15:24:40 EST(-0500)] <esm> you're looking at teh castor-web-xml-mapping.xml resource?
[15:24:52 EST(-0500)] <esm> you may have to use a handler
[15:25:00 EST(-0500)] <EricDalquist> yeah
[15:25:03 EST(-0500)] <EricDalquist> I will
[15:25:05 EST(-0500)] <esm> i had to do that to fix 2.3 and 2.4 validation
[15:25:11 EST(-0500)] <EricDalquist> the xmlns for servlet 2.4 is different than 2.5
[15:25:15 EST(-0500)] <EricDalquist> well
[15:25:19 EST(-0500)] <esm> yes
[15:25:20 EST(-0500)] <EricDalquist> oh well
[15:25:40 EST(-0500)] <EricDalquist> they changed it from http://java.sun.com/xml/ns/j2ee to http://java.sun.com/xml/ns/javaee
[15:25:43 EST(-0500)] <EricDalquist> which is annoying
[15:25:51 EST(-0500)] <EricDalquist> since it could have stayed the same
[15:39:49 EST(-0500)] <EricDalquist> hrm ... any idea how to create a handler to add an attribute that doesn't really have a corresponding object property?
[15:41:17 EST(-0500)] <esm> you mean you want to add a handler for the 'xmlns' attribute but it isn't modeled as an object in the descriptor-api?
[15:41:27 EST(-0500)] <EricDalquist> yup
[15:41:28 EST(-0500)] <esm> you'll have to create it I think.
[15:41:36 EST(-0500)] <EricDalquist> I'm not sure that will even work

[15:41:46 EST(-0500)] <esm> it should...
[15:41:58 EST(-0500)] <esm> unless castor treats 'xmlns' special, which it may
[15:42:03 EST(-0500)] <EricDalquist>

[15:42:19 EST(-0500)] <EricDalquist> so you're saying I need to add an attribute to the object
[15:43:06 EST(-0500)] <esm> Yeah, WebAppDD will need a string field named something like 'xmlNs'
[15:43:13 EST(-0500)] <EricDalquist> ah ok
[15:43:56 EST(-0500)] <esm> you'll need to create a Castor handler which will control what the value of the string field is, and whether or not it is emitted when serialized
[15:44:17 EST(-0500)] <esm> if you take a look at the 'servletVersion' field you'll get the idea
[15:44:19 EST(-0500)] <EricDalquist> yeah, I'm copying your servlet version
[15:44:30 EST(-0500)] <esm> cool yeah that will do it I think
[15:46:30 EST(-0500)] <esm> i'm not sure what order the handlers are called in... since you'll probably want to look at the value of the servlet version field to determine what xmlns to put in
[15:46:38 EST(-0500)] <EricDalquist> looks like this should work
[15:46:48 EST(-0500)] <EricDalquist> yup
[15:47:30 EST(-0500)] <esm> and if you can write a Servlet25WebAppDescriptorTest

[15:47:34 EST(-0500)] <EricDalquist> nice ... the test web.xml files used for pluto aren't valid

[15:47:42 EST(-0500)] <EricDalquist> yup
[15:47:53 EST(-0500)] <esm> heh
[15:49:10 EST(-0500)] <EricDalquist> ah
[15:49:14 EST(-0500)] <EricDalquist> the test .xml files are valid
[15:49:20 EST(-0500)] <EricDalquist> the castor mappings create invalid files
[15:49:48 EST(-0500)] <esm> hm
[15:49:51 EST(-0500)] <esm> servlet-2.4-webapp-descriptor.xml is invalid
[15:49:58 EST(-0500)] <EricDalquist> oh yeah
[15:50:01 EST(-0500)] <EricDalquist> the 2.3 is valid
[15:50:11 EST(-0500)] <EricDalquist> the marshalling output for both is invalid though
[15:51:31 EST(-0500)] <esm> nice
[15:51:33 EST(-0500)] <EricDalquist> just ordering issues it looks like
[15:51:39 EST(-0500)] <EricDalquist> I'll get it all cleaned up
[15:51:43 EST(-0500)] <esm> yup
[15:51:48 EST(-0500)] <EricDalquist> and working for 2.3 - 2.5
[15:51:49 EST(-0500)] <esm> the ordering is pita
[16:33:39 EST(-0500)] <EricDalquist> uhg
[16:33:48 EST(-0500)] <EricDalquist> and some ordering has changed between servlet spec versions
[17:27:25 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal
[19:41:23 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal
[19:57:05 EST(-0500)] <esm> yeah i'd write a handler
[19:57:13 EST(-0500)] <esm> that's why it hasn't been done
[19:57:16 EST(-0500)] <EricDalquist> hey
[19:57:18 EST(-0500)] <EricDalquist> well
[19:57:21 EST(-0500)] <esm> noone's cared enough
[19:57:26 EST(-0500)] <EricDalquist> I'm not sure how I can do this with a handler
[19:57:29 EST(-0500)] <esm> oh
[19:57:30 EST(-0500)] <esm> i mean
[19:57:33 EST(-0500)] <esm> sorry
[19:57:42 EST(-0500)] <EricDalquist> the ordering of elements follows what is in castor-web-xml-mapping.xml
[19:57:50 EST(-0500)] <EricDalquist> bah
[19:57:57 EST(-0500)] <esm> i didn't mean a castor handler. I was thinkging about this earler
[19:58:04 EST(-0500)] <EricDalquist> ah

[19:58:13 EST(-0500)] <esm> because of the ordering issue, I think there has to be multiple mapping files
[19:58:22 EST(-0500)] <EricDalquist> yeah

[19:58:40 EST(-0500)] <EricDalquist> is it important enough to be writing out 'validating' files to do that?
[19:59:26 EST(-0500)] <esm> right i think that is why it hasn't been done before.... it was just too much pain
[19:59:46 EST(-0500)] <esm> all tomcat cared about was having 'version=2.4' in the <web-app> element
[19:59:53 EST(-0500)] <esm> jetty, IIRC, was more particular
[19:59:55 EST(-0500)] <EricDalquist> yeah
[19:59:58 EST(-0500)] <EricDalquist> hrm
[20:00:15 EST(-0500)] <esm> and there has been talk of dumping castor
[20:00:50 EST(-0500)] <esm> so do do it as it is now, you'dhave to have a generic handler which would use the correct mapping file for the proper version
[20:00:52 EST(-0500)] <EricDalquist> this is really annoying ... the description element in context-param and env-entry-value in env-entry changed ordering
[20:00:57 EST(-0500)] <esm> yeah
[20:01:01 EST(-0500)] <EricDalquist> yup
[20:01:13 EST(-0500)] <EricDalquist> and then we have to maintain a castor mapping file per servlet spec version
[20:01:21 EST(-0500)] <esm> right
[20:01:27 EST(-0500)] <EricDalquist> so I think I'm going to leave it like this as 'good enough' for now
[20:01:48 EST(-0500)] <esm> sounds good to me
[20:01:59 EST(-0500)] <EricDalquist> cause really for most web.xml files they will still be valid
[20:02:06 EST(-0500)] <EricDalquist> since they aren't going to use those tags
[20:02:09 EST(-0500)] <esm> yeah
[20:04:19 EST(-0500)] <EricDalquist> it would be nice to look into something like xstream perhaps for the xml/bean mappng
[20:04:24 EST(-0500)] <esm> yeah
[20:04:44 EST(-0500)] <esm> i'm a fan of doing it with xstream but people on the list were talking about jax-fing-b
[20:04:51 EST(-0500)] <EricDalquist>

[20:04:53 EST(-0500)] <esm> whoever writes it first, wins
[20:04:56 EST(-0500)] <EricDalquist> ah
[20:05:09 EST(-0500)] <esm> that's how it'll work probably
[20:05:15 EST(-0500)] <EricDalquist> well I was also thinking about possible ways to redo parts of the container to move more code out of shared
[20:05:34 EST(-0500)] <esm> everyone will say how nice it would be if there was jaxb, but if someone writes it in xstream, I don't think people will argue
[20:05:54 EST(-0500)] <esm> especially if its an impl of an interface that people can swap out with a jaxb impl if they really want
[20:06:17 EST(-0500)] <EricDalquist> yeah
[20:06:18 EST(-0500)] <esm> well...
[20:07:35 EST(-0500)] <esm> right now the only-non-pluto library in shared is castor IIRC
[20:07:47 EST(-0500)] <esm> besides portlet-1.0
[20:08:29 EST(-0500)] <EricDalquist> yup
[20:08:42 EST(-0500)] <esm> so if we can hand-roll an impl for munging the xml, that would work.
[20:08:46 EST(-0500)] <EricDalquist> I think it could be viable to move that out too
[20:09:12 EST(-0500)] <esm> we could use the maven-shade plugin to do some magic
[20:09:44 EST(-0500)] <EricDalquist> doing things via interfaces and injection from the 'portal webapp' could result in only needing pluto interfaces in shared
[20:10:10 EST(-0500)] <EricDalquist> then the libraries that do the xml parsing could live in the portal webapp
[20:13:12 EST(-0500)] <esm> yeah we've talked about that before
[20:13:34 EST(-0500)] <esm> addtional services in the container
[20:13:40 EST(-0500)] <EricDalquist> it is a bit more work
[20:13:45 EST(-0500)] <EricDalquist> but I've done code like it before
[20:13:48 EST(-0500)] <EricDalquist> and the result is quite nice
[20:14:29 EST(-0500)] <EricDalquist> how up are you on the 2.0 work?
[20:14:35 EST(-0500)] <EricDalquist> if I go and do a bunch of coding in 1.1.x
[20:14:41 EST(-0500)] <EricDalquist> is it going to just be lost?
[20:14:52 EST(-0500)] <esm> i'm not up on 2.0 at all.
[20:15:14 EST(-0500)] <esm> there is a discusson on pluto-dev now about promoting the 286 work to trunk
[20:15:29 EST(-0500)] <esm> and what do with the existing branches
[20:15:46 EST(-0500)] <EricDalquist> ah
[20:15:51 EST(-0500)] <EricDalquist> well I'll keep my eye on it
[20:16:05 EST(-0500)] <EricDalquist> and if it looks like there is a chance I may be interested in doing the xstream & interfacing work
[20:16:07 EST(-0500)] <esm> yeah i'd run it by the list
[20:16:15 EST(-0500)] <EricDalquist> the less we have in shared the happier I'll be
[20:16:21 EST(-0500)] <esm> people seem.... inane.
[20:16:22 EST(-0500)] <EricDalquist> all that stuff does is cause problems
[20:16:24 EST(-0500)] <esm> yeah
[20:16:34 EST(-0500)] <esm> assembler needs to be broken out of util
[20:16:41 EST(-0500)] <esm> and we need container services for assembly
[20:17:01 EST(-0500)] <esm> people seemed to get irritated at the idea...
[20:17:11 EST(-0500)] <EricDalquist> eh
[20:17:22 EST(-0500)] <EricDalquist> as uportal continues with its momentum we will drive some of that
[21:21:23 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal
[21:45:02 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal
[21:45:15 EST(-0500)] <EricDalquist> still working?
[22:40:16 EST(-0500)] <esm> yeah
[22:40:17 EST(-0500)] <esm> lol
[23:19:22 EST(-0500)] * EricDalquist (n=EricDalq@adsl-99-162-101-97.dsl.lsan03.sbcglobal.net) has joined ##uportal

Browser not supported