Cool, thanks for the update On Thu, Feb 23, 2012 at 6:59 AM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote:
> 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 > >> > > > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
