That is good to know, but the point here is more about what to specify and how cause I believe we use XBean Finder [1] for the same purpose to collect reflective information about Java code in classpath among other things.
[1] - http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ On Thu, Feb 23, 2012 at 12:11 AM, Aldrin Leal <ald...@leal.eng.br> wrote: > This is very close to what reflections does - with a very permissive > license. > > http://code.google.com/p/reflections/ > > -- > -- Aldrin Leal, <ald...@leal.eng.br> / http://meadiciona.com/aldrinleal > > > On Wed, Feb 22, 2012 at 8:08 PM, Mohammad Nour El-Din < > nour.moham...@gmail.com> wrote: > > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <david.blev...@gmail.com > > >wrote: > > > > > From what I understand you're talking about a file that contains 100% > of > > > the metadata and eliminates the need for most or all of the actual > > > deployment process. That's definitely a good idea. > > > > > > > That is exactly what I am talking about but this meta-data file I was > > talking to make it in *code* and compile as part of the deployment > process > > to make it fast and memory efficient. More specifically for running the > > application(s) over and over again, unless there is a chance and hence > the > > process is repeated. > > > > The code can be generated in Groovy or any dynamic language that can make > > it easy to deal with at run time. > > > > Using Groovy can have an advantage which that Groovy has facilities for > > building DSL(s) which we can use to define a DSL for describing whatever > > aspects we need while scanning or any other operation we want to do while > > deploying which also can serve as a more readable, almost English > language > > rather than the tree like language based on XML. > > > > > > > > > > Some work has been done in that regard, though it's not yet functional. > > > It's a much harder problem than optimizing component scanning. > > > > > > > Can you give me hints where I can find that, I want to have a look at it > > and continue that if possible ? At last I could have a successful OpenEJB > > build on my machine since years now :D. > > > > > > > > > > Note also that there are two types of scanning. There is: > > > > > > A. scanning jars for classes that use a specific annotation > > > B. scanning a class for annotations > > > > > > Due to memory and speed limitations you can't do B on every class in > all > > > jars, so limiting that scope is important. This is where A comes in. > > > > > > The scan.xml proposal effectively only tackles issue A. > > > > > > > We can have options to control on which level we want to apply this. Or > > even this can be provided a tool for developers to run over their code > > before deploying it generating the meta-date *code* which can be detected > > while deployment loaded and take actions based on what we find there. > > > > I know this might sound like complicated, but it is not it is just > > different in my ex-company we used Python all the time even when > describing > > services and object model(s) (a.k.a DSL) which is more readable and > > more efficient than reading XML or YAML. > > > > Thoughts ? > > > > > > > > > > > > > -David > > > > > > On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote: > > > > > > > Never it seems not to be a good idea :) > > > > > > > > On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau > > > > <rmannibu...@gmail.com>wrote: > > > > > > > >> Hmm, not sure i follow too, > > > >> > > > >> We just spoke about generating xml then reading it to avoid > scanning. > > > >> > > > >> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <l...@toolazydogs.com> a > > > écrit : > > > >> > > > >>> > > > >>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote: > > > >>> > > > >>>> Hi Romain and Alan :) > > > >>>> > > > >>>> I didn't say ever to not use XML or a simple file, which what I > > meant > > > >>> by > > > >>>> the declarative side, what I mean is additionally to that, at the > > time > > > >> of > > > >>>> deploy that out of that file Java code is generated which provides > > the > > > >>>> information we need while scanning and thats what I meant by the > > > >>>> execution/runtime perspective. > > > >>> > > > >>> I think I'm a bit lost. Why would Java code be generated when > simply > > > >>> reading the file will do? :) > > > >>> > > > >>> Can you provide a more detailed and concrete example that explains > > your > > > >>> idea? > > > >>> > > > >>> > > > >>> Regards, > > > >>> Alan > > > >>> > > > >>> > > > >> > > > > > > > > > > > > > > > > -- > > > > Thanks > > > > - Mohammad Nour > > > > ---- > > > > "Life is like riding a bicycle. To keep your balance you must keep > > > moving" > > > > - Albert Einstein > > > > > > > > > > > > -- > > Thanks > > - Mohammad Nour > > ---- > > "Life is like riding a bicycle. To keep your balance you must keep > moving" > > - Albert Einstein > > > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
