6:42 p.m.
We need to finalize the 3 month road map for AS5.x and its relation to
AS6. The current discussions have been around embedded and EE6 type
profiles and that we should focus on incorporating AS6 elements in the
next AS5.x release that improve the following areas:
* Unit Test Capabilities. The ability to embed JBoss inside unit tests
so that they can be run with no special plugins within an IDE, vanilla
maven testsuite, vanilla ant testsuite.
* Maven JBoss Plugin. You can define a configuration or override the
default. Basically making it nice and easy to use for maven people.
* Bundling of embedded jopr for the management console
* Get on-demand working for as many services as possible
* Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
* Deprecate and prune components and move them to a deprecated folder so
that they don't boot up with default config. (Web Console, JMX-Console,
Scheduler, EJB 2.x)
* Clean up service dependencies so its easier to add/remove components
and subsystems. This is related to on-demand as well.
* Define proper packaging of services so that dependencies and isolation
of implementation details exist.
* Profile service supporting subprofiles and proper repository
abstraction to allow for simple requirements descriptions of services in
a profile driving the post MC bootstrap loading of services.
10:57 a.m.
We need to finalize the 3 month road map for AS5.x and its relation
to
AS6. The current discussions have been around embedded and EE6 type
profiles and that we should focus on incorporating AS6 elements in the
next AS5.x release that improve the following areas:
* Unit Test Capabilities. The ability to embed JBoss inside unit
tests so that they can be run with no special plugins within an IDE,
vanilla maven testsuite, vanilla ant testsuite.
* Maven JBoss Plugin. You can define a configuration or override the
default. Basically making it nice and easy to use for maven people.
Enable JBoss
Tools AS Plugin: AS 5 should provide an API we can use for
efficient deployment.
:)
* Bundling of embedded jopr for the management console
* Get on-demand working for as many services as possible
* Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
* Deprecate and prune components and move them to a deprecated folder
so that they don't boot up with default config. (Web Console,
JMX-Console, Scheduler, EJB 2.x)
* Clean up service dependencies so its easier to add/remove components
and subsystems. This is related to on-demand as well.
* Define proper packaging of services so that dependencies and
isolation of implementation details exist.
* Profile service supporting subprofiles and proper repository
abstraction to allow for simple requirements descriptions of services
in a profile driving the post MC bootstrap loading of services.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:08 a.m.
Tied to this is what we're going to do with the branches.
We need a branch to get to EAP 5 which will contain fixes which are not
backwards compatible with AS 5.0 GA, by definition this rules out
Branch_5_0. For community purposes we should only have to use trunk, so
effectively Branch_5_0 is a dead branch unless we need to do a 5.0.1. So
we might as well startup the EAP branch right away.
In AS trunk we can pursue the plan outlined below by Scott. Meanwhile I
would say we create an AS 6 project in which we build 6 as we envisioned
it in the first place: JBoss Bootstrap (MC, VDF etc) + JBoss Profile
Service. For the first iteration we can hardcode one profile: JavaEE 6
until the Profile Service is up and running. That means any components
coming free out of the AS 5 (/trunk) refactoring can immediately be
incorporated into AS 6. At some point the refactoring of AS 5 will make
it look almost exactly as AS 6 or AS 6 will become fully operational. At
which we deprecate AS 5 (/trunk).
Carlo
Scott Stark wrote:
We need to finalize the 3 month road map for AS5.x and its relation
to
AS6. The current discussions have been around embedded and EE6 type
profiles and that we should focus on incorporating AS6 elements in the
next AS5.x release that improve the following areas:
* Unit Test Capabilities. The ability to embed JBoss inside unit
tests so that they can be run with no special plugins within an IDE,
vanilla maven testsuite, vanilla ant testsuite.
* Maven JBoss Plugin. You can define a configuration or override the
default. Basically making it nice and easy to use for maven people.
* Bundling of embedded jopr for the management console
* Get on-demand working for as many services as possible
* Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
* Deprecate and prune components and move them to a deprecated folder
so that they don't boot up with default config. (Web Console,
JMX-Console, Scheduler, EJB 2.x)
* Clean up service dependencies so its easier to add/remove components
and subsystems. This is related to on-demand as well.
* Define proper packaging of services so that dependencies and
isolation of implementation details exist.
* Profile service supporting subprofiles and proper repository
abstraction to allow for simple requirements descriptions of services
in a profile driving the post MC bootstrap loading of services.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:16 p.m.
Regarding EAP5, my suggestion is to stick with Branch_5_0 and continue work there. If at
some point we *have* to consider non-backwards compatible changes, then we can branch off
Branch_5_1 from the latest Branch_5_0. Or even stay with Branch_5_0 if the changes are not
significant.
What are the non-backward compatible changes anyway? That's the real question to ask.
If we
are certain of those we could Branch_5_1 now. The key is that we don't want to deviate
much
from 5.0.0.GA. Otherwise all the testing and stabilization we have done is lost.
About trunk, I think we should point to AS6 Alpha. To try experimenting with a different
Bootstrap+ProfileService type of setup either create another working branch or an external
project (JBoss Reloaded or whatever) and merge back when done.
I think the key is to keep trunk relatively usable and stable. If we start breaking things
here and there we'll repeat the same mistakes we did with AS5; the whole thing will
soon get
out of control.
Carlo de Wolf wrote:
Tied to this is what we're going to do with the branches.
We need a branch to get to EAP 5 which will contain fixes which are not
backwards compatible with AS 5.0 GA, by definition this rules out
Branch_5_0. For community purposes we should only have to use trunk, so
effectively Branch_5_0 is a dead branch unless we need to do a 5.0.1. So
we might as well startup the EAP branch right away.
In AS trunk we can pursue the plan outlined below by Scott. Meanwhile I
would say we create an AS 6 project in which we build 6 as we envisioned
it in the first place: JBoss Bootstrap (MC, VDF etc) + JBoss Profile
Service. For the first iteration we can hardcode one profile: JavaEE 6
until the Profile Service is up and running. That means any components
coming free out of the AS 5 (/trunk) refactoring can immediately be
incorporated into AS 6. At some point the refactoring of AS 5 will make
it look almost exactly as AS 6 or AS 6 will become fully operational. At
which we deprecate AS 5 (/trunk).
Carlo
Scott Stark wrote:
> We need to finalize the 3 month road map for AS5.x and its relation to
> AS6. The current discussions have been around embedded and EE6 type
> profiles and that we should focus on incorporating AS6 elements in the
> next AS5.x release that improve the following areas:
>
> * Unit Test Capabilities. The ability to embed JBoss inside unit
> tests so that they can be run with no special plugins within an IDE,
> vanilla maven testsuite, vanilla ant testsuite.
> * Maven JBoss Plugin. You can define a configuration or override the
> default. Basically making it nice and easy to use for maven people.
> * Bundling of embedded jopr for the management console
> * Get on-demand working for as many services as possible
> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
> * Deprecate and prune components and move them to a deprecated folder
> so that they don't boot up with default config. (Web Console,
> JMX-Console, Scheduler, EJB 2.x)
> * Clean up service dependencies so its easier to add/remove components
> and subsystems. This is related to on-demand as well.
> * Define proper packaging of services so that dependencies and
> isolation of implementation details exist.
> * Profile service supporting subprofiles and proper repository
> abstraction to allow for simple requirements descriptions of services
> in a profile driving the post MC bootstrap loading of services.
>
>
> _______________________________________________
> 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
8:31 p.m.
Restraining myself from commenting on the silliness of calling it
"Branch_anything" when it's already in the branches/ dir...
I think that if there's going to be 6.0 work starting now, then 6.0 should
be in the trunk and there should be a 5.x branch from that which acts as
trunk-for-5.x, and then a branch for 5.0 from 5.x once work on 5.1 is to
start, etc.
It's just like any regular project except there's one extra level of
branches; any general bugfix should go trunk -> 5.x -> 5.0/5.1/whatever the
current release branch is. Any bugfix or feature that is intended only for
5.x (e.g. would be redundant in 6.0) would go in the 5.x branch and
possibly merged from there into 5.0/5.1/etc.
Seems pretty straightforward to me.
- DML
On 12/22/2008 12:16 PM, Dimitris Andreadis wrote:
Regarding EAP5, my suggestion is to stick with Branch_5_0 and
continue
work there. If at some point we *have* to consider non-backwards
compatible changes, then we can branch off Branch_5_1 from the latest
Branch_5_0. Or even stay with Branch_5_0 if the changes are not
significant.
What are the non-backward compatible changes anyway? That's the real
question to ask. If we are certain of those we could Branch_5_1 now. The
key is that we don't want to deviate much from 5.0.0.GA. Otherwise all
the testing and stabilization we have done is lost.
About trunk, I think we should point to AS6 Alpha. To try experimenting
with a different Bootstrap+ProfileService type of setup either create
another working branch or an external project (JBoss Reloaded or
whatever) and merge back when done.
I think the key is to keep trunk relatively usable and stable. If we
start breaking things here and there we'll repeat the same mistakes we
did with AS5; the whole thing will soon get out of control.
Carlo de Wolf wrote:
> Tied to this is what we're going to do with the branches.
>
> We need a branch to get to EAP 5 which will contain fixes which are
> not backwards compatible with AS 5.0 GA, by definition this rules out
> Branch_5_0. For community purposes we should only have to use trunk,
> so effectively Branch_5_0 is a dead branch unless we need to do a
> 5.0.1. So we might as well startup the EAP branch right away.
>
> In AS trunk we can pursue the plan outlined below by Scott. Meanwhile
> I would say we create an AS 6 project in which we build 6 as we
> envisioned it in the first place: JBoss Bootstrap (MC, VDF etc) +
> JBoss Profile Service. For the first iteration we can hardcode one
> profile: JavaEE 6 until the Profile Service is up and running. That
> means any components coming free out of the AS 5 (/trunk) refactoring
> can immediately be incorporated into AS 6. At some point the
> refactoring of AS 5 will make it look almost exactly as AS 6 or AS 6
> will become fully operational. At which we deprecate AS 5 (/trunk).
>
> Carlo
>
> Scott Stark wrote:
>> We need to finalize the 3 month road map for AS5.x and its relation
>> to AS6. The current discussions have been around embedded and EE6
>> type profiles and that we should focus on incorporating AS6 elements
>> in the next AS5.x release that improve the following areas:
>>
>> * Unit Test Capabilities. The ability to embed JBoss inside unit
>> tests so that they can be run with no special plugins within an IDE,
>> vanilla maven testsuite, vanilla ant testsuite.
>> * Maven JBoss Plugin. You can define a configuration or override the
>> default. Basically making it nice and easy to use for maven people.
>> * Bundling of embedded jopr for the management console
>> * Get on-demand working for as many services as possible
>> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
>> * Deprecate and prune components and move them to a deprecated folder
>> so that they don't boot up with default config. (Web Console,
>> JMX-Console, Scheduler, EJB 2.x)
>> * Clean up service dependencies so its easier to add/remove
>> components and subsystems. This is related to on-demand as well.
>> * Define proper packaging of services so that dependencies and
>> isolation of implementation details exist.
>> * Profile service supporting subprofiles and proper repository
>> abstraction to allow for simple requirements descriptions of services
>> in a profile driving the post MC bootstrap loading of services.
>>
>>
>> _______________________________________________
>> 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
10:42 p.m.
Dimitris Andreadis wrote:
Regarding EAP5, my suggestion is to stick with Branch_5_0 and
continue
work there. If at some point we *have* to consider non-backwards
compatible changes, then we can branch off Branch_5_1 from the latest
Branch_5_0. Or even stay with Branch_5_0 if the changes are not
significant.
What are the non-backward compatible changes anyway? That's the real
question to ask. If we are certain of those we could Branch_5_1 now.
I think they'd likely focus on changes to the ProfileService. Work to
improve things so that tools like Jopr that continue to advance over the
life of an EAP have as solid a base to administer as possible. I don't
know that such work will introduce non-backward compatible changes, but
it wouldn't surprise me.
I also think we'll find a number of small things that weren't quite
right in 5.0.0.GA where fixing them will introduce minor
incompatibilities. E.g. https://jira.jboss.org/jira/browse/JBAS-6281 .
Somehow I doubt that will be the only way. Perhaps a few tiny behavior
differences like that don't justify calling something 5.1, but if they
start to add up, IMHO they do.
The
key is that we don't want to deviate much from 5.0.0.GA. Otherwise all
the testing and stabilization we have done is lost.
+1. I think a next-release-in-3-months can only stand to have one
significant area of development; the rest should all be just bug fixes
and minor polishing. People not involved in that one area can shift to
trunk or whatever we call it.
That said, I don't think we should use the release name as a way
controlling the roadmap. Let's not call something that contains
incompatible changes 5.0.1 just as a way to try to prevent further
incompatible changes. Instead control the roadmap to an agreed upon
scope, and then call it what it is.
About trunk, I think we should point to AS6 Alpha. To try
experimenting
with a different Bootstrap+ProfileService type of setup either create
another working branch or an external project (JBoss Reloaded or
whatever) and merge back when done.
I think the key is to keep trunk relatively usable and stable. If we
start breaking things here and there we'll repeat the same mistakes we
did with AS5; the whole thing will soon get out of control.
Carlo de Wolf wrote:
> Tied to this is what we're going to do with the branches.
>
> We need a branch to get to EAP 5 which will contain fixes which are
> not backwards compatible with AS 5.0 GA, by definition this rules out
> Branch_5_0. For community purposes we should only have to use trunk,
> so effectively Branch_5_0 is a dead branch unless we need to do a
> 5.0.1. So we might as well startup the EAP branch right away.
>
> In AS trunk we can pursue the plan outlined below by Scott. Meanwhile
> I would say we create an AS 6 project in which we build 6 as we
> envisioned it in the first place: JBoss Bootstrap (MC, VDF etc) +
> JBoss Profile Service. For the first iteration we can hardcode one
> profile: JavaEE 6 until the Profile Service is up and running. That
> means any components coming free out of the AS 5 (/trunk) refactoring
> can immediately be incorporated into AS 6. At some point the
> refactoring of AS 5 will make it look almost exactly as AS 6 or AS 6
> will become fully operational. At which we deprecate AS 5 (/trunk).
>
> Carlo
>
> Scott Stark wrote:
>> We need to finalize the 3 month road map for AS5.x and its relation
>> to AS6. The current discussions have been around embedded and EE6
>> type profiles and that we should focus on incorporating AS6 elements
>> in the next AS5.x release that improve the following areas:
>>
>> * Unit Test Capabilities. The ability to embed JBoss inside unit
>> tests so that they can be run with no special plugins within an IDE,
>> vanilla maven testsuite, vanilla ant testsuite.
>> * Maven JBoss Plugin. You can define a configuration or override the
>> default. Basically making it nice and easy to use for maven people.
>> * Bundling of embedded jopr for the management console
>> * Get on-demand working for as many services as possible
>> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
>> * Deprecate and prune components and move them to a deprecated folder
>> so that they don't boot up with default config. (Web Console,
>> JMX-Console, Scheduler, EJB 2.x)
>> * Clean up service dependencies so its easier to add/remove
>> components and subsystems. This is related to on-demand as well.
>> * Define proper packaging of services so that dependencies and
>> isolation of implementation details exist.
>> * Profile service supporting subprofiles and proper repository
>> abstraction to allow for simple requirements descriptions of services
>> in a profile driving the post MC bootstrap loading of services.
>>
>>
>> _______________________________________________
>> 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
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
11:26 p.m.
Dimitris Andreadis wrote:
Regarding EAP5, my suggestion is to stick with Branch_5_0 and
continue
work there. If at some point we *have* to consider non-backwards
compatible changes, then we can branch off Branch_5_1 from the latest
Branch_5_0. Or even stay with Branch_5_0 if the changes are not
significant.
What are the non-backward compatible changes anyway? That's the real
question to ask. If we are certain of those we could Branch_5_1 now. The
key is that we don't want to deviate much from 5.0.0.GA. Otherwise all
the testing and stabilization we have done is lost.
About trunk, I think we should point to AS6 Alpha. To try experimenting
with a different Bootstrap+ProfileService type of setup either create
another working branch or an external project (JBoss Reloaded or
whatever) and merge back when done.
Are you suggesting we continue dev on Branch_5_whatever after the next
release in a few months? And then work toward AS6 Alpha continues in
parallel on trunk? Or is it more that Branch_5_whatever dies after the
next release?
Here's my concern about the latter: I'm a bit tired of working on major
releases. :-) Tired because they alter priorities; a major release
defines APIs that you expect to have to live with for several years. So
small things that might impact API take high priority, higher than they
otherwise would.
I'd like to see a few minor (not micro) releases, which give us the
flexibility to change lots of stuff without bringing in the overhead of
calling it "AS 6". If what we want to do over the next 6 months is such
a big change that it should be a major release, well, c'est la vie, but
let's not put a major release as next on the roadmap until we know the
scope requires it.
Note that EE 6 doesn't have to mean AS 6. Not if the components that
make up the AS work in the way Carlo wants EJB3 to work -- a backwards
compatible core that exposes EE 5 or EE 6 facades. With that a 5.x
server could have an EE 6 profile and an EE 5 profile. Or, while we work
on EE 6 a 5.x server could have a partial EE 6 profile and and EE 5 profile.
I think the key is to keep trunk relatively usable and stable. If we
start breaking things here and there we'll repeat the same mistakes we
did with AS5; the whole thing will soon get out of control.
Carlo de Wolf wrote:
> Tied to this is what we're going to do with the branches.
>
> We need a branch to get to EAP 5 which will contain fixes which are
> not backwards compatible with AS 5.0 GA, by definition this rules out
> Branch_5_0. For community purposes we should only have to use trunk,
> so effectively Branch_5_0 is a dead branch unless we need to do a
> 5.0.1. So we might as well startup the EAP branch right away.
>
> In AS trunk we can pursue the plan outlined below by Scott. Meanwhile
> I would say we create an AS 6 project in which we build 6 as we
> envisioned it in the first place: JBoss Bootstrap (MC, VDF etc) +
> JBoss Profile Service. For the first iteration we can hardcode one
> profile: JavaEE 6 until the Profile Service is up and running. That
> means any components coming free out of the AS 5 (/trunk) refactoring
> can immediately be incorporated into AS 6. At some point the
> refactoring of AS 5 will make it look almost exactly as AS 6 or AS 6
> will become fully operational. At which we deprecate AS 5 (/trunk).
>
> Carlo
>
> Scott Stark wrote:
>> We need to finalize the 3 month road map for AS5.x and its relation
>> to AS6. The current discussions have been around embedded and EE6
>> type profiles and that we should focus on incorporating AS6 elements
>> in the next AS5.x release that improve the following areas:
>>
>> * Unit Test Capabilities. The ability to embed JBoss inside unit
>> tests so that they can be run with no special plugins within an IDE,
>> vanilla maven testsuite, vanilla ant testsuite.
>> * Maven JBoss Plugin. You can define a configuration or override the
>> default. Basically making it nice and easy to use for maven people.
>> * Bundling of embedded jopr for the management console
>> * Get on-demand working for as many services as possible
>> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
>> * Deprecate and prune components and move them to a deprecated folder
>> so that they don't boot up with default config. (Web Console,
>> JMX-Console, Scheduler, EJB 2.x)
>> * Clean up service dependencies so its easier to add/remove
>> components and subsystems. This is related to on-demand as well.
>> * Define proper packaging of services so that dependencies and
>> isolation of implementation details exist.
>> * Profile service supporting subprofiles and proper repository
>> abstraction to allow for simple requirements descriptions of services
>> in a profile driving the post MC bootstrap loading of services.
>>
>>
>> _______________________________________________
>> 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
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
9:13 a.m.
Dimitris Andreadis wrote:
Regarding EAP5, my suggestion is to stick with Branch_5_0 and
continue
work there. If at some point we *have* to consider non-backwards
compatible changes, then we can branch off Branch_5_1 from the latest
Branch_5_0. Or even stay with Branch_5_0 if the changes are not
significant.
What are the non-backward compatible changes anyway? That's the real
question to ask. If we are certain of those we could Branch_5_1 now.
The key is that we don't want to deviate much from 5.0.0.GA. Otherwise
all the testing and stabilization we have done is lost.
About trunk, I think we should point to AS6 Alpha. To try
experimenting with a different Bootstrap+ProfileService type of setup
either create another working branch or an external project (JBoss
Reloaded or whatever) and merge back when done.
The current codebase contains dead
and petrified code. Or I would rather
say code gems. Right now we keep lugging this stuff around. If we can
cleanly separate it from trunk we got true diamonds, which we test once
and use forever.
By doing so we get the stable box of Lego blocks we want to keep around
(I still have my Lego from childhood :-) ). Some blocks wouldn't even
need any change, so there you'll find the stability.
For EAP5 already some issues have been identified which are not
backwards compatible:
- pruning of 'legacy' EJB3 functions (like ejb3-timerservice)
- xsd cleanup
I don't mind putting them into Branch_5_0, but the important thing is
that I don't want to be hampered by the backwards compatibility rule. So
do we get 'carte blanche'?
Names are important. Giving something the correct name is covering half
the expectancy and I say JBoss Reloaded *is* AS 6. If we rename trunk to
AS 6 Alpha, we can't release something from there that remotely looks
like AS 6. It looks (and is) AS 5 with some refactoring in progress.
I think the key is to keep trunk relatively usable and stable. If we
start breaking things here and there we'll repeat the same mistakes we
did with AS5; the whole thing will soon get out of control.
I agree, but it means
trunk can't move fast enough. So I would say keep
the AS 5.1 name and let's start work on JBoss Reloaded. We can do stable
releases of trunk and we can then do preview releases of Reloaded.
Carlo
Carlo de Wolf wrote:
> Tied to this is what we're going to do with the branches.
>
> We need a branch to get to EAP 5 which will contain fixes which are
> not backwards compatible with AS 5.0 GA, by definition this rules out
> Branch_5_0. For community purposes we should only have to use trunk,
> so effectively Branch_5_0 is a dead branch unless we need to do a
> 5.0.1. So we might as well startup the EAP branch right away.
>
> In AS trunk we can pursue the plan outlined below by Scott. Meanwhile
> I would say we create an AS 6 project in which we build 6 as we
> envisioned it in the first place: JBoss Bootstrap (MC, VDF etc) +
> JBoss Profile Service. For the first iteration we can hardcode one
> profile: JavaEE 6 until the Profile Service is up and running. That
> means any components coming free out of the AS 5 (/trunk) refactoring
> can immediately be incorporated into AS 6. At some point the
> refactoring of AS 5 will make it look almost exactly as AS 6 or AS 6
> will become fully operational. At which we deprecate AS 5 (/trunk).
>
> Carlo
>
> Scott Stark wrote:
>> We need to finalize the 3 month road map for AS5.x and its relation
>> to AS6. The current discussions have been around embedded and EE6
>> type profiles and that we should focus on incorporating AS6 elements
>> in the next AS5.x release that improve the following areas:
>>
>> * Unit Test Capabilities. The ability to embed JBoss inside unit
>> tests so that they can be run with no special plugins within an IDE,
>> vanilla maven testsuite, vanilla ant testsuite.
>> * Maven JBoss Plugin. You can define a configuration or override
>> the default. Basically making it nice and easy to use for maven
>> people.
>> * Bundling of embedded jopr for the management console
>> * Get on-demand working for as many services as possible
>> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
>> * Deprecate and prune components and move them to a deprecated
>> folder so that they don't boot up with default config. (Web Console,
>> JMX-Console, Scheduler, EJB 2.x)
>> * Clean up service dependencies so its easier to add/remove
>> components and subsystems. This is related to on-demand as well.
>> * Define proper packaging of services so that dependencies and
>> isolation of implementation details exist.
>> * Profile service supporting subprofiles and proper repository
>> abstraction to allow for simple requirements descriptions of
>> services in a profile driving the post MC bootstrap loading of
>> services.
>>
>>
>> _______________________________________________
>> 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
11:01 p.m.
Carlo de Wolf wrote:
Tied to this is what we're going to do with the branches.
We need a branch to get to EAP 5 which will contain fixes which are not
backwards compatible with AS 5.0 GA, by definition this rules out
Branch_5_0. For community purposes we should only have to use trunk,
If we are going to do significant (i.e. not just simple bug fixes) work
toward an EAP, we should release a community version when that work is
complete (i.e. when we hand it over to QA for the extra-extensive
pounding that an EAP gets). Otherwise the work we do doesn't get the
benefit of community review.
If we do that work on trunk, then we're limiting what we do over the
next X weeks to EAP-compatible stuff.
so
effectively Branch_5_0 is a dead branch unless we need to do a 5.0.1. So
we might as well startup the EAP branch right away.
An EAP branch should happen when we create a community release and then
turn the code over to QA.
In AS trunk we can pursue the plan outlined below by Scott. Meanwhile I
would say we create an AS 6 project in which we build 6 as we envisioned
it in the first place: JBoss Bootstrap (MC, VDF etc) + JBoss Profile
Service. For the first iteration we can hardcode one profile: JavaEE 6
until the Profile Service is up and running. That means any components
coming free out of the AS 5 (/trunk) refactoring can immediately be
incorporated into AS 6. At some point the refactoring of AS 5 will make
it look almost exactly as AS 6 or AS 6 will become fully operational. At
which we deprecate AS 5 (/trunk).
Carlo
Scott Stark wrote:
> We need to finalize the 3 month road map for AS5.x and its relation to
> AS6. The current discussions have been around embedded and EE6 type
> profiles and that we should focus on incorporating AS6 elements in the
> next AS5.x release that improve the following areas:
>
> * Unit Test Capabilities. The ability to embed JBoss inside unit
> tests so that they can be run with no special plugins within an IDE,
> vanilla maven testsuite, vanilla ant testsuite.
> * Maven JBoss Plugin. You can define a configuration or override the
> default. Basically making it nice and easy to use for maven people.
> * Bundling of embedded jopr for the management console
> * Get on-demand working for as many services as possible
> * Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
> * Deprecate and prune components and move them to a deprecated folder
> so that they don't boot up with default config. (Web Console,
> JMX-Console, Scheduler, EJB 2.x)
> * Clean up service dependencies so its easier to add/remove components
> and subsystems. This is related to on-demand as well.
> * Define proper packaging of services so that dependencies and
> isolation of implementation details exist.
> * Profile service supporting subprofiles and proper repository
> abstraction to allow for simple requirements descriptions of services
> in a profile driving the post MC bootstrap loading of services.
>
>
> _______________________________________________
> 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
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5660
days inactive
5664
days old
jboss-development@lists.jboss.org
8 comments
6 participants
participants (6)
-
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
Dimitris Andreadis -
Max Rydahl Andersen -
Scott Stark