IMHO if it is no more the case one day it will be quickly forked so no
worry about it.
- Romain
2012/2/27 Mark Struberg <strub...@yahoo.de>
> 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
> >> >
> >>
> >
>
