On Feb 27, 2012, at 4:54 AM, Mark Struberg wrote:
> 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.
Right.
All of XBean used to live at Codehaus and was mostly used by OpenEJB and
ActiveMQ, etc. which lived at Codehaus at the time. The goal was a central
place to put reusable libs with a server focus which is why it has many odds
and ends. Most the code still living from that time came from OpenEJB (e.g.
finder, reflect) or ActiveMQ (e.g. xbean-spring). There were also some new
parts that hoped to replace parts of Geronimo (e.g. xbean-kernel) and this
caused a lot of problems.
Moving all of XBean to be a subproject of Geronimo seemed to be an answer.
Eventually, the "replace parts of Geronimo" modules all died. Some things were
deleted as no one other than the original community found them useful. A few
modules have been added since, but overall it has withered more than grown as a
sharing place. Everything that's there, though, still is reusable
independently of any project.
So there's the XBean history in the very brief :)
We could move finder to commons and that might help others feel more welcome to
it. The upside is it'd be easier to get people commit to the code -- most the
active OpenEJB people don't have Geronimo commit these days and I have to apply
all the patches. The downside of that is changing the package names creates a
bit of a mess in OpenEJB and Geronimo integration wise unless both OpenEJB and
Geronimo switch. The onus to do all that work is likely going to fall to the
person who pushes hardest to see the code move.
-David
> ----- 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
>>>>
>>>
>>
