Re: Documentation refactoring progress

[Pete Muir]

Broken again ;-)

> On 16 Oct 2014, at 14:35, Rafael Benevides  wrote:
> 
> Fixed!
> 
> Thanks
> Em 10/16/14, 9:34, Pete Muir escreveu:
>> The staging URL is broken now.
>> 
>> On 15 Oct 2014, at 15:35, Rafael Benevides  wrote:
>> 
>>> Hi all,
>>> 
>>> I'd like to share a preview (and ask for feedback) of the documentation 
>>> refactoring that is being made by Michelle and her team.
>>> 
>>> It's not complete yet, but as soon as we have a feedback (and help) it 
>>> should get done faster and better.
>>> 
>>> The staging documentation was published at 
>>> https://deltaspike.apache.org/documentation/staging/
>>> 
>>> If you want to check the changes, they're here on this commit (that I 
>>> squashed until Michelle does that): 
>>> https://github.com/rafabene/deltaspike/commit/045bad532d3073a586f77f768921a83fc094f353
>>> 
>>> Please, let us know if you have any feedback or if you're willing to 
>>> provide some missing information.
>>> 
>>> Thank you.
>>> 
>>> -- 
>>> 
>>> Rafael Benevides | Senior Software Engineer
>>> JBoss Developer
>>> M: +55-61-9269-6576
>>> 
>>> <{a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg>
>>> 
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at www.redhat.com
>>> 
>>>  
>> 
> 

Re: Documentation refactoring progress

[Pete Muir]

The staging URL is broken now.

On 15 Oct 2014, at 15:35, Rafael Benevides  wrote:

> Hi all,
> 
> I'd like to share a preview (and ask for feedback) of the documentation 
> refactoring that is being made by Michelle and her team. 
> 
> It's not complete yet, but as soon as we have a feedback (and help) it should 
> get done faster and better.
> 
> The staging documentation was published at 
> https://deltaspike.apache.org/documentation/staging/ 
> 
> If you want to check the changes, they're here on this commit (that I 
> squashed until Michelle does that): 
> https://github.com/rafabene/deltaspike/commit/045bad532d3073a586f77f768921a83fc094f353
> 
> Please, let us know if you have any feedback or if you're willing to provide 
> some missing information.
> 
> Thank you.
> 
> -- 
> 
> Rafael Benevides | Senior Software Engineer
> JBoss Developer
> M: +55-61-9269-6576
> 
> <{a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg>
> 
> Better technology. Faster innovation. Powered by community collaboration. 
> See how it works at www.redhat.com 
> 
>  

Re: Release Notes pages

[Pete Muir]

+1 this is something I’ve heard a lot of people ask for, and will make getting 
the word out about DS much easier.

On 7 Sep 2014, at 16:06, John D. Ament  wrote:

> Hi all
> 
> I was looking at other apache projects and noted that many of them include
> dedicated pages for each release, with some summary information about what
> went in.  In DeltaSpike we're currently putting a short blurb, I was
> wondering if it makes sense to include something similar, and perhaps even
> merge with the generated release notes that make it into the SCM.
> 
> Here's a prototype page: [1].
> 
> 
> http://deltaspike.staging.apache.org/documentation/deltaspike_1.0.2.html

Re: Feedback on CMS with Github and Asciidoctor

[Pete Muir]

Looks good to me.

On 28 Aug 2014, at 18:03, Rafael Benevides  wrote:

> I believe that the work for the asciidoc documentation is ready!
> 
> Please, check this generated asciidcotor page: 
> http://deltaspike.apache.org/documentation/container-control-test.html
> 
> The branch with the source code is here: 
> https://github.com/rafabene/deltaspike/tree/documentation/documentation
> 
> 
> Em 8/27/14, 18:14, Rafael Benevides escreveu:
>> Yeap. I have to agree with you.
>> 
>> So I've changed my strategy...
>> 
>> I've taken your PoC and made some minor modifications and place it on my 
>> branch: 
>> https://github.com/rafabene/deltaspike/tree/documentation/documentation
>> 
>> Note that I'm using the agreed path for documentation folder and that I also 
>> included a Readme.md that instructs how to setup the credentials on 
>> ~/.m2/settings.xml and what maven command that should be used to deploy.
>> 
>> The result was published here: 
>> http://deltaspike.apache.org/documentation/container-control-test.html
>> 
>> What is missing now is the generated html template/styles.
>> 
>> 
>> Em 8/27/14, 17:23, John D. Ament escreveu:
>>> IMHO, the current approach is a bit safer and more testable.  running mvn 
>>> site will generate the asciidoc.  That would be a bit harder to do if we 
>>> need to support running it as a part of a staging pull.
>>> 
>>> 
>>> On Wed, Aug 27, 2014 at 4:14 PM, Rafael Benevides >> > wrote:
>>> 
>>>I was trying to avoid two steps to deploy:
>>> 
>>>1 - mvn site-deploy on git repo to copy it to the CMS staging are
>>>2 - CMS deploy to publish it
>>> 
>>>But I think that should not be a problem, Right?
>>> 
>>>So what I'll do now, based on your PoC is to make the templates of
>>>the generated html to be close to deltaspike site style.
>>> 
>>>Em 8/27/14, 17:10, John D. Ament escreveu:
Rafael,
 
This shouldn't be needed any longer.  Based on what I did, we can
now do a mvn site-deploy to copy everything into the CMS staging
area.  Once verified go into CMS and do a publish.
 
John
 
 
On Wed, Aug 27, 2014 at 3:57 PM, Rafael Benevides
mailto:benevi...@redhat.com>> wrote:
 
Hi all,
 
This email is just to give a feedback about making CMS to
work with Github and Asciidoc.
 
Finally  I was able to understand enough how CMS works and
probably I'm stopped where John Ament was.
 
What I'm doing now is writing a GitUtil Perl Module that will
be hosted at
 http://svn.apache.org/repos/asf/deltaspike/site/trunk/lib/
that will be responsible for cloning the documentation (on
deltaspike git repo) and then another module will run the
build (asciidoc to html) just for [/documentation/].
 
The idea is that the final documentation gets hosted at
deltaspike.apache.org/documentation/
 (note the sub
folder).
 
Further steps: Prepare a template so asciidoc generated html
uses the same style of deltaspike.apache.org
.
 
Well, the idea here is to make everyone aware about this and
also say that if is there anybody if Perl knowledge, you're
welcome to give some hints!
 
Thanks
 
 
--
*Rafael Benevides | Senior Software Engineer*
JBoss Developer
M: +55-61-9269-6576 
 
Red Hat
 
Better technology. Faster innovation. Powered by community
collaboration.
See how it works at www.redhat.com 
 
LinkedIn  Youtube

 
 
>>> 
>>> 
>> 
>> 
> 

Re: DeltaSpike docs plan

[Pete Muir]

On 7 Aug 2014, at 18:47, Rafael Benevides  wrote:

> Before we have a deal with Michelle's team about these content changes, I 
> think we should close the two other definitions:
> 
> - docs location: move to deltaspike sources, create a new repository, other?

+1 to move to sources

> and
> -docs format: markdown or asciidoc

+1 for asciidoc.

However I believe we also need agree on:

* add support for asciidoc to Apache CMS
* add support for importing external repo to Apache CMS

so that the docs can still be build as part of the website.

From what people have said in the past, both are possible, if someone (e.g. 
Rafael ;-) can spend a couple of days doing it.

> 
> I believe that we should propose a vote to decided this, otherwise it can 
> become an endless discussion. Wdyt ?
> 
> 
> 
> Em 8/4/14, 17:28, Gerhard Petracek escreveu:
>> @suggested content changes:
>> +1
>> 
>> regards,
>> gerhard
>> 
>> 
>> 
>> 2014-08-01 18:46 GMT+02:00 Rafael Benevides > >:
>> 
>>Hi all,
>> 
>>As you may known, Red Hat docs team was called to help on
>>DeltaSpike docs. After a long period, they have analyzed the
>>documentation and bring us an awesome plan that is available here:
>>
>> https://docs.google.com/document/d/186f_amQ9XuREq8FcO7orxvOjQZtvEEYa7WPj1e8p8bM/edit#heading=h.4sqhyz68wgg2
>> 
>>The document is opened for comments.
>> 
>>Something that was also discussed not only inside Red Hat but with
>>some community members is about the format and source of the
>>documentation. I strongly believe that we should have the
>>documentation somewhere else but the DS site source. It could
>>improve the ease to the community to contribute with it. Having
>>said that, it's also suggested that we should use asciidoc as
>>documentation format.
>> 
>>So what we have until now ?
>> 
>>- The documentation plan to be reviewed and approved by the DS
>>community. Then we can talk about the plans to make it happen.
>>- The documentation location: Recommendation to be out of the site
>>source.
>>- The documentation format: Suggested to use asciidoc.
>> 
>>Please, read the plan and lets discuss about these 3 topics
>>individually.
>> 
>>Michelle Murray (whose team provided the plan and she is copied on
>>this Thread) can follow the feedback.
>>-- 
>>*Rafael Benevides | Senior Software Engineer*
>>JBoss Developer
>>M: +55-61-9269-6576 
>> 
>>Red Hat
>> 
>>Better technology. Faster innovation. Powered by community
>>collaboration.
>>See how it works at www.redhat.com 
>> 
>>LinkedIn  Youtube
>>
>> 
>> 
> 

Re: [DeltaSpike SHADOW] DeltaSpike docs plan

[Pete Muir]

On 1 Aug 2014, at 17:46, Rafael Benevides  wrote:

> Hi all,
> 
> As you may known, Red Hat docs team was called to help on DeltaSpike docs. 
> After a long period, they have analyzed the documentation and bring us an 
> awesome plan that is available here: 
> https://docs.google.com/document/d/186f_amQ9XuREq8FcO7orxvOjQZtvEEYa7WPj1e8p8bM/edit#heading=h.4sqhyz68wgg2
> 
> The document is opened for comments.
> 
> Something that was also discussed not only inside Red Hat but with some 
> community members is about the format and source of the documentation. I 
> strongly believe that we should have the documentation somewhere else but the 
> DS site source. It could improve the ease to the community to contribute with 
> it. Having said that, it's also suggested that we should use asciidoc as 
> documentation format.
> 
> So what we have until now ?
> 
> - The documentation plan to be reviewed and approved by the DS community. 
> Then we can talk about the plans to make it happen.

+1 for the content changes, whatever else. This is the most important thing for 
the wider community IMO.

> - The documentation location: Recommendation to be out of the site source.

This would be nice. It can then be imported by e.g. an svn submodule or git 
checkout as part of the site build

> - The documentation format: Suggested to use asciidoc.

+1 asciidoc is really nice, it allows you do a lot of stuff you would like to 
do in markdown (e.g. tables) but can’t without non-standard extensions.

> 
> Please, read the plan and lets discuss about these 3 topics individually.
> 
> Michelle Murray (whose team provided the plan and she is copied on this 
> Thread) can follow the feedback. 
> -- 
> 
> Rafael Benevides | Senior Software Engineer
> JBoss Developer
> M: +55-61-9269-6576
> 
> <{a8aabf3a-4467-4e37-9bc5-48b1d7b494a2}_LATAM_RedHat.jpg>
> 
> Better technology. Faster innovation. Powered by community collaboration. 
> See how it works at www.redhat.com 
> 
>  

Re: Promoting and evangelising DeltaSpike

[Pete Muir]

Nice!

Antoine has 4 sessions on CDI, so we should be CDI heavy this year :-)

On 18 Jun 2014, at 18:22, John D. Ament  wrote:

> Actually, my JavaOne talk focused on DeltaSpike got accepted.. we'll
> see how it goes :-)
> 
> On Wed, Jun 18, 2014 at 12:32 PM, Anil Saldhana  
> wrote:
>> Hi all,
>> the website needs an update with details on the 1.0 release.
>> http://deltaspike.apache.org/news.html#8th-release-100-14062014  has a one
>> line statement. :)
>> 
>> Congrats to all....
>> 
>> 
>> On Wed, Jun 18, 2014 at 11:08 AM, Pete Muir  wrote:
>> 
>>> Hi all,
>>> 
>>> Now that we have released DeltaSpike 1.0, we have a great opportunity to
>>> tell the world about DeltaSpike.
>>> 
>>> Arun Gupta (Director of Developer Advocacy at Red Hat) has volunteered to
>>> help us with ways to do this.
>>> 
>>> Hopefully we can use this thread to start devising a plan.
>>> 
>>> As a starting point, I know Arun was looking for an overview of 1.0, so he
>>> can see what to blog and tweet about. I had a quick look around, but I
>>> couldn’t find anything like this.
>>> 
>>> Pete

Promoting and evangelising DeltaSpike

[Pete Muir]

Hi all,

Now that we have released DeltaSpike 1.0, we have a great opportunity to tell 
the world about DeltaSpike.

Arun Gupta (Director of Developer Advocacy at Red Hat) has volunteered to help 
us with ways to do this.

Hopefully we can use this thread to start devising a plan. 

As a starting point, I know Arun was looking for an overview of 1.0, so he can 
see what to blog and tweet about. I had a quick look around, but I couldn’t 
find anything like this.

Pete

Re: [VOTE] logo-color

[Pete Muir]

+1 for blue.

On 14 Jun 2014, at 19:55, Gerhard Petracek  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: DeltaSpike Logo Updates

[Pete Muir]

I particularly like variant 2 from versions 7 - 10. I like the yellow colour 
scheme. I find the purple is too close to the black, and I can’t really see it 
- but 9-1, 4 does work.

On 7 Jun 2014, at 22:40, Matt Benson  wrote:

> From the peanut gallery, I'd say that applying the gradient from 5-4 to the
> spike from 5-1 would look pretty cool.
> Matt
> On Jun 7, 2014 2:04 PM, "James Parenti"  wrote:
> 
>> Hello all,
>> 
>> Here are some logo version updates, some of which are based on notes that
>> Gerhard has provided.
>> 
>> Versions 5 & 6 (color changes and some different stylizations):
>> 
>> https://www.dropbox.com/sh/5myvevnmwpiy7qd/AACxanLDzIVB5S7PzA9kBvrya
>> 
>> Versions 7 through 10 (additional color & shape changes):
>> 
>> https://www.dropbox.com/sh/o56t4lku20jxnmx/AABjGiMbT7o8d5OvKtEiib_3a
>> 
>> I know that versions 7 to 10 looks like a lot of content, but really it’s
>> just the same array of shapes with different colors provided for each.
>> 
>> PLEASE NOTE: What is seen in the DropBox website previewer is NOT the
>> correct color version. You’ll want to download each image and preview on
>> your monitor to get an idea of color that’s accurate.
>> 
>> Jim
>> 
>> 
>> --
>> 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: DeltaSpike Revision Version 4, now with stylization applied

[Pete Muir]

I agree, I’m still a fan of #1 here. I like the “retro” look of it :-)

On 3 Jun 2014, at 03:11, James Parenti  wrote:

> Hello again,
> 
> Here are a couple of updated layouts for the DeltaSpike logo. After a good 
> bit of narrowing down, I’ve taken #1 – the preference among most of us – and 
> tried a few variations on its basic shape (mainly slight alterations to the 
> “spike” part of the emblem). 
> 
> Though I’ve included these new changes, I think I might be most partial to #1 
> still, as it turns out.
> 
> With that said, I’ve taken that basic shape and in the second mockup, tried 
> it with some different stylizations applied. The first 2 are rather simple, 
> with some glowing effects added. The second two have a little more in the way 
> of applied geometry and shadow.
> 
> https://www.dropbox.com/sh/hhvussplfsrzpnr/AACsGLSPJvQxYx1DP_YaLEqKa
> 
> 
> --
> 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: DeltaSpike Revision Version 3

[Pete Muir]

I really like #1

On 29 May 2014, at 15:26, James Parenti  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: Apache DeltaSpike Logo Revised Samples

[Pete Muir]

Jim’s email bounced.

Here are the logos: 
https://www.dropbox.com/sh/6doraoq6ap3qyr3/AABXLSF-LyxEEL29jyHkyWCUa?n=289270217


On 26 May 2014, at 21:03, James Parenti  wrote:

> Hello again everyone,
> 
> I just revised some of the logos and cleaned up some additional versions I 
> was working on and I’m including with this email. A few quick notes on these:
> 
>   • As was the case before, these are all “sketches” and therefore have 
> some minor line flaws and whatnot. Final selections would of course be 
> refined to an exact, even finish.
>   • From the email exchange, the concenus appeared to be for “Emblems” 
> and/or the font I made called “Geometric” so I focused on those two design 
> elements for this batch of revisions. I of course tried to marry the two into 
> a single logo, but I think that it is rather busy-looking so a final version 
> would be one or the other, IMO. Either just the Geometric name or the 
> finalized emblem with a simple font.
>   • It was pointed out that the “S” in the DeltaSpike emblem/logo looked 
> a bit like that of the Schutzstaffel. After a second look, I’m inclined to 
> agree, so I’ve tried to change it or otherwise modify it’s appearance to 
> mitigate that to whatever extent I thought possible. It may yet need to be 
> that I ditch that look entirely, but I really look the general idea of it. 
> There are a couple of other Geometric logos included where I’ve re-styled the 
> S.
> 
>  Spike Version 2_Emblems with alternate styling.jpg> Version 2_Geometric-V2.jpg> with Title.jpg>
> 
> 
> --
> 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: [DISCUSS] next release as 1.0?

[Pete Muir]

Hi all,

(Note Rafael is away on vacation atm, so I am responding partly for him ;-)

I definitely agree with getting to 1.0 asap. However also agree that we need to 
make sure we are ready.

If there are issues with docs, please open issues, I know Rafael will be 
pleased to pick any that are open up when he is back from vacation. Same for 
any issues like performance.

I’ve also asked for help with the docs from our docs team at Red Hat. This 
would be more of a general edit to make them read nicely, and put them in a 
good order for a user to follow, rather than adding new content. However, I 
haven’t managed to secure any time before July/August. I will follow up with 
the list when I have some details.

On 19 May 2014, at 12:40, Thomas Andraschko  wrote:

> +0
> - no logo
> - documentation... there are many TODOs. Also a docu for some for the
> really core features is not available (like Deactivatable).
> - we should check the performance of the modules. (i already openend some
> improvements for the JSF module)
> 
> 
> 2014-05-19 12:39 GMT+02:00 Karl Kildén :
> 
>> "Design help for the logo"
>> 
>> Saw that mail just now, sounds great :-)
>> 
>> 
>> On 19 May 2014 12:37, Karl Kildén  wrote:
>> 
>>> +0 because I would really like to see a logotype selected before 1.0.
>>> 
>>> I am aware of https://issues.jboss.org/browse/DESIGN-520 and I am also
>>> fine with going with one already proposed. I just feel that every project
>>> needs a good logo
>>> 
>>> 
>>> On 19 May 2014 11:55, Christian Kaltepoth 
>> wrote:
>>> 
 +1
 
 
 2014-05-19 11:34 GMT+02:00 Romain Manni-Bucau :
 
> +1
> 
> 
> 
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 2014-05-19 11:13 GMT+02:00 Mark Struberg :
> 
>> Hi!
>> 
>> Is there ANYTHING which holds us back from moving our version to
>> 1.0?
>> 
>> We are long overdue and there are SOOO many companies using
 DeltaSpike in
>> production since years now...
>> 
>> LieGrue,
>> strub
>> 
> 
 
 
 
 --
 Christian Kaltepoth
 Blog: http://blog.kaltepoth.de/
 Twitter: http://twitter.com/chkal
 GitHub: https://github.com/chkal
 
>>> 
>>> 
>> 

Design help for the logo

[Pete Muir]

Hi all,

I’ve managed to secure some design time from one of Red Hat’s design 
contractors, Jim Parenti (based in Chicago, so expect him to respond from that 
timezone :-).

I’ve pointed him at http://deltaspike.apache.org and he immediately asked me 
"Aside from the description shown on that sample page, is there some background 
available on where the name comes from?” - so we wanted to open it up to the 
full group to start getting input.

I think any other ideas or thoughts you may have about logos will also be 
gratefully received!

Please make sure you keep Jim in the cc when you respond, as he isn’t on the 
DeltaSpike mailing list (Gerhard is going to make sure his mails get through to 
the list).

Pete

Re: JBoss Tools & DeltaSpike

[Pete Muir]

Alexey Kazakov, from the JBDS team, should set something up soon.

On 8 Feb 2014, at 17:03, Mark Struberg  wrote:

> Not that I'm aware of...
> 
> 
> 
> 
> 
> On Saturday, 8 February 2014, 15:58, John D. Ament  
> wrote:
> 
> Just wondering if this ever happened?
>> 
>> 
>> On Thu, Jan 16, 2014 at 3:12 PM, Marcos Lois Bermúdez
>>  wrote:
>>> +1
>>> 
>>> Europe/Madrid
>>> 
>>> 
>>> 2014/1/16 Cody Lerum 
>>> 
>>>> +1
>>>> 
>>>> US/Mountain
>>>> 
>>>> On Thu, Jan 16, 2014 at 5:41 AM, Gerhard Petracek
>>>>  wrote:
>>>>> +1
>>>>> 
>>>>> regards,
>>>>> gerhard
>>>>> 
>>>>> 
>>>>> 
>>>>> 2014/1/16 Pete Muir 
>>>>> 
>>>>>> 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
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> ---
>>> *Marcos Lois Bermúdez*
>>> Consultoría tecnológica
>>> 
>>> E-mail: marcos.l...@gmail.com
>>> Teléfono: +34 661 772 336
>> 

JBoss Tools & DeltaSpike

[Pete Muir]

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: [DISCUSS] next release version? 0.6 or 1.0?

[Pete Muir]

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  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 
>> 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  
>> 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 
>>> 
>>>> 
>>>> 
>>>> 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 
>>>>> To: Mark Struberg ; 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"  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 
>>>>>>> To: dev@deltaspike.apache.org
>>>>>>> Cc: Mark Struberg 
>>>>>>> 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
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> 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.
>>>>>>>>

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

[Pete Muir]

+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  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 
> 
>> 
>> 
>> 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 
>>> To: Mark Struberg ; 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"  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 
> To: dev@deltaspike.apache.org
> Cc: Mark Struberg 
> 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
> wrote:
> 
>> 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 
> 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: General Converter

[Pete Muir]

Right, this is how the Seam 2 convertor worked. It used an abstraction over JPA 
providers (to give us extra hooks, maybe not needed now in JPA 2) to extract 
the id of an entity (as you can't rely on the annotation as there is xml as 
well). It then use a unique id generator to put that into the form as an id, 
and stored a map that attached the database id to this unique id (this 
prevented leaking database ids to the UI).

It worked pretty well in the end.

On 19 Aug 2013, at 15:49, Arne Limburg  wrote:

> Hmm,
> 
> 
> Anyway, with an EntityManager we could identify the id field of the entity
> and convert the entity to its id and vice versa. This could be useful for
> lists or select menus.
> 
> Am 19.08.13 16:35 schrieb "Jason Porter" unter :
> 
>> Hm, I'll have to go back to the code to see what was done.
>> 
>> 
>> On Mon, Aug 19, 2013 at 5:06 AM, Pete Muir  wrote:
>> 
>>> The Seam 2 converter worked on any entity class, you just had to provide
>>> it with a reference to the EntityManager.
>>> 
>>> On 18 Aug 2013, at 05:16, Jason Porter  wrote:
>>> 
>>>> The problem with a generic JSF converter is that it has to be very
>>> dumb,
>>> or you have to use a certain kind of object.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   The Seam 3 converter went as generic as possible, it also kept
>>> things
>>> in the conversion (and should work fine in the request as a
>>> conversation is
>>> at least as long as a request). Depending on what state you're storing
>>> in
>>> the converter, you probably wouldn't want anything longer than the
>>> conversation due to memory issues.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   If memory serves correctly, the Seam 2 converter really only worked
>>> if you were using the EntityHome classes.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   If you were to do anything similar to the Seam 2 converter you'd
>>> need
>>> to create some sort of object hierarchy the user would need to use, or
>>> try
>>> to perform some sort of generic magic with the criteria API, which is
>>> not
>>> the easiest of things to do.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   All that being said, I'd be happy to talk ideas out anyone may
>>> have.
>>>> 
>>>>   ‹
>>>> Sent from Mailbox for iPhone
>>>> 
>>>> On Sat, Aug 17, 2013 at 7:51 PM, hantsy  wrote:
>>>> 
>>>>> I have posted some content on JBoss.org forum beforethe Seam3
>>> faces
>>>>> object converter does not work well as the Seam 2 one.
>>>>> The Seam 3 only works in a conversation(the view is a conversation),
>>> and
>>>>> it also does not support @ManytoMany.
>>>>> The Seam2 version works perfectlyit works in request,
>>> conversation
>>>>> and other scopes...the better is when I used multi check box...it can
>>>>> deal with the Hibernate/JPA @ManyToMany relation correctly with any
>>>>> codes in the backend codes when I selected or unselected an option.
>>>>> Hantsy
>>>>> On 8/18/2013 05:42, Adrian Gonzalez wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> In the meantime, if you're looking for a JSF converter, you can
>>> take a
>>> look at Omnifaces SelectItemsConverter [1].
>>>>>> 
>>>>>> Regards,
>>>>>> Adrian
>>>>>> 
>>>>>> [1] http://showcase.omnifaces.org/converters/SelectItemsConverter
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> De : Mark Struberg 
>>>>>> À : "dev@deltaspike.apache.org" 
>>>>>> Envoyé le : Vendredi 16 août 2013 12h39
>>>>>> Objet : Re: General Converter
>>>>>> 
>>>>>> 
>>>>>> Hi Florian!
>>>>>> 
>>>>>> Not yet on our list. We are currently working on getting 0.5 out of
>>> the door (code reviews and testing against many containers)
>>>>>> 
>>>>>> 
>>>>>> Please file a feature request in JIRA describing what this Seam2
>>> feature is about and why you like it.
>>>>>> 
>>>>>> 
>>>>>> txs and LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> - Original Message -
>>>>>>> From: "i...@softwareentwicklung-hell.de" <
>>> i...@softwareentwicklung-hell.de>
>>>>>>> To: dev@deltaspike.apache.org
>>>>>>> Cc:
>>>>>>> Sent: Tuesday, 13 August 2013, 14:35
>>>>>>> Subject: General Converter
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> is there a plan to implement Seam like general Converter like the
>>> Seam
>>>>>>> Faces Object converter? I know it is not really a cdi topic, but
>>> there
>>>>>>> is still a big gap between what Seam was providing and what
>>> DeltaSpike
>>>>>>> does.
>>>>>>> 
>>>>>>> Thanks and Regards
>>>>>>> Florian
>>> 
>>> 
>> 
>> 
>> -- 
>> Jason Porter
>> http://en.gravatar.com/lightguardjp
> 

Re: General Converter

[Pete Muir]

The Seam 2 converter worked on any entity class, you just had to provide it 
with a reference to the EntityManager.

On 18 Aug 2013, at 05:16, Jason Porter  wrote:

> The problem with a generic JSF converter is that it has to be very dumb, or 
> you have to use a certain kind of object. 
> 
> 
> 
> 
> 
>The Seam 3 converter went as generic as possible, it also kept things in 
> the conversion (and should work fine in the request as a conversation is at 
> least as long as a request). Depending on what state you're storing in the 
> converter, you probably wouldn't want anything longer than the conversation 
> due to memory issues. 
> 
> 
> 
> 
> 
>If memory serves correctly, the Seam 2 converter really only worked if you 
> were using the EntityHome classes.
> 
> 
> 
> 
> 
>If you were to do anything similar to the Seam 2 converter you'd need to 
> create some sort of object hierarchy the user would need to use, or try to 
> perform some sort of generic magic with the criteria API, which is not the 
> easiest of things to do. 
> 
> 
> 
> 
> 
>All that being said, I'd be happy to talk ideas out anyone may have. 
> 
>—
> Sent from Mailbox for iPhone
> 
> On Sat, Aug 17, 2013 at 7:51 PM, hantsy  wrote:
> 
>> I have posted some content on JBoss.org forum beforethe Seam3 faces
>> object converter does not work well as the Seam 2 one.
>> The Seam 3 only works in a conversation(the view is a conversation), and
>> it also does not support @ManytoMany.
>> The Seam2 version works perfectlyit works in request, conversation
>> and other scopes...the better is when I used multi check box...it can
>> deal with the Hibernate/JPA @ManyToMany relation correctly with any
>> codes in the backend codes when I selected or unselected an option.
>> Hantsy
>> On 8/18/2013 05:42, Adrian Gonzalez wrote:
>>> Hi, 
>>> 
>>> In the meantime, if you're looking for a JSF converter, you can take a look 
>>> at Omnifaces SelectItemsConverter [1].
>>> 
>>> Regards,
>>> Adrian
>>> 
>>> [1] http://showcase.omnifaces.org/converters/SelectItemsConverter
>>> 
>>> 
>>> 
>>> De : Mark Struberg 
>>> À : "dev@deltaspike.apache.org"  
>>> Envoyé le : Vendredi 16 août 2013 12h39
>>> Objet : Re: General Converter
>>> 
>>> 
>>> Hi Florian!
>>> 
>>> Not yet on our list. We are currently working on getting 0.5 out of the 
>>> door (code reviews and testing against many containers)
>>> 
>>> 
>>> Please file a feature request in JIRA describing what this Seam2 feature is 
>>> about and why you like it.
>>> 
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> - Original Message -
 From: "i...@softwareentwicklung-hell.de" 
 To: dev@deltaspike.apache.org
 Cc: 
 Sent: Tuesday, 13 August 2013, 14:35
 Subject: General Converter
 
 Hi all,
 
 is there a plan to implement Seam like general Converter like the Seam  
 Faces Object converter? I know it is not really a cdi topic, but there  
 is still a big gap between what Seam was providing and what DeltaSpike  
 does.
 
 Thanks and Regards
 Florian

Re: Proposing a convention for declaring Annotation Literals

[Pete Muir]

I think as we can only do this for annotations in our control, it's less 
appealing, as we then end up with both patterns in use.

On 10 Jul 2013, at 12:23, Hugh Nguyen  wrote:

> Hi fellow developers,
> 
> Instead of creating a whole separate class SomeAnnotationLiteteral and put
> it in some separate .literal package, do you think we should embed the
> literal inside the annotation class itself?
> 
> For example:
> 
> 
> @Qualifier
> @Target({ FIELD, PARAMETER })
> @Retention(RUNTIME)
> public @interface RenderResponse {
> 
>@SuppressWarnings("serial")
>public static final AnnotationLiteral LITERAL = new
> AnnotationLiteral() {
>};
> }
> 
> 
> And when you use this literal as RenderResponse.LITERAL, you even have it
> highlighted properly as an annotation by the IDE.
> 
> 
> For cases where the annotation has attributes, we could declare it like
> this:
> 
> 
> @Qualifier
> @Target({ FIELD, PARAMETER })
> @Retention(RUNTIME)
> public @interface View {
>String value() default "";
> 
>// need to suppress "all" to remove warning about implementing an
> Annotation.
>@SuppressWarnings("all")
>public static class LITERAL extends AnnotationLiteral implements
> View {
>private String value = "";
> 
>@Override
>public String value() {
>return this.value;
>}
> 
>public Literal(final String value) {
>if (value != null) {
>this.value = value;
>}
>}
>}
> }
> 
> 
> And we use it as: new View.LITERAL("someViewId"). This is also highlighted
> by the IDE.
> 
> 
> Of course this is only applicable for those Annotation that's in our
> control.
> 
> What do you think?
> 
> 
> --
> Regards,
> Hugh