[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] About Profiles
|
> On 17. May 2018, at 15:24, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
>
> I believe strongly in the use of profiles in Jakarta EE not only to address different uses today but also in the future.
>
> The cost of building and maintaining a full Java EE platform is expensive and that cost is passed on to the companies licensing the software or buying support. A subset of the Java EE, such as the existing Web Profile, cost less in terms of development for vendors which means less cost for licenses and/or support for enterprise customers.
I'm not aware of such differences right now. Do Tomitribe clients have to pay different support fees for different distributions right now?
> Tomitribe, for example, supports Tomee which is a Java EE Web Profile platform; not the full Java EE platform. Supporting only the Web Profile product allows us to charge less for support and to better focus our resources on development of that platform in open source. We can also support a full platform, but that is more expensive option.
In future TomEE could fully support the Main Profile and not the Legacy Profile. This might be even better for marketing.
>
> In the future Jakarta EE will need to support things like microservices which is where the MicroProfile could be applied. In that case, it is again a subset of the full platform which is less expensive to develop and maintain for vendors who only want to focus on that aspect of archiecture. That translates into more choices and lower costs for enterprises who only need that subset of Jakarta EE. A vendor that specializes in microservices can more easily enter the market if they can focus their energies on only the subset of Jakarta EE technologies. If everyone has to support the full platform to be Jakarta EE compliant, than you are going to end up with a very small selection of vendors all of who have a very expensive platform to develop and maintain. That translates into higher costs for and weaker adoption by Enterprise customers.
>
> The use of profiles isn’t a technical solution so much as a market solution.
This didn't worked for MS Windows OS at all.
There were several Windows distributions available with different prices. I remember I was not sure what is the difference between "Professional" and "Ultimate".
I like the Apple model better. One OS for everyone - no confusion.
> It allows Jakarta EE to support a wider variety of applications and a larger ecosystem of vendors which translates, if well done, into a broader market appeal and stronger industry commitment.
I ran a full profile Wildlfly and Payara on a "microcontroller" of a weather station. What concrete use cases / hardware are you thinking about?
> Keep in mind that a vendor may choose to implement the full profile, a sub-profile, several sub-profiles, or all of the above and price their licenses and/or support accordingly. That is a Win, Win for everyone.
I don't think for the users. It introduces "unique snowflake" project.
Onboarding of young developers could be also challenging. I would always go with "keep it simple".
>
> On Thu, May 17, 2018 at 7:59 AM 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@xxxxxxxxxxx [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@xxxxxxxxxxx>
> 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@xxxxxxxxxxx [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@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
>
>
>
> ---
>
> 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
