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