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
