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