I didn't know they "warped" the apache jars. (off topic, I think Sun once did something similar w/ Xerces). Well, that is good to know. <br><br>On legal, I know that redistributing apache jars is a piece of cake, due to the non-viral nature of the license. But is there anything extra if JSFUnit distributes the jars in a changed form (move packages or stripped classes). I would imagine that answer is "No".
<br><br>Dennis Byrne<br><br><div><span class="gmail_quote">On 10/29/07, <b class="gmail_sendername">Stan Silvert</b> <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dennis Byrne wrote:<br>> I think we agree then that there *has* to be a common model for XML<br>> based and annotation based configuration details. Similar to how the<br>> AnnonationConfiguration extends Configuration in hibernate 3.
<br>><br>> Unfortunately there is no way to rip out clogging. Myfaces and Digester<br>> both have binary dependencies on it. I agree that logging is not needed<br>> by us - just let it rip. I felt the same about performance when I wrote
<br>> the code.<br>><br>> I thought about using JAXB as an alternative also but that only covers<br>> JSF 1.2 conf files (JAXB requires an XSD, JSF 1.1 used a DTD). Maybe if<br>> we can determine if all JSF
1.1 documents could conform to the new JSF<br>> 1.2 schema, I could just do a string replace on the XML and replace DTD<br>> processing instruction w/ an schema reference ... then send it through JAXB.<br>><br>> BTW, what does the RI use for this task? I remember them having very
<br>> few dependencies.<br><br>Well, yes and no. They forked beanutils, collections, digester, and<br>even commons logging. They just changed the package names to<br>com.sun.org.apache.whatever. So what you end up with is just two jars,
<br>jsf-api.jar and jsf-impl.jar. The impl jar has all the forked apache<br>commons stuff in it.<br><br>Every project in the world seems to need these four commons packages<br>these days. So I don't think it's a big issue to add them.
<br><br>Is there still something you want me to ping the attorney about? What<br>was the exact question?<br><br>><br>> Still thinking.<br>><br>> Dennis Byrne<br>><br>> On 10/29/07, *Stan Silvert* <<a href="mailto:ssilvert@redhat.com">
ssilvert@redhat.com</a><br>> <mailto:<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>>> wrote:<br>><br>> I've been working on a reply to this for awhile. I'll post what I have<br>
> so far, which I know does not answer the question. I'm still<br>> working on<br>> it though.<br>><br>> --------------------------------------------------------------<br>> So at the end of the day, what do you have? It would be really great if
<br>> you had all the composite config info accessible through a simple API.<br>> I'm talking about the result of all the faces-config files in the<br>> application. Plus a report that you can spit out to see all of your
<br>> configuration. Bonus points if it also shows the config that results<br>> from Seam annotations. Everybody would love that.<br>><br>> Right now, you have managed bean definitions coming from scads of
<br>> thrid-party libraries, factory declarations, etc. For instance, which<br>> FacesContextFactory won the battle? Can I see the whole chain of<br>> factories?<br>><br>> Same goes for web.xml
. I know that MyFaces parses the web.xml. Even<br>> having an API that can tell me how the FacesServlet is mapped would be<br>> very useful.<br>><br>> So I hope that's where you are going with this, but unfortunately it
<br>> doesn't answer your questions.<br>><br>> How hard would it be to at least get rid of commons logging? Right now<br>> everything in JSFUnit just lets the exceptions bubble all the way up.
<br>> Then the application developer can decide if/how they are logged. I<br>> think this is a good approach for JUnit tests because in a test you<br>> usually just let the exceptions bubble up and allow JUnit to report a
<br>> failure.<br>><br>><br>><br>> Dennis Byrne wrote:<br>> > I took MyFaces 1.2.0 and stripped somewhere around 80% of the<br>> classes.<br>> > Pretty much ripped out everything but
org.apache.myfaces.config<br>> > package. Doing this gives you just enough to parse versions 1.0, 1.1<br>> > and 1.2 of faces-config files using two lines of code.<br>> ><br>> > ByteArrayInputStream bais = new
<br>> > ByteArrayInputStream(testFacesConfig.getBytes());<br>> > dispenser.feed(unmarshaller.getFacesConfig(bais, null));<br>> ><br>> > Here are the costs of going this route. This introduces a
<br>> dependency on<br>> > digestor, commons logging, beanutils and commons collections. It<br>> also<br>> > means we have to maintain the myfaces-stripped jar until the config<br>> > stuff gets moved into the new myfaces commons project (which
<br>> probably<br>> > won't be released before JSFUnit). It also means we have to ping a<br>> > lawyer because I have never done this before (change ASF artifact,<br>> > release under LGPL).
<br>> ><br>> > Let me know your thoughts. I timeboxed this at an hour so I<br>> don't have<br>> > a lot of emotions behind going this route. Part of me feels like<br>> just
<br>> > benching this until after the release.<br>> > --<br>> > Dennis Byrne<br>> ><br>> ><br>> ><br>> ------------------------------------------------------------------------
<br>><br>> ><br>> > _______________________________________________<br>> > jsfunit-dev mailing list<br>> > <a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org
</a> <mailto:<a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org</a>><br>> > <a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">https://lists.jboss.org/mailman/listinfo/jsfunit-dev
</a><br>><br>> _______________________________________________<br>> jsfunit-dev mailing list<br>> <a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org</a> <mailto:<a href="mailto:jsfunit-dev@lists.jboss.org">
jsfunit-dev@lists.jboss.org</a>><br>> <a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">https://lists.jboss.org/mailman/listinfo/jsfunit-dev</a><br>><br>><br>><br>><br>> --<br>> Dennis Byrne
<br>><br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> jsfunit-dev mailing list<br>> <a href="mailto:jsfunit-dev@lists.jboss.org">
jsfunit-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">https://lists.jboss.org/mailman/listinfo/jsfunit-dev</a><br><br>_______________________________________________<br>jsfunit-dev mailing list
<br><a href="mailto:jsfunit-dev@lists.jboss.org">jsfunit-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/jsfunit-dev">https://lists.jboss.org/mailman/listinfo/jsfunit-dev</a><br></blockquote></div>
<br><br clear="all"><br>-- <br>Dennis Byrne