You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/06/18 02:25:49 UTC
Re: [jira] Closed: (MNG-2943) Same package name is used in different modules
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?
Either way, the resolution is wrong...
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Closed: (MNG-2943) Same package name is used in different modules
Posted by Carlos Sanchez <ca...@apache.org>.
On 6/20/07, Brett Porter <br...@apache.org> wrote:
>
> 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.
It's not an issue in the sense that there are other ways of doing things
you can reference packages or bundle names, if you use packages then
the framework picks up one bundle and then you can switch bundles,
rename them, etc and everything will still work, specially handy when
you have work against an API whose implementation can be
interchangeable
so it's not required for OSGi but it's a best practice, for all the
other reasons Brett mentioned
>
> > 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Closed: (MNG-2943) Same package name is used in different modules
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [jira] Closed: (MNG-2943) Same package name is used in different modules
Posted by Jason van Zyl <ja...@maven.org>.
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? Is this a requirement for JSR-277? This
is a function of how OSGi does resolution and I'm frankly not sure
it's useful or not. 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'm not going to assume just
because OSGi needs it, it's good.
> Either way, the resolution is wrong...
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org