Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by Charles Honton:
http://wiki.apache.org/commons/classscan?action=diffrev1=6rev2=7
The `[classscan]` component aims to provide a general-purpose
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by Charles Honton:
http://wiki.apache.org/commons/classscan?action=diffrev1=7rev2=8
Cache
With this approach, `MetaRegistry` would have
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The ClassScan page has been changed by Charles Honton:
http://wiki.apache.org/commons/ClassScan
New page:
#REDIRECT classscan
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by Charles Honton:
http://wiki.apache.org/commons/classscan?action=diffrev1=5rev2=6
=== High-Level Modules ===
- Core
+ api
no. and thats exactly the problem.
LieGrue,
strub
- Original Message -
From: Honton, Charles charles_hon...@intuit.com
To: Mark Struberg strub...@yahoo.de; Commons Developers List
dev@commons.apache.org
Cc:
Sent: Thursday, June 7, 2012 5:28 PM
Subject: Re: [classscan] new URL
:
Sent: Friday, June 8, 2012 5:47 PM
Subject: Re: [classscan] Metadata API discussion
In on my MacBook, I get the following counts for running just the unit
tests:
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode
In on my MacBook, I get the following counts for running just the unit
tests:
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Cache: 1
BootstrapClassLoader: 1
WeakConcurrentHashMap: 1
MetaUrlClassLoader:
, June 7, 2012 1:49 AM
Subject: Re: [classscan] Metadata API discussion
Mark,
In the BCEL implementation I originally used adapter classes which
implemented the appropriate interface and delegated to the BCEL object.
Unfortunately, this created a large memory footprint. The BCEL objects
@commons.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Thursday, June 7, 2012 1:59 AM
Subject: Re: [classscan] new URL(xxx) and it's problems
I did originally use URLs. Due to the ugliness Mark alludes to, I moved
to URIs. The biggest performance consideration was using a URL as a Key
On Thu, Jun 7, 2012 at 3:56 AM, sebb seb...@gmail.com wrote:
Not sure I follow this. Why would an interface use extra memory?
I can see that it might add a bit more to the static size of a class,
but why would it add more to each instance of a class that uses it?
It's not the interface
On 7 June 2012 21:11, James Carman ja...@carmanconsulting.com wrote:
On Thu, Jun 7, 2012 at 3:56 AM, sebb seb...@gmail.com wrote:
Not sure I follow this. Why would an interface use extra memory?
I can see that it might add a bit more to the static size of a class,
but why would it add more to
There can be quite a few if you have to have them for every class,
interface, annotation, method, field, etc. Then again if you just reuse 1
adapter object all the time it wouldn't be that bad. You would just have to
let users know that they cannot maintain references to those objects after
List dev@commons.apache.org
Cc:
Sent: Wednesday, June 6, 2012 7:50 AM
Subject: Re: [classscan] Experiment on xbean-finder
g ood stuff.
I'd like to go on and do the following:
in ./trunk add the following new directories
tck - our mass tests, etc which we can use for common testing
Hi!
Should we set our java language level to java5 or java6?
LieGrue,
strub
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
6
On Jun 6, 2012 8:51 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
Should we set our java language level to java5 or java6?
LieGrue,
strub
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
that no decisions were made, only ideas bandied about.
Matt
[1] http://wiki.apache.org/commons/classscan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi!
I've now looked through both impls and both share some very similar API classes
obviously (MetaClass, MetaField, etc). Details are different, but I think we
can extract a common API.
One thing I figured while looking at the code is that some parts are full with
URI handling instead of
Hi!
I now did read through the metadata classes of Chas' and Davids impls.
Both look pretty similar to some degree. A few key differences
* using AnnotatedElement instead of HasName() makes it possible to replace most
'old' code which does getAnnotations() etc 1:1
Imo we should keep this
Mark,
In the BCEL implementation I originally used adapter classes which
implemented the appropriate interface and delegated to the BCEL object.
Unfortunately, this created a large memory footprint. The BCEL objects
are not frugal with memory.
I'm pretty sure we could tease apart the BCEL parts
I did originally use URLs. Due to the ugliness Mark alludes to, I moved
to URIs. The biggest performance consideration was using a URL as a Key
to a map. That completely blew up performance.
Does anyone have a concrete example of !url.equals(new
URL(url.toExternalForm()) ?
Thanks,
Chas
On
...@yahoo.de
Cc:
Sent: Thursday, June 7, 2012 1:49 AM
Subject: Re: [classscan] Metadata API discussion
Mark,
In the BCEL implementation I originally used adapter classes which
implemented the appropriate interface and delegated to the BCEL object.
Unfortunately, this created a large memory
URLs in a map you need to do special tricks :(
LieGrue,
strub
- Original Message -
From: Honton, Charles charles_hon...@intuit.com
To: Commons Developers List dev@commons.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Thursday, June 7, 2012 1:59 AM
Subject: Re: [classscan
]
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
everyone's input/features/alternative implementations for X/Y/Z
Matt,
What particular approaches do you have in mind?
How is xbean-finder going to be plugged in? Is classscan to be dependent
upon xbean-finder or vice versa? What functionality will be required from
the dependency?
Thanks,
chas
On 6/5/12 7:26 AM, Matt Benson gudnabr...@gmail.com wrote:
I
I think Matt is talking about introducing a SPI concept.
On Tue, Jun 5, 2012 at 11:17 AM, Honton, Charles
charles_hon...@intuit.comwrote:
Matt,
What particular approaches do you have in mind?
How is xbean-finder going to be plugged in? Is classscan to be dependent
upon xbean-finder
configuration required.
Another module that will provide its own SPI will be more or less what
you see at
https://github.com/struberg/Apache-commons-classscanner/tree/master/classscan-api/src/main/java/org/apache/commons/classscan/api
.
How is xbean-finder going to be plugged in? Is classscan
-classscanner/tree/master/classscan-api/src/main/java/org/apache/commons/classscan/api
.
How is xbean-finder going to be plugged in? Is classscan to be dependent
upon xbean-finder or vice versa? What functionality will be required
from
the dependency?
xbean-finder could be plugged
will be more or less what
you see at
https://github.com/struberg/Apache-commons-classscanner/tree/master/classscan-api/src/main/java/org/apache/commons/classscan/api
.
How is xbean-finder going to be plugged in? Is classscan to be
dependent
upon xbean-finder or vice versa? What
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by MattBenson:
http://wiki.apache.org/commons/classscan?action=diffrev1=1rev2=2
== classscan development ideas ==
- The [classscan] component
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by MarkStruberg:
http://wiki.apache.org/commons/classscan?action=diffrev1=2rev2=3
== classscan development ideas ==
The [classscan] component
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by JamesCarman:
http://wiki.apache.org/commons/classscan?action=diffrev1=3rev2=4
* foo
* bar
* baz
+ * Implementation details (BCEL, ASM
Adding a branch of xbean-finder for experimentation in what it might look like
to break it apart and abstract out ASM and other bits.
Just playing, no obligation or expectation this will go anywhere :)
-David
-
To
Welcome, David!
Matt
On Tue, Jun 5, 2012 at 3:07 PM, David Blevins david.blev...@gmail.com wrote:
Adding a branch of xbean-finder for experimentation in what it might look
like to break it apart and abstract out ASM and other bits.
Just playing, no obligation or expectation this will go
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by MattBenson:
http://wiki.apache.org/commons/classscan?action=diffrev1=4rev2=5
- == classscan development ideas ==
+ The `[classscan]` component
Yes, Welcome! Looking forward to your input into our little classpath
scanning experiment! :)
On Tue, Jun 5, 2012 at 4:12 PM, Matt Benson gudnabr...@gmail.com wrote:
Welcome, David!
Matt
On Tue, Jun 5, 2012 at 3:07 PM, David Blevins david.blev...@gmail.com
wrote:
Adding a branch of
On Jun 5, 2012, at 1:12 PM, Matt Benson wrote:
Welcome, David!
Thanks, Matt!
Ok, so I refactored it a bit to work in some of the ideas I was hearing on IRC
today.
Those changes were primarily:
- Promote Info objects that represent class data to a separate package not
tied to any bytecode
An expanded view of the info below in markdown:
https://gist.github.com/2880038
Pulled in some also pulled in some Meta-Annotation information from the
proposals going around Java EE 7. There's a lot there, feel free to ignore it.
Not critical.
-David
On Jun 5, 2012, at 9:57 PM, David
-finder to
LieGrue,
strub
- Original Message -
From: David Blevins david.blev...@gmail.com
To: Commons Developers List dev@commons.apache.org; gudnabr...@gmail.com
Cc:
Sent: Wednesday, June 6, 2012 7:32 AM
Subject: Re: [classscan] Experiment on xbean-finder
An expanded view
Carman
jcar...@carmanconsulting.com wrote:
I pointed my local Jenkins/Sonar setup at classscan at:
http://svn.apache.org/repos/asf/commons/sandbox/classscan/trunk
It's failing on:
Could not resolve dependencies for project
org.apache.commons:classscan:jar:0.1-SNAPSHOT: Could not find artifact
James,
I've tried to duplicate this issue and have failed. I removed all
org.apache.bcel:bcel and bcel:bcel artifacts from my local repository and built
classscan from new sandbox. I subsequently saw a bcel snapshot being
downloaded.
If you have any more clues as to why this fails for you
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 [classscan]
into multiple
Can anyone provide a reason [classscan] should not simply use
slf4j-simple in the test scope rather than logback? It's a small
change, but any reduction in complexity...
Matt
-
To unsubscribe, e-mail: dev-unsubscr
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
Well, you might want the logging to be silent during normal testing but to be
enabled if problems arise.
Ralph
On Jun 3, 2012, at 8:27 AM, Matt Benson wrote:
Can anyone provide a reason [classscan] should not simply use
slf4j-simple in the test scope rather than logback? It's a small
, Matt Benson wrote:
Can anyone provide a reason [classscan] should not simply use
slf4j-simple in the test scope rather than logback? It's a small
change, but any reduction in complexity...
Matt
-
To unsubscribe, e-mail: dev
On Jun 3, 2012, at 11:40, Matt Benson gudnabr...@gmail.com 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
On Sun, Jun 3, 2012 at 5:59 PM, Gary Gregory garydgreg...@gmail.com wrote:
I would rather we eat our own dog food with log4j or commons logging.
As classscan is in sandbox... I think it would help the logging team
if we would try log4j 2.0 alpha. It is a great framework already and
logging
://www.99soft.org/
On Sun, Jun 3, 2012 at 6:29 PM, Gary Gregory garydgreg...@gmail.com wrote:
On Jun 3, 2012, at 11:40, Matt Benson gudnabr...@gmail.com wrote:
I propose that we, in the immediate future, reorganize [classscan]
into multiple modules. I fully expect that by the time we get
I pointed my local Jenkins/Sonar setup at classscan at:
http://svn.apache.org/repos/asf/commons/sandbox/classscan/trunk
It's failing on:
Could not resolve dependencies for project
org.apache.commons:classscan:jar:0.1-SNAPSHOT: Could not find artifact
org.apache.bcel:bcel:jar:6.0-SNAPSHOT.
Do I
Oddly, I had this problem, but on the second try the build worked. :|
Matt
On Sun, Jun 3, 2012 at 10:25 PM, James Carman
jcar...@carmanconsulting.com wrote:
I pointed my local Jenkins/Sonar setup at classscan at:
http://svn.apache.org/repos/asf/commons/sandbox/classscan/trunk
It's failing
Hello all,
As Charles has been recently voted in as a Commons committer by
virtue of his other contributions to Commons components
(congratulations!), he is now free to import his work into the
[classscan] sandbox repo as a base for the rest of us to start
stuffing features. ;P
Regarding IP: I
-
From: Matt Benson mben...@apache.org
To: Commons Developers List dev@commons.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Thursday, May 31, 2012 6:53 PM
Subject: Re: [classscan] Source repository
Hello all,
As Charles has been recently voted in as a Commons committer by
virtue
The classscan sandbox is open for play!
http://svn.apache.org/viewvc/commons/sandbox/classscan/trunk/
Chas
On 5/31/12 9:53 AM, Matt Benson mben...@apache.org wrote:
Hello all,
As Charles has been recently voted in as a Commons committer by
virtue of his other contributions to Commons
: Re: [classscan] Source repository
2012/5/4 Honton, Charles charles_hon...@intuit.com:
In order to move classscan forward, I think we need a commons community
repository. Is any PMC willing to create one?
An 3 weeks old e-mail, but seems unanswered...
I do not quite understand
2012/5/4 Honton, Charles charles_hon...@intuit.com:
In order to move classscan forward, I think we need a commons community
repository. Is any PMC willing to create one?
An 3 weeks old e-mail, but seems unanswered...
I do not quite understand the question, because there is already
In order to move classscan forward, I think we need a commons community
repository. Is any PMC willing to create one?
Thanks,
chas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail
I think there are 2 mechanisms involved here:
a.) the part which takes a jar, scans it's bytecode in a well performing manner
and provides all the class structure information to the user.
b.) a mechanism which allows to reuse this scanning process for multiple
'classscan-clients'. Currently
the community work [classscan]
based on his classscanner name. I lean here, but could possibly be
persuaded to [classpath] which name suggests a slightly larger
potential scope (not necessarily a bad thing).
Matt
On Fri, Apr 20, 2012 at 10:09 AM, Gary Gregory garydgreg...@gmail.com
wrote:
On Fri
the community work [classscan]
based on his classscanner name. I lean here, but could possibly be
persuaded to [classpath] which name suggests a slightly larger
potential scope (not necessarily a bad thing).
Matt
On Fri, Apr 20, 2012 at 10:09 AM, Gary Gregory garydgreg...@gmail.com
wrote
upon
here. WRT the name: trying to reconstruct the past, I think Mark and
I must have just agreed offline to call the community work [classscan]
based on his classscanner name. I lean here, but could possibly be
persuaded to [classpath] which name suggests a slightly larger
potential scope
: [classpath,meiyo]
Agreed; there are any number of things the PMC needs to agree upon
here. WRT the name: trying to reconstruct the past, I think Mark and
I must have just agreed offline to call the community work [classscan]
based on his classscanner name. I lean here, but could possibly
and
I must have just agreed offline to call the community work [classscan]
based on his classscanner name. I lean here, but could possibly be
persuaded to [classpath] which name suggests a slightly larger
potential scope (not necessarily a bad thing).
Matt
On Fri, Apr 20, 2012 at 10:09 AM
, ...) need to take care about Class visibility and
might even have to deal with 'shared-contexts'. Thus the
commons-classscan as well as xbean-finder must be aware of the
ClassLoader hierarchy. Especially in multi-webapp environments this
might
(as side effect) also bring a pretty neat performance
-contexts'. Thus the
commons-classscan as well as xbean-finder must be aware of the
ClassLoader hierarchy. Especially in multi-webapp environments this might
(as side effect) also bring a pretty neat performance improvement as we
don't need to scan those shared class paths redundantly
frameworks (EJB, CDI, ...) need to take care about Class visibility and
might even have to deal with 'shared-contexts'. Thus the
commons-classscan as well as xbean-finder must be aware of the
ClassLoader hierarchy. Especially in multi-webapp environments this might
(as side effect) also bring
to provide class scanning on a per-ClassLoader level. Many
frameworks (EJB, CDI, ...) need to take care about Class visibility and
might even have to deal with 'shared-contexts'. Thus the
commons-classscan as well as xbean-finder must be aware of the
ClassLoader hierarchy. Especially in multi-webapp
Same here, as main Meiyo contributor I'm of course interested, but no
available cycles ATM, hopefully during the weekend :(
Anyway, just to speak about it, I am changing my mind about classpath
scanning, that - even only when bootstrapping, of course - is a time
consuming operation.
I'd invite
: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for
class path scanning / class metadata
Same here, as main Meiyo contributor I'm of course interested, but no
available cycles ATM, hopefully during the weekend :(
Anyway, just to speak about it, I am changing my mind about classpath
scanning
second? Ten seconds?
Thanks,
chas
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Wednesday, April 11, 2012 12:17 AM
To: Commons Developers List
Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal
], but the point is that Mark
Struberg is after all free to add his
https://github.com/struberg/Apache-commons-classscanner code to
[classscan]. This will give us a little more to discuss wrt merging
its and [meiyo]'s features. As I recall, Mark was having trouble
logging into the Moin wiki, which
the commons-classscan as well as xbean-finder must be
aware of the ClassLoader hierarchy. Especially in multi-webapp environments
this might (as side effect) also bring a pretty neat performance improvement as
we don't need to scan those shared class paths redundantly!
But I need to think about
[mailto:simone.trip...@gmail.com] On Behalf
Of Simone Tripodi
Sent: Wednesday, April 11, 2012 12:17 AM
To: Commons Developers List
Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for
class path scanning / class metadata
Same here, as main Meiyo contributor I'm of course
[mailto:strub...@yahoo.de]
... We need to provide class scanning on a per-ClassLoader level. Many
frameworks (EJB, CDI, ...) need to take care about Class visibility and might
even have to deal with 'shared-contexts'. Thus the commons-classscan as well as
xbean-finder must be aware of the ClassLoader
frameworks (EJB, CDI, ...) need to take care about Class visibility and might
even have to deal with 'shared-contexts'. Thus the commons-classscan as well
as xbean-finder must be aware of the ClassLoader hierarchy. Especially in
multi-webapp environments this might (as side effect) also bring
There's been sporadic talk on this newsgroup since September 2010 about
providing a commons component which can scan a classpath and provide metadata
about the classes. I have a clean (license-wsie) concrete interface and
implementation to share. This code will support the following use
I am interested. I do want to keep it as simple as possible to set up
and retrieve the information. I haven't had a chance to take a look
at your stuff, yet, though. Perhaps I can get a few cycles this week.
On Mon, Apr 9, 2012 at 5:29 PM, Honton, Charles
charles_hon...@intuit.com wrote:
I remember us having discussions a while back about a ClassScan API.
The sandbox/classscan/trunk directory is empty, though. Did we give
it a different name? Did we give up on the idea?
-
To unsubscribe, e-mail: dev-unsubscr
Hi James!
ClassScan is a Mark Struberg's proposal, I pinged him on Twitter and
replied they need to clean their code before moving to commons :)
Meiyo actually works with reflection, ClassScan instead reads the
bytecode via ASM - and it's faster.
Ideally we could replicate the same behavior
%+ of the scenarios.
On Sat, Nov 5, 2011 at 11:25 AM, Simone Tripodi
simonetrip...@apache.org wrote:
Hi James!
ClassScan is a Mark Struberg's proposal, I pinged him on Twitter and
replied they need to clean their code before moving to commons :)
Meiyo actually works with reflection, ClassScan
...@yahoo.de wrote:
Hi Simo!
Sorry, I guess I was not clear enough!
Some specs require us to pickup this info from some config (e.g.
META-INF/beans.xml). The classscan-client needs to pickup this configuration
from there and must tell it the classscan-server somehow. This could be some
form
...@carmanconsulting.com
Subject: Re: [sandbox] [classscan] classscan API design review needed
To: Commons Developers List dev@commons.apache.org
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 strub
implementation - just kidding ;)
Nah serious, a few Ideas from Meyio (e.g. the Callback for the Filter) are
really cool and we should incorporate them into classscan. A few other
interfaces are imo a bit too generic.
The hardest nut will most probably be the design of the Filter.
The requirements
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
Hi Simo!
Sorry, I guess I was not clear enough!
Some specs require us to pickup this info from some config (e.g.
META-INF/beans.xml). The classscan-client needs to pickup this configuration
from there and must tell it the classscan-server somehow. This could be some
form of Domain Specific
Hallo Mark!!!
Some specs require us to pickup this info from some config (e.g.
META-INF/beans.xml). The classscan-client needs to pickup this configuration
from there and must tell it the classscan-server somehow
Got it, my fault that didn't pay enough attention on your previous
messages
Why the client / server nomenclature? Makes it sound too heavyweight
On Jul 28, 2011 4:20 PM, Mark Struberg strub...@yahoo.de wrote:
Hi Simo!
Sorry, I guess I was not clear enough!
Some specs require us to pickup this info from some config (e.g.
META-INF/beans.xml). The classscan-client
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
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
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr jakob.korh...@gmail.com 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
+1
Regards,
Jakob
2011/7/27 Matt Benson gudnabr...@gmail.com:
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr jakob.korh...@gmail.com
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
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The classscan page has been changed by MattBenson:
http://wiki.apache.org/commons/classscan
New page:
== classscan development ideas ==
The [classscan] component aims to provide
http://wiki.apache.org/commons/classscan
On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr jakob.korh...@gmail.com wrote:
+1
Regards,
Jakob
2011/7/27 Matt Benson gudnabr...@gmail.com:
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr jakob.korh...@gmail.com
wrote:
Hi Mark, Simone,
I would
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
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
94 matches
Mail list logo
