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
