| [jakarta.ee-spec.committee] process, platforms, profiles, etc. |
|
First, thanks to David for trying to pull me into the discussion.
Sadly, it was too early in the morning for me to have the
lightning-fast reflexes needed to unmute and interrupt the
discussion before someone else jumped in. But that's ok because
many of you made the same points I would've made. Next, it wasn't clear to me whether this was formally done so I'd like to nominate Mike as the chairperson for this group and the leader of these meetings. Eclipse needs to own and manage the process we're defining so Mike seems like the right person to lead this group. I'm still trying to understand whether we're defining a process to replace the JCP, or whether we're defining a process that can and will only be used to define the Jakarta EE platform. If the former, most of the discussion about profiles belongs elsewhere. And we would need to allow for the possibility that a new spec would be defined but not included in the Jakarta EE platform. Think of the Portlet and related specs in the JCP; would we want to allow for another ecosystem of specs perhaps related to but not part of Jakarta EE? Expanding the platform to include every spec ever defined means the platform will grow without bound, placing a significant burden on vendors that ship full platform implementations. Making every new thing optional means they're not really part of the platform because applications can't depend on them. Diving into the profile issue a bit, let me provide some background on the Web Profile and my opinion on what we should do going forward... The Web Profile was primarily a response to the complaints we heard from developers that Java EE is too big and heavyweight. (I've never fully understood why Java SE isn't also too big and heavyweight given that it's much larger than Java EE, but so be it.) The Web Profile allowed Java EE to compete more directly with "roll your own" solutions based on (e.g.) Tomcat. Secondarily, the Web Profile allowed additional vendors to enter the Java EE ecosystem by lowering the barriers to entry. Given the consolidation we were seeing in the Java EE vendor space it seemed important to enable new vendors to enter this space, thus encouraging competition in this space. This all made sense in the Java EE 6 timeframe. Since then, my thinking has evolved. With the introduction, finally, of a module system in Java SE, it makes more sense to me to address the complaints of Java EE / Jakarta EE being "heavyweight" by dividing the platform into modules and allowing users to choose the modules they need for their application. A vendor would be required to provide the complete set of modules defined by a platform, but a user of the vendor's product would consider the product more of a box of "Lego" bricks from which many different runtimes could be assembled. Several others said the same thing in the meeting and in the separate jakarta.ee-community thread. Profiles define what vendors must provide and thus what things the brand can be associated with. If there's a different profile for the different collection of things each vendor wants to provide, then you've destroyed any value in the platform. Three profiles is probably fine, five profiles seems like an extreme upper limit. And I don't think profiles need to be concentric circles. It was clear in the discussion that there's no agreement on what a "core" profile would be so I wouldn't even consider that. Again, profiles are more for vendors than for developers so we need to be clear what additional vendors are being enabled by the definition of additional profiles. Profiles should be defined by a separate spec. Defining them in the platform spec means you have to update the platform spec to define a new profile. That results in gratuitous updates to the platform (and corresponding RI and TCK) or the inability to define a profile based on existing component specs. And while it might not be a requirement, it seems perfectly reasonable for there to be a profile TCK that tests the interactions between specs. Finally, I agree that the intent should be to define a collection of specs that integrate to form a coherent platform. Still, there's value in being able to use many of the specs independently. There doesn't need to be a name for each interesting collection of specs. If the implementations of the specs all come from a single vendor's Jakarta EE product, then you know that you're still writing a Jakarta EE application even if you only use a few of the specs. You can choose just the specs you need, adding or subtracting based on your application requirements. If the implementations of the specs come from multiple vendors and you're assembling them yourself, that's fine, but that's not Jakarta EE and there doesn't have to be a name for the collection you assembled. And it's up to you to make sure they work together. Looking forward to a pointer to Mike's document so I can provide more direct feedback on it... |