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 <rmannibu...@gmail.com>

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

Reply via email to