Re: [DISCUSS] deltaspike v0.1
I really like the idea of releasing early and often! +1 2012/1/14 Matthias Wessendorf mat...@apache.org: +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 -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: git commit: DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
thanks for catching this!
In fact we just used more or less random default values for the default
ordinal.
The principle is easy: the higher the ordinal, the more important the value in
this config.
Each ConfigSource has as default ordinal which takes precedence if the
'deltaspike_ordinal=820'
(820 is a sample ordinal)
is not present in the current ConfigSource (e.g. a
META-INF/apache-deltaspike.properties)
Please note that each property file is treated as a distinct ConfigSource and
can define it's own ordinal!
The default ordinals should provide a 'natural order'. But we need to define
this order first.
From less important to most important
1.) property files
2.) environment property (via System.getenv())
3.) system property (via System.getProperty())
4.) JNDI
Wdyt? I'm not really sure about 2. and 3.
Of course, as noted above any user can chagne the default ordinal in his
configuration anyway.
But it should not necessary - convention over configuration rules!
LieGrue,
strub
From: gpetra...@apache.org gpetra...@apache.org
To: deltaspike-comm...@incubator.apache.org
Sent: Saturday, January 14, 2012 6:00 AM
Subject: git commit: DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
Updated Branches:
refs/heads/master f6b229b0a - 06b5c444e
DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
(including important hints needed
for to the changed approach)
Project: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo
Commit:
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/06b5c444
Tree: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/06b5c444
Diff: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/06b5c444
Branch: refs/heads/master
Commit: 06b5c444eb8eec02f94cfc536762f5aa13313166
Parents: f6b229b
Author: gpetracek gpetra...@apache.org
Authored: Sat Jan 14 05:47:05 2012 +0100
Committer: gpetracek gpetra...@apache.org
Committed: Sat Jan 14 05:47:05 2012 +0100
--
.../deltaspike/core/spi/config/ConfigSource.java | 32 ++-
1 files changed, 31 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/06b5c444/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
--
diff --git
a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
index c77cd33..fec7720 100644
---
a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
+++
b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
@@ -35,9 +35,39 @@ public interface ConfigSource
* Any ConfigSource might use it's own though or even return a hardcoded
* in {@link #getOrdinal()}.
*/
- static final String DELTASPIKE_ORDINAL = deltaspike_ordinal;
+ static String DELTASPIKE_ORDINAL = deltaspike_ordinal;
/**
+ * Lookup order:
+ *
+ * ol
+ * liSystem properties (ordinal 400)/li
+ * liEnvironment properties (ordinal 300)/li
+ * liJNDI values (ordinal 200)/li
+ * liProperties file values
(/META-INF/apache-deltaspike.properties) (ordinal 100)/li
+ * /ol
+ * p/
+ * pbImportant Hints for custom implementations/b:/p
+ * p
+ * If a custom implementation should be invoked bbefore/b the default
implementations, use a value gt; 400
+ * /p
+ * p
+ * If a custom implementation should be invoked bafter/b the default
implementations, use a value lt; 100
+ * /p
+ * p
+ *
+ * bIMPORTANT: /b Have a look at the abstract base-implementation
DeltaSpike is using internally,
+ * if a custom implementation should load the ordinal value from the
config-source like the default
+ * implementations provided by DeltaSpike do.
+ *
+ * /p
+ * p/
+ * pReordering of the default order of the config-sources:/p
+ * pExample: If the properties file/s should be used bbefore/b the
other implementations,
+ * you have to configure an ordinal gt; 400. That means, you have to add
e.g. deltaspike_ordinal=401 to
+ * /META-INF/apache-deltaspike.properties . Hint: In case of property
files every file is handled as independent
+ * config-source, but all of them have ordinal 400 by default (and can be
reordered in a fine-grained manner./p
+ *
* @return the 'importance' aka ordinal of the configured values. The
higher, the more important.
*/
int getOrdinal();
The IT test explained
Hi!
Gerhard and I yesterday night did some changes to the testing environment.
Since I'll be on holidays this week I like to quickly explain how it works (or
at least is intended to work):
1.) core/impl/src/test/java will be compiled and tested
1.a.) the core tests will be packaged to a jar and treated as 'attached
artifact'. Thus you'll get a file
~/.m2/repository/org/apache/deltaspike/core/deltaspike-core-impl/0.1-SNAPSHOT/deltaspike-core-impl-0.1-SNAPSHOT-tests.jar
2.) before running the integration-tests,
2.a.) the tests from core have been added as dependency and all the
**/*Test.class classes will get extracted to
core/integration-test/target/coretests/
2.b.) There is now a 2nd surefire execution which picks up those tests via
configuration
testClassesDirectory${project.build.directory}/coretests//testClassesDirectory
..
I already deleted a few of our duplicated tests, but I'm sure there is yet more
to do...
LieGrue,
strub
PS:
I'm almost sure I broke a few container tests because we still figure how we
can set the ProjectStage on any remote Arquillian container.
Aslak, is there a way to programmatically 'deploy' a JNDI entry or system
property to the remote container under test?
Re: git commit: DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
here we really just talk about the better default (which can be changed
easily - in both cases).
the following part is just important for projects which use both - jndi and
system properties for the same low-level config-entry (e.g. the
project-stage)
from the perspective of our users:
the current order means: if users need jndi to
overrule system properties, they need to add an additional jndi value
(the higher ordinal)
your suggestion means: if users need system properties to overrule
jndi values,they need to add an additional system property (the
higher ordinal)
regards,
gerhard
2012/1/14 Mark Struberg strub...@yahoo.de
thanks for catching this!
In fact we just used more or less random default values for the default
ordinal.
The principle is easy: the higher the ordinal, the more important the
value in this config.
Each ConfigSource has as default ordinal which takes precedence if the
'deltaspike_ordinal=820'
(820 is a sample ordinal)
is not present in the current ConfigSource (e.g. a
META-INF/apache-deltaspike.properties)
Please note that each property file is treated as a distinct ConfigSource
and can define it's own ordinal!
The default ordinals should provide a 'natural order'. But we need to
define this order first.
From less important to most important
1.) property files
2.) environment property (via System.getenv())
3.) system property (via System.getProperty())
4.) JNDI
Wdyt? I'm not really sure about 2. and 3.
Of course, as noted above any user can chagne the default ordinal in his
configuration anyway.
But it should not necessary - convention over configuration rules!
LieGrue,
strub
From: gpetra...@apache.org gpetra...@apache.org
To: deltaspike-comm...@incubator.apache.org
Sent: Saturday, January 14, 2012 6:00 AM
Subject: git commit: DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
Updated Branches:
refs/heads/master f6b229b0a - 06b5c444e
DELTASPIKE-50 javadoc for ConfigSource#getOrdinal
(including important hints needed
for to the changed approach)
Project: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo
Commit:
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/06b5c444
Tree:
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/06b5c444
Diff:
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/06b5c444
Branch: refs/heads/master
Commit: 06b5c444eb8eec02f94cfc536762f5aa13313166
Parents: f6b229b
Author: gpetracek gpetra...@apache.org
Authored: Sat Jan 14 05:47:05 2012 +0100
Committer: gpetracek gpetra...@apache.org
Committed: Sat Jan 14 05:47:05 2012 +0100
--
.../deltaspike/core/spi/config/ConfigSource.java | 32 ++-
1 files changed, 31 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/06b5c444/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
--
diff --git
a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
index c77cd33..fec7720 100644
---
a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
+++
b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigSource.java
@@ -35,9 +35,39 @@ public interface ConfigSource
* Any ConfigSource might use it's own though or even return a
hardcoded
* in {@link #getOrdinal()}.
*/
-static final String DELTASPIKE_ORDINAL = deltaspike_ordinal;
+static String DELTASPIKE_ORDINAL = deltaspike_ordinal;
/**
+ * Lookup order:
+ *
+ * ol
+ * liSystem properties (ordinal 400)/li
+ * liEnvironment properties (ordinal 300)/li
+ * liJNDI values (ordinal 200)/li
+ * liProperties file values
(/META-INF/apache-deltaspike.properties) (ordinal 100)/li
+ * /ol
+ * p/
+ * pbImportant Hints for custom implementations/b:/p
+ * p
+ * If a custom implementation should be invoked bbefore/b the
default implementations, use a value gt; 400
+ * /p
+ * p
+ * If a custom implementation should be invoked bafter/b the
default implementations, use a value lt; 100
+ * /p
+ * p
+ *
+ * bIMPORTANT: /b Have a look at the abstract
base-implementation DeltaSpike is using internally,
+ * if a custom implementation should load the ordinal value from
the config-source like the default
+ * implementations provided by DeltaSpike do.
+ *
+ * /p
+ * p/
+ * pReordering of the default
Re: [DISCUSS] deltaspike v0.1
+1 On Sat, Jan 14, 2012 at 3:06 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: I really like the idea of releasing early and often! +1 2012/1/14 Matthias Wessendorf mat...@apache.org: +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 -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [DISCUSS] deltaspike v0.1
+1 Sent from my iPhone On Jan 14, 2012, at 7:30, John D. Ament john.d.am...@gmail.com wrote: +1 On Sat, Jan 14, 2012 at 3:06 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: I really like the idea of releasing early and often! +1 2012/1/14 Matthias Wessendorf mat...@apache.org: +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 -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
Re: [ANNOUNCE] Welcome Dan Allen and Lincoln Baxter III as DeltaSpike committers
Thanks everyone. I'm very glad to be a part of this group, and also my first Apache project! ~Lincoln On Fri, Jan 13, 2012 at 3:55 PM, Jason Porter lightguard...@gmail.comwrote: We expect big things from both of you :) On Fri, Jan 13, 2012 at 13:24, Dan Allen dan.j.al...@gmail.com wrote: Yeah! A very proud moment for me. Thank you! -Dan On Fri, Jan 13, 2012 at 14:12, Mark Struberg strub...@yahoo.de wrote: Hi! The DeltaSpike team is happy to welcome Dan Allen and Lincoln Baxter III as new committers to our project. Welcome folks, and we hope you enjoy being part of this community! the Apache DeltaSpike PPMC -- 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 -- 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 -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com Keep it Simple
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: IP discussion
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? On Sat, Jan 14, 2012 at 13:13, Matt Benson gudnabr...@gmail.com wrote: 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 ;) ), It worked, no worries. 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 -- 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
