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 >
