Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Okay, I spent some time with Sam on IRC hashing this out. Assuming that Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike, his view is that it's not terribly important who does the initial code import, though it would be best for a so-authorized Red Hatter to be the one to change the file headers. I will be out of pocket for the rest of the week beyond today, so if you, Marius, are able to work on the import end of this week/early next then that's in any event as soon as I would have been able to get to it anyway. Otherwise, anyone can do that, with someone still employed by RH finally applying the change that modifies the headers--which, I suppose, could be prepared by anyone else and simply shared among our private git repos. Matt On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici marius.bogoev...@gmail.com wrote: I still am a participant on this thread, but doing more reading than writing as of late :) So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next. With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw. On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote: Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP. Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter lightguard...@gmail.com wrote: I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to see if Marius has subscribed to this list on a personal email as he has embarked on a new adventure outside of Red Hat. On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson gudnabr...@gmail.com wrote: Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger. Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com wrote: I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle is that each side (Spring, CDI) should not know about the existence of the other. Spring beans should be used as CDI beans transparently and vice-versa. So where do beans come from? Spring beans are exposed through a /resource producer pattern//./ @Produces @SpringBean Foo bar; Will produce a CDI bean of the type Foo acquired from the Spring context Details: http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us age.html#d0e92 What Spring context? -- For flexibility reasons, we do not
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger. Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com wrote: I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.htmlhttp://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.htmlhttp://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP. Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter lightguard...@gmail.comwrote: I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to see if Marius has subscribed to this list on a personal email as he has embarked on a new adventure outside of Red Hat. On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson gudnabr...@gmail.com wrote: Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger. Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com wrote: I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support
Re: XML Config requirements
Here's a random thought: would any other format be better than XML for what is effectively describing CDI annotations? :) Matt On Mon, Sep 24, 2012 at 12:11 PM, Jason Porter lightguard...@gmail.com wrote: I haven't heard anything for 15 days on this. Seems like it's safe to take this and put it up on the wiki and get started. On Wed, Sep 19, 2012 at 12:17 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: For me that's almost all, wonder about: 1) xml? Shouldnt we discuss about it when this thread will be done? 2) do we want it extensible to let the user add 'shortcuts' (webservices, camel context...)? Le 19 sept. 2012 00:09, Jason Porter lightguard...@gmail.com a écrit : Let's start listing requirements and use cases for what we want the XML config module to do. I know I have heard of two: 1) Bean configuration and wiring to allow another integration point with CDI for things such as Drools or other projects which may not be directly configured via Java 2) Applying changes to beans such as interceptors to a wide range of classes via a matched regex (Mark, we'll need your use case here) What else do people have? -- 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: XML Config requirements
Agreed; I also thought of some kind of approach that would leave the door open but, like you, thought that the basics provided by CDI were to some degree the metamodel we'd be talking about. I wonder if some kind of event handler or pull parsing approach would reduce the work for a given alternate syntax even further. Matt On Mon, Sep 24, 2012 at 1:56 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: +1 *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* 2012/9/24 Jason Porter lightguard...@gmail.com We want to keep DS free of dependencies outside core JDK and Java EE deps. We could do something like say JSON or YAML, but then we'd end up parsing that all ourselves. What I think makes the most sense is to create a metadata storage of this stuff (or, better, use what CDI already has) and anyone that wants to create a new parser for a different format can do that. Maybe kick off the parsing early in the bootstrapping and process everything we have back at a later phase. Thoughts? On Mon, Sep 24, 2012 at 12:43 PM, Matt Benson gudnabr...@gmail.com wrote: Here's a random thought: would any other format be better than XML for what is effectively describing CDI annotations? :) Matt On Mon, Sep 24, 2012 at 12:11 PM, Jason Porter lightguard...@gmail.com wrote: I haven't heard anything for 15 days on this. Seems like it's safe to take this and put it up on the wiki and get started. On Wed, Sep 19, 2012 at 12:17 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: For me that's almost all, wonder about: 1) xml? Shouldnt we discuss about it when this thread will be done? 2) do we want it extensible to let the user add 'shortcuts' (webservices, camel context...)? Le 19 sept. 2012 00:09, Jason Porter lightguard...@gmail.com a écrit : Let's start listing requirements and use cases for what we want the XML config module to do. I know I have heard of two: 1) Bean configuration and wiring to allow another integration point with CDI for things such as Drools or other projects which may not be directly configured via Java 2) Applying changes to beans such as interceptors to a wide range of classes via a matched regex (Mark, we'll need your use case here) What else do people have? -- 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 -- 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: [Vote] New DeltaSpike Web site
How about a syringe with a feather in it? ;P On Tue, Aug 7, 2012 at 9:39 AM, Charles Moulliard ch0...@gmail.com wrote: I would like to come with a new idea for the DeltaSpike logo Idea : Add a spear/javellin to the DeltaSpike name. By example, we could add it top of the i letter The spear symbolizes the movement and in certain way the movement represented by action to inject something in a Java Object. What do you think about this ? On Sun, Jul 15, 2012 at 11:09 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: had a crazy thought about the log: DS should be a kind of superman for cdi and we have the delta...and the Spike... http://people.apache.org/~rmannibucau/graphic/ds-2.png - Romain 2012/7/6 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, i like the basic idea of [delta symbol] + spike. imo logos with nice symbols are way better than most pure text-logos. + as soon as we have a final name, we will get professional suggestions. regards, gerhard 2012/7/6 Mehdi Heidarzadeh heidarzad...@gmail.com How about an up side down triangle. (sth unusual, hackers way ;) ) -- Mehdi Heidarzadeh Ardalani Independent JEE Consultant, Architect and Developer. http://www.TheBigJavaBlog.com -- Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com
Re: [suggestion] - Documentation
On Wed, Jul 25, 2012 at 8:58 AM, Pete Muir pm...@redhat.com wrote: On 25 Jul 2012, at 07:17, Mark Struberg wrote: David, the CMS is already set up and running (in SVN [1]). We just need a bit more stylish css. And you can perfectly create pdf docs out of markdown. Of course we can also use alternative formats. But to me this is like a colour preference - markdown is supported out of the box and provides all needed options. My only concern here is that Markdown doesn't support a few useful things for full on docs (vs readmes and snippets of text): FWIW, * admonitions I.e., warnings? What are you looking for here? * callouts on code Again, not sure I know what you're meaning here. * a standard way of indicating what the source language of a code block is Apache CMS has this. * definition lists Example? * tables (though there are extensions to Markdown that support this, idk if Apache CMS' implementation of Markdown does?) Apache CMS has this extension enabled. Matt I find all of these things useful when writing docs. It was for these reasons that we decided at JBoss we needed more than MarkDown for docs. We choose AsciiDoc as our extended format for docs: * It can process 95% of markdown's syntax * It supports all of the above deficiencies in markdown * It has a good toolchain built in, that spits out pdf and epub * It can convert to docbook * It has good docs I'm not suggesting that DeltaSpike should do the same, just contributing our findings :-) Shane, I don't think I bypassed anyone. We discussed this since 6 months and noone started working on it. Thus I finally dropped a mail and then implemented it. I also got no stop mail back then. Honestly I really don't care which format we use, IF someone else is doing the work and others can easily add documentation. LieGrue, strub [1] http://svn.apache.org/repos/asf/incubator/deltaspike/site/trunk/ - Original Message - From: David Blevins david.blev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Wednesday, July 25, 2012 2:37 AM Subject: Re: [suggestion] - Documentation T he answer to both these questions really that the CMS creates websites, some details on that below I'll note that the CMS is svn based -- maybe undesirable given the use of git. On Jul 24, 2012, at 4:54 PM, Shane Bryzak wrote: Does the choice of Apache CMS for hosting documentation meet the following requirements? 1) Making available the documentation for previously released versions of DeltaSpike. If by make available the intention is browsable on the website, then sure there are ways to handle that. 2) Making available the documentation in offline formats, such as HTML or PDF available for download. Certainly you can use the same source to generate non-website looking HTML. Same goes for PDF. You wouldn't be using the CMS to do this, but the CMS doesn't prevent it. It'd be something we setup ourselves and could be done via a CI server or something done at release time. Basically the CMS is a system that is for generate website html using the following layout: - content/source-files-and-directories - lib/site-generating-perl-functions - templates/whatever-you-need-for-templates When something in 'content/' is updated, it will run it through lib/ (which leverages templates/) and save the resulting html to disk and take care of synching that html file from staging to production. When something in 'lib/' or 'templates/' is updated, it pretends as if everything in 'content/' has changed and performs the above step on every source file. You can organize the 'content/' dir however you want. That could mean: - content/v0.1/ - content/v0.2/ - content/current/ Where 'current' gets versioned on release. Or anything at all. Maybe just: - content/wild-wild-west So the short answer is there isn't anything there to prevent or help the two points. In terms of generating outside the CMS which is what would be needed for say, turning many files into one file such as a zip of html or a PDF, it's up to us. There are projects that do it via buildbot. Buildbot is not so much a CI tool as it is cron with a webUI and also happens to have the ability to be trigger by commits. Really, you can get anything done with buildbot without much in the way of restrictions. It's a mediocre CI system and an amazing cron replacement. -David
Re: [suggestion] - Documentation
On Wed, Jul 25, 2012 at 10:22 AM, Pete Muir pm...@redhat.com wrote: On 25 Jul 2012, at 16:16, Matt Benson wrote: On Wed, Jul 25, 2012 at 8:58 AM, Pete Muir pm...@redhat.com wrote: On 25 Jul 2012, at 07:17, Mark Struberg wrote: David, the CMS is already set up and running (in SVN [1]). We just need a bit more stylish css. And you can perfectly create pdf docs out of markdown. Of course we can also use alternative formats. But to me this is like a colour preference - markdown is supported out of the box and provides all needed options. My only concern here is that Markdown doesn't support a few useful things for full on docs (vs readmes and snippets of text): FWIW, * admonitions I.e., warnings? What are you looking for here? Yes, admonitions is the term given (I think by docbook) to the boxouts that are e.g. Warning, Info, Important. * callouts on code Again, not sure I know what you're meaning here. I can have a little icon (e.g. a 1), next to a line of code, then a table at the bottom of the codeblock that links to that. Allows you to annotate a code block with notes. * a standard way of indicating what the source language of a code block is Apache CMS has this. Cool. How would this work if we were also producing pdfs and epubs? Is this a standard extension to markdown? Yes; the code highlighting is done with http://freewisdom.org/projects/python-markdown/CodeHilite; depending on the structure of whatever mechanism would be theoretically used to produce other formats, we'd presumably just make the same extensions available. * definition lists Example? http://www.w3schools.com/tags/tag_dl.asp As it turns out, http://freewisdom.org/projects/python-markdown/Definition_Lists is also enabled in the Apache CMS. The full list of enabled extensions is at http://www.apache.org/dev/cmsref#markdown . Matt * tables (though there are extensions to Markdown that support this, idk if Apache CMS' implementation of Markdown does?) Apache CMS has this extension enabled. Matt I find all of these things useful when writing docs. It was for these reasons that we decided at JBoss we needed more than MarkDown for docs. We choose AsciiDoc as our extended format for docs: * It can process 95% of markdown's syntax * It supports all of the above deficiencies in markdown * It has a good toolchain built in, that spits out pdf and epub * It can convert to docbook * It has good docs I'm not suggesting that DeltaSpike should do the same, just contributing our findings :-) Shane, I don't think I bypassed anyone. We discussed this since 6 months and noone started working on it. Thus I finally dropped a mail and then implemented it. I also got no stop mail back then. Honestly I really don't care which format we use, IF someone else is doing the work and others can easily add documentation. LieGrue, strub [1] http://svn.apache.org/repos/asf/incubator/deltaspike/site/trunk/ - Original Message - From: David Blevins david.blev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Mark Struberg strub...@yahoo.de Sent: Wednesday, July 25, 2012 2:37 AM Subject: Re: [suggestion] - Documentation T he answer to both these questions really that the CMS creates websites, some details on that below I'll note that the CMS is svn based -- maybe undesirable given the use of git. On Jul 24, 2012, at 4:54 PM, Shane Bryzak wrote: Does the choice of Apache CMS for hosting documentation meet the following requirements? 1) Making available the documentation for previously released versions of DeltaSpike. If by make available the intention is browsable on the website, then sure there are ways to handle that. 2) Making available the documentation in offline formats, such as HTML or PDF available for download. Certainly you can use the same source to generate non-website looking HTML. Same goes for PDF. You wouldn't be using the CMS to do this, but the CMS doesn't prevent it. It'd be something we setup ourselves and could be done via a CI server or something done at release time. Basically the CMS is a system that is for generate website html using the following layout: - content/source-files-and-directories - lib/site-generating-perl-functions - templates/whatever-you-need-for-templates When something in 'content/' is updated, it will run it through lib/ (which leverages templates/) and save the resulting html to disk and take care of synching that html file from staging to production. When something in 'lib/' or 'templates/' is updated, it pretends as if everything in 'content/' has changed and performs the above step on every source file. You can organize the 'content/' dir however you want. That could mean: - content/v0.1/ - content/v0.2/ - content/current/ Where 'current' gets versioned on release. Or anything at all. Maybe just: - content/wild-wild-west So the short
[jira] [Created] (DELTASPIKE-238) Add HandlerMethodStorage tests
Matt Benson created DELTASPIKE-238: -- Summary: Add HandlerMethodStorage tests Key: DELTASPIKE-238 URL: https://issues.apache.org/jira/browse/DELTASPIKE-238 Project: DeltaSpike Issue Type: Task Components: ExceptionControl-Module Affects Versions: 0.3-incubating Reporter: Matt Benson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] New DeltaSpike Web site
Um, lots of Apache project logos incorporate pictures. :/ http://ant.apache.org/ http://hadoop.apache.org/ http://tomcat.apache.org/ http://aries.apache.org/ http://cocoon.apache.org/ http://cayenne.apache.org/ http://cassandra.apache.org/ Et al... The meaning of the triangle is both delta and spike, and would be intended to help instill brand recognition. Matt On Fri, Jul 6, 2012 at 11:48 AM, Charles Moulliard cmoulli...@gmail.com wrote: No existing apache project logo contains a symbol. So why would you like to add a triangle or greek delta letter ? What is the meaning of this triangle ? On Fri, Jul 6, 2012 at 6:42 PM, Matt Benson [via Apache DeltaSpike Incubator Discussions] ml-node+s2316169n4653121...@n4.nabble.com wrote: As for a final logo, I am thinking about the incorporation of a triangle to represent both delta and spike. :D Matt On Fri, Jul 6, 2012 at 11:16 AM, Jason Porter [hidden email]http://user/SendEmail.jtp?type=nodenode=4653121i=0 wrote: On Fri, Jul 6, 2012 at 2:36 AM, Charles Moulliard [hidden email]http://user/SendEmail.jtp?type=nodenode=4653121i=1wrote: If you don't like, maybe you could try to suggest something ;-) Proposition of colors : - Sand + blue (http://colorschemedesigner.com/#0y21Tw0w0w0w0) [] [] +1 - Sand + yellow + red (http://colorschemedesigner.com/#0y51Tw0w0w0w0) [] [] - Blue + Sand + Orange (http://colorschemedesigner.com/#3u31Tw0w0w0w0) [] [] +1 - Sand (http://colorschemedesigner.com/#0F11Tw0w0w0w0) - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Vote-New-DeltaSpike-Web-site-tp4653058p4653102.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com. -- 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 -- If you reply to this email, your message will be added to the discussion below: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Vote-New-DeltaSpike-Web-site-tp4653058p4653121.html To unsubscribe from [Vote] New DeltaSpike Web site, click herehttp://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4653058code=Y21vdWxsaWFyZEBnbWFpbC5jb218NDY1MzA1OHwxNzg3OTk3NDU3 . NAMLhttp://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Vote-New-DeltaSpike-Web-site-tp4653058p4653122.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
Re: Add pages from old web site
Out of curiosity, how much of the developer-targeted info cannot be conveyed through good old Javascript? Matt On Mon, Jul 2, 2012 at 10:48 AM, Mark Struberg strub...@yahoo.de wrote: There are definitely 2 different user groups. The ones who just like to 'use' DeltaSpike in their apps and the others who like to use DS to build own Extensions. Sometimes those 2 groups overlap, but there are imo 2 distinct target groups. We could keep the grouping via functionality and add the user vs dev for each of them. There are for sure some functionality (BeanBuilder, AnnotatedTypeBuilder) which is clearly only relevant for Extension devs. LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, July 2, 2012 5:38 PM Subject: Re: Add pages from old web site T o be honest, I don't think splitting the documentation into two different parts (developer and user) is a good idea. I think people may be confused which of the two documents they have to read if they are looking for a specific information. Especially for advanced use cases (like using extension points of the API) the difference between the two could be not clear for everyone. Christian 2012/7/2 Charles Moulliard cmoulli...@gmail.com: I agree on the idea to separate the user guide from developer guide as we have done that for Apache Karaf project (http://karaf.apache.org/manual/latest-2.2.x/users-guide/index.html, http://karaf.apache.org/manual/latest-2.2.x/developers-guide/index.html). And as you can see, there are no overlap between content of the 2 guides. Users and Developers guide will have 2 different goals. The developer guide will be focused on How to build the code, debug, maintain it and also How to develop CDI extensions, new modules while User guide will be more focused on providing examples of using @ConfigProperty, Running DeltaSpike with JavaSE + weld / own, OSGI. So I don't see any overlapping from this perspective as they drive 2 difference scopes. - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Add-pages-from-old-web-site-tp4652925p4652933.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com. -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Add pages from old web site
Argh, s/Javascript/Javadoc/ :P Matt On Mon, Jul 2, 2012 at 11:13 AM, Matt Benson gudnabr...@gmail.com wrote: Out of curiosity, how much of the developer-targeted info cannot be conveyed through good old Javascript? Matt On Mon, Jul 2, 2012 at 10:48 AM, Mark Struberg strub...@yahoo.de wrote: There are definitely 2 different user groups. The ones who just like to 'use' DeltaSpike in their apps and the others who like to use DS to build own Extensions. Sometimes those 2 groups overlap, but there are imo 2 distinct target groups. We could keep the grouping via functionality and add the user vs dev for each of them. There are for sure some functionality (BeanBuilder, AnnotatedTypeBuilder) which is clearly only relevant for Extension devs. LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, July 2, 2012 5:38 PM Subject: Re: Add pages from old web site T o be honest, I don't think splitting the documentation into two different parts (developer and user) is a good idea. I think people may be confused which of the two documents they have to read if they are looking for a specific information. Especially for advanced use cases (like using extension points of the API) the difference between the two could be not clear for everyone. Christian 2012/7/2 Charles Moulliard cmoulli...@gmail.com: I agree on the idea to separate the user guide from developer guide as we have done that for Apache Karaf project (http://karaf.apache.org/manual/latest-2.2.x/users-guide/index.html, http://karaf.apache.org/manual/latest-2.2.x/developers-guide/index.html). And as you can see, there are no overlap between content of the 2 guides. Users and Developers guide will have 2 different goals. The developer guide will be focused on How to build the code, debug, maintain it and also How to develop CDI extensions, new modules while User guide will be more focused on providing examples of using @ConfigProperty, Running DeltaSpike with JavaSE + weld / own, OSGI. So I don't see any overlapping from this perspective as they drive 2 difference scopes. - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Add-pages-from-old-web-site-tp4652925p4652933.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com. -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Add pages from old web site
If necessary, a whole book can be written. :) I was just curious how useful it would be over extension developers browsing the Javadoc to see what scaffolding was available. Matt On Mon, Jul 2, 2012 at 11:41 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Cant a single page doc be kept? Le 2 juil. 2012 18:30, Matt Benson gudnabr...@gmail.com a écrit : Argh, s/Javascript/Javadoc/ :P Matt On Mon, Jul 2, 2012 at 11:13 AM, Matt Benson gudnabr...@gmail.com wrote: Out of curiosity, how much of the developer-targeted info cannot be conveyed through good old Javascript? Matt On Mon, Jul 2, 2012 at 10:48 AM, Mark Struberg strub...@yahoo.de wrote: There are definitely 2 different user groups. The ones who just like to 'use' DeltaSpike in their apps and the others who like to use DS to build own Extensions. Sometimes those 2 groups overlap, but there are imo 2 distinct target groups. We could keep the grouping via functionality and add the user vs dev for each of them. There are for sure some functionality (BeanBuilder, AnnotatedTypeBuilder) which is clearly only relevant for Extension devs. LieGrue, strub - Original Message - From: Christian Kaltepoth christ...@kaltepoth.de To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, July 2, 2012 5:38 PM Subject: Re: Add pages from old web site T o be honest, I don't think splitting the documentation into two different parts (developer and user) is a good idea. I think people may be confused which of the two documents they have to read if they are looking for a specific information. Especially for advanced use cases (like using extension points of the API) the difference between the two could be not clear for everyone. Christian 2012/7/2 Charles Moulliard cmoulli...@gmail.com: I agree on the idea to separate the user guide from developer guide as we have done that for Apache Karaf project (http://karaf.apache.org/manual/latest-2.2.x/users-guide/index.html, http://karaf.apache.org/manual/latest-2.2.x/developers-guide/index.html). And as you can see, there are no overlap between content of the 2 guides. Users and Developers guide will have 2 different goals. The developer guide will be focused on How to build the code, debug, maintain it and also How to develop CDI extensions, new modules while User guide will be more focused on providing examples of using @ConfigProperty, Running DeltaSpike with JavaSE + weld / own, OSGI. So I don't see any overlapping from this perspective as they drive 2 difference scopes. - Apache Committer / Sr. Pr. Consultant at FuseSource.com Email: [hidden email] Twitter : @cmoulliard, @fusenews Blog : http://cmoulliard.blogspot.com -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Add-pages-from-old-web-site-tp4652925p4652933.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com. -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: Documentation revisit
Per Gerhard's request, points wrt the Apache CMS in the context of the DS documentation question: - the CMS is adequate to the task of creating a project website - AFAIK DS would need a location in Apache SVN to maintain the site source - adapting the straight Apache CMS into a Maven-runnable plugin for the purpose of creating portable documentation would probably be doable, while not super-trivial - considering the above, there might still be merit in using the CMS for the project website and using another Markdown-like option for docs, to pursue the greatest possible degree of commonality - then again, maybe not :| $0.02, Matt On Mon, Feb 27, 2012 at 4:08 PM, Jason Porter lightguard...@gmail.com wrote: I believe John Ament created one. We could certainly revisit, or if we can't find it anymore we could create another one. On Mon, Feb 27, 2012 at 15:01, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi jason, +1 if i remember correctly, we talked about creating a simple case with sphinx (with our discussion git-workflow), because apache-cms uses ReStructuredText as well. regards, gerhard 2012/2/27 Jason Porter lightguard...@gmail.com As we have one version out the door, should we revisit the documentation question? As I recall we had three options we were looking at: - Docbook - ReStructuredText via Sphinx (the plugin we were looking at is up to date and should be in maven central now) - Continue with Confluence -- 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: DELTASPIKE-151 Provide lookup method with Map result
From my perspective in the peanut gallery, it would seem that providing mechanisms for not-necessarily-CDI-aware libraries to bridge to CDI is as much a part of deltaspike's declared scope as e.g. providing a Spring bridge. $0.02, Matt 2012/4/10 Łukasz Dywicki l...@code-house.org: Hi all, I would like to start discussion as sugested by Gerhard in his comment for my issue. I created an issue to include a new method in BeanProvider class. Purpose of method is to find all named references and return them in Map where key is name and value is bean instance. Just to give short introduction to Camel - it is mediation library which allows to create complex integration logic with various DSL variants. With Camel you can do transformations, evaluate different kind of expressions and so on. I think it is also worth to note that Camel supports multiple Dependency Injection containers - starting from Spring and Guice up to Blueprint (OSGi specific). My goal is to provide same level of support for CDI as Camel have for Spring. For example Camel allows to inject Interceptors, error handlers and so on. To find these elements Camel scans beans registry (which is customizable through SPI) for all named references and use them. Most of you can identify the issue and path as Camel specific but I belive it is not. This method can be requested by any other project. We just started to integrate our component with deltaspike before others. From proposal I know that your goal is to create industry standard set of extensions for CDI. Previous version of camel-cdi had own BeanManagerProvider, BeanProvider classes, own AnyLiteral class and so on. I've found similar classes in your codebase so I wanted to use code written by you to simply avoid duplication between various Apache repos. Only one part which was missing in Deltaspike is named lookup result, which is not big deal to write and maintain. There is no external dependencies necessary to implement this method and it can be implemented on top of current BeanProvider API. I think that cooperation with other projects can bring lots of benefits for deltaspike community with no cost from your side. Best regards, Lukasz
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
Makes sense, guys--back to the peanut gallery for me. :) Matt On Mon, Mar 26, 2012 at 4:36 PM, Mark Struberg strub...@yahoo.de wrote: 'Core' means that this are all things which will not only run in Java EE but also in Java SE. This includes end-user functionality as well as Extension programmer tools. We just need to put them into different packages. Core just means that we don't force any additional dependencies on our users. The reason I don't like to split those things out into own jars is that it soon gets really complicated to get the modularity right without restricting ourselfs too much. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org; gudnabr...@gmail.com Cc: Sent: Monday, March 26, 2012 11:07 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner It could, I sort of envisioned that's what Core was for. On Mon, Mar 26, 2012 at 15:01, Matt Benson gudnabr...@gmail.com wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek
Re: [DISCUSS] DELTASPIKE-77 Identity API
On Tue, Feb 14, 2012 at 3:34 PM, Shane Bryzak sbry...@redhat.com wrote: On 13/02/12 19:55, Gerhard Petracek wrote: hi shane, i'm sure there are good reasons for most/all details. since i don't know them, i just list the topics which come to my mind after reading the provided information. #tryLogin i don't see the need for it compared to #login, because it can be done by users easily (if needed). at least at the beginning i would keep the api as minimal as possible. we can add further parts based on concrete and important use-cases. There are actually two quite important use cases for this - applications that implement some kind of Remember Me function must be able to authenticate without producing the usual events/messages generated when performing a conscious authentication. The same goes for stateless applications that must authenticate on every request. We can probably remove the quietLogin() method and make it an implementation detail. #login uses string as return type instead of an enum. ingeneral : we should define a general rule for the usage of exceptions which should be used by most deltaspike apis. This method returns a String to make it easy to write navigation rules for JSF. The three possible values are success, failure or exception, which allows the navigation rules to redirect the user to an appropriate page based on the result. I'm happy to hear alternatives here if someone has other suggestions. e.g. documentation of h:commandButton in JSF 2.1 docs says of @action The expression must evaluate to a public method that takes no parameters, and returns an Object (the toString() of which is called to derive the logical outcome) which is passed to the NavigationHandler for this application. I read from this that an enum is as good for JSF as anything else we might return here. Matt #quietLogin is method is intended to be used primarily as an internal API call ... then it shouldn't be part of the api. (that's related to a 2nd topic. see api vs. spi) See comment above. #hasRole Checks if the authenticated user is a member of the specified role. #checkRole Checks that the current authenticated user is a member of the specified role. #hasRole and #checkRole look very similar - if the exception is the only difference: see my comment about #tryLogin. at least we should think about unified names. We can probably merge these into a single method / overloaded methods: hasRole(String role, String group) // default doesn't throw exception hasRole(String role, String group, boolean throwException) // throws exception is throwException == true I personally think this looks ugly though. Another alternative is to just remove the checkRole() method altogether. Since most authorization now should be performed using the typesafe security bindings, it can simply be left to the authorizer method to implement the desired behaviour. Same thing goes for checkGroup(). #addXyz that's a general topic we have to discuss. in myfaces codi we have all write-methods which aren't intended to be used frequently in the spi to keep the api simple and small ([1] and [2] illustrate it in case of the initial refactoring of @Secured for deltaspike - the naming convention is always Editable[ApiName]). I agree that it would be nice to separate these methods into an SPI class. The reason they're in the API is so that developers can simply inject a single class (Identity) into their custom authentication class and have all the things they need there to perform authentication. I'll try to think of a more suitable alternative that doesn't put too much additional burden on the developer. @type string in the api: i know - it's easy, generic and sometimes just needed to use strings. however, at least we should re-visit them and just use them if there is no useful alternative. @rudy: i agree with you. for v0.1 we always started to discuss the basic use-cases and requirements and afterwards the concrete api. imo that leads to a better api and we should try to keep this approach (for sure the content of v0.1 was easier). regards, gerhard [1] http://s.apache.org/4sL [2] http://s.apache.org/j2E 2012/2/13 Rudy De Busscherrdebussc...@gmail.com Hi, I think it is also important that you can work with permissions. It is much more fine grained then roles but more flexible. It becomes much easier to change what a group of people can do, even without changing the code. I never use roles in an application, only permissions. I'm not saying we need to do the implementation of it by default in deltaspike but should have at least something like boolean hasPermission(String permissionName) in the identity API. my idea about security. regards Rudy On 12h February 2012 23:33, Shane Bryzaksbry...@redhat.com wrote: I've created an umbrella issue to track the work we do on the security module [1], and the
Re: IP discussion
On Sun, Jan 15, 2012 at 10:22 AM, Mark Struberg strub...@yahoo.de wrote: Copyright 2011, Red Hat, Inc. and/or its affiliates, and individual contributors by the @authors tag. To clarify this as well. This doesn't mean a 'shared' ownership! Usually this wording in an OSS license is used to express that both the projects hosting and managing partner (Red Hat) AS WELL as the original author have _full_ rights on this work (the authors of course only for the part they did). I thought I had responded to this, only to find the response languishing as a draft. Jason, Pete, Shane, and their manager Mark Little are currently CC'd on an email discussion between myself and RH OSS attorney Richard Fontana. Their position is that RH does indeed hold the copyright as an owner rather than as a mere licensee. So far I have seen no indication that they intend to share copyright with the individual authors, but I have now fired the question pretty much point-blank, so if my current understanding is mistaken in that regard, we'll know it soon enough. Basically this says: Red Hat gets all rights to use this software, but the original author _remains_ all this rights as well! Otherwise Red Hat could not do _anything_ without first asking _all_ contributors (on the very class) for allowance first ;) So if Pete, Stuart and Jason originally wrote it and agreed to contribute this code, then all is well. Of course, having the ok from Red Hat as well would make things easier - because then we would not need to scan all the files history to check if only iCLA signees have touched it. Not just easier--if their individual employees do not share copyright, it is essential! I have raised the issue on incubator-general yesterday. If I don't receive a response today, I'll escalate to legal-discuss. As it stands now, we need to know what, if any, explicit assurance we need from RH that their CCLA is applicable to code-relevant-to-DeltaSpike. Maybe it will turn out that I've been overly paranoid and the CCLA is all we need, but this strikes me as telling your children they can have one cookie, and they turn around and eat the whole box. Thanks again to all for participating, being patient, and having faith that there *is* a point to all this, and that once we get it resolved we can move on to the fun stuff! Matt LieGrue, strub
Re: IP discussion
On Tue, Jan 17, 2012 at 8:40 AM, Marek Schmidt masch...@redhat.com wrote: On 16/01/12 02:17, Matt Benson wrote: (sent once to Marius accidentally dropping the list) On Sun, Jan 15, 2012 at 12:16 PM, Marius Bogoevici marius.bogoev...@gmail.com wrote: On 2012-01-15, at 1:02 PM, Antoine Sabot-Durand wrote: Hi Matt, On Sun, Jan 15, 2012 at 10:28 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: what about individuals like me ? Or about IP of code coming from other project ? In Seam social, I get lots of services API binding from Spring Social (an ASL2 license project). I there any issue about that ? All code must be expressly licensed by its rightful owner to be included in the ASF repo. For code you write yourself, you simply license it under your filed ICLA. Anything else needs a software grant OR a CLA of some sort and the intent that the contribution be covered under that CLA. The second sentence above is why a simple handshake agreement from Red Hat is enough for me--their corporate CLA is already on file. I lost sight of that fact momentarily when I sent my last message on this thread. But back to the idea of code that comes, e.g., from SpringSource, yes, we must obtain express license to the code itself, particularly when it would take the form of an entire class. Depending on a compatibly-licensed third-party binary is of course no problem whatever. Sorry, but I'm really puzzled about this IP issue. My understanding is that ASL2 is useless. Springsource put their code under ASL2, I used some of their code in respect of the license (keeping names of original authors) but I still need to ask an authorization. So the original license has no value. Unless Apache needs that Springsource ASL2 licensing has to be violated by removing names of original authors, in this case I understand the need of authorization but I'm still puzzled that Apache don't recognize ASL2 value or needs to bypass it to use code under its own license. Could you get me out this kafka-ish point of view :-) ? Yeah, I could benefit from some clarification here as well. Reading Matt's response I understand that this is not an ASL2 issue, but rather an ASF policy issue (ASL2 would require listing Spring social original authors, but that cannot be done without their express permission). Or? That is my understanding, yes; ASF projects don't use code from anyplace unless its author expressly wants the code used in the form in which we wish to use it. It's easy enough to see that the mere fact that a simple piece of code is under ASL2 could be construed as enough, but again that's not my understanding of the Apache spirit, if you will. I will spend some more research on this tomorrow in case I (or anyone else) can demonstrate through ASF precedent that I'm being overly paranoid. Thanks all, Matt um, and what about the CLA article 7? 7. Should You wish to submit work that is not Your original creation, You may submit it to the Foundation separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as Submitted on behalf of a third-party: [named here]. Good catch. I had quite forgotten about this clause. Honestly, I've never seen this actually done; rather I've heard endless times that Apache committers should *not* submit contributions on another party's behalf but that those contributions should come through well-defined channels, usually issue trackers and/or mailing lists. This would be another policy question to bring to the incubator general mailiing list. In any event, on behalf of a third party still implies that third party's complicity. Matt Thanks all for the constructive discussion, Matt regards, Antoine SABOT-DURAND Le 15 janv. 2012 à 16:59, Mark Struberg a écrit : Hi! Thanks Matt for bringing this up! This is definitely something we must do before thinking about a -incubating-0.1 release. Btw, I'll now rename the version to reflect the incubation status . Mark Little from JBoss was the manager at RedHat/JBoss who was involved in preparing the incubator proposal. But Shane and Jason for sure know whom to ping. LieGrue, strub - Original Message - From: Shane Bryzaksbry...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: gudnabr...@gmail.com Sent: Sunday, January 15, 2012 2:28 PM Subject: Re: IP discussion We'd need to follow this up with Red Hat legal, to confirm what we need to do. On Sun, Jan 15, 2012 at 6:24 AM, Jason Porter lightguard...@gmail.comwrote: Would someone like myself or Shane work or do we need someone higher up in the organization or a lawyer to sign off on it?
Re: IP discussion
Hi all--we have worked through the issues with regard to Red Hat's contributions to DeltaSpike. Suffice it to say that regardless of *copyright* ownership, Red Hat unquestionably has the authority to *license* the relevant IP, and does so freely under its CCLA. The details of the dialogue with Red Hat are available on deltaspike-private for those with access. Thanks and happy coding, Matt On Tue, Jan 17, 2012 at 9:46 AM, Matt Benson gudnabr...@gmail.com wrote: On Tue, Jan 17, 2012 at 8:40 AM, Marek Schmidt masch...@redhat.com wrote: On 16/01/12 02:17, Matt Benson wrote: (sent once to Marius accidentally dropping the list) On Sun, Jan 15, 2012 at 12:16 PM, Marius Bogoevici marius.bogoev...@gmail.com wrote: On 2012-01-15, at 1:02 PM, Antoine Sabot-Durand wrote: Hi Matt, On Sun, Jan 15, 2012 at 10:28 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: what about individuals like me ? Or about IP of code coming from other project ? In Seam social, I get lots of services API binding from Spring Social (an ASL2 license project). I there any issue about that ? All code must be expressly licensed by its rightful owner to be included in the ASF repo. For code you write yourself, you simply license it under your filed ICLA. Anything else needs a software grant OR a CLA of some sort and the intent that the contribution be covered under that CLA. The second sentence above is why a simple handshake agreement from Red Hat is enough for me--their corporate CLA is already on file. I lost sight of that fact momentarily when I sent my last message on this thread. But back to the idea of code that comes, e.g., from SpringSource, yes, we must obtain express license to the code itself, particularly when it would take the form of an entire class. Depending on a compatibly-licensed third-party binary is of course no problem whatever. Sorry, but I'm really puzzled about this IP issue. My understanding is that ASL2 is useless. Springsource put their code under ASL2, I used some of their code in respect of the license (keeping names of original authors) but I still need to ask an authorization. So the original license has no value. Unless Apache needs that Springsource ASL2 licensing has to be violated by removing names of original authors, in this case I understand the need of authorization but I'm still puzzled that Apache don't recognize ASL2 value or needs to bypass it to use code under its own license. Could you get me out this kafka-ish point of view :-) ? Yeah, I could benefit from some clarification here as well. Reading Matt's response I understand that this is not an ASL2 issue, but rather an ASF policy issue (ASL2 would require listing Spring social original authors, but that cannot be done without their express permission). Or? That is my understanding, yes; ASF projects don't use code from anyplace unless its author expressly wants the code used in the form in which we wish to use it. It's easy enough to see that the mere fact that a simple piece of code is under ASL2 could be construed as enough, but again that's not my understanding of the Apache spirit, if you will. I will spend some more research on this tomorrow in case I (or anyone else) can demonstrate through ASF precedent that I'm being overly paranoid. Thanks all, Matt um, and what about the CLA article 7? 7. Should You wish to submit work that is not Your original creation, You may submit it to the Foundation separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as Submitted on behalf of a third-party: [named here]. Good catch. I had quite forgotten about this clause. Honestly, I've never seen this actually done; rather I've heard endless times that Apache committers should *not* submit contributions on another party's behalf but that those contributions should come through well-defined channels, usually issue trackers and/or mailing lists. This would be another policy question to bring to the incubator general mailiing list. In any event, on behalf of a third party still implies that third party's complicity. Matt Thanks all for the constructive discussion, Matt regards, Antoine SABOT-DURAND Le 15 janv. 2012 à 16:59, Mark Struberg a écrit : Hi! Thanks Matt for bringing this up! This is definitely something we must do before thinking about a -incubating-0.1 release. Btw, I'll now rename the version to reflect the incubation status . Mark Little from JBoss was the manager at RedHat/JBoss who was involved in preparing the incubator proposal. But Shane and Jason for sure know whom to ping. LieGrue, strub - Original Message - From: Shane Bryzaksbry...@gmail.com
Re: DeltaSpike IP clarifications
Adding deltaspike-dev back to the distribution: On Tue, Jan 17, 2012 at 3:01 PM, Gerhard Petracek gpetra...@apache.org wrote: ok - matt and i just had a short talk with sam to ensure that we are talking about the same. it isn't the only way, but to resolve it once and for all it's easier to handle it via a software grant. @matt: it would be great if you can contact them again. Done, copying deltaspike-private. Matt @sam: thx for your help regards, gerhard 2012/1/17 Gerhard Petracek gpetra...@apache.org hi, in general - fyi: we don't have a huge import. we discuss single features and if we agree on one, one of the members (of the original project) commits it. all authors have their icla on file, joined the project and participate in the discussion and the release votes. regards, gerhard 2012/1/17 Sam Ruby ru...@intertwingly.net On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I didn't mention CCLA's on purpose. A corporation will have a CCLA on file to either a) declare that certain employees are permitted to contribute software or b) declare that certain software is contributed to the ASF. A CCLA that is on file that only includes Schedule A doesn't grant the ASF permission to use specific software created by the company. If the company is donating the software they need to specify it. If the software is being contributed via an ICLA then the CCLA simply says the company is giving the contributor the right to contribute software that normally the company would own. However, an individual should never contribute software under their ICLA that they didn't author, unless they have explicit permission from the other authors. For a significant contribution a software grant is typically the best way to do it. I concur. Either an (additional|updated) CCLA with a concurrent software grant (Schedule B) for the code in question -or- simply a separate Software Grant would be appreciated. If RedHat is on board with this (and everything in this conversations indicated that that is indeed the case), then that shouldn't be a problem? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
DeltaSpike IP clarifications
Hi, all--per [1], Generally, the mentors of a new project will need to consult with gene...@incubator.apache.org or the Apache legal team about the particular circumstances. So, here I am. The situation can be read in detail at [2], but in short is this: DeltaSpike is intended to amalgamate best of add-on solutions from the Java EE community with regard to the Contexts and Dependency Injection for the Java EE platform (CDI) specification. Thus its sources may incorporate code originating from numerous sources, but due to a number of reasons including e.g. anticipated feature overlap, it does not seem appropriate to include whole codebases under software grants. The specific question at the moment regards code to which Red Hat holds the copyright. The ASF has a filed CCLA from Red Hat, but I have been taking the position that we still need some form of assurance that code relating to CDI (primarily embodied in the Solder and Seam) projects is *specifically* approved for contribution to DeltaSpike. I'll present the basic question in multiple-choice form (with options shown in order of difficulty): What do we need to show provenance? a. Nothing. Stop being so damned paranoid. The CCLA is enough. b. DeltaSpike's Red Hat-employed committers' assurance that their employer is on board. c. A signed statement from Red Hat to the effect that their employees are authorized to contribute CDI-related code. d. A software grant for any codebase, even if we only intend to cherry-pick from it. e. Jim Whitehurst's eternal soul. f. Something else, namely _. Thanks, Matt on behalf of DeltaSpike [1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance [2] http://markmail.org/thread/g65yi42mdzvq5bu2
Re: IP discussion
On Sun, Jan 15, 2012 at 10:37 AM, Pete Muir pm...@redhat.com wrote: We need to ensure all non-Red Hat contributors to Seam 3 whose code we migrate to DeltaSpike have either signed the Deltaspike CLAs OR can provide a statement that the license the code to the Apache Foundation AIUI. I would support this statement, with the clarification that DeltaSpike CLAs = ASF ICLA, acknowledging a context of Seam-to-DeltaSpike. Matt On 15 Jan 2012, at 16:28, Antoine Sabot-Durand wrote: what about individuals like me ? Or about IP of code coming from other project ? In Seam social, I get lots of services API binding from Spring Social (an ASL2 license project). I there any issue about that ? regards, Antoine SABOT-DURAND Le 15 janv. 2012 à 16:59, Mark Struberg a écrit : Hi! Thanks Matt for bringing this up! This is definitely something we must do before thinking about a -incubating-0.1 release. Btw, I'll now rename the version to reflect the incubation status . Mark Little from JBoss was the manager at RedHat/JBoss who was involved in preparing the incubator proposal. But Shane and Jason for sure know whom to ping. LieGrue, strub - Original Message - From: Shane Bryzak sbry...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: gudnabr...@gmail.com Sent: Sunday, January 15, 2012 2:28 PM Subject: Re: IP discussion We'd need to follow this up with Red Hat legal, to confirm what we need to do. On Sun, Jan 15, 2012 at 6:24 AM, Jason Porter lightguard...@gmail.comwrote: Would someone like myself or Shane work or do we need someone higher up in the organization or a lawyer to sign off on it?
Re: IP discussion
On Sat, Jan 14, 2012 at 2:09 PM, Jason Porter lightguard...@gmail.com wrote: Of course, I don't deal with legal matters, but would the simplest way be to have a statement from someone representing Red Hat that code from Seam 3 and Solder is permissible to use? That would be great. Failing that, taking all contributions on the merits of their individual authors' copyright ownership is fine too; I'd just like for us to be more explicit about it. Thanks for your quick response (and sorry you had to read the original message on a phone ;) ), Matt Sent from my iPhone On Jan 14, 2012, at 13:00, Matt Benson gudnabr...@gmail.com wrote: Hi all, Deltaspike is a bit unusual as podlings go: its code is not a drop from one single source (which would typically be accompanied by a software grant), nor is its code grown entirely from nothing. Part of the incubation process requires the necessary precautions be taken to ensure that the project's IP is not encumbered in any way. I'm not here to scold folks, but now that I step back and take in the landscape, I am not fully comfortable with our process thus far wrt absorbing code from the various points of ingress we all represent. I'll go on: Firstly, it's simply a fact that the CODI code is a non-issue: it's been grown under the auspices of an Apache TLP and there is no reason to doubt that it remains as unencumbered now as ever. I mention this because it's not at all like I or anyone else is of the old boys club mentality or any such nonsense; I'm just categorizing the DeltaSpike codebase as it now stands. Thus far, I am concerned by the Solder-based code. For example, the copyright notice at https://github.com/seam/solder/blob/develop/impl/src/main/java/org/jboss/solder/reflection/annotated/AnnotatedTypeBuilder.java (this is pretty clearly the same code as currently lives in the DeltaSpike repo) says Copyright 2011, Red Hat, Inc. and/or its affiliates, and individual contributors by the @authors tag. The @authors tag cites Stuart Douglas and Pete Muir, so I read the notice as saying that copyright is shared between these individuals and Red Hat for this particular file. Fine; both Stuart and Pete have filed their ICLAs and have received their accounts (I've not checked the other files, but I assume they are similarly attributed). However, Jason actually committed the code. This is not necessarily wrong; Red Hat does have a corporate CLA on file with the ASF, and Jason is a Red Hat employee. IMO then the only thing missing is an unequivocal statement on the parts of the Red Hat-employed DeltaSpike committers that any of them (or, in this case, at least Jason) is authorized to license whatever Solder, etc. code he sees fit, on Red Hat's behalf, to Apache for inclusion in the DeltaSpike codebase. Just because Red Hat has filed the CCLA does not mean that every line of their code is now up for grabs, and I see nothing to this explicit effect in the incubation proposal, so that connection from point A to point B is essential. We must be able to show clear provenance for any code that we bring in, regardless of the source, so again, please don't feel singled out. The builder code is the first example I thought of, and I'm pretty sure that nothing has, as yet, been added from source other than CODI/Solder. Now, if the Solder code is rather to be contributed on the basis of the individual authors' copyrights, making sure everything that has already been added is kosher will require a little more work, but ultimately the situation is the same: one of the copyright holders needs to have been responsible for licensing the code for ASF use, although it is fine by me if that authorization comes in blanket form and I'm perfectly willing to take committers at their word wrt to the Red Hat or any similar situation. Finally, if and when we do end up with any code being officially licensed from Red Hat rather than from the individual authors (or if I've misinterpreted the spirit of the Solder copyright notice), then Red Hat would also need to be credited in the project's NOTICE file. Thanks in advance for addressing my concerns (or pointing out what I've missed that proactively addressed them), Matt
Re: git commit: Added myself as a PPMC member
Hi Marius--I would suggest moving your entry to before mine so we keep them sorted alphabetically by id. Matt On Fri, Dec 23, 2011 at 7:53 AM, mar...@apache.org wrote: Updated Branches: refs/heads/master 88ff7635a - 37414d7d3 Added myself as a PPMC member Project: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/37414d7d Tree: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/37414d7d Diff: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/37414d7d Branch: refs/heads/master Commit: 37414d7d36d40464f622a4cd9b40b7835143de74 Parents: 88ff763 Author: Marius Bogoevici marius.bogoev...@gmail.com Authored: Fri Dec 23 08:52:40 2011 -0500 Committer: Marius Bogoevici marius.bogoev...@gmail.com Committed: Fri Dec 23 08:52:40 2011 -0500 -- deltaspike/parent/pom.xml | 9 + 1 files changed, 9 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/37414d7d/deltaspike/parent/pom.xml -- diff --git a/deltaspike/parent/pom.xml b/deltaspike/parent/pom.xml index 443070f..cd3eae8 100644 --- a/deltaspike/parent/pom.xml +++ b/deltaspike/parent/pom.xml @@ -90,6 +90,15 @@ /roles timezone-6/timezone /developer + developer + idmarius/id + nameMarius Bogoevici/name + emailmar...@apache.org/email + roles + rolePPMC/role + /roles + timezone-5/timezone + /developer /developers !-- TODO move to a 'owb' profile --
Re: basic decisions - package and class naming
What would the drawbacks be of putting the api/impl code in completely separate modules? Seemingly this would solve the packaging problems and the impl jar could simply shade the api jar. Matt On Wed, Dec 21, 2011 at 11:04 AM, Jason Porter lightguard...@gmail.com wrote: +1 I'm fine with this. Sent from my iPhone On Dec 21, 2011, at 4:05, Gerhard Petracek gerhard.petra...@gmail.com wrote: i agree with mark. regards, gerhard 2011/12/21 Mark Struberg strub...@yahoo.de As I see it we have 3 different options: 1.) .api.* + .impl.* because it's more easy to 'grab' any api package in e.g. an Arquillian test. If we don't have the modulename.api package name, then we cannot do something like this in Arquillian: Shrinkwrap.createArchive(JavaArchive.class).addPackages(true, ...modulename.api); Without the explicit .api package name we would not be able to add just the api module without also adding all the impl stuff as well. (This is needed if we e.g. like to test single features of the impl module). The very same will hit us with the maven-shade-plugin where we would not be able to explicitely shade all classes of the api modules. thus a +1 for this. 2.) noting + '.internal' possible, but with the downsides as noted above. -0.5 thus. LieGrue, strub - Original Message - From: Antoine Sabot-Durand anto...@sabot-durand.net To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, December 20, 2011 11:55 AM Subject: Re: basic decisions - package and class naming Social API: org.apache.deltaspike.social.* +1 the implementation org.apache.deltaspike.social.impl.* +0 (we don't have this in Seam and have the distinction in module name, but it's not a big deal for me) @SPI = +0 I'm not sure to use it but why not. Antoine SABOT-DURAND Le 15 déc. 2011 à 18:43, Matthias Wessendorf a écrit : On Thu, Dec 15, 2011 at 3:31 PM, Mark Struberg strub...@yahoo.de wrote: Well, we are now hitting the wall - so we need a resolution asap. For the core module we would have for core-api: org.apache.deltaspike.core. ? for core-impl: org.apache.deltaspike.core.impl. ? yes! And/or JPA API: org.apache.deltaspike.jpa.* the implementation org.apache.deltaspike.jpa.impl.* @SPI = fine for me! But please NO 'api' inside of the pkg names; (impl is a must, IMO (fine in naming it 'internal', but I guess impl is more 'standard') -M The problem is that by omitting the .api. package, we don't have any good handle to include/exclude all the classes from core.api, jsf.api, etc in the maven-shade-plugin or any other include/exclude mechanism. That could hurt a bit. Matze, you have not been fond of the api package, what do you suggest as an alternative option? LieGrue, strub
