Re: basic decisions - package and class naming
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
Re: basic decisions - package and class naming
What would the drawbacks be of putting the api/impl code in completely separate modules? Seemingly this would solve the packaging problems and the impl jar could simply shade the api jar. Matt On Wed, Dec 21, 2011 at 11:04 AM, Jason Porter lightguard...@gmail.com wrote: +1 I'm fine with this. Sent from my iPhone On Dec 21, 2011, at 4:05, Gerhard Petracek gerhard.petra...@gmail.com wrote: i agree with mark. regards, gerhard 2011/12/21 Mark Struberg strub...@yahoo.de 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
Re: basic decisions - package and class naming
i agree with mark. regards, gerhard 2011/12/21 Mark Struberg strub...@yahoo.de 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
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
Re: basic decisions - package and class naming
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 - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, December 12, 2011 7:21 PM Subject: Re: basic decisions - package and class naming I'm good for the package naming, include the JSF split, if we're going to be cutting artifacts via the shade plugin (and we only get one repo so everything has to be done in one place) that will make it much easier. Also it will help users know what they're using when the send in bug reports. If they're JSF2 stuff in a JSF12 project that'll be much easier to spot. If we don't have an api package then I certainly want to see internal (I like seeing that in the package better than impl, imo it means more and it certainly signifies to me that those classes are off limits for usage by the user). I'd like to see SPI though, I think we'll need that and it more clearly demarcates for extension writers what they should be using. Anything we can do to make things easier for users w/o having to explicitly write globs of documentation to explain something (in other words making things self documented) is a huge plus in my book. On Mon, Dec 12, 2011 at 05:47, Jakob Korherr jakob.korh...@gmail.comwrote: Hi, +1 for the package names. IMO we can drop the api package, but we really should keep the impl (or internal) package. Otherwise - as Gerhard stated - users will start to use implementation classes without even noticing (remember: not everyone uses impl-dependencies with scope=runtime). Regards, Jakob 2011/12/12 Gerhard Petracek gpetra...@apache.org: @package names: +1 @shane: currently we don't have issues with it (see what we are doing in codi with the shade plugin) to skip 'api' as package would mean that it might be harder to use our bundles (e.g. extval doesn't have api/impl packages and users started to use impl classes, utils,... at least until we marked them as internal). +/- 0 @other rules: no names which start with an underscore regards, gerhard 2011/12/12 Shane Bryzak sbry...@gmail.com On Mon, Dec 12, 2011 at 9:24 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! Back to work after being sick for a week. I think it's time to start hacking on DeltaSpike! But before we do so, I'd like to clarify a few basic things a.) package names I'd suggest org.apache.deltaspike.core.* for our core stuff org.apache.deltaspike.jpa.* for JPA +1 for the org.apache.deltaspike package prefix, followed by the module name. org.apache.deltaspike.jsf.jsf12.* for JSF-1.2 org.apache.deltaspike.jsf.jsf20.* for JSF-2.0, etc -1 for the separation of JSF packages, I think this may cause problems longer term, especially when we get JSF3, JSF4 etc. The way I would handle this is to have a separate module for each JSF version, but re-use the org.apache.deltaspike.jsf package name. In general most of our project parts will contain the following 3 sub- parts *) api - the parts meant to be imported in customer projects with Maven scopecompile *) impl - does the actual work, not intended to be used in customer projects diretly. Thus Maven scoperuntime only. *) spi - parts meant to be used for extending the default functionality. Up for discussion, not sure if we really need it! This might also be done directly in impl, users can still Matze mentioned that he doesn't like to have 'api' in the package name. What do you like to use instead to distinguish between those? Having an own package name probably makes it easier to use the maven-shade-plugin. Any opinions? I would prefer not to have 'api' or 'impl' in the package name either. We never had them in any of the Seam modules that I'm aware of, and there was no problem
