On Feb 21, 2012, at 8:29 AM, Romain Manni-Bucau wrote: > - Romain > > > 2012/2/21 Alan D. Cabrera <[email protected]> > >> >> On Feb 21, 2012, at 7:40 AM, Romain Manni-Bucau wrote: >> >>> 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
I am not speaking to the number of properties to configure the location of the scan.xml file but to the fact that it can be configured at all. The power of this scanner is that it puts the scan report in a known fixed location. I think making it configurable weakens that feature. >> 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 Agreed, hence my idea of publishing the profiles. > 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 Service loader uses the classpath. IMO, this file should be directly configured instead of being automagically found. wdyt? Regards, Alan
