- Romain
2012/2/21 Alan D. Cabrera <l...@toolazydogs.com> > > On Feb 21, 2012, at 7:40 AM, Romain Manni-Bucau wrote: > > > i created a module xbean-xml in maven plugins to be able to commit but it > > should be in xbean i think (the mvn plugin too by the way). > > > > the example needs openjpa (not jpa ;)) because before using the plugin i > > enhance the entities with the openjpa plugin so then the classes are > > enhanced and reference some openjpa classes so it is needed in this case. > > Can you provide more detail on this enhancement? It sounds like you're > mixing concerns. > Romain: the example needs OpenJPA enhancement ( http://openjpa.apache.org/entity-enhancement.html) so i added it but it is done before the plugin scan. then entities are modified and are openjpa dependent so classes are needed. I don't like it but i didn't manage to make the exemple working well without it. > > Concerning the verbosity of xml it is simply a ratio between useful > > characters and useless ones (yes i use vim :p). > > > > The scan.xml location is configurable. For the moment there is 2 > properties > > but it can be (should be) merged in one (today we have base + relative > > path, i liked it because relative is the convention and base is whatever > > you want). > > It seems that you are simply restating what you've done instead of > justifying the weakening of a feature or explaining why the feature of > having the scan.xml file in a known place is not all that important. > Romain: one property is enough, if everybody thinks 2 are useles si'll simply remove the second, i don't think one or the other solution is better > > > The snippet David sent in his first mail is till available, i just added > > the notion of "profile" which are in my mind a set of predefined > > [implementations, subclasses, annotations] easier to configure (the one i > > provided is jee6, simply look what it looks like to understand why it is > > not so useless ;)). Maybe it should be done through files at the > classpath > > instead of hardcoding it...was a first step ;) > > I'm not sure that hardcoding is required. Per David's earlier email the > configuration would dictate what would be searched for in the scan. > Romain: hardcoding is clearly not required, was just easier to start to provide something > > I thought about profiles as well but then one must publish and maintain > those profiles. I hate, hate, hate, finding things in the classpath. > Things magically appear and disappear all too often. :) What might be a > good idea is to publish the profile file in Maven. Then we could use the > Maven dependency plugin to pull own the file and drop it into the target > directory. Then the scan plugin could be configured to read it. > Romain: right but always listing javaee6 annotations is clearly a pain too > > One subtle point to the above use case, it's better to just loosely couple > things and simply list the exact criteria, and not the profile, that was > searched for in the scan.xml. > Romain: i think i'll update as i said the plugin to be able to get information from a file, a kind of serviceloader thing > > > Regards, > Alan > >
