mer' but not sure how to name the
> piece which does the actual scanning. Ideas?
>
> txs and LieGrue,
> strub
>
> --- On Thu, 7/28/11, James Carman wrote:
>
>> From: James Carman
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>&
dbox] [classscan] classscan API design review needed
> To: "Commons Developers List"
> Date: Thursday, July 28, 2011, 11:01 PM
> Why the client / server
> nomenclature? Makes it sound too heavyweight
> On Jul 28, 2011 4:20 PM, "Mark Struberg"
> wrote:
>
hu, 7/28/11, Simone Tripodi wrote:
>>
>>> From: Simone Tripodi
>>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>>> To: "Commons Developers List"
>>> Date: Thursday, July 28, 2011, 6:44 PM
>>> Hallo Mark,
>&g
k filters
of course.
>
> LieGrue,
> strub
>
> --- On Thu, 7/28/11, Simone Tripodi wrote:
>
>> From: Simone Tripodi
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>> To: "Commons Developers List"
>> Date: Thursday, July
rub
>
> --- On Thu, 7/28/11, Simone Tripodi wrote:
>
>> From: Simone Tripodi
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>> To: "Commons Developers List"
>> Date: Thursday, July 28, 2011, 6:44 PM
>> Hallo Mark,
>>
>>
Language, but I'm not sure if this isn't a complete
overkill here.
It could be interesting to use the DSL approach for the callback filters of
course.
LieGrue,
strub
--- On Thu, 7/28/11, Simone Tripodi wrote:
> From: Simone Tripodi
> Subject: Re: [sandbox] [classscan] clas
Hallo Mark,
>
> Some classscan-clients maybe first need to read some config files for getting
> exclude/include info.
>
sorry for being repetitive but that's here too that I suggest adopting
the Meiyo's alike way of configuring the component via EDSL instead of
config files - there's no reason t
e I get
access.
--- On Wed, 7/27/11, Simone Tripodi wrote:
> From: Simone Tripodi
> Subject: Re: [sandbox] [classscan] classscan API design review needed
> To: "Commons Developers List" , gudnabr...@gmail.com
> Date: Wednesday, July 27, 2011, 7:44 PM
> Hi Jakob,
> I&#
Hi Jakob,
I'm worried I was not able to explain my ideas well; my intentions are
not proposing to modify how classscan behaves, but rather how it
looks!
Having an expression language rather than a configuration based on n
parameters is IMHO still a valid contribution that the existing
sandbox compo
http://wiki.apache.org/commons/classscan
On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr wrote:
> +1
>
> Regards,
> Jakob
>
> 2011/7/27 Matt Benson :
>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr
>> wrote:
>>> Hi Mark, Simone,
>>>
>>> I would prefer a way in which the classscan-clients can t
+1
Regards,
Jakob
2011/7/27 Matt Benson :
> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr
> wrote:
>> Hi Mark, Simone,
>>
>> I would prefer a way in which the classscan-clients can tell the
>> classscan-server in what they are interested in via an API like Mark
>> proposed (e.g. subscribe()) b
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr wrote:
> Hi Mark, Simone,
>
> I would prefer a way in which the classscan-clients can tell the
> classscan-server in what they are interested in via an API like Mark
> proposed (e.g. subscribe()) before the scanning of a specific artifact
> (e.g. jar)
Hi Mark, Simone,
I would prefer a way in which the classscan-clients can tell the
classscan-server in what they are interested in via an API like Mark
proposed (e.g. subscribe()) before the scanning of a specific artifact
(e.g. jar) starts. I guess this could be kinda like the
ProcessAnnotatedType
Hi Mark!!!
after had a (quick, honestly) look at your APIs I'm more convinced we
can merge our efforts to provide our users a kickass library to scan
the classpath.
Your ScanJob class could be configured with my Meiyo EDSL filters[1]
instead of passing parameters to the constructor, allowing users
Hi folks!
We need a few idea and brainstorming on the filter/selection mechanism for our
new classscan-api (yes, 3 's' in classscan).
There are some specs which require some marker files to actually enable the
class scanning. E.g. the JSR-299 CDI spec defines that only jars with
META-INF/bean
15 matches
Mail list logo
