deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@apache.org>
Subject Re: basic decisions - package and class naming
Date Fri, 30 Dec 2011 10:47:17 GMT
On Tue, Dec 27, 2011 at 10:20 PM, Mark Struberg <struberg@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 <matzew@apache.org>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <struberg@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 <struberg@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 <antoine@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
>> <struberg@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

Mime
View raw message