: Romain Manni-Bucau rmannibu...@gmail.com
To: Mark Struberg strub...@yahoo.de; dev@openejb.apache.org
Cc:
Sent: Monday, February 27, 2012 12:41 AM
Subject: Re: Annotation scanning plugin
Not so agree.
You can use it today without circular dep. Same tmr. Just a repo question.
From a code
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
...
LieGrue,
strub
- Original Message -
From: Karan Malhi karan.ma...@gmail.com
To: dev@openejb.apache.org
Cc:
Sent: Tuesday, February 21, 2012 9:02 PM
Subject: Re: Annotation scanning plugin
Was wondering if we could use tomee instead of xbean in the groupid. Also
the artifact
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
On Feb 21, 2012, at 8:29 AM, Romain Manni-Bucau wrote:
- Romain
2012/2/21 Alan D. Cabrera l...@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).
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
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).
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 l...@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
On Wed, Feb 22, 2012 at 11:07 PM, Mohammad Nour El-Din
nour.moham...@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 rmannibu...@gmail.com
wrote:
Hmm, not sure i follow too,
We just spoke about
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
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 nour.moham...@gmail.com
I have one concern, still by having an XML generated and we
On Tue, Feb 21, 2012 at 11:15 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
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
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 nour.moham...@gmail.com
On Tue, Feb 21, 2012 at 11:15 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
isn't it close to our dump descriptor
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
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 l...@toolazydogs.com
I think that
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
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
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 l...@toolazydogs.com wrote:
I like XML because we can have enforcement via schema.
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 daniel.hais...@googlemail.com
There's JSON schema [1] for instance but I guess that pulls in another
dependency...
[1]
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
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
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
- Romain
2012/2/21 Alan D. Cabrera l...@toolazydogs.com
On Feb 21, 2012, at 7:40 AM, Romain Manni-Bucau wrote:
i created a module xbean-xml in maven plugins to be able to commit but it
should be in xbean i think (the mvn plugin too by the way).
the example needs openjpa (not jpa ;))
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
groupIdorg.apache.openejb/groupId
version0.0.1-SNAPSHOT/version
artifactIdspi-helper-maven-plugin/artifactId
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
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:
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
On Tue, Feb 21, 2012 at 12:32 AM, Alan D. Cabrera l...@toolazydogs.comwrote:
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
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
29 matches
Mail list logo
