Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

[Cody Lerum]

+1

1.9.x seems very stable with minimal updates so it is unlikely to be
much of a burden to keep it alive for pre-Jakarta use.

I could see some people say setting a JDK 17 minimum would be
aggressive, but those starting new Jakarta projects or going through
the upgrade work for an older project should really be moving up to
it.

-C

On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg  wrote:
>
> Hi folks!
>
> There was a bunch of user requests on the mailing list  to add support for 
> Jakarta enterprise namespaces.
> I tried to implement this via shading but it seems not to be sufficient.
> The problem with shading is that the poms only have classifier to access 
> deltaspike.
> This is especially a problem with transitive dependencies.
>
> The other point is that we had many discussions about shipping an upgraded 
> version of DeltaSpike and deprecate/remove some obsolete APIs.
> So let's go big and why not move up to jakartaEE namespace and Java17 at the 
> same time?
>
> Potential candidates for dropping coming to my mind:
>
> .) BeanManagerProvider/BeanProvider. We historically kept this for 2 reasons. 
> 1.) backward compatibility with CDI-1.0, 2.) in EARs this is still the only 
> way which works to properly access the BeanManager on all containers. 
> CDI.current() is sadly broken in EARs in almost all containers. But since 
> EARs might go away in JakartaEE anyways, I'm fine with dropping it.
>
> .) servlet module. Injecting the various servlet information objects like 
> HttpServletRequest, HttpSession etc is nowadays specified by the CDI spec as 
> well.
>
> .) Many parts of the JSF module are nowadays not needed anymore as well. 
> Remember the times when there was no injection into PhaseListeners and 
> FacesConverters? We did have support for it since ages, the spec added this 
> much later, but they finally did.
>
> .) bean validation module. Those parts are imo all part of the spec nowadays
>
> .) scheduler. I'm not sure about that one. It probably would make sense to 
> implement an own smallish scheduler based on ScheduledExecutor instead of 
> going fully blown quartz?
>
>
>
> wdyt?
>
> I'd go on and create a new umbrella ticket for all the work.
>
> LieGrue,
> strub
>
>

Re: [VOTE] release Apache DeltaSpike-1.8.1

[Cody Lerum]

+1

On Sat, Dec 30, 2017 at 9:39 AM, Mark Struberg
 wrote:
> Hi folks!
>
> I did run the necessary steps for releasing DeltaSpike-1.8.1
>
> The following bugs and improvements got implemented:
>
> Bug
>
> • [DELTASPIKE-1252] - data-documentation missing Optional return value
> • [DELTASPIKE-1271] - [perf] cache Transactional
> • [DELTASPIKE-1272] - ConfigResolver asList breaks if no value is 
> found
> • [DELTASPIKE-1275] - Build fails on Linux because Testclass 
> filenames are to long
> • [DELTASPIKE-1278] - PropertyFileConfig does not respect optional on 
> external resources
> • [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to 
> persistenf factory config using "javax.persistence.bean.manager"
> • [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no 
> configured value exists
> • [DELTASPIKE-1288] - Default values are not interpolated
> • [DELTASPIKE-1294] - Secured Stereotypes are not applied to 
> inherited methods
> • [DELTASPIKE-1296] - PropertyFileConfig doesn't work with internal 
> extensions
> • [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is 
> always empty
> • [DELTASPIKE-1303] - @Configuration proxies should support List 
> without converters
> • [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple redirects
> • [DELTASPIKE-1306] - IE sometimes doesn't set window.name correctly
> • [DELTASPIKE-1307] - Deltaspike JSF: XSS WindowIdHtmlRenderer.java
> Improvement
>
> • [DELTASPIKE-940] - @Transactional and @EntityManagerConfig each use 
> a different method to resolve EntityManagers
> • [DELTASPIKE-1070] - Refactor RepositoryComponent/s
> • [DELTASPIKE-1258] - skip flush with one EntityManager
> • [DELTASPIKE-1267] - Remove second factory mechanism of 
> QueryBuilder's
> • [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
> • [DELTASPIKE-1269] - [perf] Cache singleResultType per method
> • [DELTASPIKE-1270] - [perf] cache requiresTransaction per method
> • [DELTASPIKE-1274] - Refactor proxy-module / improve performance
> • [DELTASPIKE-1279] - SimpleSecurityViolation needs equals/hashcode
> • [DELTASPIKE-1283] - Placeholders not supported for defaults
> • [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse 
> BeanManager
> • [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
> • [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment on 
> Weld by default
> Task
>
> • [DELTASPIKE-1259] - upgraded version numbers
> • [DELTASPIKE-1297] - add test with a customized DynamicMockManager
> • [DELTASPIKE-1298] - document customization of a DynamicMockManager
> Test
>
> • [DELTASPIKE-1273] - Test against OWB 2
>
>
>
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/
>
> The source release can be found at
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/
> sha1 is 4d7db712629261a92e6dcddfdcb7a446015bf432
>
>
> Please VOTE:
>
> [+1] yea, let's ship it
> [+0] meh, don't care
> [-1] yikes, stop because ${showstopper}
>
> The VOTE is open for 72h.
>
>
> Here is my own +1
>
> txs and LieGrue,
> strub

Re: Cutting over to Java 7

[Cody Lerum]

At this point it seems the main driver for dropping Java6 is to
discourage its use. I think there is sufficient discouragement
elsewhere and anyone with active or new projects is working towards or
planning for Java7/8.

+1 for keeping Java6 until the next major bump.

On Thu, Apr 7, 2016 at 7:25 AM, Mark Struberg  wrote:
> Agree, we don't gain much with moving to Java7.
>
> Thus I'd say that we keep Java6/CDI-1.0 and have the next major version bump 
> (aka DeltaSpike-2.x) targeting Java8 and CDI-2.0. But of course keep a ds-1.x 
> maintenance branch even after that for a while.
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Thursday, 7 April 2016, 14:42, Gerhard Petracek  
>> wrote:
>> > as mentioned in the initial discussion i also don't see a real benefit for
>> us as a community (to drop the java 6 support at this point).
>> in the end ds targets ee6 + supports ee7 servers (including optional
>> features).
>> ee6 isn't bound to java 6 technically, however, e.g. some vendors require
>> it...
>>
>> regards,
>> gerhard
>>
>>
>>
>>
>> 2016-04-07 13:18 GMT+02:00 Rooda, William (John.) :
>>
>>>  Ford has an internal “shared farm” of servers that our applications can
>>>  use. The shared farm is Websphere Application Server 8.0.0.x.  This only
>>>  has Java6 available.  While some teams go out and spend the money to
>>>  procure their own servers outside of the shared farm, this is prohibitively
>>>  expensive without a powerful use case.
>>>
>>>
>>>
>>>  Our Java applications won't have a server offering in our internal
>> shared
>>>  farm for Java 7 until 4Q2016 or 1Q2017 at the earliest. We plan on
>>>  developing almost all applications against Java6 until that time, and
>>>  unfortunately we have to re-evaluate continuing to use at an enterprise
>>>  level any open source software that no longer patches and supports Java6
>>>  due to the risk it introduces to our applications. We understand that this
>>>  makes us an outlier in the community of DeltaSpike users.
>>>
>>>
>>>
>>>  Thanks,
>>>
>>>
>>>
>>>  ~john
>>>
>>>
>>>  From: John D. Ament [mailto:johndam...@apache.org]
>>>  Sent: Thursday, April 07, 2016 7:13 AM
>>>  To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
>>>  Cc: Rooda, William (John.); Shvartsman, Oleg (O.I.); Hall, Todd (T.B.)
>>>  Subject: Re: Cutting over to Java 7
>>>
>>>  Hi Marvin,
>>>
>>>  Thanks for the input.  You can find our discussion/vote thread from last
>>>  month here:
>>>
>> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAOqetn_vo69sx-yQjLt%3DQpfdRXgXVqu7NiobanLgXKOOr6Co0Q%40mail.gmail.com%3E
>>>
>>>  The curious thing about your note - the WebSphere version I've seen the
>>>  Ford team mention a few times requires Java 7.  In general, EE 7 systems
>>>  were built for Java 7 support (JMS made use of autocloseable is one I can
>>>  think of off the top of my head).
>>>
>>>  As mentioned, there's still a plan to support the 1.6.x line.  If you
>> guys
>>>  find any issues that you need to stay on 1.6.x, please feel free to raise
>>>  them and we can address as additional 1.6.x patches.
>>>
>>>  John
>>>  On Thu, Apr 7, 2016 at 6:42 AM Marvin Toll >>  > wrote:
>>>  A data point: Ford Motor Company is on Java 6.  Given our portfolio of
>>>  4,000 applications (a subset of which are Java) - it is difficult to know
>>>  how long a migration to Java 7 will take.  It was scheduled to begin in
>>>  calendar year 2016 - the current "begin" target is 2017.
>>>
>>>  _Marvin
>>>
>>>  -Original Message-
>>>  From: John D. Ament [mailto:johndam...@apache.org>>  johndam...@apache.org>]
>>>  Sent: Wednesday, April 6, 2016 10:14 PM
>>>  To: deltaspike
>> >>  >>
>>>  Subject: Cutting over to Java 7
>>>
>>>  All,
>>>
>>>  I wanted to get opinions for how to cut over to Java 7.
>>>
>>>  There's two ways I've done similar cut overs in the past, wanted to
>> share
>>>  them and build out some ideas.
>>>
>>>  1. Continue maintenance on 1.6 for x months.  When we decide that we're
>>>  going to cut a 1.7 we do the switch then.
>>>
>>>  2. Decide now that the next release is going to be planned as 1.7.  If we
>>>  need to do maintenance on 1.6 we branch from the tag and merge back in when
>>>  done.
>>>
>>>  The former is safer, but will take longer.  The last minor release had the
>>>  most patch releases on it, 4.  The latter is more practical and shows
>>>  implementation much quicker.  It creates a bit more overhead as we'd
>> need
>>>  to merge branches.  In the 4.5 years of deltaspike, we haven't had to
>> do it
>>>  thus yet.  I suspect that given our user base, #2 would be acceptable since
>>>  most everyone's using Java 7+, so it seems a small chance that we'd
>> run
>>>  into a JVM difference.  I'm not sure if others have different ideas to
>>>  throw out.
>>>
>>>  John
>>>

Re: [VOTE] Release of Apache DeltaSpike 1.6.0

[Cody Lerum]

+1
On Apr 2, 2016 16:46, "Gerhard Petracek"  wrote:

> Hi,
>
> I was running the needed tasks to get the 24th release of Apache DeltaSpike
> out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and the release-branch at [4].
> They will get pushed to the ASF repository once the vote passed.
>
> Please take a look at the 1.6.0 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see
> [5]).
>
> 
> [ ] +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
>
> [1]
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1034/
> [2]
>
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1034/org/apache/deltaspike/deltaspike/1.6.0/deltaspike-1.6.0-source-release.zip
> [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.6.0
> [4] https://github.com/os890/deltaspike-vote/tree/ds-1.6.0
> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes
>

Re: [VOTE] Release of Apache DeltaSpike 1.5.3

[Cody Lerum]

+1

On Fri, Feb 5, 2016 at 6:01 AM, Gerhard Petracek  wrote:
> Hi,
>
> I was running the needed tasks to get the 22th release of Apache DeltaSpike
> out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and the release-branch at [4].
> They will get pushed to the ASF repository once the vote passed.
>
> Please take a look at the 1.5.3 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see [5]).
>
> 
> [ ] +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
>
> [1]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1032/
> [2]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1032/org/apache/deltaspike/deltaspike/1.5.3/deltaspike-1.5.3-source-release.zip
> [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.5.3
> [4] https://github.com/os890/deltaspike-vote/tree/ds-1.5.3
> [5] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: v1.5.0 instead of v1.4.3

[Cody Lerum]

+0

On Tue, Aug 4, 2015 at 12:37 AM, Christian Kaltepoth
christ...@kaltepoth.de wrote:
 +0

 2015-08-03 23:38 GMT+02:00 Daniel Cunha daniels...@gmail.com:

 +1

 On Mon, Aug 3, 2015 at 6:33 PM, Romain Manni-Bucau rmannibu...@gmail.com
 wrote:

  +1
  Le 3 août 2015 22:44, John D. Ament johndam...@apache.org a écrit :
 
   +0
   These are all bug fixes, no major api changes that i can tell.
  
   On Mon, Aug 3, 2015 at 4:24 PM Gerhard Petracek gpetra...@apache.org
   wrote:
  
hi @ all,
   
if there are no objections, i'll change the version number to 1.5.0
before the next release.
   
reasons:
 - security fix
 - changes for window-handling
   
regards,
gerhard
   
  
 



 --
 Best regard,
 Daniel Cunha (soro)




 --
 Christian Kaltepoth
 Blog: http://blog.kaltepoth.de/
 Twitter: http://twitter.com/chkal
 GitHub: https://github.com/chkal

Re: [VOTE] Release of Apache DeltaSpike 1.4.2

[Cody Lerum]

Builds + tests + looks fine locally for me.

+1

On Sun, Jul 19, 2015 at 11:11 AM, Gerhard Petracek gpetra...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the 18th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).

 The tag is available at [3] and the release-branch at [4].
 They will get pushed to the ASF repository once the vote passed.

 Please take a look at the 1.4.2 artifacts and vote!

 Please note:
 This vote is majority approval with a minimum of three +1 votes (see [5]).

 
 [ ] +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

 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1028/
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1028/org/apache/deltaspike/deltaspike/1.4.2/deltaspike-1.4.2-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-1.4.2
 [4] https://github.com/os890/deltaspike-vote/tree/ds-1.4.2
 [5] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] Release of Apache DeltaSpike 1.2.1

[Cody Lerum]

+1

On Sun, Dec 21, 2014 at 2:06 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 @thomas:
 see [1].

 regards,
 gerhard

 [1]
 https://github.com/os890/deltaspike-vote/blob/master/deltaspike/readme/ReleaseNotes-1.2.1.txt



 2014-12-21 21:29 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 +1
 it would be great if you could add a link to the resolved jira issues in
 the future

 2014-12-21 21:18 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:

  +1
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2014-12-20 23:56 GMT+01:00 Gerhard Petracek gpetra...@apache.org:
   +1
  
   regards,
   gerhard
  
  
  
   2014-12-20 23:56 GMT+01:00 Gerhard Petracek gpetra...@apache.org:
  
   Hi,
  
   I was running the needed tasks to get the 14th release of Apache
   DeltaSpike out.
   The artifacts are deployed to Nexus [1] (and [2]).
  
   The tag is available at [3] and will get pushed to the ASF repository
  once
   the vote passed.
  
   Please take a look at the 1.2.1 artifacts and vote!
  
   Please note:
   This vote is majority approval with a minimum of three +1 votes (see
   [4]).
  
   
   [ ] +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
  
   [1]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1018
   [2]
  
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1018/org/apache/deltaspike/deltaspike-project/1.2.1/deltaspike-project-1.2.1-source-release.zip
   [3]
  https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.2.1
   [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
 

Re: [VOTE] Release of Apache DeltaSpike 1.0.2

[Cody Lerum]

+1

On Mon, Aug 18, 2014 at 7:31 PM, Jason Porter lightguard...@gmail.com wrote:
 +1—
 Sent from Mailbox

 On Sun, Aug 17, 2014 at 7:16 AM, Gerhard Petracek gpetra...@apache.org
 wrote:

 Hi,
 I was running the needed tasks to get the 10th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).
 The tag is available at [3] and will get pushed to the ASF repository once
 the vote passed.
 Please take a look at the 1.0.2 artifacts and vote!
 Please note:
 This vote is majority approval with a minimum of three +1 votes (see [4]).
 
 [ ] +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
 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1013
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1013/org/apache/deltaspike/deltaspike-project/1.0.2/deltaspike-project-1.0.2-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.2
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] [Closed] (DELTASPIKE-685) Guard against null FacesContext in Exception Handler Bridge

[Cody Lerum (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cody Lerum closed DELTASPIKE-685.
-

Resolution: Fixed

 Guard against null FacesContext in Exception Handler Bridge
 ---

 Key: DELTASPIKE-685
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-685
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module
Affects Versions: 1.0.1
Reporter: Cody Lerum
Assignee: Cody Lerum
 Fix For: 1.0.2






--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] logo-color

[Cody Lerum]

+1 Blue

On Sat, Jun 14, 2014 at 12:55 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 hi @ all,

 this second vote is about the color and therefore the final logo.

 i've uploaded the candidates provided by jim at [1]-[4].
 please send a +1 for one of them.

 regards,
 gerhard

 [1] http://s.apache.org/DS_LOGO_BLUE_VOTE2
 [2] http://s.apache.org/DS_LOGO_ORANGE_VOTE2
 [3] http://s.apache.org/DS_LOGO_PURPLE_VOTE2
 [4] http://s.apache.org/DS_LOGO_RED_VOTE2

Re: [VOTE] Release of Apache DeltaSpike 1.0.0

[Cody Lerum]

+1

On Sat, Jun 14, 2014 at 10:00 AM, Gerhard Petracek gpetra...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the 8th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).

 The tag is available at [3] and will get pushed to the ASF repository once
 the vote passed.

 Please take a look at the 1.0.0 artifacts and vote!

 Please note:
 This vote is majority approval with a minimum of three +1 votes (see [4]).

 
 [ ] +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

 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1008/
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1008/org/apache/deltaspike/deltaspike-project/1.0.0/deltaspike-project-1.0.0-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-1.0.0
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: DeltaSpike Revision Version 3

[Cody Lerum]

#1

On Thu, May 29, 2014 at 1:26 PM, James Parenti ja...@visuale.net wrote:
 Hello everyone:

 This is a link to another set of revisions. The emblems shown are those that 
 have been commented favorably upon. As much as I like the “Geometric” font 
 logo, the more I look at it the less I like it or at least I don’t know how 
 well it will play in the long run.

 Of the included emblem logos this time, I think 1. could work if it had a 
 little more of a refinement. I tried to hint at the idea of a data “spike” as 
 though it were coming through a chart readout – I don’t know if that’s quite 
 clear. I also keep wanting to think that #2 is almost like a business shirt 
 with a red tie on so I don’t know  if that’ll work either.

 Number 3 is probably personal favorite out of the entire group right now – I 
 think the simpler the better is always the best path to take with a logo. 
 I’ve included number 4 for comparison with number 3, though I like them both.

 Does anyone else have anything they’d like to add? Or are there perhaps some 
 some logos out of the last batch that anyone would like to have another look 
 at?


 https://www.dropbox.com/s/pks4xpwoszohr0m/Red%20Hat%20Delta%20Spike%20Version%203_UpdatedEmblemLogos1.jpg

 Jim

 PS - here again is the link to the previous batch: 
 https://www.dropbox.com/sh/6doraoq6ap3qyr3/AABXLSF-LyxEEL29jyHkyWCUa

 --
 James Parenti
 Visuale
 1800 W. Cornelia Avenue
 Chicago, IL 60657
 Office: 773.234.0178
 Cell: 773.469.8843
 Skype: jamesparenti
 Google: google.com/+JamesParentiVisuale
 http://www.visuale.net
 ja...@visuale.net

Re: [VOTE] Release of Apache DeltaSpike 0.7

[Cody Lerum]

+1

builds and tests weld and owb fine on win 8.1 x64 7u51

On Wed, Apr 30, 2014 at 2:22 PM, Gerhard Petracek gpetra...@apache.org wrote:
 Hi,

 I was running the needed tasks to get the 7th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).

 The tag is available at [3] and will get pushed to the ASF repository once
 the vote passed.

 Please take a look at the 0.7 artifacts and vote!

 Please note:
 This vote is majority approval with a minimum of three +1 votes (see [4]).

 
 [ ] +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

 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1003/org/apache/deltaspike/deltaspike-project/0.7/deltaspike-project-0.7-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.7
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] #2 Release of Apache DeltaSpike 0.6

[Cody Lerum]

+1

builds fine on win 8x64 j7u51 with both weld and owb

On Mon, Mar 17, 2014 at 4:43 PM, Mark Struberg strub...@yahoo.de wrote:

 +1


 sig fine, rat passes, build runs without errors, all tests pass, hash sums 
 fine, LICENSE and NOTICE files in place and content is fine.

 txs for running the release!


 LieGrue,
 strub





 On Sunday, 16 March 2014, 18:32, Gerhard Petracek gpetra...@apache.org 
 wrote:
  Hi,

 I was running the needed tasks to get the 6th release of Apache DeltaSpike
 out.
 The artifacts are deployed to Nexus [1] (and [2]).

 The tag is available at [3] and will get pushed to the ASF repository once
 the vote passed.

 Please take a look at the 0.6 artifacts and vote!

 Please note:
 This vote is majority approval with a minimum of three +1 votes (see
 [4]).

 
 [ ] +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

 [1]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1001/
 [2]
 https://repository.apache.org/content/repositories/orgapachedeltaspike-1001/org/apache/deltaspike/deltaspike-project/0.6/deltaspike-project-0.6-source-release.zip
 [3] https://github.com/os890/deltaspike-vote/tree/deltaspike-project-0.6
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] Replace @Web with a common DeltaSpike qualifier

[Cody Lerum]

+1

To be clear it is @DeltaSpike (capital D capital S)

-C

On Mon, Feb 24, 2014 at 5:16 AM, Mark Struberg strub...@yahoo.de wrote:
 +1

 The Qualifier itself should sit in core-api.

 LieGrue,
 strub





 On Monday, 24 February 2014, 11:03, Antoine Sabot-Durand 
 anto...@sabot-durand.net wrote:

 +1 for @Deltaspike qualifier : it gives a solution to manage co-existence of 
 DS feature and future CDI standardized DS features.



Le 24 févr. 2014 à 10:16, Romain Manni-Bucau rmannibu...@gmail.com a écrit :

 +1 as well for a global qualifier @DeltaSPike
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:
 +1 for @DeltaSpike - @Inject @DeltaSpike ServletContext


 2014-02-24 9:52 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Hi,

 based on the discusstion in Servlet Module - Do we really need @Web?,
 I'd like to call a vote.

 The idea is to replace @Web with a common qualifier because @Web is
 redudant:
 @Inject @Web ServletContext.

 We could also reuse this qualifier for other features in the future.

 1) Should we replace it?
 2) What about the name? @DeltaSpike?

 Regards,
 Thomas

Re: [DISCUSS] next release version? 0.6 or 1.0?

[Cody Lerum]

+1

On Mon, Feb 17, 2014 at 2:10 AM, Mark Struberg strub...@yahoo.de wrote:
 Oki, I can help a bit with ViewAccessScoped. Romain and Thomas, please fix 
 the Tx stuff.

 In that case I'd say we gonna ship a 0.6 and then in 3 weeks move to 1.0.

 wdyt?


 LieGrue,
 strub





 On Monday, 17 February 2014, 10:06, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:

 Hi


can we wait 1 or 2 weeks (no more) to see if we can sort out @Repo/@Tx
stuff? Basically I'm waiting after it for months and this is blocker
to be used ATM.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau




2014-02-17 9:57 GMT+01:00 Mark Struberg strub...@yahoo.de:
 back 2 the topic, please!

 I'd say we should approach 1.0 NOW.

 DeltaSpike core and a few other modules is really rock solid already since 
 a year or so. It is also used heavily in production already.
 There will always be some modules which are not so perfectly mature at 
 times. E.g. if we will add a new module.

 Thus I already did propose a methology which would fix this shortcoming:
 We might introduce an 'ample page' which contains the status of each 
 project - stable / ready /in progress

 You know, the traffic light thingy where green means the module (e.g. 
 deltaspike-core) is stable and the API will not change or we will at least 
 be backward compatible unless we do a major new version.
 Orange means that the module has been tested and looks good. Whereas red 
 means that the api might change still.

 What road blockers do we have before 1.0?
 Please note that there is always something one can do better - but this 
 should not hinder us from releasing until something is really broken.
 Also the documentation is *not* a show stopper - it is perfectly fine to 
 ship this later as our CMS is completely asynchronous.


 So what BLOCKERS do you see before I go and press the release button?
 Like to do that on Wednesday...


 LieGrue,
 strub




 On Sunday, 16 February 2014, 23:14, Ove Ranheim oranh...@gmail.com wrote:

 That's reasonable enough.


On 16. feb. 2014, at 23:02, Jason Porter lightguard...@gmail.com wrote:

 Probably because we've become busy with some other projects and 
 priorities :(--
 Sent from Mailbox for iPhone

 On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim oranh...@gmail.com wrote:

 The commit graph shows too few committers.. and I appreciate your work!
 I also notice too few Redhat/JBoss Weld/Seam committers left on the 
 project. How come?
 /ove
 On 16. feb. 2014, at 22:10, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:
 hi ove,

 i was only talking about the commits.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2014-02-16 22:07 GMT+01:00 Thomas Andraschko 
 andraschko.tho...@gmail.com:

 +1 Ove
 We are really late for an 0.6. I would release 0.6 this/next month and
 after that, lets finish 1.0.
 We should fix all open issues and finish the documentation!

Re: JBoss Tools DeltaSpike

[Cody Lerum]

+1

US/Mountain

On Thu, Jan 16, 2014 at 5:41 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1

 regards,
 gerhard



 2014/1/16 Pete Muir pm...@redhat.com

 Hi all,

 Max and Alexey from the JBoss Tools team (http://www.jboss.org/tools/)
 would like to see we can improve the DeltaSpike tooling in JBoss Tools.
 They propose that we have a Google Hangout with them, and anyone interested
 from the DeltaSpike community to kick things off and brainstorm some ideas.
 Then we can proceed on email etc. as usual.

 So, I guess the first step is to collect a list of interested people -
 please let me know if you are interested in attending, and what timezone
 you are in. I can then propose some suitable times and we can decide what
 works.

 Pete

Re: DS ExceptionHandling for JSF?

[Cody Lerum]

See https://issues.apache.org/jira/browse/DELTASPIKE-341

On Fri, Jan 3, 2014 at 1:21 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
 Hi,

 what about providing DS' exception handling (@ExceptionHandler etc.) for
 JSF?
 AFAICS we would just need a small JSF ExceptionHandler.

 Regards,
 Thomas

Re: [DISCUSS] next release version? 0.6 or 1.0?

[Cody Lerum]

+1 for a 1.0 when docs are in order.

As far as versioning I prefer the same ver for each module. I do dislike
potentially having to release the exact same code multiple times just under
a different version but I don't know what the alternatives would be. If you
have modules with different version numbers it tends to make the users pom
very brittle.


On Wed, Nov 13, 2013 at 3:18 AM, Pete Muir pm...@redhat.com wrote:

 FWIW, I definitely prefer we do 1, and indicate clearly in docs and on a
 table on the website what the maturity of each module is.

 On 12 Nov 2013, at 14:34, Mark Struberg strub...@yahoo.de wrote:

  Pete, Gerhard
 
  The Problem here is that there are only 2 ways to handle the situation:
 
  1.) all modules share the same version but have different maturity grades
 
  2.) each module has it's very own version. A 0.x reflects instability,
 1.x reflects maturity. But you know what happened with exactly this
 approach in Seam3? The problem is that users do not know which version of
 ds-jsf-api works together with which version of ds-core-impl for example.
 It gets much more complicated with later modules.
 
  Thus I prefer 1.).
 
  LieGrue,
  strub
 
 
 
 
  
  From: Pete Muir pm...@redhat.com
  To: dev@deltaspike.apache.org
  Sent: Tuesday, 12 November 2013, 14:35
  Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
 
 
  +1 to Gerhard’s point (I am looking to try to find someone to help with
 docs, but the person I had in mind just left Red Hat :-(. Also +1 to going
 to 1.0 soon (i.e. making docs and stability a priority!).
 
 
  On 11 Nov 2013, at 23:09, Gerhard Petracek gerhard.petra...@gmail.com
 wrote:
 
  if we move to v1 soon, we need an useful versioning strategy, better
 docs
  and examples + the api and spi need to be stable for some time (in the
 best
  case until v2+).
 
  regards,
  gerhard
 
 
 
  2013/11/11 Mark Struberg strub...@yahoo.de
 
 
 
  how should that work?
 
  Please note that we will have some not perfectly finished modules very
  often. Basically whenever we add a new module...
  There is just no way to avoid this other than making those modules own
  releases. But this does not work out neither (as seen on a few other
  projects I don't like to name).
 
  LieGrue,
  strub
 
 
 
 
 
  
  From: Romain Manni-Bucau rmannibu...@gmail.com
  To: Mark Struberg strub...@yahoo.de; dev@deltaspike.apache.org
  Sent: Monday, 11 November 2013, 20:54
  Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
 
 
 
  Well if code is released it should be stable or explicitely in
  alpha/beta..maybe we should do subreleases for unstables modules
  Le 11 nov. 2013 18:43, Mark Struberg strub...@yahoo.de a écrit :
 
  Oki folks, txs 4 the feedback, all!
 
 
  I'd say we should create the module-maturity-matrix.md first and
 then
  we might do the version bump.
  Maybe something like green/blue/orange/red for mature / ready but
 still
  needs a few features / ready but might change it's api still / work in
  progress
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Charles Moulliard ch0...@gmail.com
  To: dev@deltaspike.apache.org
  Cc: Mark Struberg strub...@yahoo.de
  Sent: Monday, 11 November 2013, 18:25
  Subject: Re: [DISCUSS] next release version? 0.6 or 1.0?
 
  +1 to move to 1.0. We have done the same thing with Apache Aries
 moving
  Blueprint from 0.5 to 1.0 release
 
 
 
  On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament
  john.d.am...@gmail.comwrote:
 
  Yep, agreed.  Users care about the version #.  I would recommend
  that if we
  could release a 1.0 based on the current code base + some
 additional
  bug
  fixes we'll get huge wins.
 
  +1 to switching current to 1.0.0-SNAPSHOT.
 
 
  On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg 
 strub...@yahoo.de
  wrote:
 
  Hi!
 
  In the last 2 months I did a few conference talks and smaller
  presentations (OpenBlend, W-JAX, ..) and always got the same
  questions:
  it's only a 0.x version, so is it already stable? I
  don't like to use it
  in production with 0.x
 
  And the actual answer is: well, core, cdictrl, etc are stable
  since a
  long time, other modules are not yet 100% where we like them.
 
  The other fact is that we will never get all our modules 100%
  stable.
  Because new modules cannot be released with the same quality than
  established and well known and bugfixed modules.
 
  Thus I think we should rather introduce a kind of majurity-matrix
  for
  DeltaSpike.
  A simple list of modules and their majurity grade.
 
 
 
  By officially moving to 1.0 we would gain much more users.
  I personally do not care about numbers, but LOTS of users do!
 
  Wdyt?
 
  LieGrue,
  strub
 
 
 
 
 
  --
  Charles Moulliard
  Apache Committer / Architect @RedHat
  Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
 
 
 
 
 
 
 

Re: [VOTE] Release Apache DeltaSpike-0.5

[Cody Lerum]

+1

Builds and tests locally with Weld and OWB profiles (Win8.1 x64, Java 7u25)

No issues on an initial spin in my primary project moving form 0.4 to 0.5
(core,jpa,jsf,security)


On Wed, Sep 11, 2013 at 7:18 AM, Mark Struberg strub...@yahoo.de wrote:



  Hi!

 I'd like to call a VOTE for the release of DeltasSpike-0.4.

 The staging repo is:
 https://repository.apache.org/content/repositories/orgapachedeltaspike-029/

 The tag is available here:
 https://github.com/struberg/deltaspike/tree/deltaspike-project-0.5
 This will get pushed to the ASF repo and merged into the upstream master
 branch once the VOTE succeeded.

 The source release is available here:

 https://repository.apache.org/content/repositories/orgapachedeltaspike-029//org/apache/deltaspike/deltaspike-project/0.5/deltaspike-project-0.5-source-release.zip


 Release Notes:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312820version=12320947

 Guide to testing:
 Add the following to your ~/.m2/settings.xml:

 profile
   idstaging/id
   repositories
 repository
   idapache_staging/id
   url
 https://repository.apache.org/content/repositories/orgapachedeltaspike-029/
 /url
   releasesenabledtrue/enabled/releases
   snapshotsenabledfalse/enabled/snapshots
 /repository
   /repositories
 /profile

 Then upgrade your project to 0.5 and build with mvn -Pstaging.

 LieGrue,
 your Apache DeltaSpike Team

[jira] [Comment Edited] (DELTASPIKE-341) Provide Integration between Faces Exceptions and Exception Handling

[Cody Lerum (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673180#comment-13673180
 ] 

Cody Lerum edited comment on DELTASPIKE-341 at 6/3/13 2:55 PM:
---

Working example impl - https://gist.github.com/codylerum/5698723

Needs to be registered via an entry in faces-config.xml like below

[code]
factory
   
exception-handler-factorycom.foo.JsfExceptionHandlerFactory/exception-handler-factory
/factory
[code]

  was (Author: cody.lerum):
Working example impl - https://gist.github.com/codylerum/5698723

Needs to be registered via an entry in faces-config.xml like below

{code}
factory
   
exception-handler-factorycom.foo.JsfExceptionHandlerFactory/exception-handler-factory
/factory
{code}
  
 Provide Integration between Faces Exceptions and Exception Handling
 ---

 Key: DELTASPIKE-341
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-341
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: Cody Lerum
 Fix For: 0.5


 Just an ExceptionHandlerFactory and ExceptionHandlerWrapper which fire and 
 remove events so that DS core exceptional handling can intercept.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira