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). 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
