| Re: [jakarta.ee-community] About Profiles |
If you mean without UI it mostly would be a REST service kind of profile.
Anyway not sure how much of such extensive thread is taken into consideration when vendors decide what profiles to apply.A few more detailed discussions also sound like they should be continued in respective groups about Servlet, JMS and others.Werner
On Mon, May 21, 2018 at 9:19 PM, Mrinal Kanti <design@xxxxxxxxxxx> wrote:On Mon, May 21, 2018 at 5:12 PM, Adam Bien <abien@xxxxxxxxxxxxx> wrote:
> On 20. May 2018, at 12:40, Mrinal Kanti <design@xxxxxxxxxxx> wrote:
>
> I was referring to http://microprofile.io/project/eclipse/microprofile-bom/spec . Nevertheless, thanks for the info./src/main/asciidoc/architectur e.asciidoc
>
> Coming back to the point, I think this should suffice:
>
> Existing Profiles:
> • Full Profile
> • Web Profile
> Proposed Profiles:
> • Full Profile (as-is)
> • Web Profile (revised to include a few more new specs for building modern applications with greenfield approach). Existing certifications for applications should not be impacted so long as we are not removing any specs from that list. App server vendors would have to re-certify because they need to provide additional API implementations.
> • Web Profile Lite (new profile to support only bare minimum web based development using servlet, CDI and a few core specs)
Why someone would choose Web Profile Lite over Web Profile?With Web Profile Lite I meant the Web Profile without the UI (JSF) and JPA/EJB3 LIte APIs. As this would allow developers to chooses their own UI and persistence stack and still certify with Jakarta EE at a bare minimum level. I have seen a lot of applications which have chosen the path of multi-channel UI (native mobile apps + browser) and different persistence options with NoSQL databases.The Web Profile expanded version can continue to include other modern specs that can help in web development as adding more specs to it won't invalidate existing apps that are certified on it. Only app server vendors need to re-certify.The overall intent is to avoid branding anything as "Legacy" (or anything similar). {What would we mean by a Legacy profile? Do we say that Legacy profiles do not support newer APIs? If yes, then we are creating a barrier for applications that want to use the newer APIs but still have to connect with other enterprise applications over legacy channels. If no, then how is the term Legacy justified if they contain newer APIs as well.}-Mrinal> • MicroProfile (as BOM or a la carte for targeting PaaS/SaaS based cloud infrastructure). Whether, MP needs separate profiles to have a certified stack for each PaaS/SaaS platform is for them to decide.
> However, I am strongly against "Within a profile a vendor may package a newer version of a prescribed spec, if it's compatible." This may cause problems at various levels:
> • Portability issues across products which are certified on the same version of Jakarta EE as not all vendors may support the newer versions of specs.
> • Vendors shipping out half-baked/tested implementations as technology preview and still claiming certifications. This then becomes a marketing gimmick to force the customer to upgrade their licenses to the next version of app server where full support for that new implementation is assured. If someone is interested in supporting later version of specs in their existing servers certified for an existing version of Jakarta EE then they should do so as "feature/preview packs" and withdraw claims to any certifications wherever the feature packs are in use.
> • Operational Issues. IT teams would have to manage additional configurations and it becomes harder to troubleshoot issues arising out of various spec versions whose implementations also pull in third party dependencies that may create compatibility issues with existing application libraries in multi-app deployment scenario.
>
> -Mrinal
>
>
> On Sun, May 20, 2018 at 3:32 PM, Werner Keil <werner.keil@xxxxxxxxx> wrote:
> No, Microprofile does not have a BOM.
> Only a Parent POM for internal use.
>
> There were discussions but I didn't see an actual BOM created so far.
>
>
> Werner
>
> Mrinal Kanti <design@xxxxxxxxxxx> schrieb am So., 20. Mai 2018, 10:18:
> I am just trying to understand what is the agenda here. Obviously, we are not trying to debate the necessity of profiles or their importance. The first few bullet points just reiterates what profiles are. So I do not see them adding value to the discussion here.
>
> What I see is that you are trying to suggest an "all" profile sans all that stuff that you consider "legacy". I understand that you want to deliver a server config that contains only the APIs that have been developed in more recent times so that the resultant config set can be Jakarta EE certified. The way I see it, the current Web Profile should be sufficient for it if someone is trying to build a simple CRUD application based on those APIs. I don't think you are taking into consideration (or addressing) the enterprise landscape which can include integration with various middleware products/platforms and portal based applications.
>
> Microprofile already has a BOM and as I gather from various discussions, many clients are/prefer using them a la carte.
>
> We can always revisit the scope of APIs included in the current Web Profile and include more if needed without breaking applications which are already certified on it. For those who want a more leaner config set, we can define a Web Profile "lite" version with the Servlet, CDI and a few other core APIs.
>
> I think this should suffice for whatever we are trying to "solve" here.
>
> P.S. I would have preferred a more modular approach similar to what Liberty is trying to achieve. But unfortunately, based on the recent conversations in the OpenLiberty forums, it seems OpenLiberty is currently being positioned (only) as an open source version of the WebSphere Liberty app server rather than an independent platform. What I would have preferred is a set of SPI specifications that are targeted for app server vendors to implement so that we could standardize on a feature based repository approach to ensure portability across vendors.
>
> -Mrinal
>
>
> On Fri, May 18, 2018 at 5:37 AM, Dimitris Andreadis <dandread@xxxxxxxxxx> wrote:
> I've posted my own summary before and didn't get any feedback, so re-posting in case it got lost in this thread. Do people agree on those guidelines related to profiles?
> • We need to define "some" profiles for certification and portability purposes.
> • A vendor may claim compliance to one or more profiles
> • Specs should have stand alone TCKs so they can be tested separately and profiles could have additional tests that test profiles as collections of APIs (profile platform tests).
> • Profiles don't necessarily need to inherit from each other, but they could.
> • Within a profile a vendor may package a newer version of a prescribed spec, if it's compatible.
> • Within a profile a vendor may provide additional APIs. This doesn't change the profile itself.
> • Within a profile a vendor may let the user add support for additional APIs.
> • A vendor should have the freedom to offer the user the option of reducing/optimizing the runtime that implements a particular profile (which may be also enhanced by the vendor or the user with additional APIs), for example, by removing API implementations not in use by a particular app, or creating a runtime specific for a particular app and link externally to the deployment or bundle everything together in a fat jar, or perform any packaging optimization that can improve consumption in a containerized/cloud environment (e.g. bundle the app, the runtime and a customized version of the jvm to form an executable).
> • A vendor could offer the user the ability to create their own custom profiles by starting from scratch, in which case the resulting configuration is not considered "certified".
> Obviously the idea is that profiles provide to the users different minimum baselines they can enhance and use to build their apps in a portable fashion, while giving enough space to Jakarta EE implementors to compete and innovate on features and performance/deployment optimizations.
> As to what the exact profiles should be, if we believe that backwards compatibility is important, we should provide the existing
> • Java EE Full profile, (Jakarta EE Full Legacy profile?)
> • Java EE Web profile, (Jakarta EE Web profile, if still relevant)
> Then for new apps we should be probably looking at new/modern:
> • Jakarta EE All profile, with non needed legacy APIs removed and new ones (possibly) added
> • Jakarta EE Micro profile, geared towards microservices
> Again, profiles could inherit from each other, but I don't see that as a requirement, while the proposed names are just indicative.
> Cheers
>
> /Dimitris
>
> Dimitris Andreadis
> Engineering Director
> Red Hat JBoss EAP/WildFly
>
> On 17/05/2018 15:48, Kevin Sutter wrote:
>> +1, Mark. We (IBM) were able to capitalize on the defined WebProfile for Java EE 6 for our early WebSphere Liberty offerings. Our customers were demanding "Java EE" for Liberty, but we knew we couldn't deliver the full platform in these early releases of Liberty. (Actually, we didn't even know if we *wanted* to deliver the full Java EE platform on Liberty at that time...) Having a defined WebProfile in Java EE 6 allowed us to satisfy these customer requirements in a timely manner. We were able to pass the defined subset of CTS/TCK tests for the WebProfile and this defined compliance with the standard provided the necessary assurances to our customers that Liberty was a real application server.
>>
>> Since that time, we have decided that Liberty should also be compliant with the full platform. But, that decision would not cause us to promote a single profile (or platform) for Jakarta EE. We need subsets of functionality defined as profiles to allow more flexibility for both the developers/vendors implementing the technology and the customers that consume the technology.
>>
>> ---------------------------------------------------
>> Kevin Sutter
>> STSM, MicroProfile and Java EE architect
>> e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
>> phone: tl-553-3620 (office), 507-253-3620 (office)
>> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>>
>>
>>
>> From: Mark Little <mlittle@xxxxxxxxxx>
>> To: Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
>> Date: 05/17/2018 08:28 AM
>> Subject: Re: [jakarta.ee-community] About Profiles
>> Sent by: jakarta.ee-community-bounces@eclipse.org
>>
>>
>>
>> Dominik, you may feel that my examples are not valid but that doesn't
>> mean they are actually invalid :) The discussions around profiles date
>> back many years in the JCP and unfortunately I'm not able to check at
>> the moment as to whether those were public. But suffice it to say we
>> (Red Hat), IBM, Oracle and many others here, including users, provided
>> examples of why profiles were a good thing and necessary based on many
>> many years of real world use cases and thousands of customers asking
>> for precisely that sort of thing. As I said earlier though, you are
>> not alone in only wanting to have the full profile and that's fine
>> too. Maybe others, such as Tomitribe who only provide the WebProfile,
>> will chime in with some examples of their own but I can tell you that
>> since Red Hat implemented both the WebProfile and full profile in our
>> community and product app servers we have seen significant adoption of
>> both and those developers make the choice based on some of the reasons
>> I gave and they clearly understand why and believe their actions are
>> valid too :)
>>
>> Mark.
>>
>> On Thu, May 17, 2018 at 1:59 PM, Dominik Hufnagel
>> <mail@xxxxxxxxxxxxxxxxxxx> wrote:
>> > Well, there certainly are users which are not happy with just the full
>> > profiles and I am sure there are reasons. I do not say there is no need for
>> > more profiles, but until now I have not seen reasons for it, which justifies
>> > it.
>> >
>> > For me, your arguments do not justify the complexity for users having to
>> > choose between profiles. If I start a project and having to make decisions
>> > on what profile to use, how would that be less expensive than running a
>> > cloud machine with 50MB more for years? Let’s take AWS for example, where a
>> > block storage costs about 0.1-0.2$ per GB per Month.
>> >
>> > Regarding boot times, may you/one can specify what fast means? I have a
>> > wildfly app booting in < 10 seconds where a spring boot app I am currently
>> > working on (with almost just REST interfaces) needs > 15 seconds to boot.
>> >
>> >
>> >
>> > If you think about the buzzword IoT, then clearly the full profile may not
>> > suit. But I am not sure if this has to be covered under Jakarta EE.
>> >
>> >
>> >
>> > I am with you in terms of complexity and portability. For small
>> > applications, where mostly one war or app is deployed, it would be
>> > beneficial to be able to configure the Application Server (DB, JMS-Queues,
>> > …) with any mechanism from inside the war (let’s say a properties file or
>> > something). I would love to see such mechanisms in Jakarta EE, but this is
>> > not really related to profiles.
>> >
>> >
>> >
>> > I also think it would be beneficial to have a legacy profile for the stuff
>> > that is not anymore ‘state ot the art’, so that the main profile could be
>> > more lean.
>> >
>> >
>> >
>> > To be clear: I have no final opinion about this topic yet. I just like to
>> > see some valid arguments for having more profiles or for not have more
>> > profiles. What I also did not see in this discussion so far, are examples
>> > for profiles and how they fit together. This would help getting a clearer
>> > image of the needs from those who argue for having more profiles.
>> >
>> >
>> >
>> > Dominik
>> >
>> >
>> >
>> > Von: jakarta.ee-community-bounces@eclipse.org
>> > [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx ] Im Auftrag von Mark Little
>> > Gesendet: Donnerstag, 17. Mai 2018 13:47
>> >
>> >
>> > An: Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
>> > Betreff: Re: [jakarta.ee-community] About Profiles
>> >
>> >
>> >
>> > This isn’t just about vendor choice. You are certainly not alone in being
>> > happy with the full profile option. However, there are other classes of
>> > users/developers that aren’t and these have existed since the dawn of J2EE.
>> > For example, some people want to deploy their favour app server on to
>> > constrained devices which may be running on the cloud where an additional
>> > 50MB costs real money when run for hours or days or weeks or longer. Some
>> > developers want to reduce the maintenance complexity or boot time of their
>> > favourite app server by stripping out those capabilities they don’t want.
>> > Now you could argue that these developers could just do this themselves
>> > anyway, e.g., JBossAS has supported this kind of pruning from the start.
>> > However, if you want portability and interoperability of your apps so you’re
>> > not tied to a specific app server implementation/vendor, having standardised
>> > profiles is the right approach.
>> >
>> >
>> >
>> > Mark.
>> >
>> >
>> >
>> >
>> >
>> > On 16 May 2018, at 23:16, Dominik Hufnagel <mail@xxxxxxxxxxxxxxxxxxx> wrote:
>> >
>> >
>> >
>> > As a user of JavaEE, I do not get the idea behind having multiple profiles.
>> > May someone can explain the benefits for users? If I can have a single
>> > profile with all available features, I would take it and I do not bother
>> > using a server which is 50MB larger of one with a „smaller“ profile. I can
>> > understand that it could be harder for vendors to enter the market having to
>> > provide the full profile. But for me, this would not be an argument for
>> > using smaller profiles. I’d rather take a server from a vendor which offers
>> > me the full profile.
>> >
>> >
>> >
>> > If I would use the MicroProfile and want to have JPA, do I have to add
>> > external dependencies? I really like some of the new APIs of the
>> > MicroProfile and would be happy to see them coming to JakartaEE.
>> >
>> > Dominik
>> >
>> >
>> >
>> >
>> >
>> > Von: jakarta.ee-community-bounces@eclipse.org
>> > [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx ] Im Auftrag von Mark Little
>> > Gesendet: Mittwoch, 16. Mai 2018 11:42
>> > An: Jakarta EE community discussions <jakarta.ee-community@eclipse.org >
>> > Betreff: Re: [jakarta.ee-community] About Profiles
>> >
>> >
>> >
>> > Hopefully others have responded already but … it’s for both: quick summary …
>> > vendors so they can ensure conformance and users so they can ensure
>> > portability and interoperability of their apps.
>> >
>> >
>> >
>> > Speaking with my MicroProfile hat on, I for one would not want to trade the
>> > current MicroProfile for a full Jakarta EE profile and neither would our
>> > users.
>> >
>> >
>> >
>> > Mark.
>> >
>> >
>> >
>> >
>> >
>> > On 7 May 2018, at 17:33, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>> >
>> >
>> >
>> > So then the first question is perhaps; who wants profiles and benefits from
>> > it? Is a profile intended for vendors or for users?
>> >
>> >
>> >
>> >
>> >
>> > ---
>> >
>> > Mark Little
>> >
>> > mlittle@xxxxxxxxxx
>> >
>> >
>> >
>> > JBoss, by Red Hat
>> >
>> > Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
>> > Road, Co. Cork.
>> > Registered in the Companies Registration Office, Parnell House, 14 Parnell
>> > Square, Dublin 1, Ireland, No.304873
>> > Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
>> > Keith Phelan, Matt Parson (USA)
>> >
>> >
>> >
>> > _______________________________________________
>> > jakarta.ee-community mailing list
>> > jakarta.ee-community@eclipse.org
>> > To change your delivery options, retrieve your password, or unsubscribe from
>> > this list, visit
>> > https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>> >
>> >
>> >
>> > ---
>> >
>> > Mark Little
>> >
>> > mlittle@xxxxxxxxxx
>> >
>> >
>> >
>> > JBoss, by Red Hat
>> >
>> > Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
>> > Road, Co. Cork.
>> > Registered in the Companies Registration Office, Parnell House, 14 Parnell
>> > Square, Dublin 1, Ireland, No.304873
>> > Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
>> > Keith Phelan, Matt Parson (USA)
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > jakarta.ee-community mailing list
>> > jakarta.ee-community@eclipse.org
>> > To change your delivery options, retrieve your password, or unsubscribe from
>> > this list, visit
>> > https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>> >
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>>
>>
>>
>>
>>
>>
>> ______________________________
>> _________________
>> jakarta.ee-community mailing list
>>
>> jakarta.ee-community@eclipse.org
>>
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>
>> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
workshops.adam-bien.com
webstandards.training
webcomponents.training
javaeemicro.services
adambien.blog
Author of:
"Real World Java EE Night Hacks”,
"Real World Java EE Patterns— Rethinking Best Practices"
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee- community