| Re: [ee4j-community] EE4J and the JCP |
The Answer has been posted a few times (on this list as well)The intent is that the javax and java packages will continue to be allowed to be used for the existing Java EE 8 JSR API + extensions to that API. New specifications etc will have to use a new domain name space.I think this is an eminently fair compromise.Cheers,
Martijn_______________________________________________On 11 October 2017 at 11:01, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:Guillermo González de AgüeroAn explanatory note on this would be greatly appreciated from the community.Thanks Will for this words. So if I understand you correctly, the idea is to move the whole thing to a new more open and faster process. Will that include the permission to use the name Java and the javax pacakages?I'm sorry for being so insistent on this subject but I know there are a lot of people worried about that and I haven't seen a clear answer on the intentions. If the goal is to keep doing the same thing just in another place, trademark permissions should be moved, but I haven't perceived that intention.Regards,El mar., 10 oct. 2017 a las 0:33, Will Lyons (<will.lyons@xxxxxxxxxx>) escribió:The JCP has been extremely successful in creating the Java EE standards
since 1999, but software communities in 2017 have different
expectations. The Java EE community does not currently perceive the
process of evolving Java EE through the JCP as nimble, flexible or open
enough.
There are multiple reasons for this, but among them is the structure of
the JCP, which includes a set of interrelated agreements and governance
rules that define, for example, how technology is licensed, or voting
procedures. These are the kinds of things that community members want
to change. Unfortunately it is difficult to start with a set of
interrelated agreements and governance rules that are designed to make
the process what it is today, and simply tweak them to transform the
process. Comments from JCP EC members indicate this has been attempted
without success in the past. See Mark's, Martijn's and Mike's comments.
So I believe a fresh approach is required, not only to make it possible
to create a more nimble, flexible and open process, but to create a
process that will be perceived that way.
Will
On 10/9/17 4:57 PM, Lilian BENOIT wrote:
> I understand that you are in jcp and you know inside.
> But, now, the context is different. Oracle moves Java EE to Eclipse
> Foundation and loses leadership on this platform.
>
> Without JCP, what is standard in EE4J ?
> What different between Microprofile, EE4j or other ?
>
> The slowness of Java EE 8 was-it related to the Oracle Spec Lead who
> did not have the working time on it.
> On next version, Spec lead will come from Eclipse ?
>
> Too bad that we do not have the Oracle point of view in this discussion.
>
> Bests regards,
> Lilian.
>
> Le 2017-10-09 21:26, Martijn Verburg a écrit :
>> +1 - we’ve been involved for 5-7 years as the LJC and we’ve very
>> much come to the same conclusion
>>
>> On Mon, 9 Oct 2017 at 19:30, Mark Little <mlittle@xxxxxxxxxx> wrote:
>>
>>> We've tried to change the JCP over the years and have made some
>>> improvements but many of the things we (collective we) wanted to
>>> change ran into issues with various legal and process problems. I'm
>>> not allowed to disclose but suffice it to say that I believe we have
>>> evolved the JCP as far as we can where it is today and time spend
>>> trying to change it more would be better spent elsewhere.
>>>
>>> Sent with AquaMail for Android
>>> http://www.aqua-mail.com [1]
>>>
>>> On 9 October 2017 11:02:33 reza_rahman <reza_rahman@xxxxxxxxx>
>>> wrote:
>>> I would like to hear a bit more from the EE4J stakeholders, but my
>>> impression is that Oracle has no intention of doing anything else
>>> with Java EE in the JCP.
>>>
>>> You are correct in that I am alluding to the fact that Oracle has
>>> the unique power to unilaterally vote down whatever it wants in the
>>> JCP. While I am sure that could be changed, I am not sure it is
>>> worth it or whether it is even accomplishable. My impression also is
>>> that the Eclipse Foundation is not that averse to functioning more
>>> like a standards body.
>>>
>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>>
>>> -------- Original message --------
>>> From: Werner Keil <werner.keil@xxxxxxxxx>
>>> Date: 10/9/17 1:48 PM (GMT-05:00)
>>> To: ee4j-community@xxxxxxxxxxx
>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>>
>>> There is no Oracle veto on JSR votings in the EC.
>>>
>>> What Reza most likely means
>>> ishttps://jcp.org/en/procedures/jcp2#3.7.7 [2]
>>>
>>> Only for platform Umbrella JSRs (like Java EE 8 and before) Oracle
>>> must vote "yes" in order to make it pass. It could therefore fail a
>>> ballot except everyone else voting in favor, but it could not flip a
>>> failing vote unless it was just theirs missing to get to 3/4
>>> positive votes.
>>>
>>> EE4J is deliberately NOT meant to be an update to the Java EE
>>> platform in JSR terms. Otherwise a Spec Lead transfer ballot would
>>> be inevitable to do so. This seems neither in the interest of Oracle
>>> nor Eclipse or others. It'll be a "fork" (what everybody feared ;-)
>>> but hopefully one that remains compatible with existing APIs and
>>> standards where they continue to be used.
>>>
>>> Nevertheless, if EE4J "Release Train" 1.0 had to go through the JCP,
>>> then a few changes to the JCP documents could be necessary. In fact
>>> Oracle being the only possible Umbrella Spec Lead seems gone with
>>> 2.10 already. So jcp.next did some work on that.
>>>
>>> Whether EE4J still has obligations for backward-compatibility with
>>> its "ancestor" Java EE or not, that will be a good question. Most
>>> importantly to companies who trust in a mature, reliable stack that
>>> often needs to run for decades.
>>> Some "Hipsters" and more end customer facing solutions could afford
>>> to break and change things every other year, but when it comes to
>>> Industrial, Financial or even Safety Critical systems, you cannot
>>> afford to lose money or lives just because an upgrade from "My
>>> Bleeding Edge Hipster API" was upgraded from 3.0 to 5.0 and
>>> everything is different and incompatible.
>>>
>>> Whether Oracle is interested in either Java Embedded or Enterprise
>>> that is hard to say. All the things announced at Oracle Code around
>>> Fn sound like the only common denominator seems something running on
>>> the JVM, sometines not even that but some .js script library. As
>>> long as it runs in the Oracle Cloud and not somewhere else.
>>>
>>> If other vendors are still interested that e.g. your WAR, EAR or
>>> "Fat JAR" can be deployed against a Wildfly, IBM Liberty, Payara or
>>> TomEE container beside a few others then standardization remains
>>> crucial, regardless if it's JCP.org or something else.
>>>
>>> Werner
>>>
>>> On Mon, Oct 9, 2017 at 6:59 PM, <ee4j-community-request@xxxxxxxxxxx>
>>> wrote:
>>> Send ee4j-community mailing list submissions to
>>> ee4j-community@xxxxxxxxxxx
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>> or, via email, send a message with subject or body 'help' to
>>> ee4j-community-request@xxxxxxxxxxx
>>>
>>> You can reach the person managing the list at
>>> ee4j-community-owner@xxxxxxxxxxx
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of ee4j-community digest..."
>>>
>>> Today's Topics:
>>>
>>> 1. Re: EE4J and the JCP (reza_rahman)
>>>
>>>
>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Mon, 09 Oct 2017 12:59:01 -0400
>>> From: reza_rahman <reza_rahman@xxxxxxxxx>
>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>> Message-ID: <mailman.503.1507568346.6952.ee4j-community@xxxxxxxxxxx>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> It is not that well known, but Oracle actually wields sole veto
>>> power in the EC. As you also know, as holder of most of the JCP IP,
>>> Oracle can basically ignore whatever the EC says. At best, the EC
>>> can stop JCP progress, but that's hardly productive or in any ones
>>> interest.
>>> I've always wished the EC well. It was setup with the right
>>> intentions and has well meaning folks like yourself on it. The
>>> practical reality from an Oracle management perspective is sadly
>>> very different from what it should be. Indeed many companies in the
>>> EC Oracle management views with deep seated suspicion.
>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>> -------- Original message --------From: Werner Keil
>>> <werner.keil@xxxxxxxxx> Date: 10/9/17 12:29 PM (GMT-05:00) To:
>>> ee4j-community@xxxxxxxxxxx Subject: Re: [ee4j-community] EE4J and
>>> the JCP
>>> I don't think there are so many alternatives.?Eclipse never was and
>>> never intends to standardize things itself.
>>> There are always actual standard bodies like OASIS, OGC, OSGi and
>>> others defining standards which projects build upon.
>>> There are not too many such organizations that would suit the needs
>>> of the Java or other languages and platforms.?Sun discussed with a
>>> few like ISO, but I know best, almost all of them are extremely
>>> slow-moving.
>>> Take W3C and efforts like HTML5, it took decades. The update to JSR
>>> 363 is fueled by changes to the Metric System and SI Standard
>>> (inter-related to various ISO standards). The first major change to
>>> that standard since 1960!!!
>>> Then there are other players like NetFlix who just don't care about
>>> standardization. I spoke to one of their speakers at the JCP Party
>>> and they said like Inspector Morse "We don't join things". Meaning,
>>> like Facebook or several others they do most things in the open, but
>>> they have no interest to standardize them nor to join either Eclipse
>>> or Apache Foundation or the JCP.
>>>> I agree with Kevin's assessment on this. Efficiency is also just
>>> one issue
>>>> at the JCP. The bigger issue is direct and indirect Oracle
>>> control,
>>>> especially at the EC level. While these are solvable problems, the
>>> question
>>>> we should ask is whether it is worth solving instead of using
>>> avenues that
>>>> are already far more vendor neutral.
>>> What could be more vendor neutral than the JCP EC?Oracle has no way
>>> of overruling things in the EC.?
>>> Jigsaw was nearly stopped by the EC. The issues that got many of us
>>> vote against it came by members of the community. And were
>>> ultimately heard. If this was Microsoft, Facebook or even Google in
>>> their own projects like .NET, OpenGraph, Android, etc. they merely
>>> listen to a few large partners and vendors maybe but you would not
>>> see their projects take the community that much into consideration.
>>> The only JSR that failed a Renewal Ballot was also led by Oracle.
>>> That one also got delayed by other duties the Spec Lead was drawn
>>> into (e.g. stuff like Project FN;-) so the EC killed it and Oracle
>>> could only vote against that with a single vote like everyone else.
>>> As for "a new JCP.next" that's already happening. Especially when it
>>> comes to new JSRs that differ very little from the previous ones
>>> (e.g. the Java SE Umbrellas) there shall be an easier way to file
>>> them based on existing information.
>>> Werner
>>>
>>> On Mon, Oct 9, 2017 at 6:00 PM,
>>> <ee4j-community-request@xxxxxxxxxxx> wrote:
>>> Send ee4j-community mailing list submissions to
>>>
>>> ? ? ? ? ee4j-community@xxxxxxxxxxx
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>
>>> ? ? ? ? https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>> or, via email, send a message with subject or body 'help' to
>>>
>>> ? ? ? ? ee4j-community-request@xxxxxxxxxxx
>>>
>>> You can reach the person managing the list at
>>>
>>> ? ? ? ? ee4j-community-owner@xxxxxxxxxxx
>>>
>>> When replying, please edit your Subject line so it is more specific
>>>
>>> than "Re: Contents of ee4j-community digest..."
>>>
>>> Today's Topics:
>>>
>>> ? ?1. Re: EE4J and the JCP (Guillermo Gonz?lez de Ag?ero)
>>>
>>>
>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>>
>>> Date: Mon, 09 Oct 2017 15:59:38 +0000
>>>
>>> From: Guillermo Gonz?lez de Ag?ero? ? ? <z06.guillermo@xxxxxxxxx>
>>>
>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>>
>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>>
>>> Message-ID:
>>>
>>> ? ? ? ?
>>> <CAG1ZpUa0u=cV1N=YPmDkZ1QEYB8HQDYFVzmkV-FDPA4VeL7tsg@xxxxxxxxxxxxxx>
>>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> But creating a new standards body that fulfils the requirements of
>>> other
>>>
>>> Java specs will also need a lot of work.
>>>
>>> I'm not against the idea of creating a new standarization process,
>>> but the
>>>
>>> JCP still provides us some benefits like the use of the Java name
>>> and
>>>
>>> packages. I'd personally don't create a new system while those
>>> issues are
>>>
>>> not resolved.
>>>
>>> The Config JSR will be a good experiment of the MicroProfile style
>>> of
>>>
>>> defining a spec on its own and then moving it to the JCP just for
>>>
>>> standarization purposes.
>>>
>>> I believe that approach could work for us *while* we define a new
>>> system.
>>>
>>> Rushing to create a new body will probably make us fail and fragment
>>>
>>> community.
>>>
>>> Some kind of EG and process will be needed in the meantime but
>>> MicroProfile
>>>
>>> has shown us that progress can be fast yet solid with little
>>> bureaucracy. A
>>>
>>> new JCP.next can be created in parallel.
>>>
>>> Maybe private discussions are already taking place on this subject.
>>> Some
>>>
>>> overview of the ideas and intentions would be appreciated.
>>>
>>> Regards,
>>>
>>> Guillermo Gonz?lez de Ag?ero
>>>
>>> El lun., 9 de octubre de 2017 17:38, reza_rahman
>>> <reza_rahman@xxxxxxxxx>
>>>
>>> escribi?:
>>>
>>>> I agree with Kevin's assessment on this. Efficiency is also just
>>> one issue
>>>
>>>> at the JCP. The bigger issue is direct and indirect Oracle
>>> control,
>>>
>>>> especially at the EC level. While these are solvable problems, the
>>> question
>>>
>>>> we should ask is whether it is worth solving instead of using
>>> avenues that
>>>
>>>> are already far more vendor neutral.
>>>
>>>>
>>>
>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>>
>>>>
>>>
>>>> -------- Original message --------
>>>
>>>> From: Kevin Sutter <kwsutter@xxxxxxxxx>
>>>
>>>> Date: 10/9/17 10:59 AM (GMT-05:00)
>>>
>>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>>
>>>> Subject: Re: [ee4j-community] EE4J and the JCP
>>>
>>>>
>>>
>>>> I can understand Michael's and others concerns voiced in this
>>> thread...
>>>
>>>> Splintering the Java community is definitely not a goal of this
>>> EE4J
>>>
>>>> movement.? But, the JCP has not demonstrated that it can move
>>> faster.
>>>
>>>> Yet...? Granted, there is a requirement for Java SE to have it
>>> move faster
>>>
>>>> to meet the newly proposed 6 month cycles, but it hasn't been
>>> proven yet.
>>>
>>>> The MicroProfile community has shown that it can innovate on a
>>> faster
>>>
>>>> schedule with it's recent MP 1.1 and 1.2 releases.? I'm not trying
>>> to say
>>>
>>>> that the MicroProfile efforts produced "standards", but I am
>>> noting that
>>>
>>>> innovation needs a lighter weight process in order to compete and
>>> succeed
>>>
>>>> in this cloud-native, microservices world.
>>>
>>>>
>>>
>>>> The specification process in EE4J has not been determined yet.?
>>> Maybe if
>>>
>>>> the JCP proves that it can process JSRs in a more expedient
>>> manner, then
>>>
>>>> maybe it can or will be considered as part of the EE4J
>>> specification
>>>
>>>> process.? In the mean time, we have to leave other options on the
>>> table.
>>>
>>>>
>>>
>>>> --? Kevin
>>>
>>>>
>>>
>>>> On Mon, Oct 9, 2017 at 5:04 AM, Martijn Verburg
>>> <martijnverburg@xxxxxxxxx>
>>>
>>>> wrote:
>>>
>>>>
>>>
>>>>> Hi All,
>>>
>>>>>
>>>
>>>>> I can clarify some of this.? Responses inline
>>>
>>>>>
>>>
>>>>> On 9 October 2017 at 10:00, Guillermo Gonz?lez de Ag?ero <
>>>
>>>>> z06.guillermo@xxxxxxxxx> wrote:
>>>
>>>>>
>>>
>>>>>> Hi,
>>>
>>>>>>
>>>
>>>>>> As I said on Markus thread, my concern is that we might not be
>>> moving
>>>
>>>>>> Java EE to a different place, but discontinuing Java EE and
>>> creating a new
>>>
>>>>>> project based on it. On that matter, we'll need clarification
>>> from Oracle
>>>
>>>>>> and the participating vendors: are you really open sourcing
>>> what's already
>>>
>>>>>> there, or are you making Java slimmer by moving away everything
>>> but the
>>>
>>>>>> standard edition? In the second case (which I hope is not the
>>> case), I'd
>>>
>>>>>> sadly understand that a common standards body wouldn't make
>>> sense.
>>>
>>>>>>
>>>
>>>>>> The JCP process has been blamed for being too slow, but how will
>>> it
>>>
>>>>>> allow Java SE to release a new version every 6 months? Surely
>>> that will
>>>
>>>>>> need some changes on the JCP. Could those changes also help us?
>>> Should we
>>>
>>>>>> participate on those discussions asking for our needs?
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>> Yes the JCP is altering its process, primarily cutting down the
>>> minimum
>>>
>>>>> and maximum times for various phases and voting periods.? This is
>>> being
>>>
>>>>> worked on in conjunction with the folks from OpenJDK and Oracle
>>> and I
>>>
>>>>> everyone is comfortable with the changes being proposed (just
>>> needs to go
>>>
>>>>> through various votes to pass).
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>> In my opinion it's still too early to abandon the JCP. We should
>>> see
>>>
>>>>>> before if it can still be changed to take everyone's concerns
>>> into account
>>>
>>>>>> (Java SE, Java ME and Java EE) and in case it's too difficult,
>>> I'm with you
>>>
>>>>>> and Markus, we should create a common replacement.
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>> I think the EE4J community will need to define a *vendor neutral*
>>> body to
>>>
>>>>> effectively replace the JCP with regards to defining
>>> specifications and
>>>
>>>>> certifications for whatever the community produces.
>>>
>>>>>
>>>
>>>>> The JCP is the best construct we could have at the time. But
>>> because it
>>>
>>>>> is 'heavily influenced' by a single vendor (Oracle) it's simply
>>> not the
>>>
>>>>> true neutral body that we all want going forwards.? That's not to
>>> say that
>>>
>>>>> the JCP and/or Oracle did a bad job in stewarding Java EE /
>>> Enterprise
>>>
>>>>> Java, but a more open body will certainly be an improvement.
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>> PS: could you please point me to some link on the Java ME
>>> movement you
>>>
>>>>>> mention? I haven't found any information about it.
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>> Gluon, V2Com and other ME companies are trying to get ME kick
>>> started
>>>
>>>>> again.? please contact pmo@xxxxxxx to get involved.
>>>
>>>>>
>>>
>>>>> Cheers,
>>>
>>>>> Martijn (London Java Community - JCP EC member)
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>> Regards,
>>>
>>>>>>
>>>
>>>>>> Guillermo Gonz?lez de Ag?ero
>>>
>>>>>>
>>>
>>>>>> El lun., 9 oct. 2017 a las 4:19, Michael Nascimento
>>> (<misterm@xxxxxxxxx>)
>>>
>>>>>> escribi?:
>>>
>>>>>>
>>>
>>>>>>> Consolidating my thoughts here with the correct thread name:
>>>
>>>>>>>
>>>
>>>>>>> My main concern is that, while we might be doing something
>>> better
>>>
>>>>>>> suited for the Java EE community, we're scattering the Java
>>> community even
>>>
>>>>>>> more. OpenJDK has its own contribution agreements, rules and
>>> process; we're
>>>
>>>>>>> about to create something different here; everything else left
>>> in the JCP
>>>
>>>>>>> will follow the current process; apparently Java ME wants to do
>>> something
>>>
>>>>>>> similar to EE. So this new reality will mean one's
>>> contributions to one
>>>
>>>>>>> part of Java means nothing when they contribute to the rest,
>>> there'll be a
>>>
>>>>>>> lot to learn process-wise, paperwork to be filled... We're
>>> actually making
>>>
>>>>>>> it harder for people to contribute to Java *in general*.
>>>
>>>>>>>
>>>
>>>>>>> While I understand OpenJDK is kind of a "sideways" situation,
>>> I'd like
>>>
>>>>>>> to propose we pursue something here in terms of specification
>>> process that
>>>
>>>>>>> can be used for all Java specifications in the future that find
>>> the JCP too
>>>
>>>>>>> heavyweight and problematic, so that we don't have one solution
>>> for every
>>>
>>>>>>> facet of Java. Something like "Open Standards for Java". If key
>>> players as
>>>
>>>>>>> IBM, Red Hat, Tomitribe et al and some communities, as the LJC,
>>> conclude
>>>
>>>>>>> the JCP is not the way to do things going forward, I'm making a
>>> plea for
>>>
>>>>>>> JCP.next to be established here - and not just EE4J spec
>>> process;
>>>
>>>>>>> otherwise, we're fragmenting the community even more and making
>>>
>>>>>>> contributions to Java, as a whole, even more painful.
>>>
>>>>>>>
>>>
>>>>>>> To Mike Milinkovich, following up the question I've made: if
>>> the
>>>
>>>>>>> Eclipse Foundation is the one submitting the JSRs, wouldn't all
>>> IP from the
>>>
>>>>>>> specs belong to the Foundation? Wouldn't it be open and
>>> egalitarian?
>>>
>>>>>>>
>>>
>>>>>>> Regards,
>>>
>>>>>>> Michael
>>>
>>>>>>> _______________________________________________
>>>
>>>>>>> ee4j-community mailing list
>>>
>>>>>>> ee4j-community@xxxxxxxxxxx
>>>
>>>>>>> To change your delivery options, retrieve your password, or
>>> unsubscribe
>>>
>>>>>>> from this list, visit
>>>
>>>>>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>>>>>>
>>>
>>>>>>
>>>
>>>>>> _______________________________________________
>>>
>>>>>> ee4j-community mailing list
>>>
>>>>>> ee4j-community@xxxxxxxxxxx
>>>
>>>>>> To change your delivery options, retrieve your password, or
>>> unsubscribe
>>>
>>>>>> from this list, visit
>>>
>>>>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>> _______________________________________________
>>>
>>>>> ee4j-community mailing list
>>>
>>>>> ee4j-community@xxxxxxxxxxx
>>>
>>>>> To change your delivery options, retrieve your password, or
>>> unsubscribe
>>>
>>>>> from this list, visit
>>>
>>>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>>>>
>>>
>>>>>
>>>
>>>> _______________________________________________
>>>
>>>> ee4j-community mailing list
>>>
>>>> ee4j-community@xxxxxxxxxxx
>>>
>>>> To change your delivery options, retrieve your password, or
>>> unsubscribe
>>>
>>>> from this list, visit
>>>
>>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>>>
>>>
>>> -------------- next part --------------
>>>
>>> An HTML attachment was scrubbed...
>>>
>>> URL:
>>>
>> <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/f9a6234f/attachment.html
>>
>>> [4]>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>>
>>> ee4j-community mailing list
>>>
>>> ee4j-community@xxxxxxxxxxx
>>>
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>>
>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>> End of ee4j-community Digest, Vol 2, Issue 46
>>>
>>> *********************************************
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>>
>> <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/f6574597/attachment.html
>>
>>> [5]>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> ee4j-community mailing list
>>> ee4j-community@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>>
>>> End of ee4j-community Digest, Vol 2, Issue 52
>>> *********************************************
>>>
>>> _______________________________________________
>>> ee4j-community mailing list
>>> ee4j-community@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community [3]
>>
>> --
>>
>> Cheers, Martijn (Sent from Gmail Mobile)
>>
>> Links:
>> ------
>> [1] http://www.aqua-mail.com
>> [2] https://jcp.org/en/procedures/jcp2#3.7.7
>> [3] https://dev.eclipse.org/mailman/listinfo/ee4j-community
>> [4]
>> https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/f9a6234f/attachment.html
>>
>> [5]
>> https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171009/f6574597/attachment.html
>>
>>
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community