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
