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
