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 >> >> >> ----- 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.com>wrote: >>> >>>> 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 >>>> >> > <scope>compile >>>> >> > >>>> >> > *) impl - does the actual work, not intended to be used in >>> customer >>>> >> > projects diretly. Thus Maven <scope>runtime 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 with this. >>>> >> >>>> >> >>>> >> > >>>> >> > >>>> >> > Are there any Class naming conventions/rules you like to >>> introduce? >>>> Pros, >>>> >> > cons? >>>> >> > >>>> >> >>>> >> I think standard Java naming conventions should be fine. >>>> >> >>>> >> >>>> >> > >>>> >> > >>>> >> > LieGrue, >>>> >> > strub >>>> >> > >>>> >> > >>>> >> >>>> >>>> >>>> >>>> -- >>>> Jakob Korherr >>>> >>>> blog: http://www.jakobk.com >>>> twitter: http://twitter.com/jakobkorherr >>>> work: http://www.irian.at >>>> >>> >>> >>> >>> -- >>> Jason Porter >>> http://lightguard-jp.blogspot.com >>> http://twitter.com/lightguardjp >>> >>> Software Engineer >>> Open Source Advocate >>> Author of Seam Catch - Next Generation Java Exception Handling >>> >>> PGP key id: 926CCFF5 >>> PGP key available at: keyserver.net, pgp.mit.edu >>> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf
