What to do about jboss-common-core?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

What to do about jboss-common-core?

Brian Stansberry
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Darran Lofthouse
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Carlo de Wolf
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Brian Stansberry
In reply to this post by Darran Lofthouse
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Jesper Pedersen
In reply to this post by Brian Stansberry
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

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Darran Lofthouse
In reply to this post by Brian Stansberry


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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

David Lloyd-2
In reply to this post by Brian Stansberry
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Ales Justin
>> 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) {

---
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Brian Stansberry
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/jboss/as/server/parsing/PropertiesValueResolver.java

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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Brian Stansberry
In reply to this post by David Lloyd-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Bartosz Baranowski
I can move PEs to some lib just to kill this issue. Where should this thing end up ?

----- Original Message -----
From: "Brian Stansberry" <[hidden email]>
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Carlo de Wolf
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"<[hidden email]>
> To: [hidden email]
> 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?
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Dimitris Andreadis
In reply to this post by Brian Stansberry
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/
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

David Lloyd-2
In reply to this post by Carlo de Wolf
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"<[hidden email]>
>> To: [hidden email]
>> 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.

>
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Carlo de Wolf
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"<[hidden email]>
>>> To: [hidden email]
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: What to do about jboss-common-core?

Bartosz Baranowski


----- Original Message -----
From: "Carlo de Wolf" <[hidden email]>
To: [hidden email]
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"<[hidden email]>
>>> To: [hidden email]
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev