krimple (141) [Avatar] Offline
#1
I wanted to update our readers on our progress, and give you all a heads up on a change we are planning to make to the content.

First, we are getting close to the end (close is a nebulous term, but that means relatively soon we'll be mostly editing and cleaning up, writing forwards, indexing, etc). I want to thank everyone for your participation, and ask those of you who have submitted bugs to accept this big note of thanks. We still can use your feedback, as anything discussed in the next one to two months we can probably address before print time.

Next, in researching and writing what is currently the add-ons chapter, a few things occurred to me:

#1 - Add-ons are a HUGE topic
#2 - OSGi is a HUGE topic
#3 - 40 pages is NOT enough to cover add-ons
#4 - we had this chapter named 'leaving roo', so...

Since the whole concept of push-in and pull-up refactoring has basic, and incomplete coverage in an early chapter (chapter 2) I am planning on expanding that material to include what we wanted to talk about with the "Leaving Roo" chapter, or at least most of it.

We would add "creating your own ITD / pull up refactoring" and "push-in refactoring", and something on what it will take to leave Roo behind. That is probably 4-6 pages in length, and in retrospect probably belongs in an early chapter to show you what you are capable of doing in the Roo platform.

Second, as my add-ons chapter currently stops at creating an 'advanced add-on' but not any deep details on ITDs, annotations, or the type system, I feel we need an ITDs Roo Add-on chapter - so many of the add-ons you use have things like @RooEntity, @RooJavaBean, etc., and I've been trying to put together samples - two candidates that I have on the block are a Jmx add-on (maybe we can annotate a method with @RooExposeJmx or something, and a @RooComparable, but when I wrote that the expression of how to mark the fields hurt my head).

So, my plan is to wrap up this introductory add-on chapter, get it in the MEAP queue, and begin working on the second add-on chapter. I feel like we'd be letting the Roo community down if we didn't delve a bit into the deeper aspects of the Roo add-ons system.

Another word - SpringSource has been EXTREMELY helpful when I have logged bugs / suggestions in the add-ons area, as with everything else I've submitted. I just wanted to take a moment and say that it is gratifying to work on a book that actually helps to move a framework forward. So, that's been a blast.

More info soon, and I'm opening the thread up to your comments. Let us know your thoughts.

Best,

Ken

Message was edited by:
krimple
jbbarquero (84) [Avatar] Offline
#2
Re: Updated TOC plans - additional add-on chapter and moving of 'leaving roo'
Hello,

Thanks for this POST that let us know the progress of the book.

In my humble opinion, OSGI is out of bounds for a Roo book, besides, Manning has at least three books for that topic.

I'm looking forward the add-ons chapters, the real power of Roo, because they allow to extend the system (yes, they're based on OSGI, but there's no need of mastering that technology)

I found a good article introducing add-ons: http://www.ibm.com/developerworks/opensource/library/os-springroo3/index.html

The parts 1 and 2 are worthy too.


Regarding leaving Roo, I think it's interesting to know about it, because it proves Roo is unintrusive. And it's also a good idea to know how the @Roo annotations work. But I'd rather to use the Aspects, as Roo does, for separating concerns.

I'm used to expanding a Roo project adding functionality without Roo, a Service layer without @Roo annotations for instance, instead of leaving Roo entirely.
ken.rimple (246) [Avatar] Offline
#3
Re: Updated TOC plans - additional add-on chapter and moving of 'leaving roo'
Benito,

I agree about the DeveloperWorks article. It was actually a punch to the stomach to see that come out JUST BEFORE wrapping up this chapter. Dang! This project has taken quite a long time for me, because it's not the only high-pressure thing I work on day-to-day. So, when someone comes out with an article that nice, it makes me stand up and take inventory smilie

I will definitely cover the leaving roo/push in / pull up, etc., part in the early chapters and fold it in.

While I agree that OSGi itself is not a big part of add-ons (they mostly use it just to make it easy to expose and send events) you need to know enough terminology to be dangerous. More important is the Roo API itself, things like the projectOperations object, metadata, etc... That's what I'll be wrestling with a bit during the hurricane...

Thanks for your feedback and your readership.

Ken


> Hello,
>
> Thanks for this POST that let us know the progress of
> the book.
>
> In my humble opinion, OSGI is out of bounds for a Roo
> book, besides, Manning has at least three books for
> that topic.
>
> I'm looking forward the add-ons chapters, the real
> power of Roo, because they allow to extend the system
> (yes, they're based on OSGI, but there's no need of
> mastering that technology)
>
> I found a good article introducing add-ons:
> http://www.ibm.com/developerworks/opensource/library/o
> s-springroo3/index.html
>
> The parts 1 and 2 are worthy too.
>
>
> Regarding leaving Roo, I think it's interesting to
> know about it, because it proves Roo is unintrusive.
> And it's also a good idea to know how the @Roo
> annotations work. But I'd rather to use the Aspects,
> as Roo does, for separating concerns.
>
> I'm used to expanding a Roo project adding
> functionality without Roo, a Service layer without
> @Roo annotations for instance, instead of leaving Roo
> entirely.

(apparently THIS is my author account)
jbbarquero (84) [Avatar] Offline
#4
Re: Updated TOC plans - additional add-on chapter and moving of 'leaving roo'
Thanks to you too.

By the way, you can call me Javier
ken.rimple (246) [Avatar] Offline
#5
Re: Updated TOC plans - additional add-on chapter and moving of 'leaving roo'
Javier,

Ok, then! smilie

FYI, I've been going through the internals of the Roo add-on system, and they are all OSGi service components. You can inject them into your add-ons with a simple

@Reference TheComponentInterface componentReference;

and then you're in. A ton of services, which could take a whole book to describe, but it breaks down to things like type services, shell services, maven services, project services, file services, metadata services, etc... I'm documenting some of the types of things you can do in the second chapter.

I was able to get a groovy console mounted inside of my Roo shell for a bit, so I was digging around with the injectable Roo services. I would expose it, but it was a hack-a-thon to get it to mount.

More later...