Home » Language IDEs » Objectteams » The Road Ahead - Request for Feedback
| The Road Ahead - Request for Feedback [message #629583] |
Tue, 28 September 2010 18:55  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
After our first two releases from Eclipse.org it's probably time to re-adjust our plans with what users need most. Every now and then I talk to people who on the one hand see the potential in Object Teams but on the other hand feel that they cannot yet apply this technology in real-life projects. At this point I'd like to learn from you, what exactly are the criteria that Object Teams must meet for being used in your projects.
To start the discussion I will briefly outline the items that are on our agenda right now:
Update to the 3.7.x stream of Eclipse development
Previously, we did one big jump once a year, migrating our sources to the next version of Eclipse. This time I did the basic migration right after the Service Release 1. By staying closer to the development head adopting changes from Eclipse is no longer a risk but pure routine.
Joining the Indigo release train
After milestone 2 of the Indigo release train (3.7 M2, due this Friday), we will join the train so that one Object Teams milestone will always be delivered simultaneously with all the other Indigo projects. Hopefully, Object Teams will then be served from the central Indigo update site.
More contributions
We still have code in our pipeline to be uploaded to our SVN:
- The OT/JPA module was initially held back due to the sheer number of 3rd party dependencies. After first analysis, many of these dependencies can be worked out (e.g. using Orbit). A particular pain point was the plexus compiler plugin for Maven, which would probably not pass the legal analysis at the Eclipse Foundation. Luckily, in Maven3 we should no longer need the plexus plugin (experiments are work in progress).
- One more test suite is currently under legal analysis. It is the core suite for testing OTJLD compliance of compiler and runtime environment. This suite was held back because it previously used a GPL'ed framework. It has been transformed into a JUnit suite and should now be fit for Eclipse.org.
- An alternative implementation of the OTRE is pending for submission. This implementation uses ASM instead of BCEL and shall bring two advantages to OT/J: faster weaving and the option of runtime weaving and re-weaving.
Graduation
When all these are done and when the API for all our plugins has been defined the project should apply for "graduation", i.e., leaving the "incubation" state. To reflect the maturity of the code base and all the previous releases up-to 1.4.0 the first version after graduation will be 2.0.
Bugtracking
Compared to the above tasks our mere 34 open bugzillas are a piece of cake 
Given these plan items, what do you see missing? Which would be your priorities?
TIA for your comments
Stephan
|
|
| | | |
| Re: The Road Ahead - Request for Feedback [message #631031 is a reply to message #631030] |
Tue, 05 October 2010 21:54  |
ruwen
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
| Stephan Herrmann wrote on Tue, 05 October 2010 23:26 | Thanks, ruwen, for your comment,
So in terms of a roadmap, maven support matching current tool versions
is just around the corner (let us know if you want s.t. now).
Migrating the JPA integration to Eclipse.org is the next place we're heading for.
Combining OT/J with "other bytecode-enhancement tools" will have to be
investigated individually. Did you have any particular tools in mind?
Any other road blocks or obstacles?
best,
Stephan
|
No I don't have any other on my mind since I am not using OT/J at the moment. But I think generally of frameworks which use bytecode-enhancement (for different purposes).
I talked to another N-OT-E guy:
One maybe overlooked use-case of OT could be tests and debugging. Lots of people maybe argue that only the public api of a class should be tested. But there are cases were you wanna test that neat private helper method. Since you can "ignore" visibility with OT, you can easily test them. Using callins you can easily assure that certain methods are not called.
Or you can trace certain calls. Imagine you got a performance problem in a productive live environment. If you created a DebugTeam, which collects verious debug information, you can just switch it on. Of course you can do such stuff with logging. But there are certain points, where OT is superior.
Example:
Under some special circumstances, method foobar() is not only called up to 10 times, it is called 1000 times. But you don't know which conditions lead to that situation. If a team you can set up a counter, which prints all necessary debug information if method foobar is called more that 10 times.
Of course OT can do way more. But maybe this is a possible way how to do the first steps with OT.
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 05:56:29 GMT 2024
Powered by FUDForum. Page generated in 0.03362 seconds |
] 
Search
Help
Register
Login
Home
.