Pete, This morning I released the jboss-javaee_6.0_spec, 1.0.0.Beta3. http://repository.jboss.org/maven2/org/jboss/spec/jboss-javaee_6.0_spec/1... This release contains fix for JBEE-33 - update to use JACC 1.4. Shelly McGowan JBoss, by Red Hat ----- Original Message ----- From: "Pete Muir" <pmuir(a)redhat.com&gt; To: "Steven Boscarine" <steven.boscarine(a)childrens.harvard.edu&gt; Cc: "Weld-Dev List" <weld-dev(a)lists.jboss.org&gt;, smcgowan(a)redhat.com Sent: Tuesday, April 13, 2010 8:00:35 AM GMT -05:00 US/Canada Eastern Subject: Re: [weld-dev] Maven Archetype Bill of Materials - How should we handle minor variations in point releases of Java EE 6 containers? Shelly has pointed us at http://repository.jboss.org/maven2//org/jboss/spec/jboss-javaee_6.0_spec/... works great as a jboss-6.0.0-bom. Unfortunately, Sun control the javax namespace, and don't publish a BOM for Java EE, so producing one of these is much harder. I suggest we stick with the JBoss one for now, along with instructions on how to create one for other app servers. WDYT? On 12 Apr 2010, at 16:47, Steven Boscarine wrote: > Hello All, > The Weld archetypes need to be updated to reflect the latest Weld 1.0.1 > release. > > Presently, we're using the weld-extensions-bom > > <dependency> > <groupId>org.jboss.weld</groupId> > <artifactId>weld-extensions-bom</artifactId> > <version>1.0.0-CR2</version> > <type>pom</type> > <scope>import</scope> > </dependency> > > The immediate issue is that the archetypes need to reflect the changes. > > The hairier issue is dealing with minor point release differences > > Now there's 2 variants of weld in the wild, via 2 Java EE containers. > Glassfish has weld-1.0.0 and JBoss 6 will have 1.0.1. Should this be > reflected via different BOMs? > > Should there be a weld-jboss-6.0.0-bom? glassfish-v3-bom? Presumably, > down the road, there will be more variants as other APIs have minor > point increases. > > If not, does anyone have suggestions for dealing with trivial variations > in versions between container point releases? > > Thanks, > Steven > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On 19 Apr 2010, at 02:31, Dan Allen wrote: > Great initiative! This is a real win for JBoss, especially given the debacle of the aggregate jar that Sun published to the java.net repository. > > It seems that several core specs are missing, such as bean validation, CDI > Shelly is working on CDI at least. > and JSF. I'm I just not seeing them or are they missing for a reason? Also, are we planning on doing profile stack poms such as the web profile? > This would be nice. > Again, nice start. > > -Dan > > On Wed, Apr 14, 2010 at 10:44 AM, Shelly McGowan&lt;smcgowan(a)redhat.com&gt; wrote: > > Pete, > > This morning I released the jboss-javaee_6.0_spec, 1.0.0.Beta3. > > http://repository.jboss.org/maven2/org/jboss/spec/jboss-javaee_6.0_spec/1... > > > This release contains fix for JBEE-33 - update to use JACC 1.4. > > > Shelly McGowan > JBoss, by Red Hat > > ----- Original Message ----- > From: "Pete Muir&quot;&lt;pmuir(a)redhat.com&gt; > To: "Steven Boscarine&quot;&lt;steven.boscarine(a)childrens.harvard.edu&gt; > Cc: "Weld-Dev List&quot;&lt;weld-dev(a)lists.jboss.org&gt;, smcgowan(a)redhat.com > Sent: Tuesday, April 13, 2010 8:00:35 AM GMT -05:00 US/Canada Eastern > Subject: Re: [weld-dev] Maven Archetype Bill of Materials - How should we handle minor variations in point releases of Java EE 6 containers? > > Shelly has pointed us at http://repository.jboss.org/maven2//org/jboss/spec/jboss-javaee_6.0_spec/... which works great as a jboss-6.0.0-bom. Unfortunately, Sun control the javax namespace, and don't publish a BOM for Java EE, so producing one of these is much harder. > > I suggest we stick with the JBoss one for now, along with instructions on how to create one for other app servers. > > WDYT? > > On 12 Apr 2010, at 16:47, Steven Boscarine wrote: > > >> Hello All, >> The Weld archetypes need to be updated to reflect the latest Weld 1.0.1 >> release. >> >> Presently, we're using the weld-extensions-bom >> >> <dependency> >> <groupId>org.jboss.weld</groupId> >> <artifactId>weld-extensions-bom</artifactId> >> <version>1.0.0-CR2</version> >> <type>pom</type> >> <scope>import</scope> >> </dependency> >> >> The immediate issue is that the archetypes need to reflect the changes. >> >> The hairier issue is dealing with minor point release differences >> >> Now there's 2 variants of weld in the wild, via 2 Java EE containers. >> Glassfish has weld-1.0.0 and JBoss 6 will have 1.0.1. Should this be >> reflected via different BOMs? >> >> Should there be a weld-jboss-6.0.0-bom? glassfish-v3-bom? Presumably, >> down the road, there will be more variants as other APIs have minor >> point increases. >> >> If not, does anyone have suggestions for dealing with trivial variations >> in versions between container point releases? >> >> Thanks, >> Steven >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

It's not the same JAR, but it is the same API (subtly different ;-)

> On one hand, I prefer the javax.* because it is more conventional and in my opinion, more polished looking, especially for people who choose to run weld or Java EE outside of a JBoss container. > Agreed. However even if we decided to maintain a BOM for this, we couldn't have it 100% using javax. as some specs in EE6 are missing published Maven artifacts. So, the question becomes whether it is worth doing a split one?

> I imagine this is relatively important for the AS team as I am guessing a non-trivial number of errors in the wild occur due to library version mismatches. Perhaps maintaining a good set of archetypes that match your container precisely will either reduce these or at least give the developers less of an excuse for these errors? > > What options are available? > Shelly, are you willing to allow both the javax.* and the org.jboss.spec.javax.* entries in the BOM? > Personally, I don't think this is a good idea. It would be better to maintain a separate BOM for the javax. ones.

On 04/20/2010 06:14 AM, Pete Muir wrote: > It's not the same JAR, but it is the same API (subtly different ;-) > The contents are the same, correct? There is no JBoss-specific magic in an org.jboss.spec.javax.* jar, right? The classes and interfaces are otherwise identical, right?

> >> On one hand, I prefer the javax.* because it is more conventional and in my opinion, more polished looking, especially for people who choose to run weld or Java EE outside of a JBoss container. >> > Agreed. However even if we decided to maintain a BOM for this, we couldn't have it 100% using javax. as some specs in EE6 are missing published Maven artifacts. So, the question becomes whether it is worth doing a split one? > Fully understood. Sun/Oracle hasn't been good about pushing their APIs to maven central. It's been frustrating me and every other maven user for many years now.

On 20 Apr 2010, at 19:11, Dan Allen wrote: > On Tue, Apr 20, 2010 at 12:20 PM, Steven Boscarine < steven.boscarine(a)childrens.harvard.edu&gt; wrote: > On 04/20/2010 06:14 AM, Pete Muir wrote: > > It's not the same JAR, but it is the same API (subtly different ;-) > > > > The contents are the same, correct? There is no JBoss-specific magic in > an org.jboss.spec.javax.* jar, right? The classes and interfaces are > otherwise identical, right? 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... 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 It is however safe to compile against the JBoss versions of the APIs and deploy to GlassFish.

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.

> Sonatype has been working on merging the java.net 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. They will be offering a long-term strategy based on nexus for java.netprojects 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. They may be going further, I need to check with the Sonatype guys.