<div class="gmail_quote">On Tue, Apr 20, 2010 at 2:35 PM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 20 Apr 2010, at 19:11, Dan Allen wrote:<br>
<br>
> On Tue, Apr 20, 2010 at 12:20 PM, Steven Boscarine <<a href="mailto:steven.boscarine@childrens.harvard.edu">steven.boscarine@childrens.harvard.edu</a>> wrote:<br>
> On 04/20/2010 06:14 AM, Pete Muir wrote:<br>
> > It's not the same JAR, but it is the same API (subtly different ;-)<br>
> ><br>
><br>
> The contents are the same, correct? There is no JBoss-specific magic in<br>
> an org.jboss.spec.javax.* jar, right? The classes and interfaces are<br>
> otherwise identical, right?<br>
<br>
</div>This is almost certainly not the case - take for example the JSF API - it contains a lot of impl-specfic logic. Now, we happen to use the JSF RI in JBoss AS, so it's likely we use the JSF API RI (javax.faces:jsf-api) too. But it's not the only spec like this...<br>
<br>
So, as I said, to be clear, the public API is (of course) exactly the same but the classes aren't. This is subtle, but important, because you should not use a JBoss AS *at runtime* inside another container. This could affect us in test cases in exactly the same ways as the stripped APIs hit test cases<br>
<br>
It is however safe to compile against the JBoss versions of the APIs and deploy to GlassFish.<br></blockquote><div><br></div><div>Right. They are legit Java EE APIs. That's all you should assume. Thanks for clarifying.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Given the difficulties around embedded test classpaths, I do wonder if we can even recommend that people ever use any API jars except those for their target container. We need to do some brainstorming here. I added it to the meeting agenda.<br>
</blockquote><div><br></div><div>I mentioned to Jason Van Zyl that there should be a way to specify a "compile only" scope in Maven. He was open to the idea. I think we should push him on it. To me, compile only aligns perfectly with a platform APi JAR. It's not used on the test classpath or packaged.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Sonatype has been working on merging the <a href="http://java.net" target="_blank">java.net</a> Maven repository into central. Here's the story as I know it. They have put a lot of effort into it and they haven't gotten much support. So this is a one-time important and won't address future publication needs. So while it gives us the JARs we need in the short term, we still need a long term strategy.<br>
<br>
</div>They will be offering a long-term strategy based on nexus for <a href="http://java.net" target="_blank">java.net</a> projects that want it (and some projects have popped up and asked for it). So at least there will be an avenue for projects that want it.<br>
<br>
They may be going further, I need to check with the Sonatype guys.</blockquote></div><br>Let's keep pushing them on this too because I'm consistently getting feedback after every talk that Java EE adoption is struggling because of missing API dependencies in the central repository.<div>
<br></div><div>-Dan<br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>
</div>