My view is still the same. I'm still willing to patch and release from 1.7.x. At the stage, I don't think we could consider getting it working with Java 11, and I wouldn't actively develop this branch, but I'd be willing to apply fixes and patches to it where possible.
Jon On Thu, Dec 13, 2018 at 1:09 PM Roberto Cortez <radcor...@yahoo.com.invalid> wrote: > Hi folks, > > I’m sorry for digging back this old thread. > > I think we never ended up making a decision on this, and a year and a half > as passed since we discussed this. > > So, I would like to bring to the table again the discussion around > supporting TomEE 1.x and EOL. > > Cheers, > Roberto > > > On 30 Jun 2017, at 22:34, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > > As mentionned tomcat 8.0 EOL has been announced, here is the interesting > > part of it: > > > > " > > The Apache Tomcat team announces that support for Apache Tomcat 8.0.x > > will end on 30 June 2018. > > > > This means that after 30 June 2018: > > - releases from the 8.0.x branch are highly unlikely > > - bugs affecting only the 8.0.x branch will not be addressed > > - security vulnerability reports will not be checked against the 8.0.x > > branch > > > > Three months later (i.e. after 30 September 2017) > > - the 8.0.x download links will be removed > > - the latest 8.0.x release will be removed from the mirror system > > - the 8.0.x branch in svn will move from /tomcat/tc8.0.x to > > /tomcat/archive/tc8.0.x > > - the links to the 8.0.x documentation will be removed from > > tomcat.apache.org > > " > > > > We are already on 8.5 so not directly impacted for 7.x but think we can > > take it as a good example for 1.x. > > > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://blog-rmannibucau.rhcloud.com> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > 2017-06-19 16:14 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > > >> > >> > >> 2017-06-19 16:04 GMT+02:00 Jonathan Gallimore < > >> jonathan.gallim...@gmail.com>: > >> > >>> Firstly, I note the page Romain started - thank you for listening to my > >>> feedback. I'd be happy to test instructions and contribute to that > page. I > >>> suspect some DBCP(2) settings are different so we should call those > out. > >>> I'll also try and help build it out into a step by step guide. > >>> > >> > >> Hmm, database pool can need there own thread but current doc basically > >> says "read the pool doc" cause each time we copied it, we ended up > messing > >> more than solving in term of user experience so I'm not sure we should > do > >> this exercise. That said +1 to add a point saying it should be > validated. > >> Tomcat pool being the default we shouldn't be too much affected in > "prod". > >> > >> > >>> > >>> Secondly, I have been thinking about the EOL. I personally really > dislike > >>> the term 'End of life' for an Open Source project / branch. The branch > >>> will > >>> ultimately live on while there are committers / contributors whether > >>> individual or organizations that are prepared to provide patches. The > >>> OpenEJB Eclipse Plugin could be thought of as "End Of Life", but if > >>> someone > >>> showed up on the mailing list wanting to use it with the latest > version of > >>> Eclipse, and it didn't work (which I expect is the case), or found a > bug, > >>> truthfully, I would be simply delighted to update it - so in that > regard > >>> it > >>> isn't EOL. > >>> > >> > >> Agree but think not using EOL would be misleading. What we want is to: > >> > >> 1. show 1.x is not more active > >> 2. 1.x is no more maintained (and once again this is not linked to our > >> only will in term of OS ecosystem) > >> 3. you should migrate to 7 > >> > >> I'm fine detailling it in the announce but not sure if using a more > >> accurate term (EOS - end of support ?) wouldn't be more misleading :s > >> > >> > >>> > >>> Similarly, if someone / an organization wanted to contribute and > maintain > >>> 1.7.x, then there shouldn't really be any blocker to them doing so, and > >>> therefore it also wouldn't be EOL. > >>> > >> > >> Well the OS side is a blocker. This means 1.x needs to live with a tons > of > >> fork which should be ack by tomee project before being an option. > >> > >> > >>> > >>> I do, however, appreciate that there is a desire for people to migrate > to > >>> the latest version, as there is more activity there in terms of later > >>> specs > >>> and new functionality, and I also appreciate the issue where > dependencies > >>> 1.7.x uses may not be updated any more. > >>> > >>> I'd like to make the suggestion that we give an honest statement about > >>> each > >>> version available, in order to help facilitate decision making. As to > what > >>> "honest statement" means... well I think we'd need to discuss and agree > >>> the > >>> specific statements. Off the top of my head, it could be something > like: > >>> > >>> Pre-1.7.x: No longer being updated within the community. > >>> 1.7.x: Stable, certified, supports Java EE 6 Web Profile. Receives > >>> security > >>> fixes, occasional feature updates and backports, and bug fixes. Last > >>> commit: yyyy-MM-dd, last release: yyyy-MM-dd. N.B. some dependencies > (e.g. > >>> <list here>) no longer receive updates. Consider upgrading to 7.0, see > the > >>> migration guide here: http://tomee.apache.org/........ > >>> 7.x: Stable, GA, supports Java EE 7 Web Profile. Actively developed, > >>> receives security fixes, numerous feature updates and bug fixes. Last > >>> commit: yyyy-MM-dd, last release: yyyy-MM-dd > >>> 8.x: In progress, not yet GA, supports Java EE 8 Web Profile. Consider > >>> this > >>> to be ahead of "bleeding edge". Last commit: yyyy-MM-dd, last release: > >>> yyyy-MM-dd > >>> > >>> > >> Hmm, this looks really awesome and close to what we should go with IMHO > >> but experience shows it is not as reliable as it is written to. Maybe we > >> should rephrase it more in a way saying "maintained as best effort > allows > >> and when some companies want, will be EOL [next year]" - "EOL" and "next > >> year" to replace by this thread outcome indeed. > >> > >> What I want to avoid here is the understanding 1.7 will get backports or > >> security fixes systematically which never have been the case - not > blaming > >> since I'm a lot responsible of it but just trying to be realistic with > our > >> resources. > >> > >> > >>> Thoughts? > >>> > >>> Jon > >>> > >>> On Mon, Jun 19, 2017 at 2:42 PM, Andy Gumbrecht < > agumbre...@tomitribe.com > >>>> > >>> wrote: > >>> > >>>> -1 > >>>> > >>>> I would welcome an EOL announcement at the end of the year (with a > years > >>>> notice), but not right now. That's too much pressure. So to make that > >>>> clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan > >>> 2019 > >>>> - That gives everyone plenty of time to create detailed documentation > on > >>>> the site that targets everyone, and then plenty of time to migrate. > >>>> > >>>> We could make a pre-EOL announcement that details the above plan. An > >>>> announcement of the planned announcement so to say - That would enable > >>>> contribution and discussion regarding the EOL effort by the community > >>>> rather than being a snap decision. > >>>> > >>>> Andy. > >>>> > >>>> On 18 June 2017 at 20:36, Romain Manni-Bucau <rmannibu...@gmail.com> > >>>> wrote: > >>>> > >>>>> http://tomee.apache.org/developer/migration/tomee-1-to-7.html > >>> intends to > >>>>> solve that issue, we can add any point we hit/encounter > >>>>> > >>>>> what else would be a blocker to make 1 EOL in June 2018? > >>>>> > >>>>> > >>>>> Romain Manni-Bucau > >>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog > >>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ > >>>>> rmannibucau> | > >>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > >>>>> <https://javaeefactory-rmannibucau.rhcloud.com> > >>>>> > >>>>> 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com > >>>> : > >>>>> > >>>>>> > >>>>>> > >>>>>> 2017-06-18 19:50 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid > >>>> : > >>>>>> > >>>>>>> regarding migration. > >>>>>>> There are 3 different main use cases afaict. > >>>>>>> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead > >>>> 1.7.x > >>>>>>> should be a no-brainer without any need to change something within > >>>> your > >>>>>>> application > >>>>>>> > >>>>>>> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb > >>> to > >>>>>>> org.apache.tomee. Done > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 3.) openejb-core for unit tests. This gets a bit trickier as the > >>>> various > >>>>>>> spec APIs from EE7 (tomee) and EE6 (your application) might clash. > >>>> This > >>>>> can > >>>>>>> be solved with an exclude setting in the maven-surefire-plugin > >>>>>>> > >>>>>> > >>>>>> Hmm, just means we upgrade API or you think to something else? > >>>>>> > >>>>>> I'll start a page > >>>>>> > >>>>>> > >>>>>>> LieGrue,strub > >>>>>>> > >>>>>>> > >>>>>>> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau < > >>>>>>> rmannibu...@gmail.com> wrote: > >>>>>>> > >>>>>>> > >>>>>>> 2017-06-18 18:42 GMT+02:00 Jonathan Gallimore < > >>>>> jgallim...@tomitribe.com > >>>>>>>> : > >>>>>>> > >>>>>>>> Thanks for the feedback. I think at least some sort of migration > >>>> guide > >>>>>>> is > >>>>>>>> needed as some settings have changed. It would be nice for > >>> people to > >>>>>>> find > >>>>>>>> out the easy way. Happy to discuss in another thread, but we > >>> should > >>>>>>> agree > >>>>>>>> when this will appear. > >>>>>>>> > >>>>>>> > >>>>>>> Which settings are you thinking about? > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> I also think some visibility on what the EOL statement will > >>> actually > >>>>>>> say (I > >>>>>>>> guess it would be a paragraph or two) would help community > >>>> discussion. > >>>>>>>> > >>>>>>> > >>>>>>> No more expectation from the core community (releases etc). So > >>>>> evolutions > >>>>>>> as best effort (no guarantee). > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> I suspect you won't agree, but I think an EOL is a major > >>>>> announcement. A > >>>>>>>> reminder is good if the thread has gone quiet, but I think lazy > >>>>>>> concensus > >>>>>>>> is less good, unless several reminders have been sent. You have > >>>>> stated a > >>>>>>>> deadline of today, a Sunday - I think some folks may miss that > >>> and > >>>> be > >>>>>>> too > >>>>>>>> late. I think mid week would be better to reduce the scope of > >>>> "missing > >>>>>>> it". > >>>>>>>> If we got to mid week, and had a couple more reminders, the lazy > >>>>>>> concensus > >>>>>>>> view would seem more reasonable. > >>>>>>>> > >>>>>>>> Wouldn't you prefer to make the EOL statement with a few more > >>> +1's? > >>>>>>>> > >>>>>>> > >>>>>>> Sure, now i used past releases as prevision of this topic activity > >>>>>>> plannification and even with 5 reminders i wouldnt have got more so > >>>>>>> preferring to move forward now. However as said I'm happy to > >>> discuss > >>>>> each > >>>>>>> points and delay what was just a proposal. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Jon > >>>>>>>> > >>>>>>>> On 18 Jun 2017 5:06 pm, "Romain Manni-Bucau" < > >>> rmannibu...@gmail.com > >>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> 2017-06-18 17:36 GMT+02:00 Jonathan Gallimore < > >>>>>>>>> jonathan.gallim...@gmail.com> > >>>>>>>>> : > >>>>>>>>> > >>>>>>>>>> On 18 Jun 2017 3:11 pm, "Romain Manni-Bucau" < > >>>>> rmannibu...@gmail.com > >>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> @Jon: please propose a policy then (same as rejecting a > >>> release, > >>>>>>> "no" > >>>>>>>> is > >>>>>>>>>> valid only if an alternative is proposed or a string blocker > >>> is > >>>>>>> found > >>>>>>>>> ;)). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I feel I stated my concerns pretty clearly. I didn't just > >>> reply > >>>> -1 > >>>>>>> and > >>>>>>>>> walk > >>>>>>>>>> away, which is what your comment above is suggesting I did. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Ok then understand it as i dont read it as an exit path for the > >>>>>>> project. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> But, allow me to rephrase anyway - beyond a "drop dead" date, > >>>> what > >>>>>>>>> exactly > >>>>>>>>>> is your policy? > >>>>>>>>>> > >>>>>>>>>> How many releases do you see in that time? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> As much as needed - up to request. Concretely if no user asks > >>> for > >>>> it > >>>>>>> no > >>>>>>>>> release, if users ask each month then ~12 (pby more ~10 > >>>>> realisticly), > >>>>>>> not > >>>>>>>>> sure we would do more but sounds way more than enough. It is in > >>>>>>>>> maintainance anyway so "when needed". > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> What documentation for migration are we going to provide? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Any doc needed but have to admit no doc should be needed. This > >>> is > >>>>>>> quite > >>>>>>>>> parallel to this track so if you see any lack please open a > >>> thread > >>>>> and > >>>>>>>>> we'll solve it. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Do we still intend to fix bugs and/or security issues after > >>> that > >>>>>>> date? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> No, EOL is exactly that: this soft is no more part of active > >>> code > >>>>>>> after > >>>>>>>> the > >>>>>>>>> date. > >>>>>>>>> > >>>>>>>>> Side note: already the case since few years actually if you > >>> check > >>>>> our > >>>>>>>> jira > >>>>>>>>> :(. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Would we continue to accept patches from the community after > >>>> that > >>>>>>> date? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> In best effort mode so no engagement but i dont see why we > >>>> wouldnt. > >>>>>>> Maybe > >>>>>>>>> something unclear: source will not be modified, moved, put read > >>>> only > >>>>>>>>> etc...just releases and maintainance is no more expectable from > >>>>> tomee > >>>>>>>>> project itself. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Your plan basically is to just stop, if I have read it > >>>> correctly. > >>>>> I > >>>>>>>> have > >>>>>>>>>> concerns about that, which I have stated. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I understand but it was to stop *next year* and we need a plan > >>>>> anyway. > >>>>>>>> 1.7 > >>>>>>>>> has several important issues due to the non maintainance it > >>> gets > >>>>>>> since > > >>>>>>>> 2 > >>>>>>>>> years. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> My proposal is simple; answer the questions and concerns > >>> about > >>>>> your > >>>>>>>>>> proposal and discuss it fully within the community rather > >>> than > >>>>>>> announce > >>>>>>>>>> something on the website with a single +1. I don't think > >>> that is > >>>>>>>>>> unreasonable. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Was not the idea, as stated in the topic it was a discussion > >>> but > >>>> no > >>>>>>>>> activity in > 10 days requires to take an action, either ack > >>> it by > >>>>>>>> default > >>>>>>>>> or .... well I don't see any alternative to take the active > >>>>> feedback. > >>>>>>>> Happy > >>>>>>>>> you catch up it now Jon and let's discuss based on previous > >>>> points - > >>>>>>> as > >>>>>>>>> this thread was intended for. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Jon > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Realisticly 1.7 is no more maintained (the cxf coming > >>>> exceptional > >>>>>>>> release > >>>>>>>>>> doesn't help since all the stack is outdated now and coming > >>> to > >>>> EOL > >>>>>>> and > >>>>>>>>>> reactivity is too long - we have > 100 bugs we don't backport > >>>> but > >>>>>>>> affect > >>>>>>>>>> 1.7). > >>>>>>>>>> The upgrade path is really a noop on our side thanks to > >>> javaee > >>>>>>> policy. > >>>>>>>> If > >>>>>>>>>> you are thinking about something in particular happy to add > >>> it > >>>> on > >>>>>>> the > >>>>>>>>> site. > >>>>>>>>>> > >>>>>>>>>> EOL doesn't mean we don't release, we can literally do 120 > >>>>> releases > >>>>>>> of > >>>>>>>>>> 1.7.x if we ack the proposed EOL. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog > >>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < > >>>> https://github.com/ > >>>>>>>>>> rmannibucau> > >>>>>>>>>> | > >>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE > >>>>> Factory > >>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> > >>>>>>>>>> > >>>>>>>>>> 2017-06-18 15:43 GMT+02:00 Mark Struberg > >>>>> <strub...@yahoo.de.invalid > >>>>>>>> : > >>>>>>>>>> > >>>>>>>>>>> So probably one more 1.7.x release and then let it fade > >>> out? > >>>>>>>>>>> > >>>>>>>>>>> LieGrue, > >>>>>>>>>>> strub > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Am 18.06.2017 um 13:55 schrieb Jonathan Gallimore < > >>>>>>>>>>> jonathan.gallim...@gmail.com>: > >>>>>>>>>>>> > >>>>>>>>>>>> I object. There are plenty of folks still using 1.7.x, > >>> and > >>>>> we've > >>>>>>>>> ported > >>>>>>>>>>>> over various fixes from master without too much trouble. > >>>>>>>>>>>> > >>>>>>>>>>>> My concern is that those on 1.7.x might be concerned to > >>> see > >>>> it > >>>>>>>> EOL'd. > >>>>>>>>>> I'd > >>>>>>>>>>>> like to see the upgrade path documented and a policy on > >>>> fixes > >>>>>>>> applied > >>>>>>>>>> to > >>>>>>>>>>>> 1.7.x documented and discussed before an EOL > >>> announcement. > >>>>>>>>>>>> > >>>>>>>>>>>> Jon > >>>>>>>>>>>> > >>>>>>>>>>>> On 18 Jun 2017 10:51 am, "Romain Manni-Bucau" < > >>>>>>>> rmannibu...@gmail.com > >>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> if noone objects before tomorrow i'll update the site > >>> with > >>>>> that > >>>>>>>>> policy > >>>>>>>>>>>>> then. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>>>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog > >>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < > >>>>>>> https://github.com/ > >>>>>>>>>>>>> rmannibucau> | > >>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | > >>>> JavaEE > >>>>>>>> Factory > >>>>>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2017-06-17 21:55 GMT+02:00 Mark Struberg > >>>>>>>> <strub...@yahoo.de.invalid > >>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> +1. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1.x has quite a few design shortcomings and 7.0.x is a > >>>>>>> backward > >>>>>>>>>>>>> compatible > >>>>>>>>>>>>>> drop in replacement. > >>>>>>>>>>>>>> And 8.x is just around the corner as well... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> LieGrue, > >>>>>>>>>>>>>> strub > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Am 06.06.2017 um 17:58 schrieb Romain Manni-Bucau < > >>>>>>>>>>>>> rmannibu...@gmail.com > >>>>>>>>>>>>>>> : > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> it is harder and harder to maintain 1.x branch since > >>>> almost > >>>>>>> no > >>>>>>>>>> library > >>>>>>>>>>>>> is > >>>>>>>>>>>>>>> maintained. Request is also decreasing for that > >>> version. > >>>>>>> Tomcat > >>>>>>>>> will > >>>>>>>>>>>>> also > >>>>>>>>>>>>>>> EOL tomcat 8 next year (1.x is on tomcat 7 which still > >>>> dont > >>>>>>> have > >>>>>>>>> an > >>>>>>>>>>>>>>> official EOL I think but never good to rely on an > >>>> outdated > >>>>>>>>> version, > >>>>>>>>>>>>>> Tomcat > >>>>>>>>>>>>>>> 7 is N-3 now). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Therefore do we want to plan an EOL for 1.7 that we > >>> don't > >>>>>>>> develop > >>>>>>>>>>>>> anymore > >>>>>>>>>>>>>>> anyway? What about june next year? Should let people > >>> more > >>>>>>> than > >>>>>>>>>> enough > >>>>>>>>>>>>>> time > >>>>>>>>>>>>>>> to migrate to TomEE 7. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> wdyt? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | > >>> Blog > >>>>>>>>>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog > >>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < > >>>>>>>> https://github.com/ > >>>>>>>>>>>>>> rmannibucau> | > >>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | > >>>>> JavaEE > >>>>>>>>> Factory > >>>>>>>>>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Andy Gumbrecht > >>>> https://twitter.com/AndyGeeDe > >>>> http://www.tomitribe.com > >>>> > >>> > >> > >> > >
