Earlier in the thread I had mentioned that the code bits and scanning should not be performed on the client side but, instead, should be done inside xbean itself. More specifically, when xbean is asked to scan a certain set of URLs it can first check to see if there's a scan.xml file in the known location. If it finds it then its job of scanning is simpler and more efficient. If it does not find it then it does what it currently does.
I think that there's little value in forcing the users of xbean to perform the above work in what amounts to an xbean implementation leak into OpenEJB's CLI and deployer code. Given that the code is best packed into xbean, according to the above line of reasoning, it makes sense to me that the plugin belong to xbean. This plugin has great value outside of tomee. Regards, Alan On Feb 21, 2012, at 12:02 PM, Karan Malhi wrote: > Was wondering if we could use tomee instead of xbean in the groupid. Also > the artifact id could be something like "classpath-scan-optimizer". The > resulting scan.xml could be stored in a package named org.apache.tomee > instead of org.apache.xbean. The more usage of "tomee" would be better. As > a user, I do not want to think , "I am using tomee, so what is this xbean". > Also, the name of the artifact-id should be a bit more exciting and reflect > the value-add it is providing. > > > On Tue, Feb 21, 2012 at 8:55 AM, Romain Manni-Bucau > <[email protected]>wrote: > >> updated to manage only one file path property and to use external profiles. >> >> I like the "i don't need to write what i scan" feature provided by >> profiles. >> >> <plugin> >> <groupId>org.apache.openejb</groupId> >> <version>0.0.1-SNAPSHOT</version> >> <artifactId>spi-helper-maven-plugin</artifactId> >> <executions> >> <execution> >> <id>generate-scan-xml</id> >> <goals> >> <goal>generate</goal> >> </goals> >> </execution> >> </executions> >> <configuration> >> >> >> <outputFilename>${project.build.directory}/${project.build.finalName}/WEB-INF/org/apache/xbean/scan.xml</outputFilename> >> </configuration> >> <dependencies> >> <dependency> <!-- mandatory for the scanning since we enhanced >> our entities --> >> <groupId>org.apache.openjpa</groupId> >> <artifactId>openjpa</artifactId> >> <version>2.2.0</version> >> </dependency> >> <dependency> <!-- to get the jee6 profile without configuration >> --> >> <groupId>org.apache.openejb</groupId> >> <version>0.0.1-SNAPSHOT</version> >> <artifactId>spi-helper-jee6-profile</artifactId> >> </dependency> >> </dependencies> >> </plugin> >> >> - Romain >> >> >> 2012/2/21 Romain Manni-Bucau <[email protected]> >> >>> >>> - Romain >>> >>> >>> 2012/2/21 Alan D. Cabrera <[email protected]> >>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> >> > > > > -- > > Karan Singh Malhi > twitter.com/KaranSinghMalhi
