11:22 a.m.
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11:29 a.m.
On 02/02/2012 05:22 PM, Jason T. Greene wrote:
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
I will tag and build the following 4 tomorrow.
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
11:59 a.m.
On 02/02/2012 11:22 AM, Jason T. Greene wrote:
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
I'll be doing these:
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.remoting3 3.2.0.CR9
The lattermost is waiting for Darran's OK.
--
- DML
12:09 p.m.
On 02/02/2012 05:59 PM, David M. Lloyd wrote:
On 02/02/2012 11:22 AM, Jason T. Greene wrote:
> I need finals of everything on this list today, tomorrow at the
> *ABSOLUTE LATEST*.
I'll be doing these:
> org.jboss.logging.jboss-logging 3.1.0.CR2
> org.jboss.logging.jboss-logging-tools 1.0.0.CR5
> org.jboss.modules.jboss-modules 1.1.0.CR8
> org.jboss.remoting3 3.2.0.CR9
The lattermost is waiting for Darran's OK.
I will do a full test run of my development branch against
Remoting/master tomorrow morning so should be able to confirm we are
good to go when you start tomorrow.
5:40 a.m.
On 02/02/2012 06:22 PM, Jason T. Greene wrote:
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.metadata 7.0.0.Beta35
Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
- jboss-logging
- https://github.com/jboss/jboss-ejb-api_spec/pull/1
Carlo
10:41 a.m.
On 3/2/12 03:40, Carlo de Wolf wrote:
On 02/02/2012 06:22 PM, Jason T. Greene wrote:
> org.jboss.ejb3.ext-api 2.0.0-beta-3
> org.jboss.metadata 7.0.0.Beta35
>
Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
- jboss-logging
- https://github.com/jboss/jboss-ejb-api_spec/pull/1
Carlo
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
jboss-logging has been
released, 3.1.0.GA.
--
James R. Perkins
JBoss by Red Hat
4:52 a.m.
On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
On 02/02/2012 06:22 PM, Jason T. Greene wrote:
> org.jboss.ejb3.ext-api 2.0.0-beta-3
> org.jboss.metadata 7.0.0.Beta35
>
Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
- jboss-logging
Upgraded to 3.1.0.GA.
I see it has been merged, but rolled back.
What is the issue here?
(Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
Carlo
Carlo
12:29 p.m.
On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>> org.jboss.ejb3.ext-api 2.0.0-beta-3
>> org.jboss.metadata 7.0.0.Beta35
>>
> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
> - jboss-logging
Upgraded to 3.1.0.GA.
> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
I see it has been merged, but rolled back.
What is the issue here?
(Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
It can also be viewed as not a regression. These dependencies should be
provided as they are only required if you actually reference those
classes. Compile scope dependencies should only be used in APIs when
the API is completely unusable without the dependency.
--
- DML
3 a.m.
On 02/04/2012 07:29 PM, David M. Lloyd wrote:
On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
> On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
>> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>>> org.jboss.ejb3.ext-api 2.0.0-beta-3
>>> org.jboss.metadata 7.0.0.Beta35
>>>
>> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
>> - jboss-logging
> Upgraded to 3.1.0.GA.
>
>> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
> I see it has been merged, but rolled back.
> What is the issue here?
> (Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
It can also be viewed as not a regression. These dependencies should be
provided as they are only required if you actually reference those
classes. Compile scope dependencies should only be used in APIs when
the API is completely unusable without the dependency.
It is a known deficiency on the EG that EJB API has dependencies on JTA
API and JAX-RPC API.
Unfortunately there is nothing that can be done to change that.
I think we should not make it any harder on consumers of the EJB API,
because having the JTA API or JAX-RPC API through EJB API should not
imply those functions are available.
In fact the EJB container is obliged to have JAX-RPC API available even
in lite mode, because else you would run into a problem with
SessionContext.getMessageContext. The method itself however will throw
an IllegalStateException.
In other words having EJB API provided, implies JTA API and JAX-RPC API
are provided as well.
Carlo
7:58 a.m.
On 02/06/2012 03:00 AM, Carlo de Wolf wrote:
On 02/04/2012 07:29 PM, David M. Lloyd wrote:
> On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
>> On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
>>> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>>>> org.jboss.ejb3.ext-api 2.0.0-beta-3
>>>> org.jboss.metadata 7.0.0.Beta35
>>>>
>>> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting on:
>>> - jboss-logging
>> Upgraded to 3.1.0.GA.
>>
>>> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
>> I see it has been merged, but rolled back.
>> What is the issue here?
>> (Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
> It can also be viewed as not a regression. These dependencies should be
> provided as they are only required if you actually reference those
> classes. Compile scope dependencies should only be used in APIs when
> the API is completely unusable without the dependency.
It is a known deficiency on the EG that EJB API has dependencies on JTA
API and JAX-RPC API.
Unfortunately there is nothing that can be done to change that.
I think we should not make it any harder on consumers of the EJB API,
because having the JTA API or JAX-RPC API through EJB API should not
imply those functions are available.
I don't think it's particularly onerous at all. At compile-time, if you
don't use JTA or JAX-RPC then there is absolutely no benefit to having
them on your compile class path. It's not about available
functionality. It's about opting in to the features that you use,
instead of opting out of features that the user probably isn't even
aware of, and avoiding pointless class path explosion and all the
problems that come with it.
In fact the EJB container is obliged to have JAX-RPC API available
even
in lite mode, because else you would run into a problem with
SessionContext.getMessageContext. The method itself however will throw
an IllegalStateException.
Good thing Maven dependencies have absolutely nothing to do with the EJB
container run time.
In other words having EJB API provided, implies JTA API and JAX-RPC
API
are provided as well.
Not at all. When something is "provided" in Maven, that doesn't mean
that the dependency is provided. The scope was named on the assumption
of the run time disposition of the JAR, which is pretty silly given that
Maven is a compile-time tool. Think of "provided" as "import" and
"compile" as "re-export" and you're a lot closer to reality
(though of
course Maven is very sloppy when it comes to actually assembling the
artifacts since they're all flattened into one class path, so it's not
perfectly identical to the corresponding modular terms).
The rule is this. Given APIs named A and B, and B depends on A, the
dependency should always be "provided" unless B is completely unusable
without A, in which case the default "compile" is acceptable.
--
- DML
9:29 a.m.
On 02/06/2012 02:58 PM, David M. Lloyd wrote:
On 02/06/2012 03:00 AM, Carlo de Wolf wrote:
> On 02/04/2012 07:29 PM, David M. Lloyd wrote:
>> On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
>>> On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
>>>> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>>>>> org.jboss.ejb3.ext-api 2.0.0-beta-3
>>>>> org.jboss.metadata 7.0.0.Beta35
>>>>>
>>>> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting
on:
>>>> - jboss-logging
>>> Upgraded to 3.1.0.GA.
>>>
>>>> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
>>> I see it has been merged, but rolled back.
>>> What is the issue here?
>>> (Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
>> It can also be viewed as not a regression. These dependencies should be
>> provided as they are only required if you actually reference those
>> classes. Compile scope dependencies should only be used in APIs when
>> the API is completely unusable without the dependency.
> It is a known deficiency on the EG that EJB API has dependencies on JTA
> API and JAX-RPC API.
> Unfortunately there is nothing that can be done to change that.
>
> I think we should not make it any harder on consumers of the EJB API,
> because having the JTA API or JAX-RPC API through EJB API should not
> imply those functions are available.
I don't think it's particularly onerous at all. At compile-time, if you
don't use JTA or JAX-RPC then there is absolutely no benefit to having
them on your compile class path. It's not about available
functionality. It's about opting in to the features that you use,
instead of opting out of features that the user probably isn't even
aware of, and avoiding pointless class path explosion and all the
problems that come with it.
I agree with that.
> In fact the EJB container is obliged to have JAX-RPC API available even
> in lite mode, because else you would run into a problem with
> SessionContext.getMessageContext. The method itself however will throw
> an IllegalStateException.
Good thing Maven dependencies have absolutely nothing to do with the EJB
container run time.
Not entirely true, whenever I fire up surefire my class path is dictated
by Maven. Should I then use EJB Embeddable the EJB container runs on
that class path as per spec. (I think we both agree that this is ugly as
hell, but the spec is as such.)
EJB 3.1 22.1
"Embeddable usage requirements allow client code to instantiate an EJB
container that runs within its
own JVM and classloader."
> In other words having EJB API provided, implies JTA API and JAX-RPC API
> are provided as well.
Not at all. When something is "provided" in Maven, that doesn't mean
that the dependency is provided. The scope was named on the assumption
of the run time disposition of the JAR, which is pretty silly given that
Maven is a compile-time tool. Think of "provided" as "import" and
"compile" as "re-export" and you're a lot closer to reality
(though of
course Maven is very sloppy when it comes to actually assembling the
artifacts since they're all flattened into one class path, so it's not
perfectly identical to the corresponding modular terms).
As long as you don't run surefire, then yes, Maven is a compile-time tool.
Once you go into surefire, you get that sloppy one class path.
I don't like Maven in this respect as well, but it is how it is.
The rule is this. Given APIs named A and B, and B depends on A, the
dependency should always be "provided" unless B is completely unusable
without A, in which case the default "compile" is acceptable.
'completely unusable' is non-definitive. It either works, or it does
not. I've shown that it does not.
Carlo
9:40 a.m.
On 02/06/2012 09:29 AM, Carlo de Wolf wrote:
On 02/06/2012 02:58 PM, David M. Lloyd wrote:
> On 02/06/2012 03:00 AM, Carlo de Wolf wrote:
>> On 02/04/2012 07:29 PM, David M. Lloyd wrote:
>>> On 02/04/2012 04:52 AM, Carlo de Wolf wrote:
>>>> On 02/03/2012 12:40 PM, Carlo de Wolf wrote:
>>>>> On 02/02/2012 06:22 PM, Jason T. Greene wrote:
>>>>>> org.jboss.ejb3.ext-api 2.0.0-beta-3
>>>>>> org.jboss.metadata 7.0.0.Beta35
>>>>>>
>>>>> Branch https://github.com/wolfc/metadata/tree/dependencies is waiting
on:
>>>>> - jboss-logging
>>>> Upgraded to 3.1.0.GA.
>>>>
>>>>> - https://github.com/jboss/jboss-ejb-api_spec/pull/1
>>>> I see it has been merged, but rolled back.
>>>> What is the issue here?
>>>> (Note that it can be viewed as a regression from 1.0.0 to 1.0.1.)
>>> It can also be viewed as not a regression. These dependencies should be
>>> provided as they are only required if you actually reference those
>>> classes. Compile scope dependencies should only be used in APIs when
>>> the API is completely unusable without the dependency.
>> It is a known deficiency on the EG that EJB API has dependencies on JTA
>> API and JAX-RPC API.
>> Unfortunately there is nothing that can be done to change that.
>>
>> I think we should not make it any harder on consumers of the EJB API,
>> because having the JTA API or JAX-RPC API through EJB API should not
>> imply those functions are available.
> I don't think it's particularly onerous at all. At compile-time, if you
> don't use JTA or JAX-RPC then there is absolutely no benefit to having
> them on your compile class path. It's not about available
> functionality. It's about opting in to the features that you use,
> instead of opting out of features that the user probably isn't even
> aware of, and avoiding pointless class path explosion and all the
> problems that come with it.
I agree with that.
>
>> In fact the EJB container is obliged to have JAX-RPC API available even
>> in lite mode, because else you would run into a problem with
>> SessionContext.getMessageContext. The method itself however will throw
>> an IllegalStateException.
> Good thing Maven dependencies have absolutely nothing to do with the EJB
> container run time.
Not entirely true, whenever I fire up surefire my class path is dictated
by Maven. Should I then use EJB Embeddable the EJB container runs on
that class path as per spec. (I think we both agree that this is ugly as
hell, but the spec is as such.)
EJB 3.1 22.1
"Embeddable usage requirements allow client code to instantiate an EJB
container that runs within its
own JVM and classloader."
This has no bearing on including JTA.
>> In other words having EJB API provided, implies JTA API and
JAX-RPC API
>> are provided as well.
> Not at all. When something is "provided" in Maven, that doesn't mean
> that the dependency is provided. The scope was named on the assumption
> of the run time disposition of the JAR, which is pretty silly given that
> Maven is a compile-time tool. Think of "provided" as "import"
and
> "compile" as "re-export" and you're a lot closer to reality
(though of
> course Maven is very sloppy when it comes to actually assembling the
> artifacts since they're all flattened into one class path, so it's not
> perfectly identical to the corresponding modular terms).
As long as you don't run surefire, then yes, Maven is a compile-time tool.
Once you go into surefire, you get that sloppy one class path.
I don't like Maven in this respect as well, but it is how it is.
This also has no bearing on including JTA.
> The rule is this. Given APIs named A and B, and B depends on A,
the
> dependency should always be "provided" unless B is completely unusable
> without A, in which case the default "compile" is acceptable.
'completely unusable' is non-definitive. It either works, or it does
not. I've shown that it does not.
Untrue. It works for many use cases; it just doesn't work in the case
that you actually use the JTA dependency. The solution is fortunately
obvious: the user adds the JTA API to their project.
To make it even more clear, there are two options. The first is that we
automatically pull in the JTA API and the user must exclude it if they
don't want it. The second is that we exclude it by default and the user
must include it if they _do_ want it.
The difference between these two is that the user will not exclude the
dependency since they will tend to not know that it has been included
for them. This becomes a problem when the transitive dependency graph
becomes large (which happens very quickly because this is unfortunately
the default). Explicit inclusion of non-essential dependencies is the
superior option.
As I said the rule is quite clear - if the API is usable without the
dependency then the dependency API should not automatically be included.
Specs do not enter into the equation. It is only when the API cannot
be used in any useful way that the dependency should be automatic. I do
not think there is really any gray here. "Does not work sometimes" is
not sufficient to justify a compile scope dependency.
--
- DML
5:46 a.m.
Jason,
on this topic, as per https://issues.jboss.org/browse/AS7-3581 and
https://issues.jboss.org/browse/AS7-3579, I'm going to update the whole
jbossws component group + apache cxf except jbossws-api. I should be
sending a pull request later today.
Cheers
Alessio
On 02/02/2012 06:22 PM, Jason T. Greene wrote:
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
--
Alessio Soldano
Web Service Lead, JBoss
2:35 a.m.
Done for
* org.jboss.arquillian.osgi
* org.jboss.osgi.metadata
https://github.com/jbossas/jboss-as/pull/1400
On 02/02/2012 06:22 PM, Jason T. Greene wrote:
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:45 a.m.
jboss-jsf-api_2.1_spec is now upgraded to 2.0.0.Final
On 02/02/2012 11:22 AM, Jason T. Greene wrote:
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
3:11 p.m.
In Arquillian's case: 1.0.0.Final is planned for WFK 2.0, where the community bits
will be certified against EAP 6.
-aslak-
----- Original Message -----
I need finals of everything on this list today, tomorrow at the
*ABSOLUTE LATEST*.
org.infinispan 5.1.1.CR1
org.jboss.arquillian.core 1.0.0.CR7
org.jboss.arquillian.osgi 1.0.0.CR6
org.jboss.as.jbossweb-native 2.0.10.Beta1
org.jboss.com.sun.httpserver 1.0.0.Beta3
org.jboss.ejb3.ext-api 2.0.0-beta-3
org.jboss.iiop-client 1.0.0.Beta2
org.jboss.interceptor 2.0.0.Alpha3
org.jboss.jboss-transaction-spi 7.0.0.CR2
org.jboss.jboss-vfs 3.1.0.CR1
org.jboss.jsfunit 2.0.0.Beta1
org.jboss.logging.jboss-logging 3.1.0.CR2
org.jboss.logging.jboss-logging-tools 1.0.0.CR5
org.jboss.metadata 7.0.0.Beta35
org.jboss.mod_cluster 1.2.0.Beta4
org.jboss.modules.jboss-modules 1.1.0.CR8
org.jboss.osgi.metadata 2.0.0.CR1
org.jboss.remote-naming 1.0.0.Beta4
org.jboss.remoting3 3.2.0.CR9
org.jboss.remoting3.remoting-jmx 1.0.0.Beta1
org.jboss.sasl 1.0.0.Beta9
org.jboss.security.jboss-negotiation 2.2.0.Beta3
org.jboss.shrinkwrap.shrinkwrap 1.0.0-cr-1
org.jboss.shrinkwrap.resolver 1.0.0-beta-5
jboss-jsf-api_2.1_spec 2.0.0.Beta1
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4703
days inactive
4708
days old
15 comments
9 participants
participants (9)
-
Alessio Soldano -
Aslak Knutsen -
Carlo de Wolf -
Darran Lofthouse -
David M. Lloyd -
James R. Perkins -
Jason T. Greene -
Paul Gier -
Thomas Diesler