Definitely the goal is to move it to xbean. Moving xbean to commons is
certainly something that can be done, though that wouldn't improve it's ability
to be used, it's really just be a package change for whatever that is worth.
Though it might have an impact on how much people actually *want* to use it :)
-David
On Feb 26, 2012, at 3:31 PM, Mark Struberg wrote:
> There has been a discussion last year to move the xbean finder to commons.
> Because OWB and MyFaces could also make use of it that way. If you move it to
> tommy it wont be possible because of the circular reference ...
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Karan Malhi <karan.ma...@gmail.com>
>> To: dev@openejb.apache.org
>> Cc:
>> Sent: Tuesday, February 21, 2012 9:02 PM
>> Subject: Re: Annotation scanning plugin
>>
>> 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
>> <rmannibu...@gmail.com>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 <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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>> Karan Singh Malhi
>> twitter.com/KaranSinghMalhi
>>
