You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Mark Struberg <st...@yahoo.de> on 2011/12/09 11:21:51 UTC
First steps
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
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.
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 do we treat future CDI-1.0 vs CDI-1.1 changes?
4.)
How we do our documentation.
We might finally split up the discussion in single mail threads, but I like to kick off the think process at least ;)
LieGrue,
strub
Re: First steps
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for including it in our discussions. :)
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 Matthias Wessendorf <ma...@apache.org>
> lol
>
> I mean the 'api' w/in the api - which is IMO awful
>
> Sent from my iPhone
>
> On 09.12.2011, at 12:52, Gerhard Petracek <ge...@gmail.com>
> wrote:
>
> > hi matthias,
> >
> > myfaces extcdi (aka codi) is a sub-project. -> with deltaspike we have a
> > different situation. -> there won't be that long package names.
> >
> > 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 Matthias Wessendorf <ma...@apache.org>
> >
> >> re #3:
> >>
> >> please let's avoid awful package names like:
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/api/src/main/java/org/apache/myfaces/extensions/cdi/jpa/api/
> >>
> >> thx,
> >> Matthias
> >>
> >> On Fri, Dec 9, 2011 at 11:49 AM, Gerhard Petracek
> >> <ge...@gmail.com> wrote:
> >>> hi @ all,
> >>>
> >>> @#1:
> >>> +1 for the basic idea
> >>>
> >>> @#2:
> >>> +1 for api + impl.
> >>> @separated spi module: +0
> >>>
> >>> @#3
> >>> +1
> >>> @versions of cdi: at myfaces the latest spec. version is used in the
> >>> trunk and all previous versions are branches. since that works pretty
> >> well,
> >>> +1 for handling it that way (for sure with the corresponding concepts
> of
> >>> git).
> >>>
> >>> @#4
> >>> at least for our reports,... we have a confluence space[1].
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>> [1] http://cwiki.apache.org/confluence/display/DeltaSpike
> >>>
> >>>
> >>>
> >>> 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 Mark Struberg <st...@yahoo.de>
> >>>
> >>>> 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
> >>>>
> >>>> 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.
> >>>>
> >>>> 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 do we treat future CDI-1.0 vs CDI-1.1 changes?
> >>>>
> >>>>
> >>>> 4.)
> >>>> How we do our documentation.
> >>>>
> >>>>
> >>>> We might finally split up the discussion in single mail threads, but I
> >>>> like to kick off the think process at least ;)
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >>
>
Re: First steps
Posted by Matthias Wessendorf <ma...@apache.org>.
lol
I mean the 'api' w/in the api - which is IMO awful
Sent from my iPhone
On 09.12.2011, at 12:52, Gerhard Petracek <ge...@gmail.com> wrote:
> hi matthias,
>
> myfaces extcdi (aka codi) is a sub-project. -> with deltaspike we have a
> different situation. -> there won't be that long package names.
>
> 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 Matthias Wessendorf <ma...@apache.org>
>
>> re #3:
>>
>> please let's avoid awful package names like:
>>
>> http://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/api/src/main/java/org/apache/myfaces/extensions/cdi/jpa/api/
>>
>> thx,
>> Matthias
>>
>> On Fri, Dec 9, 2011 at 11:49 AM, Gerhard Petracek
>> <ge...@gmail.com> wrote:
>>> hi @ all,
>>>
>>> @#1:
>>> +1 for the basic idea
>>>
>>> @#2:
>>> +1 for api + impl.
>>> @separated spi module: +0
>>>
>>> @#3
>>> +1
>>> @versions of cdi: at myfaces the latest spec. version is used in the
>>> trunk and all previous versions are branches. since that works pretty
>> well,
>>> +1 for handling it that way (for sure with the corresponding concepts of
>>> git).
>>>
>>> @#4
>>> at least for our reports,... we have a confluence space[1].
>>>
>>> regards,
>>> gerhard
>>>
>>> [1] http://cwiki.apache.org/confluence/display/DeltaSpike
>>>
>>>
>>>
>>> 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 Mark Struberg <st...@yahoo.de>
>>>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>> 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 do we treat future CDI-1.0 vs CDI-1.1 changes?
>>>>
>>>>
>>>> 4.)
>>>> How we do our documentation.
>>>>
>>>>
>>>> We might finally split up the discussion in single mail threads, but I
>>>> like to kick off the think process at least ;)
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
Re: First steps
Posted by Gerhard Petracek <ge...@gmail.com>.
hi matthias,
myfaces extcdi (aka codi) is a sub-project. -> with deltaspike we have a
different situation. -> there won't be that long package names.
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 Matthias Wessendorf <ma...@apache.org>
> re #3:
>
> please let's avoid awful package names like:
>
> http://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/api/src/main/java/org/apache/myfaces/extensions/cdi/jpa/api/
>
> thx,
> Matthias
>
> On Fri, Dec 9, 2011 at 11:49 AM, Gerhard Petracek
> <ge...@gmail.com> wrote:
> > hi @ all,
> >
> > @#1:
> > +1 for the basic idea
> >
> > @#2:
> > +1 for api + impl.
> > @separated spi module: +0
> >
> > @#3
> > +1
> > @versions of cdi: at myfaces the latest spec. version is used in the
> > trunk and all previous versions are branches. since that works pretty
> well,
> > +1 for handling it that way (for sure with the corresponding concepts of
> > git).
> >
> > @#4
> > at least for our reports,... we have a confluence space[1].
> >
> > regards,
> > gerhard
> >
> > [1] http://cwiki.apache.org/confluence/display/DeltaSpike
> >
> >
> >
> > 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 Mark Struberg <st...@yahoo.de>
> >
> >> 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
> >>
> >> 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.
> >>
> >> 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 do we treat future CDI-1.0 vs CDI-1.1 changes?
> >>
> >>
> >> 4.)
> >> How we do our documentation.
> >>
> >>
> >> We might finally split up the discussion in single mail threads, but I
> >> like to kick off the think process at least ;)
> >>
> >> LieGrue,
> >> strub
> >>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
Re: First steps
Posted by Matthias Wessendorf <ma...@apache.org>.
re #3:
please let's avoid awful package names like:
http://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/api/src/main/java/org/apache/myfaces/extensions/cdi/jpa/api/
thx,
Matthias
On Fri, Dec 9, 2011 at 11:49 AM, Gerhard Petracek
<ge...@gmail.com> wrote:
> hi @ all,
>
> @#1:
> +1 for the basic idea
>
> @#2:
> +1 for api + impl.
> @separated spi module: +0
>
> @#3
> +1
> @versions of cdi: at myfaces the latest spec. version is used in the
> trunk and all previous versions are branches. since that works pretty well,
> +1 for handling it that way (for sure with the corresponding concepts of
> git).
>
> @#4
> at least for our reports,... we have a confluence space[1].
>
> regards,
> gerhard
>
> [1] http://cwiki.apache.org/confluence/display/DeltaSpike
>
>
>
> 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 Mark Struberg <st...@yahoo.de>
>
>> 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
>>
>> 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.
>>
>> 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 do we treat future CDI-1.0 vs CDI-1.1 changes?
>>
>>
>> 4.)
>> How we do our documentation.
>>
>>
>> We might finally split up the discussion in single mail threads, but I
>> like to kick off the think process at least ;)
>>
>> LieGrue,
>> strub
>>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: First steps
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
@#1:
+1 for the basic idea
@#2:
+1 for api + impl.
@separated spi module: +0
@#3
+1
@versions of cdi: at myfaces the latest spec. version is used in the
trunk and all previous versions are branches. since that works pretty well,
+1 for handling it that way (for sure with the corresponding concepts of
git).
@#4
at least for our reports,... we have a confluence space[1].
regards,
gerhard
[1] http://cwiki.apache.org/confluence/display/DeltaSpike
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 Mark Struberg <st...@yahoo.de>
> 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
>
> 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.
>
> 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 do we treat future CDI-1.0 vs CDI-1.1 changes?
>
>
> 4.)
> How we do our documentation.
>
>
> We might finally split up the discussion in single mail threads, but I
> like to kick off the think process at least ;)
>
> LieGrue,
> strub
>
Re: First steps
Posted by Jason Porter <li...@gmail.com>.
On Fri, Dec 9, 2011 at 14:10, Mark Struberg <st...@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 <ge...@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 <li...@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 <st...@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
Re: First steps
Posted by Mark Struberg <st...@yahoo.de>.
@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 <ge...@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 <li...@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 <st...@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
>>
>
Re: First steps
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <li...@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 <st...@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
>
Re: First steps
Posted by Jason Porter <li...@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 <st...@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