8:35 a.m.
We need to decide what we want to do about usage of the
jboss-common-core library.
A pull request[1] has come in that brings a bunch of jboss-common-core
classes into the AS 7 codebase.
I know in the past we've discouraged use of jboss-common-core for
various reasons, the biggest AIUI being:
1) It's a dumping ground that brings in a lot of unnecessary classes.
2) Some of the stuff in there may not be well suited to AS 7 but is well
suited to earlier, supported releases. So to use it in both basically
means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
But pulling a bunch of classes out of it and into the AS itself is just
going to turn some module of the AS into a dumping ground. And it's
essentially a fork, but one where the forked code is in completely
separate code bases. I'd rather have people use jboss-common-core than
do that.
[1] https://github.com/jbossas/jboss-as/pull/1739
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
8:40 a.m.
I have already started to run into circular dependency issues with the
controller module when trying to connect together security from multiple
area - I am planning soon to review these dependencies again but I think
at this stage turning it into another common is just going to make it worse.
Regards,
Darran Lofthouse.
On 03/07/2012 02:35 PM, Brian Stansberry wrote:
We need to decide what we want to do about usage of the
jboss-common-core library.
A pull request[1] has come in that brings a bunch of jboss-common-core
classes into the AS 7 codebase.
I know in the past we've discouraged use of jboss-common-core for
various reasons, the biggest AIUI being:
1) It's a dumping ground that brings in a lot of unnecessary classes.
2) Some of the stuff in there may not be well suited to AS 7 but is well
suited to earlier, supported releases. So to use it in both basically
means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
But pulling a bunch of classes out of it and into the AS itself is just
going to turn some module of the AS into a dumping ground. And it's
essentially a fork, but one where the forked code is in completely
separate code bases. I'd rather have people use jboss-common-core than
do that.
[1] https://github.com/jbossas/jboss-as/pull/1739
8:57 a.m.
As a first step to scope the away from a dumping ground we should
specify and limit the dependencies allowed in jboss-common-core.
Carlo
On 03/07/2012 03:40 PM, Darran Lofthouse wrote:
I have already started to run into circular dependency issues with
the
controller module when trying to connect together security from multiple
area - I am planning soon to review these dependencies again but I think
at this stage turning it into another common is just going to make it worse.
Regards,
Darran Lofthouse.
On 03/07/2012 02:35 PM, Brian Stansberry wrote:
> We need to decide what we want to do about usage of the
> jboss-common-core library.
>
> A pull request[1] has come in that brings a bunch of jboss-common-core
> classes into the AS 7 codebase.
>
> I know in the past we've discouraged use of jboss-common-core for
> various reasons, the biggest AIUI being:
>
> 1) It's a dumping ground that brings in a lot of unnecessary classes.
> 2) Some of the stuff in there may not be well suited to AS 7 but is well
> suited to earlier, supported releases. So to use it in both basically
> means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
>
> But pulling a bunch of classes out of it and into the AS itself is just
> going to turn some module of the AS into a dumping ground. And it's
> essentially a fork, but one where the forked code is in completely
> separate code bases. I'd rather have people use jboss-common-core than
> do that.
>
>
> [1] https://github.com/jbossas/jboss-as/pull/1739
>
>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:58 a.m.
Absolutely this stuff can't go into the controller module. That's
completely out of the question. Nothing should go in controller that
isn't related to core management. A subsystem is not core management. If
something is only needed for a subsystem, it doesn't go into controller.
I don't want it in server either, although that module is a closer fit
since it has a bunch of stuff that subsystems need (e.g. the deployment
processing infrastructure.) Ideally we'd have split that "needed by
subsystems stuff" out from "needed to run a core server" stuff before
7.0.0, but we didn't have time. I see the split as an AS 8 thing. But I
don't want to make the server module a complete dumping ground.
On 3/7/12 8:40 AM, Darran Lofthouse wrote:
I have already started to run into circular dependency issues with
the
controller module when trying to connect together security from multiple
area - I am planning soon to review these dependencies again but I think
at this stage turning it into another common is just going to make it worse.
Regards,
Darran Lofthouse.
On 03/07/2012 02:35 PM, Brian Stansberry wrote:
> We need to decide what we want to do about usage of the
> jboss-common-core library.
>
> A pull request[1] has come in that brings a bunch of jboss-common-core
> classes into the AS 7 codebase.
>
> I know in the past we've discouraged use of jboss-common-core for
> various reasons, the biggest AIUI being:
>
> 1) It's a dumping ground that brings in a lot of unnecessary classes.
> 2) Some of the stuff in there may not be well suited to AS 7 but is well
> suited to earlier, supported releases. So to use it in both basically
> means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
>
> But pulling a bunch of classes out of it and into the AS itself is just
> going to turn some module of the AS into a dumping ground. And it's
> essentially a fork, but one where the forked code is in completely
> separate code bases. I'd rather have people use jboss-common-core than
> do that.
>
>
> [1] https://github.com/jbossas/jboss-as/pull/1739
>
>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:34 a.m.
On 03/07/2012 02:58 PM, Brian Stansberry wrote:
Absolutely this stuff can't go into the controller module.
That's
completely out of the question. Nothing should go in controller that
isn't related to core management. A subsystem is not core management. If
something is only needed for a subsystem, it doesn't go into controller.
I don't want it in server either, although that module is a closer fit
since it has a bunch of stuff that subsystems need (e.g. the deployment
processing infrastructure.) Ideally we'd have split that "needed by
subsystems stuff" out from "needed to run a core server" stuff before
7.0.0, but we didn't have time. I see the split as an AS 8 thing. But I
don't want to make the server module a complete dumping ground.
I would also say avoid server - that also pops up in the cyclic
dependencies I keep hitting that need splitting - the split you describe
for server is probably the same split I need so probably better not to
increase the dependencies on it.
I am also against a common or varia style module but not so much that we
break existing dependencies by overloading an existing module.
On 3/7/12 8:40 AM, Darran Lofthouse wrote:
> I have already started to run into circular dependency issues with the
> controller module when trying to connect together security from multiple
> area - I am planning soon to review these dependencies again but I think
> at this stage turning it into another common is just going to make it worse.
>
> Regards,
> Darran Lofthouse.
>
>
> On 03/07/2012 02:35 PM, Brian Stansberry wrote:
>> We need to decide what we want to do about usage of the
>> jboss-common-core library.
>>
>> A pull request[1] has come in that brings a bunch of jboss-common-core
>> classes into the AS 7 codebase.
>>
>> I know in the past we've discouraged use of jboss-common-core for
>> various reasons, the biggest AIUI being:
>>
>> 1) It's a dumping ground that brings in a lot of unnecessary classes.
>> 2) Some of the stuff in there may not be well suited to AS 7 but is well
>> suited to earlier, supported releases. So to use it in both basically
>> means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
>>
>> But pulling a bunch of classes out of it and into the AS itself is just
>> going to turn some module of the AS into a dumping ground. And it's
>> essentially a fork, but one where the forked code is in completely
>> separate code bases. I'd rather have people use jboss-common-core than
>> do that.
>>
>>
>> [1] https://github.com/jbossas/jboss-as/pull/1739
>>
>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:13 a.m.
On 03/07/2012 09:35 AM, Brian Stansberry wrote:
We need to decide what we want to do about usage of the
jboss-common-core library.
A pull request[1] has come in that brings a bunch of jboss-common-core
classes into the AS 7 codebase.
I know in the past we've discouraged use of jboss-common-core for
various reasons, the biggest AIUI being:
1) It's a dumping ground that brings in a lot of unnecessary classes.
2) Some of the stuff in there may not be well suited to AS 7 but is well
suited to earlier, supported releases. So to use it in both basically
means a semi-fork (i.e. branch it.) Forks increase maintenance burdens.
But pulling a bunch of classes out of it and into the AS itself is just
going to turn some module of the AS into a dumping ground. And it's
essentially a fork, but one where the forked code is in completely
separate code bases. I'd rather have people use jboss-common-core than
do that.
[1] https://github.com/jbossas/jboss-as/pull/1739
Blacklisting org.jboss.util and org.jboss.net in Tattletale shows:
* jboss-as-cmp-7.1.1.Final-SNAPSHOT.jar
* jboss-as-domain-management-7.1.1.Final-SNAPSHOT.jar
* jboss-as-ee-deployment-7.1.1.Final-SNAPSHOT.jar
* jboss-as-ejb3-7.1.1.Final-SNAPSHOT.jar
* jboss-as-jaxr-7.1.1.Final-SNAPSHOT.jar
* jboss-as-pojo-7.1.1.Final-SNAPSHOT.jar
* (jboss-common-core-2.2.17.GA.jar)
* jboss-jad-api_1.2_spec-1.0.0.Final.jar
* jbossws-common-2.0.2.GA.jar
* jbossws-cxf-server-4.0.2.GA.jar
* jbossws-native-core-4.0.2.GA.jar
* jbossxb-2.0.3.GA.jar
Best regards,
Jesper
9:37 a.m.
On 03/07/2012 08:35 AM, Brian Stansberry wrote:
We need to decide what we want to do about usage of the
jboss-common-core library.
Pulling things into AS is definitely the wrong thing to do. I
definitely agree on that score. I think the thing to do is to start
fragmenting common-core into categories until everything we use has been
put into its own library, and everything we don't use can then be dropped.
A pull request[1] has come in that brings a bunch of
jboss-common-core
classes into the AS 7 codebase.
[...]
For the property editor stuff, which seems to be the bulk of this
change, if it's widely used, perhaps a dedicated property editor library
is called for. Aleš, does the POJO deployment subsystem use this code?
--
- DML
9:51 a.m.
> A pull request[1] has come in that brings a bunch of
jboss-common-core
> classes into the AS 7 codebase.
> [...]
For the property editor stuff, which seems to be the bulk of this
change, if it's widely used, perhaps a dedicated property editor library
is called for. Aleš, does the POJO deployment subsystem use this code?
Good catch. :-)
Looking at the code, it looks like the only thing I use from there is sys prop
replacement.
(btw: what's the replacement for this in AS7?)
Whereas for property editor, I use java.beans.PropertyEditorManager mechanism.
-Ales
---
if (replaceProperties)
value = StringPropertyReplacer.replaceProperties(string);
}
if (clazz.isAssignableFrom(valueClass))
return value;
// First see if this is an Enum
if (clazz.isEnum()) {
Class<? extends Enum> eclazz = clazz.asSubclass(Enum.class);
return Enum.valueOf(eclazz, value.toString());
}
// Next look for a property editor
if (valueClass == String.class) {
PropertyEditor editor = PropertyEditorManager.findEditor(clazz);
if (editor != null) {
---
12:12 p.m.
On 3/7/12 9:51 AM, Ales Justin wrote:
>> A pull request[1] has come in that brings a bunch of
jboss-common-core
>> classes into the AS 7 codebase.
>> [...]
>
> For the property editor stuff, which seems to be the bulk of this
> change, if it's widely used, perhaps a dedicated property editor library
> is called for. Aleš, does the POJO deployment subsystem use this code?
Good catch. :-)
Looking at the code, it looks like the only thing I use from there is sys prop
replacement.
(btw: what's the replacement for this in AS7?)
https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/...
That class is somewhat the nose of the camel coming into the tent re:
this common-core stuff coming into the AS. If we actually end up with a
workable solution for splitting up jboss-common-core, I'd rather merge
the improvements in this class back into whatever external lib ends up
with StringPropertyReplacer.
The improvements were:
1) support for ${env.foo} where we call System.getEnv("foo") if
System.getProperty("env.foo") returns null.
2) barfing with an ISE if the property can't be resolved, instead of
just returning the unresolved string.
The latter change makes it problematic to port these things to the trunk
version of the existing jboss-common-core. There would need to be a new
Branch_2_2 or something.
Whereas for property editor, I use java.beans.PropertyEditorManager
mechanism.
-Ales
---
if (replaceProperties)
value = StringPropertyReplacer.replaceProperties(string);
}
if (clazz.isAssignableFrom(valueClass))
return value;
// First see if this is an Enum
if (clazz.isEnum()) {
Class<? extends Enum> eclazz = clazz.asSubclass(Enum.class);
return Enum.valueOf(eclazz, value.toString());
}
// Next look for a property editor
if (valueClass == String.class) {
PropertyEditor editor = PropertyEditorManager.findEditor(clazz);
if (editor != null) {
---
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:13 p.m.
On 3/7/12 9:37 AM, David M. Lloyd wrote:
On 03/07/2012 08:35 AM, Brian Stansberry wrote:
> We need to decide what we want to do about usage of the
> jboss-common-core library.
Pulling things into AS is definitely the wrong thing to do. I
definitely agree on that score. I think the thing to do is to start
fragmenting common-core into categories until everything we use has been
put into its own library, and everything we don't use can then be dropped.
Any volunteers?
We've talked about the need for this for a long time, but no one has
done it.
> A pull request[1] has come in that brings a bunch of
jboss-common-core
> classes into the AS 7 codebase.
> [...]
For the property editor stuff, which seems to be the bulk of this
change, if it's widely used, perhaps a dedicated property editor library
is called for. Aleš, does the POJO deployment subsystem use this code?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
1:33 a.m.
I can move PEs to some lib just to kill this issue. Where should this thing end up ?
----- Original Message -----
From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Wednesday, March 7, 2012 7:13:28 PM
Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
On 3/7/12 9:37 AM, David M. Lloyd wrote:
On 03/07/2012 08:35 AM, Brian Stansberry wrote:
> We need to decide what we want to do about usage of the
> jboss-common-core library.
Pulling things into AS is definitely the wrong thing to do. I
definitely agree on that score. I think the thing to do is to start
fragmenting common-core into categories until everything we use has been
put into its own library, and everything we don't use can then be dropped.
Any volunteers?
We've talked about the need for this for a long time, but no one has
done it.
> A pull request[1] has come in that brings a bunch of
jboss-common-core
> classes into the AS 7 codebase.
> [...]
For the property editor stuff, which seems to be the bulk of this
change, if it's widely used, perhaps a dedicated property editor library
is called for. Aleš, does the POJO deployment subsystem use this code?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4:53 a.m.
On 03/08/2012 08:33 AM, Bartosz Baranowski wrote:
I can move PEs to some lib just to kill this issue. Where should this
thing end up ?
----- Original Message -----
From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Wednesday, March 7, 2012 7:13:28 PM
Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
On 3/7/12 9:37 AM, David M. Lloyd wrote:
> On 03/07/2012 08:35 AM, Brian Stansberry wrote:
>> We need to decide what we want to do about usage of the
>> jboss-common-core library.
> Pulling things into AS is definitely the wrong thing to do. I
> definitely agree on that score. I think the thing to do is to start
> fragmenting common-core into categories until everything we use has been
> put into its own library, and everything we don't use can then be dropped.
>
I assume you with categories you mean maven modules under a single maven
project with a single release cycle?
We can start of with 'jboss-common' and a legacy module 'core' which is
deprecated by design.
PEs can then go into a module 'beans'.
Let it only have a dependency on JRE and nothing else for the moment.
I think we'll find a reason to include logging stuff at some point.
http://github.com/jboss/jboss-common ?
Carlo
Any volunteers?
We've talked about the need for this for a long time, but no one has
done it.
>> A pull request[1] has come in that brings a bunch of jboss-common-core
>> classes into the AS 7 codebase.
>> [...]
> For the property editor stuff, which seems to be the bulk of this
> change, if it's widely used, perhaps a dedicated property editor library
> is called for. Aleš, does the POJO deployment subsystem use this code?
>
9:18 a.m.
On 03/08/2012 04:53 AM, Carlo de Wolf wrote:
On 03/08/2012 08:33 AM, Bartosz Baranowski wrote:
> I can move PEs to some lib just to kill this issue. Where should this thing end up ?
>
> ----- Original Message -----
> From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
> To: jboss-as7-dev(a)lists.jboss.org
> Sent: Wednesday, March 7, 2012 7:13:28 PM
> Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
>
> On 3/7/12 9:37 AM, David M. Lloyd wrote:
>> On 03/07/2012 08:35 AM, Brian Stansberry wrote:
>>> We need to decide what we want to do about usage of the
>>> jboss-common-core library.
>> Pulling things into AS is definitely the wrong thing to do. I
>> definitely agree on that score. I think the thing to do is to start
>> fragmenting common-core into categories until everything we use has been
>> put into its own library, and everything we don't use can then be dropped.
>>
I assume you with categories you mean maven modules under a single maven
project with a single release cycle?
No, that defeats the point really. For the most part, common-core
consists of a pile of completely unrelated functions. There's no reason
to tie their release cycle together, especially as most modules will be
static for a long time with little or no interdependence.
We can start of with 'jboss-common' and a legacy module
'core' which is
deprecated by design.
PEs can then go into a module 'beans'.
Let it only have a dependency on JRE and nothing else for the moment.
I think we'll find a reason to include logging stuff at some point.
Definitely not.
No.
> Any volunteers?
>
> We've talked about the need for this for a long time, but no one has
> done it.
>
>>> A pull request[1] has come in that brings a bunch of jboss-common-core
>>> classes into the AS 7 codebase.
>>> [...]
>> For the property editor stuff, which seems to be the bulk of this
>> change, if it's widely used, perhaps a dedicated property editor library
>> is called for. Aleš, does the POJO deployment subsystem use this code?
>>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
4:05 p.m.
On 03/08/2012 04:18 PM, David M. Lloyd wrote:
On 03/08/2012 04:53 AM, Carlo de Wolf wrote:
> On 03/08/2012 08:33 AM, Bartosz Baranowski wrote:
>> I can move PEs to some lib just to kill this issue. Where should this thing end
up ?
>>
>> ----- Original Message -----
>> From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>> To: jboss-as7-dev(a)lists.jboss.org
>> Sent: Wednesday, March 7, 2012 7:13:28 PM
>> Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
>>
>> On 3/7/12 9:37 AM, David M. Lloyd wrote:
>>> On 03/07/2012 08:35 AM, Brian Stansberry wrote:
>>>> We need to decide what we want to do about usage of the
>>>> jboss-common-core library.
>>> Pulling things into AS is definitely the wrong thing to do. I
>>> definitely agree on that score. I think the thing to do is to start
>>> fragmenting common-core into categories until everything we use has been
>>> put into its own library, and everything we don't use can then be
dropped.
>>>
> I assume you with categories you mean maven modules under a single maven
> project with a single release cycle?
No, that defeats the point really. For the most part, common-core
consists of a pile of completely unrelated functions. There's no reason
to tie their release cycle together, especially as most modules will be
static for a long time with little or no interdependence.
> We can start of with 'jboss-common' and a legacy module 'core' which
is
> deprecated by design.
>
> PEs can then go into a module 'beans'.
>
> Let it only have a dependency on JRE and nothing else for the moment.
> I think we'll find a reason to include logging stuff at some point.
Definitely not.
> http://github.com/jboss/jboss-common ?
No.
Cool. In that case PEs can go into a standalone project at
http://github.com/jboss/jboss-common-beans.
Carlo
>> Any volunteers?
>>
>> We've talked about the need for this for a long time, but no one has
>> done it.
>>
>>>> A pull request[1] has come in that brings a bunch of jboss-common-core
>>>> classes into the AS 7 codebase.
>>>> [...]
>>> For the property editor stuff, which seems to be the bulk of this
>>> change, if it's widely used, perhaps a dedicated property editor library
>>> is called for. Aleš, does the POJO deployment subsystem use this code?
>>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:22 a.m.
----- Original Message -----
From: "Carlo de Wolf" <cdewolf(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, March 8, 2012 11:05:23 PM
Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
On 03/08/2012 04:18 PM, David M. Lloyd wrote:
On 03/08/2012 04:53 AM, Carlo de Wolf wrote:
> On 03/08/2012 08:33 AM, Bartosz Baranowski wrote:
>> I can move PEs to some lib just to kill this issue. Where should this thing end
up ?
>>
>> ----- Original Message -----
>> From: "Brian Stansberry"<brian.stansberry(a)redhat.com>
>> To: jboss-as7-dev(a)lists.jboss.org
>> Sent: Wednesday, March 7, 2012 7:13:28 PM
>> Subject: Re: [jboss-as7-dev] What to do about jboss-common-core?
>>
>> On 3/7/12 9:37 AM, David M. Lloyd wrote:
>>> On 03/07/2012 08:35 AM, Brian Stansberry wrote:
>>>> We need to decide what we want to do about usage of the
>>>> jboss-common-core library.
>>> Pulling things into AS is definitely the wrong thing to do. I
>>> definitely agree on that score. I think the thing to do is to start
>>> fragmenting common-core into categories until everything we use has been
>>> put into its own library, and everything we don't use can then be
dropped.
>>>
> I assume you with categories you mean maven modules under a single maven
> project with a single release cycle?
No, that defeats the point really. For the most part, common-core
consists of a pile of completely unrelated functions. There's no reason
to tie their release cycle together, especially as most modules will be
static for a long time with little or no interdependence.
> We can start of with 'jboss-common' and a legacy module 'core' which
is
> deprecated by design.
>
> PEs can then go into a module 'beans'.
>
> Let it only have a dependency on JRE and nothing else for the moment.
> I think we'll find a reason to include logging stuff at some point.
Definitely not.
> http://github.com/jboss/jboss-common ?
No.
Cool. In that case PEs can go into a standalone project at
http://github.com/jboss/jboss-common-beans.
Ok can someone create this repo?
Carlo
>> Any volunteers?
>>
>> We've talked about the need for this for a long time, but no one has
>> done it.
>>
>>>> A pull request[1] has come in that brings a bunch of jboss-common-core
>>>> classes into the AS 7 codebase.
>>>> [...]
>>> For the property editor stuff, which seems to be the bulk of this
>>> change, if it's widely used, perhaps a dedicated property editor library
>>> is called for. Aleš, does the POJO deployment subsystem use this code?
>>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5 a.m.
Let me review it, as well. I think I know which bits are still relevant.
On 07/03/2012 20:13, Brian Stansberry wrote:
On 3/7/12 9:37 AM, David M. Lloyd wrote:
> On 03/07/2012 08:35 AM, Brian Stansberry wrote:
>> We need to decide what we want to do about usage of the
>> jboss-common-core library.
>
> Pulling things into AS is definitely the wrong thing to do. I
> definitely agree on that score. I think the thing to do is to start
> fragmenting common-core into categories until everything we use has been
> put into its own library, and everything we don't use can then be dropped.
>
Any volunteers?
We've talked about the need for this for a long time, but no one has
done it.
>> A pull request[1] has come in that brings a bunch of jboss-common-core
>> classes into the AS 7 codebase.
>> [...]
>
> For the property editor stuff, which seems to be the bulk of this
> change, if it's widely used, perhaps a dedicated property editor library
> is called for. Aleš, does the POJO deployment subsystem use this code?
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
4672
days inactive
4674
days old
15 comments
8 participants
participants (8)
-
Ales Justin -
Bartosz Baranowski -
Brian Stansberry -
Carlo de Wolf -
Darran Lofthouse -
David M. Lloyd -
Dimitris Andreadis -
Jesper Pedersen