On Jun 11, 2007, at 8:55 AM, Andy Piper wrote:
At 10:23 PM 6/8/2007, Stanley M. Ho wrote:
Unless I miss something, this is the main use case that import-by-name
would address. Developers can package all the classes related to a
feature (e.g. networking, xml, swing, ejb, etc.) into a module, and
At 10:23 PM 6/8/2007, Stanley M. Ho wrote:
>Unless I miss something, this is the main use case that import-by-name
>would address. Developers can package all the classes related to a
>feature (e.g. networking, xml, swing, ejb, etc.) into a module, and it
>exports (or reexports from other modules) a
Stanley M. Ho wrote:
Andy Piper wrote:
...
1. The ability to express a feature in terms of its constituent
packages. Note that import-by-name doesn't really help here since the
actual packages are distributed across multiple modules. What I
really want is some kind of feature module that exports
Whew. I thought something had gone south.
Sam
On Jun 8, 2007, at 2:23 PM, Stanley M. Ho wrote:
Andy Piper wrote:
...
1. The ability to express a feature in terms of its constituent
packages. Note that import-by-name doesn't really help here since the
actual packages are distributed across mu
Andy Piper wrote:
...
1. The ability to express a feature in terms of its constituent
packages. Note that import-by-name doesn't really help here since the
actual packages are distributed across multiple modules. What I
really want is some kind of feature module that exports these
packages to you
My aghast reaction to Andy's mail is that if we aren't solving this
simple issue, what is it that we are solving? This use case is far
more like what I would want in the real world. If we don't get
something out of this JSR and the language JSR that approximates a
runtime version of 'gem' (from
Andy Piper wrote:
At 00:53 08/06/2007, Bryan Atsatt wrote:
I truly believe that the Java world will be far better served by having
277 support ONLY import-by-package!
But there has been this background fear that import-by-package is
somehow terribly complex. I can certainly believe that the un
At 00:53 08/06/2007, Bryan Atsatt wrote:
>I truly believe that the Java world will be far better served by having
>277 support ONLY import-by-package!
>
>But there has been this background fear that import-by-package is
>somehow terribly complex. I can certainly believe that the union of all
>the O
On Jun 7, 2007, at 7:53 PM, Bryan Atsatt wrote:
[snip]
Richard S.Hall wrote:
My question below still stands. In general, it seems to me that
resolution consists of:
1. Selection of candidate module/bundles based on import
declarations.
2. Class space consistency validation (which may narrow
[snip]
Richard S.Hall wrote:
My question below still stands. In general, it seems to me that
resolution consists of:
1. Selection of candidate module/bundles based on import declarations.
2. Class space consistency validation (which may narrow the list if
multiple choices, or result in a failu
Hi Richard,
Richard S. Hall wrote:
This is definitely true, but this was only introduced in R4 and is still
intended to be the exception, not the norm...from my understanding, 277
defined the norm in the opposite direction.
Ultimately, if we are making the same assumption, which is that people
On Jun 5, 2007, at 5:58 PM, Bryan Atsatt wrote:
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 04/06/2007 20:21:29:
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > I don't think I will have time to response to all your comments
this
> > week, so my response would focus o
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 04/06/2007 20:21:29:
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > I don't think I will have time to response to all your comments this
> > week, so my response would focus on the import-by-package discussion.
> >
> > Firs
Stanley M. Ho wrote:
Hi Richard,
Richard S.Hall wrote:
...
Perhaps so.
I am operating off my [possibly dated] recollection that 277 modules
explicitly list the classes that they export, which meant that they may
expose arbitrary public classes from a package. If this is no longer
the case, the
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 04/06/2007 20:21:29:
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > I don't think I will have time to response to all your comments this
> > week, so my response would focus on the import-by-package discussion.
> >
> > First, the only import dependency we ha
After writing:
>I think ResolutionContext doesn't need any detail
I remembered the class in the interoperation kernel prototype did have a
little detail (but not much):
public interface ResolutionContext extends KernelRelated {
/**
* Notify completion.
*/
void complete();
}
Hi Bryan,
Bryan Atsatt wrote:
...
Rather than surfacing the import-by-package at the API level, I think we
can solve #3 by generalizing the import dependency concept as
import-by-name, and this name can be mapped to superpackage-name in JSR
277 and OSGi-bundle-name or OSGi-exported-package-name
Hi Richard,
Richard S.Hall wrote:
...
Perhaps so.
I am operating off my [possibly dated] recollection that 277 modules
explicitly list the classes that they export, which meant that they may
expose arbitrary public classes from a package. If this is no longer
the case, then this is fine.
The p
Stanley M. Ho wrote:
Hi Bryan,
I don't think I will have time to response to all your comments this
week, so my response would focus on the import-by-package discussion.
First, the only import dependency we have consensus in this EG so far is
import-by-module-name (or import-by-superpackage-nam
On May 31, 2007, at 8:06 PM, Stanley M. Ho wrote:
Hi Richard,
Richard S.Hall wrote:
I don't think I fully understand your concerns around exporting an
entire package. As you mentioned, what's get exported in 277 module
is
in terms of classes and the information is in the module metadata,
and
I
Hi Richard,
Richard S.Hall wrote:
I don't think I fully understand your concerns around exporting an
entire package. As you mentioned, what's get exported in 277 module is
in terms of classes and the information is in the module metadata, and
I
think we can probably determine the packages associ
Hi Bryan,
I don't think I will have time to response to all your comments this
week, so my response would focus on the import-by-package discussion.
First, the only import dependency we have consensus in this EG so far is
import-by-module-name (or import-by-superpackage-name), and this was
also
Stanley,
On May 31, 2007, at 6:35 PM, Stanley M. Ho wrote:
Richard S. Hall wrote:
...
I am not so sure supporting #3 is as straight forward as you suggest
here. Specially, the OSGi modularity layer [for the most part]
assumes that packages are atomic units; there is no way to specify
that your
Hi Richard,
Richard S. Hall wrote:
...
I am not so sure supporting #3 is as straight forward as you suggest
here. Specially, the OSGi modularity layer [for the most part]
assumes that packages are atomic units; there is no way to specify
that your export or import something smaller than a packag
Bryan Atsatt wrote:
Stanley M. Ho wrote:
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 07:57:59:
...
> So the open issue is the richness of the import "language": must we
> support only lowest-common-denominator, or can we do better without
> over-complicatin
Richard S. Hall wrote:
Bryan Atsatt wrote:
Stanley M. Ho wrote:
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 07:57:59:
...
> So the open issue is the richness of the import "language": must we
> support only lowest-common-denominator, or can we do better wit
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 30/05/2007 19:11:02:
> Responses inline, and a few clarifications here (I was a bit tired when
> I finished this last night :^)...
>
> The main point I was trying to make is that resolution must occur within
> a specific context, but I don't think my examp
Stanley M. Ho wrote:
Hi,
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 07:57:59:
...
> So the open issue is the richness of the import "language": must we
> support only lowest-common-denominator, or can we do better without
> over-complicating the design?
>
On May 30, 2007, at 5:55 PM, Stanley M. Ho wrote:
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007
07:57:59:
...
> So the open issue is the richness of the import "language":
must we
> support only lowest-common-denominator, or can we do better
without
> over-co
Hi,
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 07:57:59:
...
> So the open issue is the richness of the import "language": must we
> support only lowest-common-denominator, or can we do better without
> over-complicating the design?
>
> I for one would li
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example APIs showed that well.
I was assuming that ImportResolver had a Modul
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 30/05/2007 07:57:59:
> Andy Piper wrote:
> > At 23:19 25/05/2007, Stanley M. Ho wrote:
> >> Anyway, it seems the EG consensus so far is to not add import
package
> >> support. If any EG member disagrees, please speak up.
> >
> > Well, it depends on wh
Adrian <[EMAIL PROTECTED]> wrote on 25/05/2007 12:44:54:
> On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote:
> > A better approach would be for the Java 7 platform to provide first
> > class support for JSR 291. This boils down to standardising the
> > experimental class loader deadlock fi
Andy Piper wrote:
> At 23:19 25/05/2007, Stanley M. Ho wrote:
>> Anyway, it seems the EG consensus so far is to not add import package
>> support. If any EG member disagrees, please speak up.
>
> Well, it depends on what the solution for enabling interoperation
> with JSR 291 is.
> Our requirement
Hello Stanley,
Stanley M. Ho wrote:
Richard S. Hall wrote:
Agreed, but I think part of the reason that there is an urge to push
such features into the core is because there is already feature creep in
the core that gives people the impression that we are redefining OSGi
modularity, NetBeans mod
At 23:19 25/05/2007, Stanley M. Ho wrote:
>Anyway, it seems the EG consensus so far is to not add import package
>support. If any EG member disagrees, please speak up.
Well, it depends on what the solution for enabling interoperation
with JSR 291 is.
Our requirement is that there must be a solutio
This is another repost to sync up the EG observer mailing list.
- Stanley
Original Message
Subject:Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Fri, 25 May 2007 17:06:08 +0100
From: Glyn Normington <[EMAIL PROTECTED]>
Reply-To: Jav
This is another repost to sync up the EG observer mailing list.
- Stanley
Original Message
Subject: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Sat, 26 May 2007 00:25:38 +0900
From: Daniel Leuck <[EMAIL PROTECTED]>
Reply-To: Java Community Proce
This is another repost to sync up the EG observer mailing list.
- Stanley
Original Message
Subject: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Fri, 25 May 2007 11:01:03 -0400
From: Richard S. Hall <[EMAIL PROTECTED]>
Reply-To: Java Community Proce
This is another repost to sync up the EG observer mailing list.
- Stanley
Original Message
Subject: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Fri, 25 May 2007 13:45:57 -0700
From: Stanley M. Ho <[EMAIL PROTECTED]>
Reply-To: Java Community Proce
This is a repost to sync up the EG observer mailing list.
- Stanley
Original Message
Subject: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Date: Fri, 25 May 2007 11:00:16 -0400
From: Richard S. Hall <[EMAIL PROTECTED]>
Reply-To: Java Community Proce
Hi Richard,
Richard S. Hall wrote:
Stanley M. Ho wrote:
I think we all agreed that the module system defined by JSR 277 does not
need to support import package. As far as I am aware (correct me if I'm
wrong), all the existing systems support import at the module level, and
OSGi is the only one
I haven't lost interest in this thread but I'm going on leave now
returning on Wednesday, so please don't misinterpret my silence in the
interim. :-)
Glyn
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box
Let me try to focus this discussion. What I am aiming for here is
conceptually simple:
Don't force a specific interpretation of the import String in the 277 *API*.
So, for example, change:
String ImportDependency.getModuleName()
to
String ImportDependency.getImportName();
Each ModuleSy
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
Let me clarify. It is my assumption that 277 will provide both an
API/framework *and* a specific ModuleSystem implementation. And that
OSGi will be able to supply another ModuleSystem implementation:
277 API/Framework
/
On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote:
> A better approach would be for the Java 7 platform to provide first
> class support for JSR 291. This boils down to standardising the
> experimental class loader deadlock fix ([1])
Fixing the deadlock just moves the problem.
You'll still
Hi Bryan,
Bryan Atsatt wrote:
Let me clarify. It is my assumption that 277 will provide both an
API/framework *and* a specific ModuleSystem implementation. And that
OSGi will be able to supply another ModuleSystem implementation:
277 API/Framework
/ \
/
Hi Glyn,
Glyn Normington wrote:
...
A better approach would be for the Java 7 platform to provide first
class support for JSR 291. This boils down to standardising the
experimental class loader deadlock fix ([1]) and enabling JSR 291 to
exploit JSR 277's repositories and JSR 294's superpackages.
Let me clarify. It is my assumption that 277 will provide both an
API/framework *and* a specific ModuleSystem implementation. And that
OSGi will be able to supply another ModuleSystem implementation:
277 API/Framework
/ \
/ \
277ModuleSystem OSGiMod
49 matches
Mail list logo
