deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: First steps
Date Fri, 09 Dec 2011 21:49:43 GMT
On Fri, Dec 9, 2011 at 14:10, Mark Struberg <struberg@yahoo.de> wrote:

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

Partially, the new Arquillian page is done with awestruct (
http://awestruct.org/). That could be done as well, though it's more of a
web site / blog creation / aggregation tool, not specifically geared toward
documentation.


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



-- 
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message