updating trunk to use a configurablearchive (xbean spirit) instead of an real helper class.
- Romain 2012/2/23 Romain Manni-Bucau <rmannibu...@gmail.com> > s/dd-maven-plugin/info-maven-plugin/ > > Le 23 févr. 2012 06:48, "Romain Manni-Bucau" <rmannibu...@gmail.com> a > écrit : > > The issue i had wanting to do so was how to do it before the first >> deployment. >> >> Trying to do it through a mvn plugin makes the need to be able to correct >> resources and container when you redeploy. >> >> It actually needs a big refactoring which is very impacting. >> >> Note that i hope to propose to users a release for end of april and would >> like a scan limitation feature so the easier is probably the best for the >> moment. >> >> What i started is in sandbox and called dd-maven-plugin. There is a >> branch too refering to generated descriptors. >> >> - Romain >> >> Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <nour.moham...@gmail.com> >> a écrit : >> >>> Hi... >>> >>> *cool* :D >>> >>> I will look into that the coming few days and get back with >>> questions/feedback >>> >>> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blev...@gmail.com >>> >wrote: >>> >>> > >>> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din 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. >>> > >>> > Maybe check out this doc. Some of the things you mention might tie in >>> > here: >>> > >>> > http://openejb.apache.org/dev/configuration-and-assembly.html >>> > >>> > There are two layers you could deploy apps in code: >>> > >>> > 1. Build the EjbModule by hand and configure then assemble it. >>> > 2. Build the AppInfo by hand then assemble it. >>> > >>> > Working with the AppInfo tree is a bit like writing assembly code. >>> > Working with the EjbModule and EjbJar tree is a bit more like a DSL. >>> > There are nice and fancy methods in there and even some DSL syntax. >>> > >>> > In pure performance terms, considering no other requirements, cutting >>> out >>> > the ConfigurationFactory by simply saving the resulting AppInfo object >>> then >>> > reloading it on each deploy is going to be pretty fast. It would cut >>> out >>> > 80% of the deploy code, including scanning. >>> > >>> > Not how this strictly relates to what you might be thinking, but that >>> is >>> > at least some insight on the problem space. >>> > >>> > >>> > -David >>> > >>> > >>> >>> >>> -- >>> Thanks >>> - Mohammad Nour >>> ---- >>> "Life is like riding a bicycle. To keep your balance you must keep >>> moving" >>> - Albert Einstein >>> >>
