I think your view is right, so that's why we are adjusting the resolution of componentType files to also consider the imported contribution, where the java files are located. But I think we should also consider the scenario where you are contributing a jar that you don't have access to modify it, and then you might need to have the componentType file in a different contribution. Would you agree ?
On Thu, Feb 21, 2008 at 9:04 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > Only just noticed this. > > I have a particular view of componentType files, which you may not agree > with ;-) > > Component type files are better named "Implementation Info" files - they > are intimately tied to the implementation class in Java. The original > idea was that the file would "sit alongside" the Java class file. It > would be logical to do this as it would be created by the developer of > the class to provide extra metadata about the Java class that cannot be > derived from the class by introspection. > > So it seems foreign to me to go searching somewhere else looking for the > componentType file - it should be there in the contribution containing > the Java class - ideally in the "same place" (same directory). So > searching should be virtually trivial. And if the component type file > ain't there, don't go searching anywhere else for it !! It certainly > makes no sense at all for the component type file to be in some other > contribution. > > Of course, this does NOT apply for the other types of resource files > that you have discussed. > > Yours, Mike. > > > > Luciano Resende wrote: > > I guess we have couple scenarios here : > > > > - Considering contribution A importing a java package from > > Contribution B, we can have the componentType in either Contribution > > A(supported today) or contribution B (not working: TUSCANY-1873). > > > > - We can also consider Contribution A importing a java package from > > Contribution B, but sharing a componentType from a Contribution C. > > > > We can also abstract the componentType file to some type of resource, > > that needs to be imported from a different contribution, so I was > > thinking on creating a resource import/export, that would work for > > componentType and also for other types of resources that can be > > addressed by a given URI. > > > > Thoughts ? > > > > > > On Oct 29, 2007 12:59 AM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > >> Thank you, Luciano. > >> > >> I have raise a JIRA issue ( > >> https://issues.apache.org/jira/browse/TUSCANY-1873). > >> > >> > >> > >> On 10/26/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > >>> After researching what the SCA spec says, looks like your scenario is > >>> valid : > >>> > >>> from Java C&I: > >>> 391 A component type can optionally be specified in a side file. The > >>> component type side file is found with the > >>> 392 same classloader that loaded the Java class. The side file must be > >>> located in a directory that corresponds to > >>> 393 the namespace of the implementation and have the same name as the > >>> Java class, but with a > >>> 394 .componentType extension instead of the .class extension. > >>> > >>> Also, as you mentioned, the current implementation does not consider > >>> "import/export" when resolving the componentTypes. > >>> > >>> I think we should start by raising a jira, and discussing what's the > >>> best solution here, should we just reuse some already existent > >>> import/export to configure the componentType model resolver ? You > >>> mentioned the name space import, but as this is related to specific > >>> implementation types, maybe the java import/export ? > >>> > >>> I'll keep thinking and do some investigation on this area... > >>> > >>> Thoughts ? > >>> > >>> On 10/25/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > >>>> Hello, > >>>> > >>>> Is there any reason why unlike CompositeModelResolver and > >>>> ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look > >>> at > >>>> imported namespaces for resolving component type files? > >>>> > >>>> My test case contains: > >>>> ContributionA : contains a composite file, with a component C1 > >>>> ContributionB: contains the Java implementation classes for C1 ( > >>>> x.y.C1.class), and the componentType file (x.y.C1.componentType) > >>>> > >>>> The model resolver used to resolve the composite is associated with > >>>> ContributionA, and when implementation.java looks for the componentType > >>>> file using this model resolver, it does not find it, since it doesn't > >>> look > >>>> anywhere except in ContributionA. > >>>> > >>>> Is this a valid test case, or should the componentType file always be in > >>>> ContributionA, along with the composite? > >>>> > >>>> If the componentType file is allowed to be inside ContributionB (since > >>>> componentType file describes an implementation, I would have expected it > >>> to > >>>> be colocated with the implementation), what type of import/export > >>> statement > >>>> should be used in ContributionA? ContributionA contains < > >>> import.javapackage=" > >>>> x.y"/> to find the implementation class x.y.C1. Should that be somehow > >>> used > >>>> to resolve the componentType file as well, or should there be another > >>>> namespace import specifically for the componentType file (<import > >>>> namespace="x.y"/>)? > >>>> > >>>> > >>>> Thank you... > >>>> > >>>> Regards, > >>>> > >>>> Rajini > >>>> > >>> > >>> -- > >>> Luciano Resende > >>> Apache Tuscany Committer > >>> http://people.apache.org/~lresende > >>> http://lresende.blogspot.com/ > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> Thank you... > >> > >> Regards, > >> > >> Rajini > >> > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
