deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: First steps
Date Fri, 09 Dec 2011 21:10:07 GMT
@tests: sounds good to me. There is always a back and forth between packing all in one module
vs splitting out functionality. For the unit tests directly at the modules this sounds really
good. The setup of the IntegrationTest suite can be discussed later on.

@documentation is this the stuff you wrote the new arquillian page with? How is it being maintained?
just checked into SCM?

Please also check the wiki page Gerhard did create:
https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking

LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Friday, December 9, 2011 7:48 PM
> Subject: Re: First steps
> 
> hi jason,
> 
> @tests:
> interesting idea. we should also think about manila (it
> extends arquillian - btw. those features might be interesting
> for arquillian itself).
> the most important part for me is: no c&p of tests for x target
> environments (and the only difference is the configuration).
> 
> @maven profiles:
> in codi we just used them to exclude playground examples (by default) and
> webapp tests which have to use snapshot dependencies (because it isn't
> allowed for releases). everything else works just with: mvn clean install
> in a single run.
> mark is maven committer and our maven expert -> we shouldn't face 
> blocking
> problems.
> 
> @spi:
> +1 (codi also has a rich spi.)
> 
> @modules:
> cdi is our "core-spec." like jsf is the "core-spec." for 
> myfaces projects.
> imo we shouldn't provide multiple modules for different cdi versions (see
> my previous suggestion), but we can do that for all other specs.
> e.g. at codi we have a jsf12 and a jsf20 module. as much as possible is
> pushed to the base module which is the jsf12 module. everything else (e.g.
> special features for jsf2.x or classes which have to implement new apis) is
> located in the jsf2 module. in the end the content of the jsf12 module gets
> shaded into the jar of the jsf2 module. everything which has to be replaced
> (by the content of the jsf2 module) is configured via @Specializes or
> @Alternative. that worked pretty well for us!
> 
> a related topic we have to discuss is: "general concepts" (which are
> independent of a concrete technology).
> in codi we have apis which represent general concepts in the >core< (e.g.
> @WindowScoped,...). this approach replaces the ~complex framework-adapter
> concept which was used in myfaces orchestra.
> that means e.g.: a module for jsf can use such an api but it's also
> possible to use the same api for modules for/of other web-frameworks (if
> there is a module for it). however, sometimes the term "general 
> concept"
> isn't easy to define.
> 
> @documentation:
> interesting suggestion. imo we can collect such suggestions in our
> confluence space.
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2011/12/9 Jason Porter <lightguard.jp@gmail.com>
> 
>>  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 <struberg@yahoo.de> 
> 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
>> 
> 

Mime
View raw message