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.
Some work has been done in that regard, though it's not yet functional. It's a much harder problem than optimizing component scanning. 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. -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
