no problem to change the artifactId, any good idea is welcomed.
regarding the tomee/xbean/(openejb?) question the issue is mainly this
thing should be usable in standalone (openejb with no tomee) and in tomee
so i wouldn't use tomee for standalone and i wouldn't use openejb for
tomee...
i agree xbean can be surprising so maybe we should simply remove the
package?
- Romain
2012/2/21 Karan Malhi <karan.ma...@gmail.com>
> 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
>
