ility of multiple modules.
>> >>
>> >>Matt
>> >>
>> >>On Mon, Jun 4, 2012 at 10:47 PM, Honton, Charles
>> >> wrote:
>> >>> I'd like to wait until we have use cases that require reorganization.
>> >>>I suspect that we're not
o support additional URL types. (I'm sure we're going to
> >>>need to support the JBoss vfs URLs) Plugging in URL providers may be
> >>>smaller than a multi-module project.
> >>>
> >>> Regards,
> >>> chas
> >>>
> >
Ls) Plugging in URL providers may be
>>>smaller than a multi-module project.
>>>
>>> Regards,
>>> chas
>>>
>>> -Original Message-
>>> From: Matt Benson [mailto:gudnabr...@gmail.com]
>>> Sent: Sunday, June 03, 2012 8:40
we
> >>might need to support additional URL types. (I'm sure we're going to
> >>need to support the JBoss vfs URLs) Plugging in URL providers may be
> >>smaller than a multi-module project.
> >>
> >> Regards,
> >> chas
> >>
;> chas
>>
>> -Original Message-
>> From: Matt Benson [mailto:gudnabr...@gmail.com]
>> Sent: Sunday, June 03, 2012 8:40 AM
>> To: dev@commons.apache.org
>> Subject: [classscan] organization
>>
>> I propose that we, in the immediate future, reo
: Matt Benson [mailto:gudnabr...@gmail.com]
> Sent: Sunday, June 03, 2012 8:40 AM
> To: dev@commons.apache.org
> Subject: [classscan] organization
>
> I propose that we, in the immediate future, reorganize [classscan]
> into multiple modules. I fully expect that by the time we get
may be smaller than a
multi-module project.
Regards,
chas
-Original Message-
From: Matt Benson [mailto:gudnabr...@gmail.com]
Sent: Sunday, June 03, 2012 8:40 AM
To: dev@commons.apache.org
Subject: [classscan] organization
I propose that we, in the immediate future, reorganize [clas
Hi, Matt!
I second Gary on that, there are enough preconditions to forget Java5
and focus on Java6 only.
You also have my +1 on supporting the SPI pattern on that!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://
On Jun 3, 2012, at 11:40, Matt Benson wrote:
> I propose that we, in the immediate future, reorganize [classscan]
> into multiple modules. I fully expect that by the time we get
> everyone's input/features/alternative implementations for X/Y/Z in
> place, we will want the flexibility. I am fine
I propose that we, in the immediate future, reorganize [classscan]
into multiple modules. I fully expect that by the time we get
everyone's input/features/alternative implementations for X/Y/Z in
place, we will want the flexibility. I am fine with starting small,
e.g. core/bcel modules, although
10 matches
Mail list logo