On 18/06/2007, at 10:41 AM, Jason van Zyl wrote:
On 17 Jun 07, at 5:25 PM 17 Jun 07, Brett Porter wrote:
On 17/06/2007, at 8:43 AM, Jason van Zyl (JIRA) wrote:
[ http://jira.codehaus.org/browse/MNG-2943?
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MNG-2943.
------------------------------
Resolution: Fixed
One bundle will be used, and no one wants to change all the
packages around to satisfy OSGi bundling requirements.
Correct me if I'm wrong, but I understood that we agreed with the
principle, but not the implementation of how this was done.
Completely regardless of OSGi, splitting packages across jars is
not pretty. Shouldn't this be open as a future goal?
Why is it not pretty? Why should it matter? I'm not sure it's
really a requirement for anything?
One question at a time, please :)
The 'prettiness' aspect is simply that I'd expect a package to be
self contained in a JAR. If I'm looking for code from a particular
package, I'd like to know which module to go to without having to
search. It's confusing the boundaries - if we believe that the public
API boundary is around a single JAR, then having packages split
allows you to get around that - you can have protected and package
scope fields being accessed from other JARs.
I do think this is a best practice, and when it doesn't happen it's a
smell of an incorrect design.
The only place I know of it being required is in a sealed JAR. So
while it's something we don't directly deal with now, if we were to
use Java's built in security mechanisms down the track it could be.
Keeping the packages separate is important for security reasons so
that it isn't possible to introduce classes that have access to
protected and package scope methods and fields.
Is this a requirement for JSR-277?
The 277 early draft doesn't deal with the concept of split packages,
but it is not currently planned to be supported: http://
weblogs.java.net/blog/stanleyh/archive/2006/11/more_jsr277_ear.html
So it may be a requirement.
This is a function of how OSGi does resolution and I'm frankly not
sure it's useful or not.
Funnily enough, OSGi *does* support split packages: http://
www.osgi.org/blog/2006/10/jsr-277-review.html
I admit I'm not familiar with why it's an issue in equinox.
Something that is generate may be in the same package: I think in
some cases it makes sense to have a separate module for generated
classes, and in some cases it makes sense to have them in the same
package. I honestly don't know if it matters: if it's good or it's
a hindrance.
I've never really seen the benefit of having a separate module for
generated code (though you do want to keep it relevant so it's
usually minimal stuff that operates on the model/etc), but even so I
can't see any hindrance in it being in a separate package either.
I'm not going to assume just because OSGi needs it, it's good.
That's why I threw in the "completely regardless of OSGi" reference.
Can we reopen as a future design goal?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
