Re: Supporting DeltaSpike
Hi, now that the project has been accepted, soon you can start contributing code and become a committer via the regular Apache way (e.g. code contributions and mailing list interactivity) a few more references: http://apache.org/foundation/how-it-works.html and http://apache.org/foundation/getinvolved.html -M On Tue, Dec 13, 2011 at 8:47 AM, Christian Kaltepoth chk...@googlemail.com wrote: Hey all, I would be glad to be able to support DeltaSpike. I've been working on Seam Faces mainly in regard to compatibility with MyFaces and OWB. I also wrote the project stage bean activation extension for Seam Faces whose core part I'm currently moving to Seam Solder. I'm very excited about the fact that Seam 3 and MyFaces CODI are joining their force and would love to be able to contribute to the project. Best regards Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: basic decisions - package and class naming
with this. Are there any Class naming conventions/rules you like to introduce? Pros, cons? I think standard Java naming conventions should be fine. LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: basic decisions - coding conventions
On Mon, Dec 12, 2011 at 12:37 PM, Mark Struberg strub...@yahoo.de wrote:
Hi!
I'm a fan of a pretty tight coding convention observation even at build time.
What we usually have (in owb and myfaces) is an own 'buildtools' project
which contains the checkstyle rules as own artifact.
This will then be used in the deltaspike-parent pom as dependency of the
maven-checkstyle-plugin. I'll set this up, no worries, easy stuff.
The more important thing is to decide _which_ coding conventions we like to
follow at all?
I have the following suggestions:
1.) no tabs, only spaces!
+1
2.) bracelets on new line? Actually I don't care about
if() {
dings();
}
+1
but we should only use one stile throughout the whole code.
3.) force bracelets
no
if()
dosomething;
without bracelets. Instead force:
if()
{
dosomething;
}
+1 for always:
if(blah) {
blub();
}
I'm sure there is a bit more, thus please add the rules which are important
for you.
(PS: once we found a final solution we should move this into our wiki +
provide Eclipse and Idea checkstyle rules.
LieGrue,
strub
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: basic decisions - coding conventions
On Mon, Dec 12, 2011 at 1:38 PM, Gerhard Petracek gpetra...@apache.org wrote:
+1 for 4 spaces
yup
regards,
gerhard
2011/12/12 Shane Bryzak sbry...@gmail.com
On Mon, Dec 12, 2011 at 9:37 PM, Mark Struberg strub...@yahoo.de wrote:
Hi!
I'm a fan of a pretty tight coding convention observation even at build
time.
What we usually have (in owb and myfaces) is an own 'buildtools' project
which contains the checkstyle rules as own artifact.
This will then be used in the deltaspike-parent pom as dependency of the
maven-checkstyle-plugin. I'll set this up, no worries, easy stuff.
The more important thing is to decide _which_ coding conventions we like
to follow at all?
I have the following suggestions:
1.) no tabs, only spaces!
+1, tabs suck
2.) bracelets on new line? Actually I don't care about
if()
{
dings();
}
or
if() {
dings();
}
but we should only use one stile throughout the whole code.
I don't mind either way here, comfortable with either as long as we pick
one and are consistent with it.
3.) force bracelets
no
if()
dosomething;
without bracelets. Instead force:
if()
{
dosomething;
}
+1
I'm sure there is a bit more, thus please add the rules which are
important for you.
(PS: once we found a final solution we should move this into our wiki +
provide Eclipse and Idea checkstyle rules.
One thing to decide is indent size. Currently in Seam we use 4 spaces, as
we've recently adopted the JBoss coding standards. Personally, I think
this is a little too much, previously we had 3 spaces (Gavin's preference)
which I thought was better.
LieGrue,
strub
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: basic decisions - package and class naming
On Wed, Dec 21, 2011 at 12:00 PM, Mark Struberg strub...@yahoo.de wrote: 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). Ok, I don't get the _why_; Do you mind to explain it to me (I know nothing about Arquillian and the shade plugin:-)) -M 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider
- 0,5 on supporting Java5 On Wed, Dec 28, 2011 at 9:40 AM, Mark Struberg strub...@yahoo.de wrote: Since we have quite a few vetos against Java5 usage for this new project, I'd say we go with Java6. Java7 is right around the corner, and Java5 is really only legacy now. If projects still need to use java5, they can of course also use Seam3 and CODI until they hava moved their servers. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 10:44 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider If we wanted to try it later that's fine. On Fri, Dec 23, 2011 at 02:41, Mark Struberg strub...@yahoo.de wrote: We could try to use retro-translate to produce java5 compatible artifacts later? LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 4:45 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider We have it in Seam, and Weld for that Java 5 support, but I'd prefer to stay on 6+. We *could* do a version compiled for jdk5. But then we get into issues of which branch, making sure it's all Java 5 features, etc. -0.5 On Thu, Dec 22, 2011 at 04:45, José Rodolfo Freitas joserodolfo.frei...@gmail.com wrote: +0 On Thu, Dec 22, 2011 at 9:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, this feature won't prevent users from using deltaspike with candi (even if candi only supports java6+). regards, gerhard 2011/12/22 John D. Ament john.d.am...@gmail.com Hi Gerhard, How about resin (CanDI)? John On Thu, Dec 22, 2011 at 6:01 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, the impl. would not be bound to a cdi impl. owb as well as weld (see [1]) support java5. regards, gerhard [1] https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/ServiceLoader.java 2011/12/22 John D. Ament john.d.am...@gmail.com -1 Java5 is past EOL at this point. Not suitable for production deployments from my perspective. Java EE 6 (since any code we write for delta spike is against EE6) is for Java SE 6. Even if the implementation is using Java 5 at compilation time, the runtime is 6; and I would hope we would code against spec rather than specific impls. John On Wed, Dec 21, 2011 at 3:41 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, fyi: please check [1] before you answer. [2] is the implementation used in owb. i suggest to start with it (instead of the version of codi), because the version of codi provides additional mechanisms we might need later on (if we include the corresponding features). the basic concept: ServiceProvider (btw. DefaultLoaderService) is a custom implementation of the ServiceLoader mechanism which allows to use codi with java 1.5 (if the cdi container allows it as well). in case of java6+ the std. ServiceLoader gets used. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.3/webbeans-impl/src/main/java/org/apache/webbeans/service/DefaultLoaderService.java [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- 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 -- Matthias Wessendorf blog: http
Re: basic decisions - package and class naming
On Tue, Dec 27, 2011 at 10:20 PM, Mark Struberg strub...@yahoo.de wrote: Hi Matze! Arquillian and shading both work with filters. With Arquillian you create your test @Deployment by adding classes to it. You can do this by saying .addAsPackage(blabla); but if the package blabla also contains the impl then you would need to either include or exclude all this stuff manually! It's much easier if you can just type addAsPackage(blabla.api); and you're done. awesome... :-) Same is true for shading. much easier to just include the blabla.api package than to have to explicitly list class names... I see, too bad, but hey! LieGrue, strub - Original Message - From: Matthias Wessendorf mat...@apache.org To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Wednesday, December 21, 2011 2:29 PM Subject: Re: basic decisions - package and class naming On Wed, Dec 21, 2011 at 12:00 PM, Mark Struberg strub...@yahoo.de wrote: 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). Ok, I don't get the _why_; Do you mind to explain it to me (I know nothing about Arquillian and the shade plugin:-)) -M 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [DISCUSS] deltaspike v0.1
+1 On Saturday, January 14, 2012, Mark Struberg strub...@yahoo.de wrote: +1 just finishing the integration tests and the ConfigResolver stuff a bit. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Saturday, January 14, 2012 1:10 AM Subject: [DISCUSS] deltaspike v0.1 hi @ all, we resolved over 30 jira-tickets and we finished (agreement + import/implementation) ~10 mechanisms/features. imo: we should release early and often + it would be nice to start with the first steps for a release and start with the release of v0.1 in about 1-2 weeks. (the first release might take a bit longer because we have to ensure that our setup is ok; we have to write the release guide;... .) regards, gerhard -- Sent from Gmail Mobile
Re: [VOTE] Release of Apache DeltaSpike 0.1-incubating
+1 And cheers to a great start! +1 -Dan On Mon, Feb 6, 2012 at 17:09, Brian Leathem bleat...@gmail.com wrote: +1 On 12-02-03 05:22 PM, Gerhard Petracek wrote: Hi, I'd like to call a VOTE on releasing Apache DeltaSpike 0.1-incubating. Maven staging repository: https://repository.apache.org/**content/repositories/** orgapachedeltaspike-187/https://repository.apache.org/content/repositories/orgapachedeltaspike-187/ Source release: https://repository.apache.org/**content/repositories/** orgapachedeltaspike-187/org/**apache/deltaspike/deltaspike-** project/0.1-incubating/**deltaspike-project-0.1-** incubating-source-release.ziphttps://repository.apache.org/content/repositories/orgapachedeltaspike-187/org/apache/deltaspike/deltaspike-project/0.1-incubating/deltaspike-project-0.1-incubating-source-release.zip Git release branch: http://s.apache.org/PbX (The branch will be pushed after the required votes passed.) Please take a look at the 0.1-incubating artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes of PPMC (or IPMC) members. This vote is open for 72 hours. --**-- [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why ... --**-- Thanks, Gerhard -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [ANNOUNCE] Release of Apache DeltaSpike
Congratulations on getting the first release out! -M On Sun, Feb 12, 2012 at 11:22 PM, Gerhard Petracek gpetra...@apache.org wrote: The Apache DeltaSpike team is pleased to announce the first release (v0.1-incubating). DeltaSpike consists of a number of portable CDI extensions that provide useful features for Java application developers. The goal of DeltaSpike is to create a de-facto standard of CDI-Extensions that is developed and maintained by the community. Apache DeltaSpike is available in the central Maven repository under Group ID org.apache.deltaspike.*. Release Notes: http://s.apache.org/DeltaSpike_01incubating With this first step we started to merge Apache MyFaces CODI-Core and JBoss Solder. We will release early and often. So take the chance and test the first features provided by this release. In the next release we will add further DeltaSpike-Core features and we will start with further modules. We would be happy to receive your feedback to improve Apache DeltaSpike step by step. Enjoy! Gerhard Petracek -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
