I wanted to get started but it looks like you guys beat me on this one. More inline.
On Fri, Dec 9, 2011 at 03:21, Mark Struberg <[email protected]> wrote: > Hi folks! > > Welcome on board fellow CDI geeks! > > I'd like to discuss how we kick off the work (the first steps are always > the hardest). > > 1.) > Since we will get 1 git repo for the start, and since with using git, it's > almost the most important part at all, I'd like to start the discussion > with how we slice the cake. > Means which directory structure we like to use for the project layout. > > I wrote up a first proposal into our official Wiki > https://cwiki.apache.org/confluence/display/DeltaSpike/Project+Structure I like what I see for the most part, the one section that I'd like to share our findings in Seam which will help is with the testing. We've found it much easier to have all of the tests in one section and separate them out by package structure. We can then exclude the tests we don't want in a surefire configuration based on profile. Pros - Easy to understand - Allows tests to be run within the IDE (this was something we were striving to do all along, helps with the dev turnaround) - Simple - More DRY than multi-module Cons - Little extra setup - Requires extra maven profiles - Not all the tests can be run in a single run The last con we decided would be okay because Jenkins would be running all of the tests anyway. We decided that for developers the core tests for them to execute before committing would be embedded CDI containers and standard unit tests. They catch most of the problems and they're fast. 2.) > We need to discuss which artifacts we produce. > So far we had good results with api+impl (+optional spi?) for each 'area' > and bundle them together at a later stage with the maven-shade-plugin. > We really need to focus on an SPI IMO. Because we're only going to be coding to the javax.* interfaces we need to come up with a good SPI / hooks / extension points to allow others to add their own proprietary extensions (e.g. CODI, OpenJPA, Hibernate, MyFaces, etc) > 3.) > Which 'areas' or modules do we like to forsee? > Current suggestion is to split those based on their dependencies. A user > shall not be forced to add some library to his project which he isn't going > to use. E.g. it should not be required to add javax.faces-api for writing a > pure JavaSE project. Thus the following candidates exist: > * core > * jsf12 > * jsf20 > * jpa > How much do we want to get into other specs like JSR-107, or any other Java EE 7 specs? Will those separate modules as well? Will each spec have it's own module (e.g. Bean Validation)? +1 for SE > How do we treat future CDI-1.0 vs CDI-1.1 changes? > Again, maybe another module? > 4.) > How we do our documentation. > The wiki works, though I'm not a big fan of the wiki for documentation, I much prefer it within the project sources, it also makes it easy to export, one place for contributors to go, it's nicely versioned, etc. I've looked at Sphinx (http://sphinx.pocoo.org/) and other markup solutions as well. Shpinx looks nice, has great extension points and output is great. It's used quite heavily in the python community. Of course there's always DocBook, but I don't think that's a great way to go personally, too difficult for contributors > We might finally split up the discussion in single mail threads, but I > like to kick off the think process at least ;) > > LieGrue, > strub > -- 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
