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.
Same is true for shading. much easier to just include the blabla.api package
than to have to explicitly list class names...
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
>
