Re: intermediate vcs
Since we always release all of DeltaSpike in one go, the versions are always the same. This is really convenient to just add a property properties deltaspike.version0.1-SNAPSHOT/deltaspike.version /properties and use that for all your project. LieGrue, strub From: Shane Bryzak sbry...@gmail.com To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, December 15, 2011 2:10 PM Subject: Re: intermediate vcs At the bare minimum it can contain all of the DeltaSpike module versions. Even if they're all the same, it still adds convenience. On Thu, Dec 15, 2011 at 11:07 PM, Mark Struberg strub...@yahoo.de wrote: yes, that sounds good. But is sometimes really heavily depending on the container you let this run in. So that part might become tricky. We should add it on our todo list for later evaluation. LieGrue, strub From: Shane Bryzak sbry...@gmail.com To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, December 15, 2011 2:03 PM Subject: Re: intermediate vcs Looking pretty good. Do you think we should add a BOM (Bill Of Materials) containing all of the dependencies and versions? We find that it makes life much easier for our users if they can simply import the bom and not have to worry about dependency version hell. On Thu, Dec 15, 2011 at 8:34 PM, Mark Struberg strub...@yahoo.de wrote: I started with the initial project structure and some maven stuff. I followed the intended structure from our Wiki. Please review. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, December 15, 2011 10:52 AM Subject: intermediate vcs hi @ all, since we have started several discussions, it makes sense to prototype some parts immediately. mark and i suggest to start at [1] while the infra team is preparing our repository, ldap group,... if you would like to join, send your user-name and you will be added. regards, gerhard [1] http://goo.gl/HmNBV
Re: intermediate vcs
lightguard On Thu, Dec 15, 2011 at 02:52, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi @ all, since we have started several discussions, it makes sense to prototype some parts immediately. mark and i suggest to start at [1] while the infra team is preparing our repository, ldap group,... if you would like to join, send your user-name and you will be added. regards, gerhard [1] http://goo.gl/HmNBV -- 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: basic decisions - package and class naming
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 - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, December 12, 2011 7:21 PM Subject: Re: basic decisions - package and class naming I'm good for the package naming, include the JSF split, if we're going to be cutting artifacts via the shade plugin (and we only get one repo so everything has to be done in one place) that will make it much easier. Also it will help users know what they're using when the send in bug reports. If they're JSF2 stuff in a JSF12 project that'll be much easier to spot. If we don't have an api package then I certainly want to see internal (I like seeing that in the package better than impl, imo it means more and it certainly signifies to me that those classes are off limits for usage by the user). I'd like to see SPI though, I think we'll need that and it more clearly demarcates for extension writers what they should be using. Anything we can do to make things easier for users w/o having to explicitly write globs of documentation to explain something (in other words making things self documented) is a huge plus in my book. On Mon, Dec 12, 2011 at 05:47, Jakob Korherr jakob.korh...@gmail.comwrote: Hi, +1 for the package names. IMO we can drop the api package, but we really should keep the impl (or internal) package. Otherwise - as Gerhard stated - users will start to use implementation classes without even noticing (remember: not everyone uses impl-dependencies with scope=runtime). Regards, Jakob 2011/12/12 Gerhard Petracek gpetra...@apache.org: @package names: +1 @shane: currently we don't have issues with it (see what we are doing in codi with the shade plugin) to skip 'api' as package would mean that it might be harder to use our bundles (e.g. extval doesn't have api/impl packages and users started to use impl classes, utils,... at least until we marked them as internal). +/- 0 @other rules: no names which start with an underscore regards, gerhard 2011/12/12 Shane Bryzak sbry...@gmail.com On Mon, Dec 12, 2011 at 9:24 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! Back to work after being sick for a week. I think it's time to start hacking on DeltaSpike! But before we do so, I'd like to clarify a few basic things a.) package names I'd suggest org.apache.deltaspike.core.* for our core stuff org.apache.deltaspike.jpa.* for JPA +1 for the org.apache.deltaspike package prefix, followed by the module name. org.apache.deltaspike.jsf.jsf12.* for JSF-1.2 org.apache.deltaspike.jsf.jsf20.* for JSF-2.0, etc -1 for the separation of JSF packages, I think this may cause problems longer term, especially when we get JSF3, JSF4 etc. The way I would handle this is to have a separate module for each JSF version, but re-use the org.apache.deltaspike.jsf package name. In general most of our project parts will contain the following 3 sub- parts *) api - the parts meant to be imported in customer projects with Maven scopecompile *) impl - does the actual work, not intended to be used in customer projects diretly. Thus Maven scoperuntime only. *) spi - parts meant to be used for extending the default functionality. Up for discussion, not sure if we really need it! This might also be done directly in impl, users can still Matze mentioned that he doesn't like to have 'api' in the package name. What do you like to use instead to distinguish between those? Having an own package name probably makes it easier to use the maven-shade-plugin. Any opinions? I would prefer not to have 'api' or 'impl' in the package name either. We never had them in any of the Seam modules that I'm aware of, and there was no problem with
Re: basic decisions - coding conventions
hi @ all,
i created [1] for collecting the suggestions.
if you don't like one of the mentioned conventions, add your own suggestion.
i'll start a vote about it on monday.
regards,
gerhard
[1] https://issues.apache.org/jira/browse/DELTASPIKE-12
2011/12/12 Jason Porter lightguard...@gmail.com
+1 to 120
The rest I'm okay with as well.
On Mon, Dec 12, 2011 at 11:24, Jason Porter lightguard...@gmail.com
wrote:
On Mon, Dec 12, 2011 at 04:37, 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();
}
or
if() {
dings();
}
but we should only use one stile throughout the whole code.
+1
3.) force bracelets
no
if()
dosomething;
+1
without bracelets. Instead force:
if()
{
dosomething;
}
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
Line width? Indentation width?
--
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: 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 - coding conventions
imo whitespace is a must, it helps with readability. I'm fine with
everything else
On Thu, Dec 15, 2011 at 14:02, Matthias Wessendorf mat...@apache.orgwrote:
5) a space between keyword and round bracket (e.g. if (...) instead of
if(...))
6) a space before and after an operand (e.g. a = 1 + 2 or a != b
instead of a=1+2 or a!=b)
5 and 6 are not soo important, but IMO very nice to have.
I hate: if(){
:-)
Regards,
Jakob
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
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
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: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
at [1] i summarized what we have agreed on so far. - let's continue with the util methods. suggestions for the util methods: public T T getContextualReferenceByClass(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) public T T getContextualReferenceByName(String name, boolean optionalBeanAllowed, ClassT targetType) public T T getContextualReferenceByBean(BeanT bean, boolean optionalBeanAllowed, ClassT targetType) and maybe something like public T ListT getContextualReferencesByClass(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) in codi we added the util methods later on. with those util methods it's more than just a BeanManagerProvider - maybe we find a better name. furthermore we have a static method called isActive which allows to check if the bm and therefore the environment is up and running (we delegate to it in CodiUtils#isCdiInitialized which we are using as a part of our lazy init logic which is required in some cases due to the early conifg approach of mojarra). regards, gerhard [1] http://goo.gl/7n2wj 2011/12/15 Christian Kaltepoth christ...@kaltepoth.de +1 (non-binding) I really like the proposed solution and I think it's cleaner than the Solder approach. What about obtaining the BeanManager from the ServletContext (which is specified in CDI 1.1) as an alternative to the JNDI lookup? Do we need this? It could be interesting for environments that don't support JNDI (like GAE for example). Solder does this but it requires the ServletContext to be stored in a ThreadLocal for each request which isn't very nice. I don't think an abstract base class like Solder's BeanManagerAware is required any more. Obtaining the BM with the proposed API is so simple that such a base class doesn't make sense. Christian 2011/12/14 Jason Porter lightguard...@gmail.com Here we go, right thread this time. The abstract class in Solder is https://github.com/seam/solder/blob/develop/api/src/main/java/org/jboss/solder/beanManager/BeanManagerAware.java . You'll have to follow the code around to see what it exactly does. On Wed, Dec 14, 2011 at 12:50, Jason Porter lightguard...@gmail.com wrote: +1 I think that's a better solution than what we have in Solder. Ours looks up the BM first in JNDI and then the servlet context if it's not found (for use in basic servlet containers). Not sure if that's a better approach than storing it, I do kind of like that approach though. It doesn't sound like it would be culprit to any memory leaks now that I think about it a bit more. That was my one issue at first. The way we do it in Solder is to have an abstract class so you'd have to extend that class to get the BM. I'm wondering if you've found cases where using the observer is too late or you need it the BM at creation time of the bean. On Wed, Dec 14, 2011 at 12:36, Mark Struberg strub...@yahoo.de wrote: +1 btw, it's worth mentioning that the resolution mechanism will first look up the BeanManager in JNDI. And only if it isn't available there, it will use the one from the system event. Also we store the BeanManager in a MapClassLoader, BeanManager to be able to handle EAR situations. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 14, 2011 8:28 PM Subject: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider hi @ all, fyi: please check [1] before you answer. [2] provides a short introduction as well as the basic usage. the basic concept: an observer for AfterBeanDiscovery stores the bean-manager for the current application (stored by classloader). (see BeanManagerProvider#setBeanManager) the api: BeanManagerProvider.getInstance().getBeanManager() later on we added some util methods to the api e.g. #getContextualReference. the suggestion is to keep the basic concept, usage and api and to re-visit the util methods (e.g. CodiUtils provides some nice internal util methods - we could promote some of them). please send +1, +0 or -1 because... for the basic idea as well as the basic concept which is based on the AfterBeanDiscovery event. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage#CoreUsage-BeanManagerProvider [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
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
Shane's probably tired of hearing me harp on docbook, oh well :) Here's a tool that's nice to use, output is good and it has a great community following: http://sphinx.pocoo.org/ If we want to look into it, great, if we go back to docbook, great, I'll stop complaining and just use it. Buildable docs is fine, if we have to craft a maven plugin, fine. +1 for a set of a allowed docbook elements should we go with docbook +1 for continuing discussions on the mailing list. On Thu, Dec 15, 2011 at 16:53, Gerhard Petracek gerhard.petra...@gmail.comwrote: +1 for buildable docs if we keep the documentation inside the git repository. -1 for anything else than a maven plugin. if we don't have one for the documentation tool, we can impl. it (or we use a different tool). (+0 for docbook) +1 for an alternative, if it makes sense. @discussions: +1 for continuing to use the mailing list for the main discussion/s - it's easier to follow, mirrored, ... . regards, gerhard 2011/12/16 Jason Porter lightguard...@gmail.com We haven't been discussing other issues on jira, but on the mailing list. Sent from my iPhone On Dec 15, 2011, at 16:31, Shane Bryzak sbry...@gmail.com wrote: You need to add your objections to the issue ;) Buildable by Maven just means we can build the documentation as part of the standard project build/release process. On Fri, Dec 16, 2011 at 9:25 AM, Jason Porter lightguard...@gmail.com wrote: -1 to DocBook it's difficult to get people up to speed and is a turn off for new contributors. Also what exactly do you mean by buildable with maven? Does that mean we need a plugin? Can an ant task or other scripting work? On Thu, Dec 15, 2011 at 15:39, Shane Bryzak (Created) (JIRA) j...@apache.org wrote: Choose documentation format and tools - Key: DELTASPIKE-13 URL: https://issues.apache.org/jira/browse/DELTASPIKE-13 Project: DeltaSpike Issue Type: Task Reporter: Shane Bryzak Assignee: Gerhard Petracek We need to decide on a documentation format for the DeltaSpike documentation. Requirements are: 1. Kept in the VCS with the DeltaSpike codebase 2. Buildable with Maven 3. Can generate multiple formats, including HTML and PDF Currently the industry standard is DocBook, however there may be other alternatives which are more suitable. Suggestions welcome here. -- 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 -- 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
