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
