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 >> >
