The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

chuckls (4) [Avatar] Offline
#1
The working definition of a bundle (module) is buried in the middle of the next-to-last paragraph of section 2.1 with no special formatting. It might help readers remember the definition if you highlight it by putting it in a formatted box on the page. Something like:

Module Definition:

A module is:

* a set of implementation classes,
* an optional public API based on a subset of the implementation classes,
* and a set of dependencies on external code.
richard.hall (87) [Avatar] Offline
#2
Re: Chapter 2 Errata
We are still looking for ways to highlight various "important points" in the book. Things like formatted boxes, etc. are under consideration. Regardless, it is helpful for you to point out things you feel are important to highlight, so thanks. We will see what we can do.
asenft (5) [Avatar] Offline
#3
Re: Chapter 2 Errata
I found one issue in chapter 2.5.3, p.55.

In the sidebar "Depending on packages, not bundles" the second paragraph ends with "For example, if we know enough to realize we want to use the Servlet class too."

I can follow your arguments in the text, but I find this sentence confusing. Is there something missing?

Regards,
Andreas
serverdude (24) [Avatar] Offline
#4
Re: Chapter 2 Errata
p.61 2.6.2 1st line of 2nd paragraph. lacks a 'to'
"Even though the launcher is pretty cool, we still need some way __ kick start the application"
"Even though the launcher is pretty cool, we still need some way to kick start the application"
richard.hall (87) [Avatar] Offline
#5
Re: Chapter 2 Errata
> In the sidebar "Depending on packages, not bundles"
> the second paragraph ends with "For example, if we
> know enough to realize we want to use the Servlet
> class too."
>
> I can follow your arguments in the text, but I find
> this sentence confusing. Is there something missing?

Yeah, it was a little confusing. I've changed it to:

"For example, if we know enough to realize we want to use the Servlet class in the first place, then we probably have some idea about which package it is in too."
richard.hall (87) [Avatar] Offline
#6
Re: Chapter 2 Errata
> p.61 2.6.2 1st line of 2nd paragraph. lacks a 'to'
> "Even though the launcher is pretty cool, we still
> need some way __ kick start the application"
> "Even though the launcher is pretty cool, we still
> need some way to kick start the application"

Fixed. Thanks!
jpclouse (8) [Avatar] Offline
#7
Re: Chapter 2 Errata
On page 34, just below figure 2.5 is the sentence "To run this non-modular version of the paint program go into the chapter01/paint-
nonmodular/ directory of the companion code." This code is in the chapter02 folder, not chapter01.
jpclouse (8) [Avatar] Offline
#8
Re: Chapter 2 Errata
1. On page 37, just above figure 2.7 is the sentence "So, before getting into meat of this chapter." Insert the word "the" between "into" and "meat"
2. I find the figure 2.7 illustration and text rather confusing. The illustration shows bundles A, B and C, with Class1 included in all three and Class2 included in Bundles A and B. While this is a valid practice, it's not something that is desirable, and at this point in the text it is confusing. Your point is to illustrate that classes are members of bundles, so perhaps it would be better to include class names within the bundle cylinders, without duplication of class names. The arrow extending from the three bundles to the manifest implies that multiple bundles are referenced in a single manifest file. Packages from other bundles are specified in the manifest as imports, but imports have not been introduced yet. The figure text indicates that for a class to be a member of a bundle, it must be specified in the manifest, I assume through the Bundle-Classpath attribute. This attribute is optional, although a default of "." is assumed in that case. Perhaps this figure should be removed, or reworked and placed later in the chapter, after all of the module concepts have been introduced.
3. Figure 2.12 seems a bit unenlightening. Will the illustrations in the current draft be refined for the final version?
4. Was there supposed to be a Swing bundle among the downloadable source? It's mentioned in section 2.7.1 Resolving dependencies automatically.
5. On page 72 is the sentence "The syntax for capturing directives is quite similar arbitrary attributes." Insert the word "to" between "similar" and "arbitrary."
6. On page 72 is the sentence "In this specific case, the “uses” relationship is on an imported package, but it can also be on exported
packages." My first thought was that it was stating that the "uses" attribute can be specified in an Import-Package but Import-Package has no "uses" attribute. Are you saying here that "uses" constraints are transitive?
7. Page 73 refers to org.osgi.servicee.http (notice the extra 'e' in 'servicee').
richard.hall (87) [Avatar] Offline
#9
Re: Chapter 2 Errata
> On page 34, just below figure 2.5 is the sentence "To
> run this non-modular version of the paint program go
> into the chapter01/paint-
> nonmodular/ directory of the companion code." This
> code is in the chapter02 folder, not chapter01.

Fixed. Thanks.
richard.hall (87) [Avatar] Offline
#10
Re: Chapter 2 Errata
> 1. On page 37, just above figure 2.7 is the sentence
> "So, before getting into meat of this chapter."
> Insert the word "the" between "into" and "meat"

Fixed.

> 2. I find the figure 2.7 illustration and text rather
> confusing. The illustration shows bundles A, B and C,
> with Class1 included in all three and Class2 included
> in Bundles A and B. While this is a valid practice,
> it's not something that is desirable, and at this
> point in the text it is confusing. Your point is to
> illustrate that classes are members of bundles, so
> perhaps it would be better to include class names
> within the bundle cylinders, without duplication of
> class names. The arrow extending from the three
> bundles to the manifest implies that multiple bundles
> are referenced in a single manifest file. Packages
> from other bundles are specified in the manifest as
> imports, but imports have not been introduced yet.
> The figure text indicates that for a class to be a
> member of a bundle, it must be specified in the
> manifest, I assume through the Bundle-Classpath
> attribute. This attribute is optional, although a
> default of "." is assumed in that case. Perhaps this
> figure should be removed, or reworked and placed
> later in the chapter, after all of the module
> concepts have been introduced.

I've added a note to look into fixing it.

> 3. Figure 2.12 seems a bit unenlightening. Will the
> illustrations in the current draft be refined for the
> final version?

Its only purpose (like the graphical depiction for imports) is to introduce the graphical notation the figures will use.

> 4. Was there supposed to be a Swing bundle among the
> downloadable source? It's mentioned in section 2.7.1
> Resolving dependencies automatically.

No. The sidebar tries to point out that there really isn't a swing bundle. Swing packages are just made available from the class path via the system bundle. (So, bundles still need to import the packages.) Technically, it is possible to have a bundles Swing, but we don't do that.

> 5. On page 72 is the sentence "The syntax for
> capturing directives is quite similar arbitrary
> attributes." Insert the word "to" between "similar"
> and "arbitrary."

Fixed.

> 6. On page 72 is the sentence "In this specific case,
> the “uses” relationship is on an imported package,
> but it can also be on exported
> packages." My first thought was that it was stating
> that the "uses" attribute can be specified in an
> Import-Package but Import-Package has no "uses"
> attribute. Are you saying here that "uses"
> constraints are transitive?

"uses" constraints are transitive, but that sentence was not trying to say that. The point it was trying to make is that an exported package may use other packages imported by the containing bundle or other packages exported by the containing bundle.

> 7. Page 73 refers to org.osgi.servicee.http (notice
> the extra 'e' in 'servicee').

Fixed.

Thanks.