xbean-finder is currently part of geronimo, but it has it's own build lifecycle!
It is _not_ part of the standard geronimo build chain. Thus it _currently_
doesn't lead to a circular build cycle.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rmannibu...@gmail.com>
> To: Mark Struberg <strub...@yahoo.de>; dev@openejb.apache.org
> Cc:
> Sent: Monday, February 27, 2012 12:41 AM
> Subject: Re: Annotation scanning plugin
>
> Not so agree.
>
> You can use it today without circular dep. Same tmr. Just a repo question.
> From a code point of view no big changes.
>
> Le 27 févr. 2012 00:31, "Mark Struberg" <strub...@yahoo.de> a
> écrit :
>
>> 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
>> >
>>
>
