I agree with both arguments. We must stick to rule we set for
versioning. But we must also have a means to bring in new technologies
onto the AS platform.
For me I don't see option (b) happening in a fashion project leads want
to benefit of it. Most likely we'll have a quarterly or bi-monthly AS
release, while I would want a bi-weekly release of EJB3.
That's the reason why we're working on the EJB3 plugin. It works in a
similar manner to the WB RI update. Use ant to patch AS.
In future this is going to be handled by the patching functionality of
the Profile Service. It'll be backed up by a Maven repository where
it'll download the version of a bundle/package specified by the
administrator.
Some stuff I don't see happening, for example OSGi class loading
bundles. For example, jboss-metadata must only appear once because else
JBossSessionBeanMetaData != JBossSessionBeanMetaData anymore and you can
visualize how WB, WS, REST are ignoring EJB 3.1 beans.
Other things I think we should be able to do now like a meta xml
describing the bundle/package and it's dependencies, jarring it up,
putting that into a Maven repo and downloading it (and the dependencies
again).
Merging of config files will be an interesting problem and thus left out
of scope for the moment. :-)
Installation of jar files can for the moment be handled by Ant.
So you'll get something like:
Each containing:
META-INF/jboss-profile.xml
META-INF/jboss-package-build.xml
lib/myjars.jar
With jboss-package-build.xml targets: install, uninstall.
Now I can see some mismatch between this idea and the Profile Service
designs, so I would like to move the EJB3 plugin to the next step
without slicing my fingers.
Note that developing in Branch_5_x and releasing against AS 5.0.0 is
impossible. Been there, done that. ;-)
Carlo
Threads on Profile Service:
[1]
I must say I'm enjoying this discussion :)
I think the answer is simple, really. If we want to:
(a) respect our versioning strategy (major/minor/point)
(b) speed up the release cycle
then we need to push features to minor releases. Project leads will
always want to include their latest stuff to whichever is the next AS
release, the reason being we didn't respect both (a) & (b) in the
past. And I have too many stories to tell of "smallish" changes with
cascading dependencies or causing unpredictable results.
As it is now Branch_5_0 looks pretty stable testsuite/tck-wise and
that makes my life a lot easier if I want to make the release date, so
why risk breaking it?
Besides 5.1 shouldn't be far way, end of February most probably. And
if you are too eager to integrate, perform your work in
Branch_5_x/trunk, then test against 5.0.x and release the webbeans
deployer independently.
Exception to the rules will always be, but let's try to stick to the
rule first :)
David M. Lloyd wrote:
> Yes: 5.0.x is a stable branch and should only get bug fixes.
>
> By all means, integrate it into 5.1. But if it were me running the
> project, I'd say, make sure that when it does get into the 5.x branch
> that it is stable (a GA release), as merging snapshots and betas and
> CRs at this stage will serve only to delay the release which is
> supposed to be on a fixed schedule now.
>
> The point of my email really has nothing to do with Web Beans - I
> don't really know the status at all. I was just trying to get
> Dimitris to be more assertive - he just seems so darn apologetic and
> polite all the time. :-)
>
> I would take it even a step farther and say that Dimitris should have
> a fixed window during which people are allowed to merge new features
> into the 5.x branch (which should be on a public calendar somewhere),
> to give plenty of time to get the release stable before doing the
> release. But I guess he'll only put up with me telling him how to do
> his job for so long before telling me to get bent :)
>
> - DML
>
> On 01/15/2009 06:33 AM, Pete Muir wrote:
>> Do you have a reasoned argument (other than a needing a quick power
>> trip) about why we should not be pushing new software that we
>> develop into JBoss AS (clearly marked as a technology preview), to
>> allow early access and increase the feedback we get?For example,
>> EJB3 was optionally included in JBoss 4.0.x.
>>
>> Reading between the lines, I hope that this will address your concerns:
>>
>> First, please see
https://jira.jboss.org/jira/browse/JBAS-6371 - you
>> can see that I am suggesting 5.1 as the place to introduce WB.
>>
>> Second, as I stated earlier (obviously not clearly enough) we built
>> the integration such that none of the WB libraries are included in
>> the AS or application classpath unless the deployment is a Web Beans
>> deployment (as marked by a {META-INF|WEB_INF}/web-beans.xml). Of
>> course, this doesn't apply to the WB deployers which deploy the app,
>> and push the WB libraries onto the app classpath. Thus, whether or
>> not WB is stable, shouldn't affect non-web-bean apps applied to the AS.
>>
>> On 14 Jan 2009, at 22:11, David M. Lloyd wrote:
>>
>>> Dimitris, you worded that wrong. You should have said:
>>>
>>> "We are ABSOLUTELY NOT integrating Web Beans into 5.0.1. But I
>>> will ALLOW you to merge a STABLE implementation into 5.1."
>>>
>>> Let them know who's boss. :-)
>>>
>>> - DML
>>>
>>> On 01/14/2009 04:03 PM, Dimitris Andreadis wrote:
>>>> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x)
>>>>
>>>> 5.0.1 is a bug fixing release...
>>>> Scott Stark wrote:
>>>>> In going through the integration of the current webeans
>>>>> 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number
>>>>> guess example fails to deploy on startup with:
>>>>>
>>>>> Caused by: java.lang.NullPointerException
>>>>> at
>>>>>
org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:123)
>>>>>
>>>>> at
>>>>>
org.jboss.webbeans.integration.jbossas.ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:41)
>>>>>
>>>>> at
>>>>>
org.jboss.webbeans.integration.jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:25)
>>>>>
>>>>> ... 65 more
>>>>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI
>>>>> 1.0.0.ALPHA1
>>>>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending
>>>>> context initialized event to listener instance of class
>>>>> org.jboss.webbeans.servlet.WebBeansListener
>>>>>
>>>>> So I guess we need to focus on web beans integration tests as well.
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development