On Tue, Dec 27, 2011 at 10:20 PM, Mark Struberg strub...@yahoo.de wrote:
Hi Matze!
Arquillian and shading both work with filters.
With Arquillian you create your test @Deployment by adding classes to it. You
can do this by saying .addAsPackage(blabla);
but if the package blabla also contains the impl then you would need to
either include or exclude all this stuff manually!
It's much easier if you can just type addAsPackage(blabla.api); and you're
done.
awesome... :-)
Same is true for shading. much easier to just include the blabla.api package
than to have to explicitly list class names...
I see, too bad, but hey!
LieGrue,
strub
- Original Message -
From: Matthias Wessendorf mat...@apache.org
To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
Cc:
Sent: Wednesday, December 21, 2011 2:29 PM
Subject: Re: basic decisions - package and class naming
On Wed, Dec 21, 2011 at 12:00 PM, Mark Struberg strub...@yahoo.de wrote:
As I see it we have 3 different options:
1.) .api.* + .impl.* because it's more easy to 'grab' any api
package in e.g. an Arquillian test. If we don't have the modulename.api
package name, then we cannot do something like this in Arquillian:
Shrinkwrap.createArchive(JavaArchive.class).addPackages(true,
...modulename.api);
Without the explicit .api package name we would not be able to add just the
api module without also adding all the impl stuff as well. (This is needed
if we
e.g. like to test single features of the impl module).
Ok, I don't get the _why_;
Do you mind to explain it to me (I know nothing about Arquillian and
the shade plugin:-))
-M
The very same will hit us with the maven-shade-plugin where we would not be
able to explicitely shade all classes of the api modules.
thus a +1 for this.
2.) noting + '.internal'
possible, but with the downsides as noted above.
-0.5 thus.
LieGrue,
strub
- Original Message -
From: Antoine Sabot-Durand anto...@sabot-durand.net
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Tuesday, December 20, 2011 11:55 AM
Subject: Re: basic decisions - package and class naming
Social API:
org.apache.deltaspike.social.* +1
the implementation
org.apache.deltaspike.social.impl.* +0 (we don't have this in Seam
and have
the distinction in module name, but it's not a big deal for me)
@SPI = +0 I'm not sure to use it but why not.
Antoine SABOT-DURAND
Le 15 déc. 2011 à 18:43, Matthias Wessendorf a écrit :
On Thu, Dec 15, 2011 at 3:31 PM, Mark Struberg
strub...@yahoo.de
wrote:
Well, we are now hitting the wall - so we need a resolution
asap.
For the core module we would have
for core-api:
org.apache.deltaspike.core. ?
for core-impl:
org.apache.deltaspike.core.impl. ?
yes!
And/or
JPA API:
org.apache.deltaspike.jpa.*
the implementation
org.apache.deltaspike.jpa.impl.*
@SPI = fine for me!
But please NO 'api' inside of the pkg names; (impl is a
must, IMO
(fine in naming it 'internal', but I guess impl is more
'standard')
-M
The problem is that by omitting the .api. package, we
don't have
any good handle to include/exclude all the classes from core.api,
jsf.api, etc
in the maven-shade-plugin or any other include/exclude mechanism. That
could
hurt a bit.
Matze, you have not been fond of the api package, what do you
suggest
as an alternative option?
LieGrue,
strub
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
