You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2012/02/20 23:40:49 UTC
Annotation scanning plugin
We've chatted occasionally on creating a scanning.xml file where people could setup includes and excludes and, overall, optimize classpath scanning.
Romain is already busy hacking of course :) Here's the idea for a plugin to effectively do the most expensive part of scanning in advance:
<plugin>
<groupId>org.apache.xbean</groupId>
<artifactId>maven-xbean-finder-plugin</artifactId>
<configuration>
<annotations>
<annotation>javax.ejb.Stateless</annotation>
<annotation>javax.ejb.Stateful</annotation>
<annotation>javax.ejb.Singleton</annotation>
<annotation>javax.annotation.ManagedBean</annotation>
</annotations>
<subclasses>
<subclass>javax.ws.rs.core.Application</subclass>
</subclasses>
<implementations>
<implementation>org.apache.openejb.server.ServerService</implementation>
</implementations>
</configuration>
</plugin>
With a configuration like the above, the plugin would scan the jar for subclasses of javax.ws.rs.core.Application, classes annotated with @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
The result would be a META-INF/scan.xml class that looks like so:
<scan>
<classes>
<class>org.superbiz.Foo</class>
<class>org.superbiz.Bar</class>
<class>org.superbiz.Baz</class>
</classes>
</scan>
And on the TODO list would be future support for <packages>
<scan>
<packages>
<package>org.superbiz.foo</package>
<package>org.superbiz.bar</package>
</packages>
</scan>
With the above you could easily create scan.xml file by hand that would at least be far faster than scanning an entire jar.
Thoughts?
-David
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
What need are you specifically referring to?
Regards,
Alan
On Feb 22, 2012, at 12:06 PM, Romain Manni-Bucau wrote:
> So finally removing the package in the location answer to the need?
>
> - Romain
>
> Le 22 févr. 2012 20:49, "Mohammad Nour El-Din" <no...@gmail.com> a
> écrit :
>
>> Hi Romain and Alan :)
>>
>> I didn't say ever to not use XML or a simple file, which what I meant by
>> the declarative side, what I mean is additionally to that, at the time of
>> deploy that out of that file Java code is generated which provides the
>> information we need while scanning and thats what I meant by the
>> execution/runtime perspective.
>>
>> On Wed, Feb 22, 2012 at 8:37 PM, David Blevins <david.blevins@gmail.com
>>> wrote:
>>
>>> Additional note that the ultimate goal of the scan.xml file is to provide
>>> something that could be standardized. There is interest for having a
>> more
>>> general solution.
>>>
>>> This probably affects the scan.xml file itself, the plugin could live
>>> anywhere (I'd imagined we'd eventually put it in xbean).
>>>
>>> Ideally a standard file would be:
>>>
>>> - in META-INF/scan.xml
>>> - list classes and packages
>>> - something a user can create by hand
>>>
>>> Anything that adds xbean/openejb/tomee branding, is not xml, or contains
>>> plugin-specific information would have to be removed from any proposals
>> to
>>> Java EE 7.
>>>
>>> Some things to keep in mind as we discuss.
>>>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
So finally removing the package in the location answer to the need?
- Romain
Le 22 févr. 2012 20:49, "Mohammad Nour El-Din" <no...@gmail.com> a
écrit :
> Hi Romain and Alan :)
>
> I didn't say ever to not use XML or a simple file, which what I meant by
> the declarative side, what I mean is additionally to that, at the time of
> deploy that out of that file Java code is generated which provides the
> information we need while scanning and thats what I meant by the
> execution/runtime perspective.
>
> On Wed, Feb 22, 2012 at 8:37 PM, David Blevins <david.blevins@gmail.com
> >wrote:
>
> > Additional note that the ultimate goal of the scan.xml file is to provide
> > something that could be standardized. There is interest for having a
> more
> > general solution.
> >
> > This probably affects the scan.xml file itself, the plugin could live
> > anywhere (I'd imagined we'd eventually put it in xbean).
> >
> > Ideally a standard file would be:
> >
> > - in META-INF/scan.xml
> > - list classes and packages
> > - something a user can create by hand
> >
> > Anything that adds xbean/openejb/tomee branding, is not xml, or contains
> > plugin-specific information would have to be removed from any proposals
> to
> > Java EE 7.
> >
> > Some things to keep in mind as we discuss.
> >
> >
> > -David
> >
> > On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> >
> > > We've chatted occasionally on creating a scanning.xml file where people
> > could setup includes and excludes and, overall, optimize classpath
> scanning.
> > >
> > > Romain is already busy hacking of course :) Here's the idea for a
> > plugin to effectively do the most expensive part of scanning in advance:
> > >
> > > <plugin>
> > > <groupId>org.apache.xbean</groupId>
> > > <artifactId>maven-xbean-finder-plugin</artifactId>
> > > <configuration>
> > > <annotations>
> > > <annotation>javax.ejb.Stateless</annotation>
> > > <annotation>javax.ejb.Stateful</annotation>
> > > <annotation>javax.ejb.Singleton</annotation>
> > > <annotation>javax.annotation.ManagedBean</annotation>
> > > </annotations>
> > > <subclasses>
> > > <subclass>javax.ws.rs.core.Application</subclass>
> > > </subclasses>
> > > <implementations>
> > >
> > <implementation>org.apache.openejb.server.ServerService</implementation>
> > > </implementations>
> > > </configuration>
> > > </plugin>
> > >
> > > With a configuration like the above, the plugin would scan the jar for
> > subclasses of javax.ws.rs.core.Application, classes annotated with
> > @Stateless, @Singleton, @Stateful and classes that implement
> ServiceService.
> > >
> > > The result would be a META-INF/scan.xml class that looks like so:
> > >
> > > <scan>
> > > <classes>
> > > <class>org.superbiz.Foo</class>
> > > <class>org.superbiz.Bar</class>
> > > <class>org.superbiz.Baz</class>
> > > </classes>
> > > </scan>
> > >
> > > And on the TODO list would be future support for <packages>
> > >
> > > <scan>
> > > <packages>
> > > <package>org.superbiz.foo</package>
> > > <package>org.superbiz.bar</package>
> > > </packages>
> > > </scan>
> > >
> > > With the above you could easily create scan.xml file by hand that would
> > at least be far faster than scanning an entire jar.
> > >
> > >
> > > Thoughts?
> > >
> > >
> > > -David
> > >
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On Wed, Feb 22, 2012 at 11:07 PM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:
> Never it seems not to be a good idea :)
s/Never/Nevermind
>
>
> On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> > wrote:
>
>> Hmm, not sure i follow too,
>>
>> We just spoke about generating xml then reading it to avoid scanning.
>>
>> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a écrit
>> :
>>
>> >
>> > On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
>> >
>> > > Hi Romain and Alan :)
>> > >
>> > > I didn't say ever to not use XML or a simple file, which what I
>> meant
>> > by
>> > > the declarative side, what I mean is additionally to that, at the
>> time of
>> > > deploy that out of that file Java code is generated which provides the
>> > > information we need while scanning and thats what I meant by the
>> > > execution/runtime perspective.
>> >
>> > I think I'm a bit lost. Why would Java code be generated when simply
>> > reading the file will do? :)
>> >
>> > Can you provide a more detailed and concrete example that explains your
>> > idea?
>> >
>> >
>> > Regards,
>> > Alan
>> >
>> >
>>
>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
That is good to know, but the point here is more about what to specify and
how cause I believe we use XBean Finder [1] for the same purpose to collect
reflective information about Java code in classpath among other things.
[1] - http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
On Thu, Feb 23, 2012 at 12:11 AM, Aldrin Leal <al...@leal.eng.br> wrote:
> This is very close to what reflections does - with a very permissive
> license.
>
> http://code.google.com/p/reflections/
>
> --
> -- Aldrin Leal, <al...@leal.eng.br> / http://meadiciona.com/aldrinleal
>
>
> On Wed, Feb 22, 2012 at 8:08 PM, Mohammad Nour El-Din <
> nour.mohammad@gmail.com> wrote:
>
> > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <david.blevins@gmail.com
> > >wrote:
> >
> > > From what I understand you're talking about a file that contains 100%
> of
> > > the metadata and eliminates the need for most or all of the actual
> > > deployment process. That's definitely a good idea.
> > >
> >
> > That is exactly what I am talking about but this meta-data file I was
> > talking to make it in *code* and compile as part of the deployment
> process
> > to make it fast and memory efficient. More specifically for running the
> > application(s) over and over again, unless there is a chance and hence
> the
> > process is repeated.
> >
> > The code can be generated in Groovy or any dynamic language that can make
> > it easy to deal with at run time.
> >
> > Using Groovy can have an advantage which that Groovy has facilities for
> > building DSL(s) which we can use to define a DSL for describing whatever
> > aspects we need while scanning or any other operation we want to do while
> > deploying which also can serve as a more readable, almost English
> language
> > rather than the tree like language based on XML.
> >
> >
> > >
> > > Some work has been done in that regard, though it's not yet functional.
> > > It's a much harder problem than optimizing component scanning.
> > >
> >
> > Can you give me hints where I can find that, I want to have a look at it
> > and continue that if possible ? At last I could have a successful OpenEJB
> > build on my machine since years now :D.
> >
> >
> > >
> > > Note also that there are two types of scanning. There is:
> > >
> > > A. scanning jars for classes that use a specific annotation
> > > B. scanning a class for annotations
> > >
> > > Due to memory and speed limitations you can't do B on every class in
> all
> > > jars, so limiting that scope is important. This is where A comes in.
> > >
> > > The scan.xml proposal effectively only tackles issue A.
> > >
> >
> > We can have options to control on which level we want to apply this. Or
> > even this can be provided a tool for developers to run over their code
> > before deploying it generating the meta-date *code* which can be detected
> > while deployment loaded and take actions based on what we find there.
> >
> > I know this might sound like complicated, but it is not it is just
> > different in my ex-company we used Python all the time even when
> describing
> > services and object model(s) (a.k.a DSL) which is more readable and
> > more efficient than reading XML or YAML.
> >
> > Thoughts ?
> >
> >
> > >
> > >
> > > -David
> > >
> > > On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote:
> > >
> > > > Never it seems not to be a good idea :)
> > > >
> > > > On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau
> > > > <rm...@gmail.com>wrote:
> > > >
> > > >> Hmm, not sure i follow too,
> > > >>
> > > >> We just spoke about generating xml then reading it to avoid
> scanning.
> > > >>
> > > >> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a
> > > écrit :
> > > >>
> > > >>>
> > > >>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
> > > >>>
> > > >>>> Hi Romain and Alan :)
> > > >>>>
> > > >>>> I didn't say ever to not use XML or a simple file, which what I
> > meant
> > > >>> by
> > > >>>> the declarative side, what I mean is additionally to that, at the
> > time
> > > >> of
> > > >>>> deploy that out of that file Java code is generated which provides
> > the
> > > >>>> information we need while scanning and thats what I meant by the
> > > >>>> execution/runtime perspective.
> > > >>>
> > > >>> I think I'm a bit lost. Why would Java code be generated when
> simply
> > > >>> reading the file will do? :)
> > > >>>
> > > >>> Can you provide a more detailed and concrete example that explains
> > your
> > > >>> idea?
> > > >>>
> > > >>>
> > > >>> Regards,
> > > >>> Alan
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks
> > > > - Mohammad Nour
> > > > ----
> > > > "Life is like riding a bicycle. To keep your balance you must keep
> > > moving"
> > > > - Albert Einstein
> > >
> > >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
> >
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Aldrin Leal <al...@leal.eng.br>.
This is very close to what reflections does - with a very permissive
license.
http://code.google.com/p/reflections/
--
-- Aldrin Leal, <al...@leal.eng.br> / http://meadiciona.com/aldrinleal
On Wed, Feb 22, 2012 at 8:08 PM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:
> On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <david.blevins@gmail.com
> >wrote:
>
> > From what I understand you're talking about a file that contains 100% of
> > the metadata and eliminates the need for most or all of the actual
> > deployment process. That's definitely a good idea.
> >
>
> That is exactly what I am talking about but this meta-data file I was
> talking to make it in *code* and compile as part of the deployment process
> to make it fast and memory efficient. More specifically for running the
> application(s) over and over again, unless there is a chance and hence the
> process is repeated.
>
> The code can be generated in Groovy or any dynamic language that can make
> it easy to deal with at run time.
>
> Using Groovy can have an advantage which that Groovy has facilities for
> building DSL(s) which we can use to define a DSL for describing whatever
> aspects we need while scanning or any other operation we want to do while
> deploying which also can serve as a more readable, almost English language
> rather than the tree like language based on XML.
>
>
> >
> > Some work has been done in that regard, though it's not yet functional.
> > It's a much harder problem than optimizing component scanning.
> >
>
> Can you give me hints where I can find that, I want to have a look at it
> and continue that if possible ? At last I could have a successful OpenEJB
> build on my machine since years now :D.
>
>
> >
> > Note also that there are two types of scanning. There is:
> >
> > A. scanning jars for classes that use a specific annotation
> > B. scanning a class for annotations
> >
> > Due to memory and speed limitations you can't do B on every class in all
> > jars, so limiting that scope is important. This is where A comes in.
> >
> > The scan.xml proposal effectively only tackles issue A.
> >
>
> We can have options to control on which level we want to apply this. Or
> even this can be provided a tool for developers to run over their code
> before deploying it generating the meta-date *code* which can be detected
> while deployment loaded and take actions based on what we find there.
>
> I know this might sound like complicated, but it is not it is just
> different in my ex-company we used Python all the time even when describing
> services and object model(s) (a.k.a DSL) which is more readable and
> more efficient than reading XML or YAML.
>
> Thoughts ?
>
>
> >
> >
> > -David
> >
> > On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote:
> >
> > > Never it seems not to be a good idea :)
> > >
> > > On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau
> > > <rm...@gmail.com>wrote:
> > >
> > >> Hmm, not sure i follow too,
> > >>
> > >> We just spoke about generating xml then reading it to avoid scanning.
> > >>
> > >> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a
> > écrit :
> > >>
> > >>>
> > >>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
> > >>>
> > >>>> Hi Romain and Alan :)
> > >>>>
> > >>>> I didn't say ever to not use XML or a simple file, which what I
> meant
> > >>> by
> > >>>> the declarative side, what I mean is additionally to that, at the
> time
> > >> of
> > >>>> deploy that out of that file Java code is generated which provides
> the
> > >>>> information we need while scanning and thats what I meant by the
> > >>>> execution/runtime perspective.
> > >>>
> > >>> I think I'm a bit lost. Why would Java code be generated when simply
> > >>> reading the file will do? :)
> > >>>
> > >>> Can you provide a more detailed and concrete example that explains
> your
> > >>> idea?
> > >>>
> > >>>
> > >>> Regards,
> > >>> Alan
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> > > ----
> > > "Life is like riding a bicycle. To keep your balance you must keep
> > moving"
> > > - Albert Einstein
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
updating trunk to use a configurablearchive (xbean spirit) instead of an
real helper class.
- Romain
2012/2/23 Romain Manni-Bucau <rm...@gmail.com>
> s/dd-maven-plugin/info-maven-plugin/
>
> Le 23 févr. 2012 06:48, "Romain Manni-Bucau" <rm...@gmail.com> a
> écrit :
>
> The issue i had wanting to do so was how to do it before the first
>> deployment.
>>
>> Trying to do it through a mvn plugin makes the need to be able to correct
>> resources and container when you redeploy.
>>
>> It actually needs a big refactoring which is very impacting.
>>
>> Note that i hope to propose to users a release for end of april and would
>> like a scan limitation feature so the easier is probably the best for the
>> moment.
>>
>> What i started is in sandbox and called dd-maven-plugin. There is a
>> branch too refering to generated descriptors.
>>
>> - Romain
>>
>> Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <no...@gmail.com>
>> a écrit :
>>
>>> Hi...
>>>
>>> *cool* :D
>>>
>>> I will look into that the coming few days and get back with
>>> questions/feedback
>>>
>>> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blevins@gmail.com
>>> >wrote:
>>>
>>> >
>>> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
>>> >
>>> > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <
>>> david.blevins@gmail.com
>>> > >wrote:
>>> > >
>>> > >> From what I understand you're talking about a file that contains
>>> 100% of
>>> > >> the metadata and eliminates the need for most or all of the actual
>>> > >> deployment process. That's definitely a good idea.
>>> > >>
>>> > >
>>> > > That is exactly what I am talking about but this meta-data file I was
>>> > > talking to make it in *code* and compile as part of the deployment
>>> > process
>>> > > to make it fast and memory efficient. More specifically for running
>>> the
>>> > > application(s) over and over again, unless there is a chance and
>>> hence
>>> > the
>>> > > process is repeated.
>>> > >
>>> > > The code can be generated in Groovy or any dynamic language that can
>>> make
>>> > > it easy to deal with at run time.
>>> > >
>>> > > Using Groovy can have an advantage which that Groovy has facilities
>>> for
>>> > > building DSL(s) which we can use to define a DSL for describing
>>> whatever
>>> > > aspects we need while scanning or any other operation we want to do
>>> while
>>> > > deploying which also can serve as a more readable, almost English
>>> > language
>>> > > rather than the tree like language based on XML.
>>> >
>>> > Maybe check out this doc. Some of the things you mention might tie in
>>> > here:
>>> >
>>> > http://openejb.apache.org/dev/configuration-and-assembly.html
>>> >
>>> > There are two layers you could deploy apps in code:
>>> >
>>> > 1. Build the EjbModule by hand and configure then assemble it.
>>> > 2. Build the AppInfo by hand then assemble it.
>>> >
>>> > Working with the AppInfo tree is a bit like writing assembly code.
>>> > Working with the EjbModule and EjbJar tree is a bit more like a DSL.
>>> > There are nice and fancy methods in there and even some DSL syntax.
>>> >
>>> > In pure performance terms, considering no other requirements, cutting
>>> out
>>> > the ConfigurationFactory by simply saving the resulting AppInfo object
>>> then
>>> > reloading it on each deploy is going to be pretty fast. It would cut
>>> out
>>> > 80% of the deploy code, including scanning.
>>> >
>>> > Not how this strictly relates to what you might be thinking, but that
>>> is
>>> > at least some insight on the problem space.
>>> >
>>> >
>>> > -David
>>> >
>>> >
>>>
>>>
>>> --
>>> Thanks
>>> - Mohammad Nour
>>> ----
>>> "Life is like riding a bicycle. To keep your balance you must keep
>>> moving"
>>> - Albert Einstein
>>>
>>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hope everybody will prefer this version.
note sure i mentionned it anymore but i removed the package so now scan.xml
is directly in META-INF.
Note: the new archive type should probably go to xbean too.
- Romain
2012/2/23 Mohammad Nour El-Din <no...@gmail.com>
> Cool, thanks for the update
>
> On Thu, Feb 23, 2012 at 6:59 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > s/dd-maven-plugin/info-maven-plugin/
> >
> > Le 23 févr. 2012 06:48, "Romain Manni-Bucau" <rm...@gmail.com> a
> > écrit :
> >
> > > The issue i had wanting to do so was how to do it before the first
> > > deployment.
> > >
> > > Trying to do it through a mvn plugin makes the need to be able to
> correct
> > > resources and container when you redeploy.
> > >
> > > It actually needs a big refactoring which is very impacting.
> > >
> > > Note that i hope to propose to users a release for end of april and
> would
> > > like a scan limitation feature so the easier is probably the best for
> the
> > > moment.
> > >
> > > What i started is in sandbox and called dd-maven-plugin. There is a
> > branch
> > > too refering to generated descriptors.
> > >
> > > - Romain
> > >
> > > Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <
> nour.mohammad@gmail.com>
> > > a écrit :
> > >
> > >> Hi...
> > >>
> > >> *cool* :D
> > >>
> > >> I will look into that the coming few days and get back with
> > >> questions/feedback
> > >>
> > >> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <
> david.blevins@gmail.com
> > >> >wrote:
> > >>
> > >> >
> > >> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
> > >> >
> > >> > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <
> > >> david.blevins@gmail.com
> > >> > >wrote:
> > >> > >
> > >> > >> From what I understand you're talking about a file that contains
> > >> 100% of
> > >> > >> the metadata and eliminates the need for most or all of the
> actual
> > >> > >> deployment process. That's definitely a good idea.
> > >> > >>
> > >> > >
> > >> > > That is exactly what I am talking about but this meta-data file I
> > was
> > >> > > talking to make it in *code* and compile as part of the deployment
> > >> > process
> > >> > > to make it fast and memory efficient. More specifically for
> running
> > >> the
> > >> > > application(s) over and over again, unless there is a chance and
> > hence
> > >> > the
> > >> > > process is repeated.
> > >> > >
> > >> > > The code can be generated in Groovy or any dynamic language that
> can
> > >> make
> > >> > > it easy to deal with at run time.
> > >> > >
> > >> > > Using Groovy can have an advantage which that Groovy has
> facilities
> > >> for
> > >> > > building DSL(s) which we can use to define a DSL for describing
> > >> whatever
> > >> > > aspects we need while scanning or any other operation we want to
> do
> > >> while
> > >> > > deploying which also can serve as a more readable, almost English
> > >> > language
> > >> > > rather than the tree like language based on XML.
> > >> >
> > >> > Maybe check out this doc. Some of the things you mention might tie
> in
> > >> > here:
> > >> >
> > >> > http://openejb.apache.org/dev/configuration-and-assembly.html
> > >> >
> > >> > There are two layers you could deploy apps in code:
> > >> >
> > >> > 1. Build the EjbModule by hand and configure then assemble it.
> > >> > 2. Build the AppInfo by hand then assemble it.
> > >> >
> > >> > Working with the AppInfo tree is a bit like writing assembly code.
> > >> > Working with the EjbModule and EjbJar tree is a bit more like a
> DSL.
> > >> > There are nice and fancy methods in there and even some DSL syntax.
> > >> >
> > >> > In pure performance terms, considering no other requirements,
> cutting
> > >> out
> > >> > the ConfigurationFactory by simply saving the resulting AppInfo
> object
> > >> then
> > >> > reloading it on each deploy is going to be pretty fast. It would
> cut
> > >> out
> > >> > 80% of the deploy code, including scanning.
> > >> >
> > >> > Not how this strictly relates to what you might be thinking, but
> that
> > is
> > >> > at least some insight on the problem space.
> > >> >
> > >> >
> > >> > -David
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Thanks
> > >> - Mohammad Nour
> > >> ----
> > >> "Life is like riding a bicycle. To keep your balance you must keep
> > moving"
> > >> - Albert Einstein
> > >>
> > >
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Cool, thanks for the update
On Thu, Feb 23, 2012 at 6:59 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> s/dd-maven-plugin/info-maven-plugin/
>
> Le 23 févr. 2012 06:48, "Romain Manni-Bucau" <rm...@gmail.com> a
> écrit :
>
> > The issue i had wanting to do so was how to do it before the first
> > deployment.
> >
> > Trying to do it through a mvn plugin makes the need to be able to correct
> > resources and container when you redeploy.
> >
> > It actually needs a big refactoring which is very impacting.
> >
> > Note that i hope to propose to users a release for end of april and would
> > like a scan limitation feature so the easier is probably the best for the
> > moment.
> >
> > What i started is in sandbox and called dd-maven-plugin. There is a
> branch
> > too refering to generated descriptors.
> >
> > - Romain
> >
> > Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <no...@gmail.com>
> > a écrit :
> >
> >> Hi...
> >>
> >> *cool* :D
> >>
> >> I will look into that the coming few days and get back with
> >> questions/feedback
> >>
> >> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blevins@gmail.com
> >> >wrote:
> >>
> >> >
> >> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
> >> >
> >> > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <
> >> david.blevins@gmail.com
> >> > >wrote:
> >> > >
> >> > >> From what I understand you're talking about a file that contains
> >> 100% of
> >> > >> the metadata and eliminates the need for most or all of the actual
> >> > >> deployment process. That's definitely a good idea.
> >> > >>
> >> > >
> >> > > That is exactly what I am talking about but this meta-data file I
> was
> >> > > talking to make it in *code* and compile as part of the deployment
> >> > process
> >> > > to make it fast and memory efficient. More specifically for running
> >> the
> >> > > application(s) over and over again, unless there is a chance and
> hence
> >> > the
> >> > > process is repeated.
> >> > >
> >> > > The code can be generated in Groovy or any dynamic language that can
> >> make
> >> > > it easy to deal with at run time.
> >> > >
> >> > > Using Groovy can have an advantage which that Groovy has facilities
> >> for
> >> > > building DSL(s) which we can use to define a DSL for describing
> >> whatever
> >> > > aspects we need while scanning or any other operation we want to do
> >> while
> >> > > deploying which also can serve as a more readable, almost English
> >> > language
> >> > > rather than the tree like language based on XML.
> >> >
> >> > Maybe check out this doc. Some of the things you mention might tie in
> >> > here:
> >> >
> >> > http://openejb.apache.org/dev/configuration-and-assembly.html
> >> >
> >> > There are two layers you could deploy apps in code:
> >> >
> >> > 1. Build the EjbModule by hand and configure then assemble it.
> >> > 2. Build the AppInfo by hand then assemble it.
> >> >
> >> > Working with the AppInfo tree is a bit like writing assembly code.
> >> > Working with the EjbModule and EjbJar tree is a bit more like a DSL.
> >> > There are nice and fancy methods in there and even some DSL syntax.
> >> >
> >> > In pure performance terms, considering no other requirements, cutting
> >> out
> >> > the ConfigurationFactory by simply saving the resulting AppInfo object
> >> then
> >> > reloading it on each deploy is going to be pretty fast. It would cut
> >> out
> >> > 80% of the deploy code, including scanning.
> >> >
> >> > Not how this strictly relates to what you might be thinking, but that
> is
> >> > at least some insight on the problem space.
> >> >
> >> >
> >> > -David
> >> >
> >> >
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> >> - Albert Einstein
> >>
> >
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
s/dd-maven-plugin/info-maven-plugin/
Le 23 févr. 2012 06:48, "Romain Manni-Bucau" <rm...@gmail.com> a
écrit :
> The issue i had wanting to do so was how to do it before the first
> deployment.
>
> Trying to do it through a mvn plugin makes the need to be able to correct
> resources and container when you redeploy.
>
> It actually needs a big refactoring which is very impacting.
>
> Note that i hope to propose to users a release for end of april and would
> like a scan limitation feature so the easier is probably the best for the
> moment.
>
> What i started is in sandbox and called dd-maven-plugin. There is a branch
> too refering to generated descriptors.
>
> - Romain
>
> Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <no...@gmail.com>
> a écrit :
>
>> Hi...
>>
>> *cool* :D
>>
>> I will look into that the coming few days and get back with
>> questions/feedback
>>
>> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blevins@gmail.com
>> >wrote:
>>
>> >
>> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
>> >
>> > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <
>> david.blevins@gmail.com
>> > >wrote:
>> > >
>> > >> From what I understand you're talking about a file that contains
>> 100% of
>> > >> the metadata and eliminates the need for most or all of the actual
>> > >> deployment process. That's definitely a good idea.
>> > >>
>> > >
>> > > That is exactly what I am talking about but this meta-data file I was
>> > > talking to make it in *code* and compile as part of the deployment
>> > process
>> > > to make it fast and memory efficient. More specifically for running
>> the
>> > > application(s) over and over again, unless there is a chance and hence
>> > the
>> > > process is repeated.
>> > >
>> > > The code can be generated in Groovy or any dynamic language that can
>> make
>> > > it easy to deal with at run time.
>> > >
>> > > Using Groovy can have an advantage which that Groovy has facilities
>> for
>> > > building DSL(s) which we can use to define a DSL for describing
>> whatever
>> > > aspects we need while scanning or any other operation we want to do
>> while
>> > > deploying which also can serve as a more readable, almost English
>> > language
>> > > rather than the tree like language based on XML.
>> >
>> > Maybe check out this doc. Some of the things you mention might tie in
>> > here:
>> >
>> > http://openejb.apache.org/dev/configuration-and-assembly.html
>> >
>> > There are two layers you could deploy apps in code:
>> >
>> > 1. Build the EjbModule by hand and configure then assemble it.
>> > 2. Build the AppInfo by hand then assemble it.
>> >
>> > Working with the AppInfo tree is a bit like writing assembly code.
>> > Working with the EjbModule and EjbJar tree is a bit more like a DSL.
>> > There are nice and fancy methods in there and even some DSL syntax.
>> >
>> > In pure performance terms, considering no other requirements, cutting
>> out
>> > the ConfigurationFactory by simply saving the resulting AppInfo object
>> then
>> > reloading it on each deploy is going to be pretty fast. It would cut
>> out
>> > 80% of the deploy code, including scanning.
>> >
>> > Not how this strictly relates to what you might be thinking, but that is
>> > at least some insight on the problem space.
>> >
>> >
>> > -David
>> >
>> >
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The issue i had wanting to do so was how to do it before the first
deployment.
Trying to do it through a mvn plugin makes the need to be able to correct
resources and container when you redeploy.
It actually needs a big refactoring which is very impacting.
Note that i hope to propose to users a release for end of april and would
like a scan limitation feature so the easier is probably the best for the
moment.
What i started is in sandbox and called dd-maven-plugin. There is a branch
too refering to generated descriptors.
- Romain
Le 23 févr. 2012 01:31, "Mohammad Nour El-Din" <no...@gmail.com> a
écrit :
> Hi...
>
> *cool* :D
>
> I will look into that the coming few days and get back with
> questions/feedback
>
> On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blevins@gmail.com
> >wrote:
>
> >
> > On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
> >
> > > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <
> david.blevins@gmail.com
> > >wrote:
> > >
> > >> From what I understand you're talking about a file that contains 100%
> of
> > >> the metadata and eliminates the need for most or all of the actual
> > >> deployment process. That's definitely a good idea.
> > >>
> > >
> > > That is exactly what I am talking about but this meta-data file I was
> > > talking to make it in *code* and compile as part of the deployment
> > process
> > > to make it fast and memory efficient. More specifically for running the
> > > application(s) over and over again, unless there is a chance and hence
> > the
> > > process is repeated.
> > >
> > > The code can be generated in Groovy or any dynamic language that can
> make
> > > it easy to deal with at run time.
> > >
> > > Using Groovy can have an advantage which that Groovy has facilities for
> > > building DSL(s) which we can use to define a DSL for describing
> whatever
> > > aspects we need while scanning or any other operation we want to do
> while
> > > deploying which also can serve as a more readable, almost English
> > language
> > > rather than the tree like language based on XML.
> >
> > Maybe check out this doc. Some of the things you mention might tie in
> > here:
> >
> > http://openejb.apache.org/dev/configuration-and-assembly.html
> >
> > There are two layers you could deploy apps in code:
> >
> > 1. Build the EjbModule by hand and configure then assemble it.
> > 2. Build the AppInfo by hand then assemble it.
> >
> > Working with the AppInfo tree is a bit like writing assembly code.
> > Working with the EjbModule and EjbJar tree is a bit more like a DSL.
> > There are nice and fancy methods in there and even some DSL syntax.
> >
> > In pure performance terms, considering no other requirements, cutting out
> > the ConfigurationFactory by simply saving the resulting AppInfo object
> then
> > reloading it on each deploy is going to be pretty fast. It would cut out
> > 80% of the deploy code, including scanning.
> >
> > Not how this strictly relates to what you might be thinking, but that is
> > at least some insight on the problem space.
> >
> >
> > -David
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi...
*cool* :D
I will look into that the coming few days and get back with
questions/feedback
On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <da...@gmail.com>wrote:
>
> On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
>
> > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <david.blevins@gmail.com
> >wrote:
> >
> >> From what I understand you're talking about a file that contains 100% of
> >> the metadata and eliminates the need for most or all of the actual
> >> deployment process. That's definitely a good idea.
> >>
> >
> > That is exactly what I am talking about but this meta-data file I was
> > talking to make it in *code* and compile as part of the deployment
> process
> > to make it fast and memory efficient. More specifically for running the
> > application(s) over and over again, unless there is a chance and hence
> the
> > process is repeated.
> >
> > The code can be generated in Groovy or any dynamic language that can make
> > it easy to deal with at run time.
> >
> > Using Groovy can have an advantage which that Groovy has facilities for
> > building DSL(s) which we can use to define a DSL for describing whatever
> > aspects we need while scanning or any other operation we want to do while
> > deploying which also can serve as a more readable, almost English
> language
> > rather than the tree like language based on XML.
>
> Maybe check out this doc. Some of the things you mention might tie in
> here:
>
> http://openejb.apache.org/dev/configuration-and-assembly.html
>
> There are two layers you could deploy apps in code:
>
> 1. Build the EjbModule by hand and configure then assemble it.
> 2. Build the AppInfo by hand then assemble it.
>
> Working with the AppInfo tree is a bit like writing assembly code.
> Working with the EjbModule and EjbJar tree is a bit more like a DSL.
> There are nice and fancy methods in there and even some DSL syntax.
>
> In pure performance terms, considering no other requirements, cutting out
> the ConfigurationFactory by simply saving the resulting AppInfo object then
> reloading it on each deploy is going to be pretty fast. It would cut out
> 80% of the deploy code, including scanning.
>
> Not how this strictly relates to what you might be thinking, but that is
> at least some insight on the problem space.
>
>
> -David
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by David Blevins <da...@gmail.com>.
On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote:
> On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <da...@gmail.com>wrote:
>
>> From what I understand you're talking about a file that contains 100% of
>> the metadata and eliminates the need for most or all of the actual
>> deployment process. That's definitely a good idea.
>>
>
> That is exactly what I am talking about but this meta-data file I was
> talking to make it in *code* and compile as part of the deployment process
> to make it fast and memory efficient. More specifically for running the
> application(s) over and over again, unless there is a chance and hence the
> process is repeated.
>
> The code can be generated in Groovy or any dynamic language that can make
> it easy to deal with at run time.
>
> Using Groovy can have an advantage which that Groovy has facilities for
> building DSL(s) which we can use to define a DSL for describing whatever
> aspects we need while scanning or any other operation we want to do while
> deploying which also can serve as a more readable, almost English language
> rather than the tree like language based on XML.
Maybe check out this doc. Some of the things you mention might tie in here:
http://openejb.apache.org/dev/configuration-and-assembly.html
There are two layers you could deploy apps in code:
1. Build the EjbModule by hand and configure then assemble it.
2. Build the AppInfo by hand then assemble it.
Working with the AppInfo tree is a bit like writing assembly code. Working with the EjbModule and EjbJar tree is a bit more like a DSL. There are nice and fancy methods in there and even some DSL syntax.
In pure performance terms, considering no other requirements, cutting out the ConfigurationFactory by simply saving the resulting AppInfo object then reloading it on each deploy is going to be pretty fast. It would cut out 80% of the deploy code, including scanning.
Not how this strictly relates to what you might be thinking, but that is at least some insight on the problem space.
-David
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On Wed, Feb 22, 2012 at 11:33 PM, David Blevins <da...@gmail.com>wrote:
> From what I understand you're talking about a file that contains 100% of
> the metadata and eliminates the need for most or all of the actual
> deployment process. That's definitely a good idea.
>
That is exactly what I am talking about but this meta-data file I was
talking to make it in *code* and compile as part of the deployment process
to make it fast and memory efficient. More specifically for running the
application(s) over and over again, unless there is a chance and hence the
process is repeated.
The code can be generated in Groovy or any dynamic language that can make
it easy to deal with at run time.
Using Groovy can have an advantage which that Groovy has facilities for
building DSL(s) which we can use to define a DSL for describing whatever
aspects we need while scanning or any other operation we want to do while
deploying which also can serve as a more readable, almost English language
rather than the tree like language based on XML.
>
> Some work has been done in that regard, though it's not yet functional.
> It's a much harder problem than optimizing component scanning.
>
Can you give me hints where I can find that, I want to have a look at it
and continue that if possible ? At last I could have a successful OpenEJB
build on my machine since years now :D.
>
> Note also that there are two types of scanning. There is:
>
> A. scanning jars for classes that use a specific annotation
> B. scanning a class for annotations
>
> Due to memory and speed limitations you can't do B on every class in all
> jars, so limiting that scope is important. This is where A comes in.
>
> The scan.xml proposal effectively only tackles issue A.
>
We can have options to control on which level we want to apply this. Or
even this can be provided a tool for developers to run over their code
before deploying it generating the meta-date *code* which can be detected
while deployment loaded and take actions based on what we find there.
I know this might sound like complicated, but it is not it is just
different in my ex-company we used Python all the time even when describing
services and object model(s) (a.k.a DSL) which is more readable and
more efficient than reading XML or YAML.
Thoughts ?
>
>
> -David
>
> On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote:
>
> > Never it seems not to be a good idea :)
> >
> > On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> Hmm, not sure i follow too,
> >>
> >> We just spoke about generating xml then reading it to avoid scanning.
> >>
> >> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a
> écrit :
> >>
> >>>
> >>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
> >>>
> >>>> Hi Romain and Alan :)
> >>>>
> >>>> I didn't say ever to not use XML or a simple file, which what I meant
> >>> by
> >>>> the declarative side, what I mean is additionally to that, at the time
> >> of
> >>>> deploy that out of that file Java code is generated which provides the
> >>>> information we need while scanning and thats what I meant by the
> >>>> execution/runtime perspective.
> >>>
> >>> I think I'm a bit lost. Why would Java code be generated when simply
> >>> reading the file will do? :)
> >>>
> >>> Can you provide a more detailed and concrete example that explains your
> >>> idea?
> >>>
> >>>
> >>> Regards,
> >>> Alan
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by David Blevins <da...@gmail.com>.
From what I understand you're talking about a file that contains 100% of the metadata and eliminates the need for most or all of the actual deployment process. That's definitely a good idea.
Some work has been done in that regard, though it's not yet functional. It's a much harder problem than optimizing component scanning.
Note also that there are two types of scanning. There is:
A. scanning jars for classes that use a specific annotation
B. scanning a class for annotations
Due to memory and speed limitations you can't do B on every class in all jars, so limiting that scope is important. This is where A comes in.
The scan.xml proposal effectively only tackles issue A.
-David
On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote:
> Never it seems not to be a good idea :)
>
> On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> Hmm, not sure i follow too,
>>
>> We just spoke about generating xml then reading it to avoid scanning.
>>
>> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a écrit :
>>
>>>
>>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
>>>
>>>> Hi Romain and Alan :)
>>>>
>>>> I didn't say ever to not use XML or a simple file, which what I meant
>>> by
>>>> the declarative side, what I mean is additionally to that, at the time
>> of
>>>> deploy that out of that file Java code is generated which provides the
>>>> information we need while scanning and thats what I meant by the
>>>> execution/runtime perspective.
>>>
>>> I think I'm a bit lost. Why would Java code be generated when simply
>>> reading the file will do? :)
>>>
>>> Can you provide a more detailed and concrete example that explains your
>>> idea?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>
>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Never it seems not to be a good idea :)
On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hmm, not sure i follow too,
>
> We just spoke about generating xml then reading it to avoid scanning.
>
> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a écrit :
>
> >
> > On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
> >
> > > Hi Romain and Alan :)
> > >
> > > I didn't say ever to not use XML or a simple file, which what I meant
> > by
> > > the declarative side, what I mean is additionally to that, at the time
> of
> > > deploy that out of that file Java code is generated which provides the
> > > information we need while scanning and thats what I meant by the
> > > execution/runtime perspective.
> >
> > I think I'm a bit lost. Why would Java code be generated when simply
> > reading the file will do? :)
> >
> > Can you provide a more detailed and concrete example that explains your
> > idea?
> >
> >
> > Regards,
> > Alan
> >
> >
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, not sure i follow too,
We just spoke about generating xml then reading it to avoid scanning.
Le 22 févr. 2012 21:06, "Alan D. Cabrera" <li...@toolazydogs.com> a écrit :
>
> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
>
> > Hi Romain and Alan :)
> >
> > I didn't say ever to not use XML or a simple file, which what I meant
> by
> > the declarative side, what I mean is additionally to that, at the time of
> > deploy that out of that file Java code is generated which provides the
> > information we need while scanning and thats what I meant by the
> > execution/runtime perspective.
>
> I think I'm a bit lost. Why would Java code be generated when simply
> reading the file will do? :)
>
> Can you provide a more detailed and concrete example that explains your
> idea?
>
>
> Regards,
> Alan
>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote:
> Hi Romain and Alan :)
>
> I didn't say ever to not use XML or a simple file, which what I meant by
> the declarative side, what I mean is additionally to that, at the time of
> deploy that out of that file Java code is generated which provides the
> information we need while scanning and thats what I meant by the
> execution/runtime perspective.
I think I'm a bit lost. Why would Java code be generated when simply reading the file will do? :)
Can you provide a more detailed and concrete example that explains your idea?
Regards,
Alan
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi Romain and Alan :)
I didn't say ever to not use XML or a simple file, which what I meant by
the declarative side, what I mean is additionally to that, at the time of
deploy that out of that file Java code is generated which provides the
information we need while scanning and thats what I meant by the
execution/runtime perspective.
On Wed, Feb 22, 2012 at 8:37 PM, David Blevins <da...@gmail.com>wrote:
> Additional note that the ultimate goal of the scan.xml file is to provide
> something that could be standardized. There is interest for having a more
> general solution.
>
> This probably affects the scan.xml file itself, the plugin could live
> anywhere (I'd imagined we'd eventually put it in xbean).
>
> Ideally a standard file would be:
>
> - in META-INF/scan.xml
> - list classes and packages
> - something a user can create by hand
>
> Anything that adds xbean/openejb/tomee branding, is not xml, or contains
> plugin-specific information would have to be removed from any proposals to
> Java EE 7.
>
> Some things to keep in mind as we discuss.
>
>
> -David
>
> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>
> > We've chatted occasionally on creating a scanning.xml file where people
> could setup includes and excludes and, overall, optimize classpath scanning.
> >
> > Romain is already busy hacking of course :) Here's the idea for a
> plugin to effectively do the most expensive part of scanning in advance:
> >
> > <plugin>
> > <groupId>org.apache.xbean</groupId>
> > <artifactId>maven-xbean-finder-plugin</artifactId>
> > <configuration>
> > <annotations>
> > <annotation>javax.ejb.Stateless</annotation>
> > <annotation>javax.ejb.Stateful</annotation>
> > <annotation>javax.ejb.Singleton</annotation>
> > <annotation>javax.annotation.ManagedBean</annotation>
> > </annotations>
> > <subclasses>
> > <subclass>javax.ws.rs.core.Application</subclass>
> > </subclasses>
> > <implementations>
> >
> <implementation>org.apache.openejb.server.ServerService</implementation>
> > </implementations>
> > </configuration>
> > </plugin>
> >
> > With a configuration like the above, the plugin would scan the jar for
> subclasses of javax.ws.rs.core.Application, classes annotated with
> @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
> >
> > The result would be a META-INF/scan.xml class that looks like so:
> >
> > <scan>
> > <classes>
> > <class>org.superbiz.Foo</class>
> > <class>org.superbiz.Bar</class>
> > <class>org.superbiz.Baz</class>
> > </classes>
> > </scan>
> >
> > And on the TODO list would be future support for <packages>
> >
> > <scan>
> > <packages>
> > <package>org.superbiz.foo</package>
> > <package>org.superbiz.bar</package>
> > </packages>
> > </scan>
> >
> > With the above you could easily create scan.xml file by hand that would
> at least be far faster than scanning an entire jar.
> >
> >
> > Thoughts?
> >
> >
> > -David
> >
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 22, 2012, at 11:37 AM, David Blevins wrote:
> Additional note that the ultimate goal of the scan.xml file is to provide something that could be standardized. There is interest for having a more general solution.
>
> This probably affects the scan.xml file itself, the plugin could live anywhere (I'd imagined we'd eventually put it in xbean).
>
> Ideally a standard file would be:
>
> - in META-INF/scan.xml
> - list classes and packages
> - something a user can create by hand
>
> Anything that adds xbean/openejb/tomee branding, is not xml, or contains plugin-specific information would have to be removed from any proposals to Java EE 7.
This reflects my thinking as well.
I guess the lack of a package prefix to scan.xml reflects the possible goal of this becoming a JEE7 standard. Makes sense.
Regards,
Alan
Re: Annotation scanning plugin
Posted by David Blevins <da...@gmail.com>.
Additional note that the ultimate goal of the scan.xml file is to provide something that could be standardized. There is interest for having a more general solution.
This probably affects the scan.xml file itself, the plugin could live anywhere (I'd imagined we'd eventually put it in xbean).
Ideally a standard file would be:
- in META-INF/scan.xml
- list classes and packages
- something a user can create by hand
Anything that adds xbean/openejb/tomee branding, is not xml, or contains plugin-specific information would have to be removed from any proposals to Java EE 7.
Some things to keep in mind as we discuss.
-David
On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> We've chatted occasionally on creating a scanning.xml file where people could setup includes and excludes and, overall, optimize classpath scanning.
>
> Romain is already busy hacking of course :) Here's the idea for a plugin to effectively do the most expensive part of scanning in advance:
>
> <plugin>
> <groupId>org.apache.xbean</groupId>
> <artifactId>maven-xbean-finder-plugin</artifactId>
> <configuration>
> <annotations>
> <annotation>javax.ejb.Stateless</annotation>
> <annotation>javax.ejb.Stateful</annotation>
> <annotation>javax.ejb.Singleton</annotation>
> <annotation>javax.annotation.ManagedBean</annotation>
> </annotations>
> <subclasses>
> <subclass>javax.ws.rs.core.Application</subclass>
> </subclasses>
> <implementations>
> <implementation>org.apache.openejb.server.ServerService</implementation>
> </implementations>
> </configuration>
> </plugin>
>
> With a configuration like the above, the plugin would scan the jar for subclasses of javax.ws.rs.core.Application, classes annotated with @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
>
> The result would be a META-INF/scan.xml class that looks like so:
>
> <scan>
> <classes>
> <class>org.superbiz.Foo</class>
> <class>org.superbiz.Bar</class>
> <class>org.superbiz.Baz</class>
> </classes>
> </scan>
>
> And on the TODO list would be future support for <packages>
>
> <scan>
> <packages>
> <package>org.superbiz.foo</package>
> <package>org.superbiz.bar</package>
> </packages>
> </scan>
>
> With the above you could easily create scan.xml file by hand that would at least be far faster than scanning an entire jar.
>
>
> Thoughts?
>
>
> -David
>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep i think so.
when we'll get JAXRS in webprofile we'll be able use it ;) (moreover it
will still be jaxb :p)
- Romain
2012/2/21 dsh <da...@googlemail.com>
> There's JSON schema [1] for instance but I guess that pulls in another
> dependency...
>
> [1] http://tools.ietf.org/html/draft-zyp-json-schema-03
>
> Cheers
> Daniel
>
> On Tue, Feb 21, 2012 at 3:41 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> > I like XML because we can have enforcement via schema.
> >
> >
> > Regards,
> > Alan
> >
> >
> > On Feb 21, 2012, at 6:39 AM, Romain Manni-Bucau wrote:
> >
> >> I think the same.
> >>
> >> I think we don't really have any choice regarding the format since we
> don't
> >> want to bring another lib to do anything more than we need in tomee
> >> webprofile.
> >>
> >> It is either properties, plain txt or xml file.
> >>
> >> - Romain
> >>
> >>
> >> 2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
> >>
> >>> I think that it would be nicer to have a simple file that all manner of
> >>> tooling can read, e.g. python.
> >>>
> >>> With that said, the XML file format seems simple enough and I doubt
> that
> >>> any large jar would pose a problem memory or CPU wise. JMHO.
> >>>
> >>>
> >>> Regards,
> >>> Alan
> >>>
> >>>
> >>> On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
> >>>
> >>>> I have one concern, still by having an XML generated and we still like
> >>>> reading only information about such classes and the overhead of
> reading
> >>> XML
> >>>> in memory in case we have a large one(s).
> >>>>
> >>>> Why not generate a code out of that which is compiled with the jar or
> >>> even
> >>>> added to the an existing jar which will be much faster and this code
> can
> >>> be
> >>>> based on templates which developers can extend, change or customize.
> >>>>
> >>>> Thoughts ?
> >>>>
> >>>> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> >>>> nour.mohammad@gmail.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <
> list@toolazydogs.com
> >>>> wrote:
> >>>>>
> >>>>>> Neat idea.
> >>>>>>
> >>>>>> I would include the configuration information in the scan.xml so
> that
> >>>>>> tooling would know the criteria used in the scan and decide whether
> or
> >>> not
> >>>>>> to scan for other annotations or inplementations.
> >>>>>>
> >>>>>> I would also put the scan.xml file in some package specific place
> like
> >>>>>> META-INF/org/apache/xbean/scan.xml.
> >>>>>>
> >>>>>
> >>>>> +1 on the idea and the additions on Alan
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Alan
> >>>>>>
> >>>>>>
> >>>>>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> >>>>>>
> >>>>>>> We've chatted occasionally on creating a scanning.xml file where
> >>> people
> >>>>>> could setup includes and excludes and, overall, optimize classpath
> >>> scanning.
> >>>>>>>
> >>>>>>> Romain is already busy hacking of course :) Here's the idea for a
> >>>>>> plugin to effectively do the most expensive part of scanning in
> >>> advance:
> >>>>>>>
> >>>>>>> <plugin>
> >>>>>>> <groupId>org.apache.xbean</groupId>
> >>>>>>> <artifactId>maven-xbean-finder-plugin</artifactId>
> >>>>>>> <configuration>
> >>>>>>> <annotations>
> >>>>>>> <annotation>javax.ejb.Stateless</annotation>
> >>>>>>> <annotation>javax.ejb.Stateful</annotation>
> >>>>>>> <annotation>javax.ejb.Singleton</annotation>
> >>>>>>> <annotation>javax.annotation.ManagedBean</annotation>
> >>>>>>> </annotations>
> >>>>>>> <subclasses>
> >>>>>>> <subclass>javax.ws.rs.core.Application</subclass>
> >>>>>>> </subclasses>
> >>>>>>> <implementations>
> >>>>>>>
> >>>>>>
> >>>
> <implementation>org.apache.openejb.server.ServerService</implementation>
> >>>>>>> </implementations>
> >>>>>>> </configuration>
> >>>>>>> </plugin>
> >>>>>>>
> >>>>>>> With a configuration like the above, the plugin would scan the jar
> for
> >>>>>> subclasses of javax.ws.rs.core.Application, classes annotated with
> >>>>>> @Stateless, @Singleton, @Stateful and classes that implement
> >>> ServiceService.
> >>>>>>>
> >>>>>>> The result would be a META-INF/scan.xml class that looks like so:
> >>>>>>>
> >>>>>>> <scan>
> >>>>>>> <classes>
> >>>>>>> <class>org.superbiz.Foo</class>
> >>>>>>> <class>org.superbiz.Bar</class>
> >>>>>>> <class>org.superbiz.Baz</class>
> >>>>>>> </classes>
> >>>>>>> </scan>
> >>>>>>>
> >>>>>>> And on the TODO list would be future support for <packages>
> >>>>>>>
> >>>>>>> <scan>
> >>>>>>> <packages>
> >>>>>>> <package>org.superbiz.foo</package>
> >>>>>>> <package>org.superbiz.bar</package>
> >>>>>>> </packages>
> >>>>>>> </scan>
> >>>>>>>
> >>>>>>> With the above you could easily create scan.xml file by hand that
> >>> would
> >>>>>> at least be far faster than scanning an entire jar.
> >>>>>>>
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>>
> >>>>>>> -David
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Thanks
> >>>>> - Mohammad Nour
> >>>>> ----
> >>>>> "Life is like riding a bicycle. To keep your balance you must keep
> >>> moving"
> >>>>> - Albert Einstein
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks
> >>>> - Mohammad Nour
> >>>> ----
> >>>> "Life is like riding a bicycle. To keep your balance you must keep
> >>> moving"
> >>>> - Albert Einstein
> >>>
> >>>
> >
>
Re: Annotation scanning plugin
Posted by dsh <da...@googlemail.com>.
There's JSON schema [1] for instance but I guess that pulls in another
dependency...
[1] http://tools.ietf.org/html/draft-zyp-json-schema-03
Cheers
Daniel
On Tue, Feb 21, 2012 at 3:41 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I like XML because we can have enforcement via schema.
>
>
> Regards,
> Alan
>
>
> On Feb 21, 2012, at 6:39 AM, Romain Manni-Bucau wrote:
>
>> I think the same.
>>
>> I think we don't really have any choice regarding the format since we don't
>> want to bring another lib to do anything more than we need in tomee
>> webprofile.
>>
>> It is either properties, plain txt or xml file.
>>
>> - Romain
>>
>>
>> 2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
>>
>>> I think that it would be nicer to have a simple file that all manner of
>>> tooling can read, e.g. python.
>>>
>>> With that said, the XML file format seems simple enough and I doubt that
>>> any large jar would pose a problem memory or CPU wise. JMHO.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>> On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
>>>
>>>> I have one concern, still by having an XML generated and we still like
>>>> reading only information about such classes and the overhead of reading
>>> XML
>>>> in memory in case we have a large one(s).
>>>>
>>>> Why not generate a code out of that which is compiled with the jar or
>>> even
>>>> added to the an existing jar which will be much faster and this code can
>>> be
>>>> based on templates which developers can extend, change or customize.
>>>>
>>>> Thoughts ?
>>>>
>>>> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
>>>> nour.mohammad@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <list@toolazydogs.com
>>>> wrote:
>>>>>
>>>>>> Neat idea.
>>>>>>
>>>>>> I would include the configuration information in the scan.xml so that
>>>>>> tooling would know the criteria used in the scan and decide whether or
>>> not
>>>>>> to scan for other annotations or inplementations.
>>>>>>
>>>>>> I would also put the scan.xml file in some package specific place like
>>>>>> META-INF/org/apache/xbean/scan.xml.
>>>>>>
>>>>>
>>>>> +1 on the idea and the additions on Alan
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>>
>>>>>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>>>>>>
>>>>>>> We've chatted occasionally on creating a scanning.xml file where
>>> people
>>>>>> could setup includes and excludes and, overall, optimize classpath
>>> scanning.
>>>>>>>
>>>>>>> Romain is already busy hacking of course :) Here's the idea for a
>>>>>> plugin to effectively do the most expensive part of scanning in
>>> advance:
>>>>>>>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.xbean</groupId>
>>>>>>> <artifactId>maven-xbean-finder-plugin</artifactId>
>>>>>>> <configuration>
>>>>>>> <annotations>
>>>>>>> <annotation>javax.ejb.Stateless</annotation>
>>>>>>> <annotation>javax.ejb.Stateful</annotation>
>>>>>>> <annotation>javax.ejb.Singleton</annotation>
>>>>>>> <annotation>javax.annotation.ManagedBean</annotation>
>>>>>>> </annotations>
>>>>>>> <subclasses>
>>>>>>> <subclass>javax.ws.rs.core.Application</subclass>
>>>>>>> </subclasses>
>>>>>>> <implementations>
>>>>>>>
>>>>>>
>>> <implementation>org.apache.openejb.server.ServerService</implementation>
>>>>>>> </implementations>
>>>>>>> </configuration>
>>>>>>> </plugin>
>>>>>>>
>>>>>>> With a configuration like the above, the plugin would scan the jar for
>>>>>> subclasses of javax.ws.rs.core.Application, classes annotated with
>>>>>> @Stateless, @Singleton, @Stateful and classes that implement
>>> ServiceService.
>>>>>>>
>>>>>>> The result would be a META-INF/scan.xml class that looks like so:
>>>>>>>
>>>>>>> <scan>
>>>>>>> <classes>
>>>>>>> <class>org.superbiz.Foo</class>
>>>>>>> <class>org.superbiz.Bar</class>
>>>>>>> <class>org.superbiz.Baz</class>
>>>>>>> </classes>
>>>>>>> </scan>
>>>>>>>
>>>>>>> And on the TODO list would be future support for <packages>
>>>>>>>
>>>>>>> <scan>
>>>>>>> <packages>
>>>>>>> <package>org.superbiz.foo</package>
>>>>>>> <package>org.superbiz.bar</package>
>>>>>>> </packages>
>>>>>>> </scan>
>>>>>>>
>>>>>>> With the above you could easily create scan.xml file by hand that
>>> would
>>>>>> at least be far faster than scanning an entire jar.
>>>>>>>
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks
>>>>> - Mohammad Nour
>>>>> ----
>>>>> "Life is like riding a bicycle. To keep your balance you must keep
>>> moving"
>>>>> - Albert Einstein
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> - Mohammad Nour
>>>> ----
>>>> "Life is like riding a bicycle. To keep your balance you must keep
>>> moving"
>>>> - Albert Einstein
>>>
>>>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 21, 2012, at 8:29 AM, Romain Manni-Bucau wrote:
> - Romain
>
>
> 2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
>
>>
>> On Feb 21, 2012, at 7:40 AM, Romain Manni-Bucau wrote:
>>
>>> 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
I am not speaking to the number of properties to configure the location of the scan.xml file but to the fact that it can be configured at all. The power of this scanner is that it puts the scan report in a known fixed location. I think making it configurable weakens that feature.
>> 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
Agreed, hence my idea of publishing the profiles.
> 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
Service loader uses the classpath. IMO, this file should be directly configured instead of being automagically found. wdyt?
Regards,
Alan
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ka...@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
> <rm...@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 <rm...@gmail.com>
> >
> > >
> > > - Romain
> > >
> > >
> > > 2012/2/21 Alan D. Cabrera <li...@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
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Earlier in the thread I had mentioned that the code bits and scanning should not be performed on the client side but, instead, should be done inside xbean itself. More specifically, when xbean is asked to scan a certain set of URLs it can first check to see if there's a scan.xml file in the known location. If it finds it then its job of scanning is simpler and more efficient. If it does not find it then it does what it currently does.
I think that there's little value in forcing the users of xbean to perform the above work in what amounts to an xbean implementation leak into OpenEJB's CLI and deployer code.
Given that the code is best packed into xbean, according to the above line of reasoning, it makes sense to me that the plugin belong to xbean. This plugin has great value outside of tomee.
Regards,
Alan
On Feb 21, 2012, at 12:02 PM, Karan Malhi wrote:
> 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
> <rm...@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 <rm...@gmail.com>
>>
>>>
>>> - Romain
>>>
>>>
>>> 2012/2/21 Alan D. Cabrera <li...@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
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <rm...@gmail.com>
> > To: Mark Struberg <st...@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" <st...@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 <ka...@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
> >> > <rm...@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 <rm...@gmail.com>
> >> >>
> >> >> >
> >> >> > - Romain
> >> >> >
> >> >> >
> >> >> > 2012/2/21 Alan D. Cabrera <li...@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
> >> >
> >>
> >
>
Re: Annotation scanning plugin
Posted by David Blevins <da...@gmail.com>.
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 <rm...@gmail.com>
>> To: Mark Struberg <st...@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" <st...@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 <ka...@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
>>>> <rm...@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 <rm...@gmail.com>
>>>>>
>>>>> >
>>>>> > - Romain
>>>>> >
>>>>> >
>>>>> > 2012/2/21 Alan D. Cabrera <li...@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
>>>>
>>>
>>
Re: Annotation scanning plugin
Posted by Mark Struberg <st...@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 <rm...@gmail.com>
> To: Mark Struberg <st...@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" <st...@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 <ka...@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
>> > <rm...@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 <rm...@gmail.com>
>> >>
>> >> >
>> >> > - Romain
>> >> >
>> >> >
>> >> > 2012/2/21 Alan D. Cabrera <li...@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
>> >
>>
>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@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 <ka...@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
> > <rm...@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 <rm...@gmail.com>
> >>
> >> >
> >> > - Romain
> >> >
> >> >
> >> > 2012/2/21 Alan D. Cabrera <li...@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
> >
>
Re: Annotation scanning plugin
Posted by David Blevins <da...@gmail.com>.
Definitely the goal is to move it to xbean. Moving xbean to commons is certainly something that can be done, though that wouldn't improve it's ability to be used, it's really just be a package change for whatever that is worth. Though it might have an impact on how much people actually *want* to use it :)
-David
On Feb 26, 2012, at 3:31 PM, Mark Struberg wrote:
> 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 <ka...@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
>> <rm...@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 <rm...@gmail.com>
>>>
>>>>
>>>> - Romain
>>>>
>>>>
>>>> 2012/2/21 Alan D. Cabrera <li...@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
>>
Re: Annotation scanning plugin
Posted by Mark Struberg <st...@yahoo.de>.
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 <ka...@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
> <rm...@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 <rm...@gmail.com>
>>
>> >
>> > - Romain
>> >
>> >
>> > 2012/2/21 Alan D. Cabrera <li...@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
>
Re: Annotation scanning plugin
Posted by Karan Malhi <ka...@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
<rm...@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 <rm...@gmail.com>
>
> >
> > - Romain
> >
> >
> > 2012/2/21 Alan D. Cabrera <li...@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
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@gmail.com>
>
> - Romain
>
>
> 2012/2/21 Alan D. Cabrera <li...@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
>>
>>
>
>
>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
- Romain
2012/2/21 Alan D. Cabrera <li...@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
>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@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.
> 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.
> 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.
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.
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.
Regards,
Alan
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
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).
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 ;)
- Romain
2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
>
> On Feb 21, 2012, at 6:49 AM, Romain Manni-Bucau wrote:
>
> > the only reason i don't like it is because of its verbosity otherwise it
> is
> > a cool format.
>
> I never understood the "verbosity argument" but then I don't use vi as an
> editor. My editor automatically adds end tags, quotes for attributes, and
> even automatically does auto-completion if it has the schema. What's not
> to like? :)
>
> > Well i pushed a version using the xml file. Here the several parts:
> > *
> >
> https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/spi-helper-maven-plugin/
> > :
> > the maven plugin to scan an app
> > * rest-example pom (
> >
> http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/webapps/rest-example/pom.xml
> )
> > : one usage of the plugin (even if here it is probably useless)
>
> Awesome!
>
> The power of this scanner is that it puts the scan report in a known fixed
> location. I think making it configurable weakens that feature.
>
> Why is JPA required?
>
> Do you intend to add the ability to look for certain annotations, classes,
> interfaces?
>
> > *
> https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/xbean-xml/ :
> > the module containing jaxb classes and a helper class to create the
> > annotation finder
>
> I can take a look at your plugin later tonight. Very excited! :)
>
> > * openejb-core/.../FinderFactory: updated to try to get the scan.xml file
> > before creating a standard finder
>
> I think this code belongs in xbean. Xbean can look for the file and use
> it. More specifically it needs to happen behind the scenes and not push
> the complexity on xbean users.
>
> > Note: the descriptor is in META-INF/org/apache/xbean/scan.xml excepted
> for
> > webapp where META-INF is replaced by WEB-INF to be consistent with other
> > descriptors.
>
> Makes sense.
>
>
> Regards,
> Alan
>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 21, 2012, at 6:49 AM, Romain Manni-Bucau wrote:
> the only reason i don't like it is because of its verbosity otherwise it is
> a cool format.
I never understood the "verbosity argument" but then I don't use vi as an editor. My editor automatically adds end tags, quotes for attributes, and even automatically does auto-completion if it has the schema. What's not to like? :)
> Well i pushed a version using the xml file. Here the several parts:
> *
> https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/spi-helper-maven-plugin/
> :
> the maven plugin to scan an app
> * rest-example pom (
> http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/webapps/rest-example/pom.xml)
> : one usage of the plugin (even if here it is probably useless)
Awesome!
The power of this scanner is that it puts the scan report in a known fixed location. I think making it configurable weakens that feature.
Why is JPA required?
Do you intend to add the ability to look for certain annotations, classes, interfaces?
> * https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/xbean-xml/ :
> the module containing jaxb classes and a helper class to create the
> annotation finder
I can take a look at your plugin later tonight. Very excited! :)
> * openejb-core/.../FinderFactory: updated to try to get the scan.xml file
> before creating a standard finder
I think this code belongs in xbean. Xbean can look for the file and use it. More specifically it needs to happen behind the scenes and not push the complexity on xbean users.
> Note: the descriptor is in META-INF/org/apache/xbean/scan.xml excepted for
> webapp where META-INF is replaced by WEB-INF to be consistent with other
> descriptors.
Makes sense.
Regards,
Alan
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
the only reason i don't like it is because of its verbosity otherwise it is
a cool format.
Well i pushed a version using the xml file. Here the several parts:
*
https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/spi-helper-maven-plugin/
:
the maven plugin to scan an app
* rest-example pom (
http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/webapps/rest-example/pom.xml)
: one usage of the plugin (even if here it is probably useless)
* https://svn.apache.org/repos/asf/openejb/trunk/maven-plugins/xbean-xml/ :
the module containing jaxb classes and a helper class to create the
annotation finder
* openejb-core/.../FinderFactory: updated to try to get the scan.xml file
before creating a standard finder
Note: the descriptor is in META-INF/org/apache/xbean/scan.xml excepted for
webapp where META-INF is replaced by WEB-INF to be consistent with other
descriptors.
- Romain
2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
> I like XML because we can have enforcement via schema.
>
>
> Regards,
> Alan
>
>
> On Feb 21, 2012, at 6:39 AM, Romain Manni-Bucau wrote:
>
> > I think the same.
> >
> > I think we don't really have any choice regarding the format since we
> don't
> > want to bring another lib to do anything more than we need in tomee
> > webprofile.
> >
> > It is either properties, plain txt or xml file.
> >
> > - Romain
> >
> >
> > 2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
> >
> >> I think that it would be nicer to have a simple file that all manner of
> >> tooling can read, e.g. python.
> >>
> >> With that said, the XML file format seems simple enough and I doubt that
> >> any large jar would pose a problem memory or CPU wise. JMHO.
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >>
> >> On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
> >>
> >>> I have one concern, still by having an XML generated and we still like
> >>> reading only information about such classes and the overhead of reading
> >> XML
> >>> in memory in case we have a large one(s).
> >>>
> >>> Why not generate a code out of that which is compiled with the jar or
> >> even
> >>> added to the an existing jar which will be much faster and this code
> can
> >> be
> >>> based on templates which developers can extend, change or customize.
> >>>
> >>> Thoughts ?
> >>>
> >>> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> >>> nour.mohammad@gmail.com> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <
> list@toolazydogs.com
> >>> wrote:
> >>>>
> >>>>> Neat idea.
> >>>>>
> >>>>> I would include the configuration information in the scan.xml so that
> >>>>> tooling would know the criteria used in the scan and decide whether
> or
> >> not
> >>>>> to scan for other annotations or inplementations.
> >>>>>
> >>>>> I would also put the scan.xml file in some package specific place
> like
> >>>>> META-INF/org/apache/xbean/scan.xml.
> >>>>>
> >>>>
> >>>> +1 on the idea and the additions on Alan
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Alan
> >>>>>
> >>>>>
> >>>>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> >>>>>
> >>>>>> We've chatted occasionally on creating a scanning.xml file where
> >> people
> >>>>> could setup includes and excludes and, overall, optimize classpath
> >> scanning.
> >>>>>>
> >>>>>> Romain is already busy hacking of course :) Here's the idea for a
> >>>>> plugin to effectively do the most expensive part of scanning in
> >> advance:
> >>>>>>
> >>>>>> <plugin>
> >>>>>> <groupId>org.apache.xbean</groupId>
> >>>>>> <artifactId>maven-xbean-finder-plugin</artifactId>
> >>>>>> <configuration>
> >>>>>> <annotations>
> >>>>>> <annotation>javax.ejb.Stateless</annotation>
> >>>>>> <annotation>javax.ejb.Stateful</annotation>
> >>>>>> <annotation>javax.ejb.Singleton</annotation>
> >>>>>> <annotation>javax.annotation.ManagedBean</annotation>
> >>>>>> </annotations>
> >>>>>> <subclasses>
> >>>>>> <subclass>javax.ws.rs.core.Application</subclass>
> >>>>>> </subclasses>
> >>>>>> <implementations>
> >>>>>>
> >>>>>
> >> <implementation>org.apache.openejb.server.ServerService</implementation>
> >>>>>> </implementations>
> >>>>>> </configuration>
> >>>>>> </plugin>
> >>>>>>
> >>>>>> With a configuration like the above, the plugin would scan the jar
> for
> >>>>> subclasses of javax.ws.rs.core.Application, classes annotated with
> >>>>> @Stateless, @Singleton, @Stateful and classes that implement
> >> ServiceService.
> >>>>>>
> >>>>>> The result would be a META-INF/scan.xml class that looks like so:
> >>>>>>
> >>>>>> <scan>
> >>>>>> <classes>
> >>>>>> <class>org.superbiz.Foo</class>
> >>>>>> <class>org.superbiz.Bar</class>
> >>>>>> <class>org.superbiz.Baz</class>
> >>>>>> </classes>
> >>>>>> </scan>
> >>>>>>
> >>>>>> And on the TODO list would be future support for <packages>
> >>>>>>
> >>>>>> <scan>
> >>>>>> <packages>
> >>>>>> <package>org.superbiz.foo</package>
> >>>>>> <package>org.superbiz.bar</package>
> >>>>>> </packages>
> >>>>>> </scan>
> >>>>>>
> >>>>>> With the above you could easily create scan.xml file by hand that
> >> would
> >>>>> at least be far faster than scanning an entire jar.
> >>>>>>
> >>>>>>
> >>>>>> Thoughts?
> >>>>>>
> >>>>>>
> >>>>>> -David
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks
> >>>> - Mohammad Nour
> >>>> ----
> >>>> "Life is like riding a bicycle. To keep your balance you must keep
> >> moving"
> >>>> - Albert Einstein
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Thanks
> >>> - Mohammad Nour
> >>> ----
> >>> "Life is like riding a bicycle. To keep your balance you must keep
> >> moving"
> >>> - Albert Einstein
> >>
> >>
>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I like XML because we can have enforcement via schema.
Regards,
Alan
On Feb 21, 2012, at 6:39 AM, Romain Manni-Bucau wrote:
> I think the same.
>
> I think we don't really have any choice regarding the format since we don't
> want to bring another lib to do anything more than we need in tomee
> webprofile.
>
> It is either properties, plain txt or xml file.
>
> - Romain
>
>
> 2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
>
>> I think that it would be nicer to have a simple file that all manner of
>> tooling can read, e.g. python.
>>
>> With that said, the XML file format seems simple enough and I doubt that
>> any large jar would pose a problem memory or CPU wise. JMHO.
>>
>>
>> Regards,
>> Alan
>>
>>
>> On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
>>
>>> I have one concern, still by having an XML generated and we still like
>>> reading only information about such classes and the overhead of reading
>> XML
>>> in memory in case we have a large one(s).
>>>
>>> Why not generate a code out of that which is compiled with the jar or
>> even
>>> added to the an existing jar which will be much faster and this code can
>> be
>>> based on templates which developers can extend, change or customize.
>>>
>>> Thoughts ?
>>>
>>> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
>>> nour.mohammad@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <list@toolazydogs.com
>>> wrote:
>>>>
>>>>> Neat idea.
>>>>>
>>>>> I would include the configuration information in the scan.xml so that
>>>>> tooling would know the criteria used in the scan and decide whether or
>> not
>>>>> to scan for other annotations or inplementations.
>>>>>
>>>>> I would also put the scan.xml file in some package specific place like
>>>>> META-INF/org/apache/xbean/scan.xml.
>>>>>
>>>>
>>>> +1 on the idea and the additions on Alan
>>>>
>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>>
>>>>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>>>>>
>>>>>> We've chatted occasionally on creating a scanning.xml file where
>> people
>>>>> could setup includes and excludes and, overall, optimize classpath
>> scanning.
>>>>>>
>>>>>> Romain is already busy hacking of course :) Here's the idea for a
>>>>> plugin to effectively do the most expensive part of scanning in
>> advance:
>>>>>>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.xbean</groupId>
>>>>>> <artifactId>maven-xbean-finder-plugin</artifactId>
>>>>>> <configuration>
>>>>>> <annotations>
>>>>>> <annotation>javax.ejb.Stateless</annotation>
>>>>>> <annotation>javax.ejb.Stateful</annotation>
>>>>>> <annotation>javax.ejb.Singleton</annotation>
>>>>>> <annotation>javax.annotation.ManagedBean</annotation>
>>>>>> </annotations>
>>>>>> <subclasses>
>>>>>> <subclass>javax.ws.rs.core.Application</subclass>
>>>>>> </subclasses>
>>>>>> <implementations>
>>>>>>
>>>>>
>> <implementation>org.apache.openejb.server.ServerService</implementation>
>>>>>> </implementations>
>>>>>> </configuration>
>>>>>> </plugin>
>>>>>>
>>>>>> With a configuration like the above, the plugin would scan the jar for
>>>>> subclasses of javax.ws.rs.core.Application, classes annotated with
>>>>> @Stateless, @Singleton, @Stateful and classes that implement
>> ServiceService.
>>>>>>
>>>>>> The result would be a META-INF/scan.xml class that looks like so:
>>>>>>
>>>>>> <scan>
>>>>>> <classes>
>>>>>> <class>org.superbiz.Foo</class>
>>>>>> <class>org.superbiz.Bar</class>
>>>>>> <class>org.superbiz.Baz</class>
>>>>>> </classes>
>>>>>> </scan>
>>>>>>
>>>>>> And on the TODO list would be future support for <packages>
>>>>>>
>>>>>> <scan>
>>>>>> <packages>
>>>>>> <package>org.superbiz.foo</package>
>>>>>> <package>org.superbiz.bar</package>
>>>>>> </packages>
>>>>>> </scan>
>>>>>>
>>>>>> With the above you could easily create scan.xml file by hand that
>> would
>>>>> at least be far faster than scanning an entire jar.
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> - Mohammad Nour
>>>> ----
>>>> "Life is like riding a bicycle. To keep your balance you must keep
>> moving"
>>>> - Albert Einstein
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks
>>> - Mohammad Nour
>>> ----
>>> "Life is like riding a bicycle. To keep your balance you must keep
>> moving"
>>> - Albert Einstein
>>
>>
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I think the same.
I think we don't really have any choice regarding the format since we don't
want to bring another lib to do anything more than we need in tomee
webprofile.
It is either properties, plain txt or xml file.
- Romain
2012/2/21 Alan D. Cabrera <li...@toolazydogs.com>
> I think that it would be nicer to have a simple file that all manner of
> tooling can read, e.g. python.
>
> With that said, the XML file format seems simple enough and I doubt that
> any large jar would pose a problem memory or CPU wise. JMHO.
>
>
> Regards,
> Alan
>
>
> On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
>
> > I have one concern, still by having an XML generated and we still like
> > reading only information about such classes and the overhead of reading
> XML
> > in memory in case we have a large one(s).
> >
> > Why not generate a code out of that which is compiled with the jar or
> even
> > added to the an existing jar which will be much faster and this code can
> be
> > based on templates which developers can extend, change or customize.
> >
> > Thoughts ?
> >
> > On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> > nour.mohammad@gmail.com> wrote:
> >
> >>
> >>
> >> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <list@toolazydogs.com
> >wrote:
> >>
> >>> Neat idea.
> >>>
> >>> I would include the configuration information in the scan.xml so that
> >>> tooling would know the criteria used in the scan and decide whether or
> not
> >>> to scan for other annotations or inplementations.
> >>>
> >>> I would also put the scan.xml file in some package specific place like
> >>> META-INF/org/apache/xbean/scan.xml.
> >>>
> >>
> >> +1 on the idea and the additions on Alan
> >>
> >>
> >>>
> >>>
> >>> Regards,
> >>> Alan
> >>>
> >>>
> >>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> >>>
> >>>> We've chatted occasionally on creating a scanning.xml file where
> people
> >>> could setup includes and excludes and, overall, optimize classpath
> scanning.
> >>>>
> >>>> Romain is already busy hacking of course :) Here's the idea for a
> >>> plugin to effectively do the most expensive part of scanning in
> advance:
> >>>>
> >>>> <plugin>
> >>>> <groupId>org.apache.xbean</groupId>
> >>>> <artifactId>maven-xbean-finder-plugin</artifactId>
> >>>> <configuration>
> >>>> <annotations>
> >>>> <annotation>javax.ejb.Stateless</annotation>
> >>>> <annotation>javax.ejb.Stateful</annotation>
> >>>> <annotation>javax.ejb.Singleton</annotation>
> >>>> <annotation>javax.annotation.ManagedBean</annotation>
> >>>> </annotations>
> >>>> <subclasses>
> >>>> <subclass>javax.ws.rs.core.Application</subclass>
> >>>> </subclasses>
> >>>> <implementations>
> >>>>
> >>>
> <implementation>org.apache.openejb.server.ServerService</implementation>
> >>>> </implementations>
> >>>> </configuration>
> >>>> </plugin>
> >>>>
> >>>> With a configuration like the above, the plugin would scan the jar for
> >>> subclasses of javax.ws.rs.core.Application, classes annotated with
> >>> @Stateless, @Singleton, @Stateful and classes that implement
> ServiceService.
> >>>>
> >>>> The result would be a META-INF/scan.xml class that looks like so:
> >>>>
> >>>> <scan>
> >>>> <classes>
> >>>> <class>org.superbiz.Foo</class>
> >>>> <class>org.superbiz.Bar</class>
> >>>> <class>org.superbiz.Baz</class>
> >>>> </classes>
> >>>> </scan>
> >>>>
> >>>> And on the TODO list would be future support for <packages>
> >>>>
> >>>> <scan>
> >>>> <packages>
> >>>> <package>org.superbiz.foo</package>
> >>>> <package>org.superbiz.bar</package>
> >>>> </packages>
> >>>> </scan>
> >>>>
> >>>> With the above you could easily create scan.xml file by hand that
> would
> >>> at least be far faster than scanning an entire jar.
> >>>>
> >>>>
> >>>> Thoughts?
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Thanks
> >> - Mohammad Nour
> >> ----
> >> "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> >> - Albert Einstein
> >>
> >>
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
>
>
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I think that it would be nicer to have a simple file that all manner of tooling can read, e.g. python.
With that said, the XML file format seems simple enough and I doubt that any large jar would pose a problem memory or CPU wise. JMHO.
Regards,
Alan
On Feb 20, 2012, at 4:49 PM, Mohammad Nour El-Din wrote:
> I have one concern, still by having an XML generated and we still like
> reading only information about such classes and the overhead of reading XML
> in memory in case we have a large one(s).
>
> Why not generate a code out of that which is compiled with the jar or even
> added to the an existing jar which will be much faster and this code can be
> based on templates which developers can extend, change or customize.
>
> Thoughts ?
>
> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> nour.mohammad@gmail.com> wrote:
>
>>
>>
>> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>>
>>> Neat idea.
>>>
>>> I would include the configuration information in the scan.xml so that
>>> tooling would know the criteria used in the scan and decide whether or not
>>> to scan for other annotations or inplementations.
>>>
>>> I would also put the scan.xml file in some package specific place like
>>> META-INF/org/apache/xbean/scan.xml.
>>>
>>
>> +1 on the idea and the additions on Alan
>>
>>
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>>>
>>>> We've chatted occasionally on creating a scanning.xml file where people
>>> could setup includes and excludes and, overall, optimize classpath scanning.
>>>>
>>>> Romain is already busy hacking of course :) Here's the idea for a
>>> plugin to effectively do the most expensive part of scanning in advance:
>>>>
>>>> <plugin>
>>>> <groupId>org.apache.xbean</groupId>
>>>> <artifactId>maven-xbean-finder-plugin</artifactId>
>>>> <configuration>
>>>> <annotations>
>>>> <annotation>javax.ejb.Stateless</annotation>
>>>> <annotation>javax.ejb.Stateful</annotation>
>>>> <annotation>javax.ejb.Singleton</annotation>
>>>> <annotation>javax.annotation.ManagedBean</annotation>
>>>> </annotations>
>>>> <subclasses>
>>>> <subclass>javax.ws.rs.core.Application</subclass>
>>>> </subclasses>
>>>> <implementations>
>>>>
>>> <implementation>org.apache.openejb.server.ServerService</implementation>
>>>> </implementations>
>>>> </configuration>
>>>> </plugin>
>>>>
>>>> With a configuration like the above, the plugin would scan the jar for
>>> subclasses of javax.ws.rs.core.Application, classes annotated with
>>> @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
>>>>
>>>> The result would be a META-INF/scan.xml class that looks like so:
>>>>
>>>> <scan>
>>>> <classes>
>>>> <class>org.superbiz.Foo</class>
>>>> <class>org.superbiz.Bar</class>
>>>> <class>org.superbiz.Baz</class>
>>>> </classes>
>>>> </scan>
>>>>
>>>> And on the TODO list would be future support for <packages>
>>>>
>>>> <scan>
>>>> <packages>
>>>> <package>org.superbiz.foo</package>
>>>> <package>org.superbiz.bar</package>
>>>> </packages>
>>>> </scan>
>>>>
>>>> With the above you could easily create scan.xml file by hand that would
>>> at least be far faster than scanning an entire jar.
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> -David
>>>>
>>>
>>>
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>>
>>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Sorry Mohammad but i'm not sure i get your point on executable part?
a kind of serializable thing?
- Romain
2012/2/21 Mohammad Nour El-Din <no...@gmail.com>
> On Tue, Feb 21, 2012 at 11:15 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > isn't it close to our dump descriptor feature?
> >
> > let imagine we can add the dumped descriptor during the build, if the
> > descriptor is "metadata complete" it is the same no?
> >
>
> AFAIU from what David said yes, but I was talking about two different
> aspects here, the descriptive part and the executable one. From one end the
> users will write a simple XML which we can use as is or out of it we
> generate an optimized code to make things faster, but I am not sure if that
> fits or not, any feedback would be appreciated!
>
>
> >
> > - Romain
> >
> >
> > 2012/2/21 Mohammad Nour El-Din <no...@gmail.com>
> >
> > > I have one concern, still by having an XML generated and we still like
> > > reading only information about such classes and the overhead of reading
> > XML
> > > in memory in case we have a large one(s).
> > >
> > > Why not generate a code out of that which is compiled with the jar or
> > even
> > > added to the an existing jar which will be much faster and this code
> can
> > be
> > > based on templates which developers can extend, change or customize.
> > >
> > > Thoughts ?
> > >
> > > On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> > > nour.mohammad@gmail.com> wrote:
> > >
> > > >
> > > >
> > > > On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <
> > list@toolazydogs.com
> > > >wrote:
> > > >
> > > >> Neat idea.
> > > >>
> > > >> I would include the configuration information in the scan.xml so
> that
> > > >> tooling would know the criteria used in the scan and decide whether
> or
> > > not
> > > >> to scan for other annotations or inplementations.
> > > >>
> > > >> I would also put the scan.xml file in some package specific place
> like
> > > >> META-INF/org/apache/xbean/scan.xml.
> > > >>
> > > >
> > > > +1 on the idea and the additions on Alan
> > > >
> > > >
> > > >>
> > > >>
> > > >> Regards,
> > > >> Alan
> > > >>
> > > >>
> > > >> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> > > >>
> > > >> > We've chatted occasionally on creating a scanning.xml file where
> > > people
> > > >> could setup includes and excludes and, overall, optimize classpath
> > > scanning.
> > > >> >
> > > >> > Romain is already busy hacking of course :) Here's the idea for a
> > > >> plugin to effectively do the most expensive part of scanning in
> > advance:
> > > >> >
> > > >> > <plugin>
> > > >> > <groupId>org.apache.xbean</groupId>
> > > >> > <artifactId>maven-xbean-finder-plugin</artifactId>
> > > >> > <configuration>
> > > >> > <annotations>
> > > >> > <annotation>javax.ejb.Stateless</annotation>
> > > >> > <annotation>javax.ejb.Stateful</annotation>
> > > >> > <annotation>javax.ejb.Singleton</annotation>
> > > >> > <annotation>javax.annotation.ManagedBean</annotation>
> > > >> > </annotations>
> > > >> > <subclasses>
> > > >> > <subclass>javax.ws.rs.core.Application</subclass>
> > > >> > </subclasses>
> > > >> > <implementations>
> > > >> >
> > > >>
> > >
> <implementation>org.apache.openejb.server.ServerService</implementation>
> > > >> > </implementations>
> > > >> > </configuration>
> > > >> > </plugin>
> > > >> >
> > > >> > With a configuration like the above, the plugin would scan the jar
> > for
> > > >> subclasses of javax.ws.rs.core.Application, classes annotated with
> > > >> @Stateless, @Singleton, @Stateful and classes that implement
> > > ServiceService.
> > > >> >
> > > >> > The result would be a META-INF/scan.xml class that looks like so:
> > > >> >
> > > >> > <scan>
> > > >> > <classes>
> > > >> > <class>org.superbiz.Foo</class>
> > > >> > <class>org.superbiz.Bar</class>
> > > >> > <class>org.superbiz.Baz</class>
> > > >> > </classes>
> > > >> > </scan>
> > > >> >
> > > >> > And on the TODO list would be future support for <packages>
> > > >> >
> > > >> > <scan>
> > > >> > <packages>
> > > >> > <package>org.superbiz.foo</package>
> > > >> > <package>org.superbiz.bar</package>
> > > >> > </packages>
> > > >> > </scan>
> > > >> >
> > > >> > With the above you could easily create scan.xml file by hand that
> > > would
> > > >> at least be far faster than scanning an entire jar.
> > > >> >
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> >
> > > >> > -David
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Thanks
> > > > - Mohammad Nour
> > > > ----
> > > > "Life is like riding a bicycle. To keep your balance you must keep
> > > moving"
> > > > - Albert Einstein
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> > > ----
> > > "Life is like riding a bicycle. To keep your balance you must keep
> > moving"
> > > - Albert Einstein
> > >
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On Tue, Feb 21, 2012 at 11:15 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> isn't it close to our dump descriptor feature?
>
> let imagine we can add the dumped descriptor during the build, if the
> descriptor is "metadata complete" it is the same no?
>
AFAIU from what David said yes, but I was talking about two different
aspects here, the descriptive part and the executable one. From one end the
users will write a simple XML which we can use as is or out of it we
generate an optimized code to make things faster, but I am not sure if that
fits or not, any feedback would be appreciated!
>
> - Romain
>
>
> 2012/2/21 Mohammad Nour El-Din <no...@gmail.com>
>
> > I have one concern, still by having an XML generated and we still like
> > reading only information about such classes and the overhead of reading
> XML
> > in memory in case we have a large one(s).
> >
> > Why not generate a code out of that which is compiled with the jar or
> even
> > added to the an existing jar which will be much faster and this code can
> be
> > based on templates which developers can extend, change or customize.
> >
> > Thoughts ?
> >
> > On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> > nour.mohammad@gmail.com> wrote:
> >
> > >
> > >
> > > On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <
> list@toolazydogs.com
> > >wrote:
> > >
> > >> Neat idea.
> > >>
> > >> I would include the configuration information in the scan.xml so that
> > >> tooling would know the criteria used in the scan and decide whether or
> > not
> > >> to scan for other annotations or inplementations.
> > >>
> > >> I would also put the scan.xml file in some package specific place like
> > >> META-INF/org/apache/xbean/scan.xml.
> > >>
> > >
> > > +1 on the idea and the additions on Alan
> > >
> > >
> > >>
> > >>
> > >> Regards,
> > >> Alan
> > >>
> > >>
> > >> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> > >>
> > >> > We've chatted occasionally on creating a scanning.xml file where
> > people
> > >> could setup includes and excludes and, overall, optimize classpath
> > scanning.
> > >> >
> > >> > Romain is already busy hacking of course :) Here's the idea for a
> > >> plugin to effectively do the most expensive part of scanning in
> advance:
> > >> >
> > >> > <plugin>
> > >> > <groupId>org.apache.xbean</groupId>
> > >> > <artifactId>maven-xbean-finder-plugin</artifactId>
> > >> > <configuration>
> > >> > <annotations>
> > >> > <annotation>javax.ejb.Stateless</annotation>
> > >> > <annotation>javax.ejb.Stateful</annotation>
> > >> > <annotation>javax.ejb.Singleton</annotation>
> > >> > <annotation>javax.annotation.ManagedBean</annotation>
> > >> > </annotations>
> > >> > <subclasses>
> > >> > <subclass>javax.ws.rs.core.Application</subclass>
> > >> > </subclasses>
> > >> > <implementations>
> > >> >
> > >>
> > <implementation>org.apache.openejb.server.ServerService</implementation>
> > >> > </implementations>
> > >> > </configuration>
> > >> > </plugin>
> > >> >
> > >> > With a configuration like the above, the plugin would scan the jar
> for
> > >> subclasses of javax.ws.rs.core.Application, classes annotated with
> > >> @Stateless, @Singleton, @Stateful and classes that implement
> > ServiceService.
> > >> >
> > >> > The result would be a META-INF/scan.xml class that looks like so:
> > >> >
> > >> > <scan>
> > >> > <classes>
> > >> > <class>org.superbiz.Foo</class>
> > >> > <class>org.superbiz.Bar</class>
> > >> > <class>org.superbiz.Baz</class>
> > >> > </classes>
> > >> > </scan>
> > >> >
> > >> > And on the TODO list would be future support for <packages>
> > >> >
> > >> > <scan>
> > >> > <packages>
> > >> > <package>org.superbiz.foo</package>
> > >> > <package>org.superbiz.bar</package>
> > >> > </packages>
> > >> > </scan>
> > >> >
> > >> > With the above you could easily create scan.xml file by hand that
> > would
> > >> at least be far faster than scanning an entire jar.
> > >> >
> > >> >
> > >> > Thoughts?
> > >> >
> > >> >
> > >> > -David
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> > > ----
> > > "Life is like riding a bicycle. To keep your balance you must keep
> > moving"
> > > - Albert Einstein
> > >
> > >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
> >
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Romain Manni-Bucau <rm...@gmail.com>.
isn't it close to our dump descriptor feature?
let imagine we can add the dumped descriptor during the build, if the
descriptor is "metadata complete" it is the same no?
- Romain
2012/2/21 Mohammad Nour El-Din <no...@gmail.com>
> I have one concern, still by having an XML generated and we still like
> reading only information about such classes and the overhead of reading XML
> in memory in case we have a large one(s).
>
> Why not generate a code out of that which is compiled with the jar or even
> added to the an existing jar which will be much faster and this code can be
> based on templates which developers can extend, change or customize.
>
> Thoughts ?
>
> On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
> nour.mohammad@gmail.com> wrote:
>
> >
> >
> > On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <list@toolazydogs.com
> >wrote:
> >
> >> Neat idea.
> >>
> >> I would include the configuration information in the scan.xml so that
> >> tooling would know the criteria used in the scan and decide whether or
> not
> >> to scan for other annotations or inplementations.
> >>
> >> I would also put the scan.xml file in some package specific place like
> >> META-INF/org/apache/xbean/scan.xml.
> >>
> >
> > +1 on the idea and the additions on Alan
> >
> >
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >>
> >> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> >>
> >> > We've chatted occasionally on creating a scanning.xml file where
> people
> >> could setup includes and excludes and, overall, optimize classpath
> scanning.
> >> >
> >> > Romain is already busy hacking of course :) Here's the idea for a
> >> plugin to effectively do the most expensive part of scanning in advance:
> >> >
> >> > <plugin>
> >> > <groupId>org.apache.xbean</groupId>
> >> > <artifactId>maven-xbean-finder-plugin</artifactId>
> >> > <configuration>
> >> > <annotations>
> >> > <annotation>javax.ejb.Stateless</annotation>
> >> > <annotation>javax.ejb.Stateful</annotation>
> >> > <annotation>javax.ejb.Singleton</annotation>
> >> > <annotation>javax.annotation.ManagedBean</annotation>
> >> > </annotations>
> >> > <subclasses>
> >> > <subclass>javax.ws.rs.core.Application</subclass>
> >> > </subclasses>
> >> > <implementations>
> >> >
> >>
> <implementation>org.apache.openejb.server.ServerService</implementation>
> >> > </implementations>
> >> > </configuration>
> >> > </plugin>
> >> >
> >> > With a configuration like the above, the plugin would scan the jar for
> >> subclasses of javax.ws.rs.core.Application, classes annotated with
> >> @Stateless, @Singleton, @Stateful and classes that implement
> ServiceService.
> >> >
> >> > The result would be a META-INF/scan.xml class that looks like so:
> >> >
> >> > <scan>
> >> > <classes>
> >> > <class>org.superbiz.Foo</class>
> >> > <class>org.superbiz.Bar</class>
> >> > <class>org.superbiz.Baz</class>
> >> > </classes>
> >> > </scan>
> >> >
> >> > And on the TODO list would be future support for <packages>
> >> >
> >> > <scan>
> >> > <packages>
> >> > <package>org.superbiz.foo</package>
> >> > <package>org.superbiz.bar</package>
> >> > </packages>
> >> > </scan>
> >> >
> >> > With the above you could easily create scan.xml file by hand that
> would
> >> at least be far faster than scanning an entire jar.
> >> >
> >> >
> >> > Thoughts?
> >> >
> >> >
> >> > -David
> >> >
> >>
> >>
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
I have one concern, still by having an XML generated and we still like
reading only information about such classes and the overhead of reading XML
in memory in case we have a large one(s).
Why not generate a code out of that which is compiled with the jar or even
added to the an existing jar which will be much faster and this code can be
based on templates which developers can extend, change or customize.
Thoughts ?
On Tue, Feb 21, 2012 at 1:46 AM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:
>
>
> On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>
>> Neat idea.
>>
>> I would include the configuration information in the scan.xml so that
>> tooling would know the criteria used in the scan and decide whether or not
>> to scan for other annotations or inplementations.
>>
>> I would also put the scan.xml file in some package specific place like
>> META-INF/org/apache/xbean/scan.xml.
>>
>
> +1 on the idea and the additions on Alan
>
>
>>
>>
>> Regards,
>> Alan
>>
>>
>> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>>
>> > We've chatted occasionally on creating a scanning.xml file where people
>> could setup includes and excludes and, overall, optimize classpath scanning.
>> >
>> > Romain is already busy hacking of course :) Here's the idea for a
>> plugin to effectively do the most expensive part of scanning in advance:
>> >
>> > <plugin>
>> > <groupId>org.apache.xbean</groupId>
>> > <artifactId>maven-xbean-finder-plugin</artifactId>
>> > <configuration>
>> > <annotations>
>> > <annotation>javax.ejb.Stateless</annotation>
>> > <annotation>javax.ejb.Stateful</annotation>
>> > <annotation>javax.ejb.Singleton</annotation>
>> > <annotation>javax.annotation.ManagedBean</annotation>
>> > </annotations>
>> > <subclasses>
>> > <subclass>javax.ws.rs.core.Application</subclass>
>> > </subclasses>
>> > <implementations>
>> >
>> <implementation>org.apache.openejb.server.ServerService</implementation>
>> > </implementations>
>> > </configuration>
>> > </plugin>
>> >
>> > With a configuration like the above, the plugin would scan the jar for
>> subclasses of javax.ws.rs.core.Application, classes annotated with
>> @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
>> >
>> > The result would be a META-INF/scan.xml class that looks like so:
>> >
>> > <scan>
>> > <classes>
>> > <class>org.superbiz.Foo</class>
>> > <class>org.superbiz.Bar</class>
>> > <class>org.superbiz.Baz</class>
>> > </classes>
>> > </scan>
>> >
>> > And on the TODO list would be future support for <packages>
>> >
>> > <scan>
>> > <packages>
>> > <package>org.superbiz.foo</package>
>> > <package>org.superbiz.bar</package>
>> > </packages>
>> > </scan>
>> >
>> > With the above you could easily create scan.xml file by hand that would
>> at least be far faster than scanning an entire jar.
>> >
>> >
>> > Thoughts?
>> >
>> >
>> > -David
>> >
>>
>>
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
> Neat idea.
>
> I would include the configuration information in the scan.xml so that
> tooling would know the criteria used in the scan and decide whether or not
> to scan for other annotations or inplementations.
>
> I would also put the scan.xml file in some package specific place like
> META-INF/org/apache/xbean/scan.xml.
>
+1 on the idea and the additions on Alan
>
>
> Regards,
> Alan
>
>
> On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
>
> > We've chatted occasionally on creating a scanning.xml file where people
> could setup includes and excludes and, overall, optimize classpath scanning.
> >
> > Romain is already busy hacking of course :) Here's the idea for a
> plugin to effectively do the most expensive part of scanning in advance:
> >
> > <plugin>
> > <groupId>org.apache.xbean</groupId>
> > <artifactId>maven-xbean-finder-plugin</artifactId>
> > <configuration>
> > <annotations>
> > <annotation>javax.ejb.Stateless</annotation>
> > <annotation>javax.ejb.Stateful</annotation>
> > <annotation>javax.ejb.Singleton</annotation>
> > <annotation>javax.annotation.ManagedBean</annotation>
> > </annotations>
> > <subclasses>
> > <subclass>javax.ws.rs.core.Application</subclass>
> > </subclasses>
> > <implementations>
> >
> <implementation>org.apache.openejb.server.ServerService</implementation>
> > </implementations>
> > </configuration>
> > </plugin>
> >
> > With a configuration like the above, the plugin would scan the jar for
> subclasses of javax.ws.rs.core.Application, classes annotated with
> @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
> >
> > The result would be a META-INF/scan.xml class that looks like so:
> >
> > <scan>
> > <classes>
> > <class>org.superbiz.Foo</class>
> > <class>org.superbiz.Bar</class>
> > <class>org.superbiz.Baz</class>
> > </classes>
> > </scan>
> >
> > And on the TODO list would be future support for <packages>
> >
> > <scan>
> > <packages>
> > <package>org.superbiz.foo</package>
> > <package>org.superbiz.bar</package>
> > </packages>
> > </scan>
> >
> > With the above you could easily create scan.xml file by hand that would
> at least be far faster than scanning an entire jar.
> >
> >
> > Thoughts?
> >
> >
> > -David
> >
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: Annotation scanning plugin
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Neat idea.
I would include the configuration information in the scan.xml so that tooling would know the criteria used in the scan and decide whether or not to scan for other annotations or inplementations.
I would also put the scan.xml file in some package specific place like META-INF/org/apache/xbean/scan.xml.
Regards,
Alan
On Feb 20, 2012, at 2:40 PM, David Blevins wrote:
> We've chatted occasionally on creating a scanning.xml file where people could setup includes and excludes and, overall, optimize classpath scanning.
>
> Romain is already busy hacking of course :) Here's the idea for a plugin to effectively do the most expensive part of scanning in advance:
>
> <plugin>
> <groupId>org.apache.xbean</groupId>
> <artifactId>maven-xbean-finder-plugin</artifactId>
> <configuration>
> <annotations>
> <annotation>javax.ejb.Stateless</annotation>
> <annotation>javax.ejb.Stateful</annotation>
> <annotation>javax.ejb.Singleton</annotation>
> <annotation>javax.annotation.ManagedBean</annotation>
> </annotations>
> <subclasses>
> <subclass>javax.ws.rs.core.Application</subclass>
> </subclasses>
> <implementations>
> <implementation>org.apache.openejb.server.ServerService</implementation>
> </implementations>
> </configuration>
> </plugin>
>
> With a configuration like the above, the plugin would scan the jar for subclasses of javax.ws.rs.core.Application, classes annotated with @Stateless, @Singleton, @Stateful and classes that implement ServiceService.
>
> The result would be a META-INF/scan.xml class that looks like so:
>
> <scan>
> <classes>
> <class>org.superbiz.Foo</class>
> <class>org.superbiz.Bar</class>
> <class>org.superbiz.Baz</class>
> </classes>
> </scan>
>
> And on the TODO list would be future support for <packages>
>
> <scan>
> <packages>
> <package>org.superbiz.foo</package>
> <package>org.superbiz.bar</package>
> </packages>
> </scan>
>
> With the above you could easily create scan.xml file by hand that would at least be far faster than scanning an entire jar.
>
>
> Thoughts?
>
>
> -David
>