JSR377 Review Ballot Results

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JSR377 Review Ballot Results

aalmiray
Administrator
Hello everyone!

The Review Ballot Results are ready: https://jcp.org/en/jsr/results?id=5744

We've got the green light to continue!
Next steps are:
 - finish setting up the Expert Group. There are a few nominations in the queue due to missing Exhibit B or signed JSPA.
 - setup ASLv2 CLA on github repositories for anonymous contributors.
 - setup spec website (jsr377.github.io)
 - write down and publish guidelines for doc contributions (asciidoc).

These tasks will take us a couple of weeks. In the meantime we can begin discussing the proposed feature list

* dependency injection via JSR330.
* common application structure.
* application life-cycle.
* localized resources.
* resource injection.
* localized configuration.
* decouple state from UI (binding).
* persistence session state (preferences).
* action management.
* component life-cycle.
* light-weight event bus.
* honor threading concerns (specific to UI toolkit).
* application extensibility via plugins (implies modularity).

A reminder, these features may or may not be delivered in full by the final spec. We have to decide if the scope of each one is right. Alternatively, there may be missing features (like the desktop integration feature mentioned in another thread) that should also be brought to light.

Here's to an exciting spec development cycle and the challenges that await us!

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSR377 Review Ballot Results

Hendrik Ebbers
YEAH :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSR377 Review Ballot Results

raniejade
In reply to this post by aalmiray
Finally! Excited for the weeks to come.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSR377 Review Ballot Results

johanvos
In reply to this post by aalmiray
Excellent!
It's a huge list though, with complex tasks.
Maybe we should have some priorities?

Congrats, nice work on getting it approved!

- Johan

2015-02-10 10:14 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
Hello everyone!

The Review Ballot Results are ready: https://jcp.org/en/jsr/results?id=5744

We've got the green light to continue!
Next steps are:
 - finish setting up the Expert Group. There are a few nominations in the queue due to missing Exhibit B or signed JSPA.
 - setup ASLv2 CLA on github repositories for anonymous contributors.
 - setup spec website (jsr377.github.io)
 - write down and publish guidelines for doc contributions (asciidoc).

These tasks will take us a couple of weeks. In the meantime we can begin discussing the proposed feature list

* dependency injection via JSR330.
* common application structure.
* application life-cycle.
* localized resources.
* resource injection.
* localized configuration.
* decouple state from UI (binding).
* persistence session state (preferences).
* action management.
* component life-cycle.
* light-weight event bus.
* honor threading concerns (specific to UI toolkit).
* application extensibility via plugins (implies modularity).

A reminder, these features may or may not be delivered in full by the final spec. We have to decide if the scope of each one is right. Alternatively, there may be missing features (like the desktop integration feature mentioned in another thread) that should also be brought to light.

Here's to an exciting spec development cycle and the challenges that await us!

Cheers,
Andres


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/JSR377-Review-Ballot-Results-tp25.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

alanwilliamson
In reply to this post by aalmiray
Game on.

How do you want to tackle these items?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

Sébastien Bordes
Great new !!!

Before starting to work on these items, is it possible to clarify the goal of this JSR ?

Should we try to create an absolutely fresh API or should we try to get the biggest common part of some of existing ones ?

People that are already working on their application frameworks will not throw them to the dust, and start a new one tomorrow, so how many of working Implementation (and efficient) should we have in December...

Do we want to make an universal API like OSGI, in this case we should climb a step higher to define what an application framework should provide (in terms of architecture and design pattern to use)


This orientation is essential, because the success of this JSR depends on it.

As a UI developer I'm used to criticize application frameworks I'm using (currently all eclipse folks and there are tons of remark to say), as an application framework provider I'm curious to see how I will be able to implement this JSR, finally I'm curious to know if we will have fully interoperable frameworks (another time like OSGI with equinox, felix etc...)

I'm impatient to read future discussions

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

aalmiray
Administrator
In reply to this post by alanwilliamson
Johan's right on the money. We should prioritize the features, and for that we need to know what those features mean. The aforementioned list leaves some gaps and ambiguity creeps in. I guess our first task would be to define each feature so that all of us agree on what they mean.

Allow me to remind you of some of the source materials we can sue as starting points

* http://new.griffon-framework.org
* http://netbeans.org/
* http://eclipse.org/eclipse/
* http://www.javafxdata.org/
* http://jacpfx.org/

These list is not exhaustive (Sebastien's JRebirth did not appear before the JSR was posted for example). So if you're familiar with a particular source material please take some time to write (at most) 2 paragraphs on each feature. We'll merge the results in say, 10 days time?

We can of course update these definitions as new EG members join or new data is available.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

Sébastien Bordes
It's a good starting point, where could we send these notes it can be painful to write and read contributions into the mailing list (especially to follow different interlaced topics).

Is it possible to made PR to a repo structured by topic, thus it will be easier to read all contributions (by topic) and sum up all good and bad points.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

aalmiray
Administrator
Good point. What about this: let's open an issue per feature at https://github.com/jsr377/jsr377-api/issues
We let the natural flow of GitHub issues take over.

I'm open to suggestions if you think this idea is bonkers ;-)

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSR377 Review Ballot Results

alanwilliamson
Got no problems with that, we just have to let people know that is where
all the meat of the conversations is going on, as they may think the
list to be quiet.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

aalmiray
Administrator
In reply to this post by Sébastien Bordes
Hi Sebastien,

The goal of this JSR is to deliver an API that existing and new frameworks can implement.
We'll base this API on existing behavior exposed by the source materials, thus designing interfaces, annotations and classes that are very close to what already exist today. Some features will be very easy to integrate into existing frameworks, others may require additional work, but that's just how things are.

I'd rather stay as close to the metal as possible, that is, to direct API usage without forcing architecture too much. I have strong opinions on opinionated frameworks and sensible defaults. Once size (in terms of architecture) does not fit all, so we have to make this API as extensible and light as possible without sacrificing usefulness and power.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

Sébastien Bordes
Ok, no architecture at the moment just a set of interfaces and annotations that any provider can use.

We'll learn when we'll have digested all materials used.

But would we want to be interoperable ?, in order to allow any implementation to use the same piece of code (avoiding to write one bridge per impl)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

aalmiray
Administrator
This is where the RI comes in. It's likely that some bridge functions are so common that we package them into artifacts delivered by the RI. Next implementors decide if they take in these binaries or build their own bridges from scratch. This would be mostly the case with OSGi based frameworks where the very least they can do is repackage the binaries as OSGi compliant bundles.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: JSR377 Review Ballot Results

Sébastien Bordes
I better understand the spirit but if we don't make some choice in term of architecture, how the RI could join all these disjointed topics.

IE: How the RI will be able to manage internationalization and threading if it doesn't provide the glue between them (ie: when app starts, resources files are loaded into a dedicated thread), the RI should have a Launcher class to do that, and other provider will have to use it without breaking their own launcher...

For sur we can use some annotation to say that the resource loading should be performed in a custom thread, but I think that the RI will have to make some choices, we will later when all stuff will be analyzed.
Loading...