Lars, see inline.
On Wed, Jul 6, 2011 at 12:59 AM, Lars Corneliussen <[email protected]>wrote: > So far we determine the tools by vendor, vendorVersion, frameworkVersion > (npanday-settings.xml) and then we have profile within that version > (compiler-plugins.xml), right? > > This could be: > > Microsoft;3.0;2.0+FULL > Mono;2.6;2.0+FULL > > I don't know .NETPortable, but: > > a) if it is a different toolset, and not really part of .NET framework > releases, we should maybe rephrase "Vendor" by "Distribution" or so - and > then add .NETPortable > > b) if it is a part of .NET core (versioned within), a profile > ".NETPortable,Profile2" might be enough. > > But I rather think .NETPortable is comparable to "silverlight", which is > separately released and still not supported by NPanday. > .NETPortable seems much closer in spirit to .NETFramework CLIENT profile, in fact the currently checked-in code uses "PORTABLE" in place of "CLIENT" for just that purpose. However, there are nuances with .NETPortable, specifically that .NETPortable by itself is insufficient to define which exact subset of the already restricted .NET 4 subset should be available during compilation. Hence, I suspect the best fit might be ".NETPortable,Profile2" as described in option (b) above. Note that .NETPortable is not really akin to "silverlight" because Silverlight DLLs do not execute on the .NET platform, whereas .NETPortable DLLs do execute on the .NET platform (and they also happen to execute on the Silverlight 4 platform too). However, there are still APIs in Silverlight that are not available in .NETPortable, similarly so for Windows Phone and XBox. So, based on this analysis, I'm planning to change "PORTABLE" into ".NETPortable,Profile1", ".NETPortable,Profile2", ".NETPortable,Profile3" and ".NETPortable,Profile4" with the corresponding minimal set of System libraries added during compilation for each one. Then, there is no longer any need for the project pom to define the target framework attribute value as it is entirely predictable once the concept of Profile[1-4] is managed by NPanday. Therefore this information will be moved to declarative text in compiler-plugins.xml instead and the only difference between a dotnet-library that is non-portable vs. one that is portable will be the one line profile configuration. <plugin> <groupId>org.apache.npanday.**plugins</groupId> <artifactId>maven-compile-**plugin</artifactId> <extensions>true</extensions> <configuration> *<profile>.NETPortable,Profile2</profile>* <frameworkVersion>v4.0</**frameworkVersion> </configuration> </plugin> > ____________ > > From here, what about respecifying the attributes: > > vendor: means, what it means today > vendorVersion: this one, too > > runtime: CLR, Mono, silverlight, Portable? > runtimeVersion: instead of frameworkVersion > runtimeProfile: Profile2, FULL, CLIENT, ... > This is an interesting suggestion that deserves further discussion, including the impact from a backwards-compatibility perspective. tc, -john. > > ____________ > > What do you guys think? > > > Am 06.07.11 04:35, schrieb John Fallows: > > Devs, >> >> Now that PCL has landed in trunk, I'd like to discuss some alternatives in >> how we might prefer to expose the feature. >> >> <plugin> >> <groupId>org.apache.npanday.**plugins</groupId> >> <artifactId>maven-compile-**plugin</artifactId> >> <extensions>true</extensions> >> <configuration> >> <profile>PORTABLE</profile> >> <frameworkVersion>v4.0</**frameworkVersion> >> <frameworkName>.NETPortable,**Version=v4.0,Profile=Profile2<** >> /frameworkName> >> >> <frameworkDisplayName>Portable Library</frameworkDisplayName> >> </configuration> >> >> </plugin> >> >> It turns out that the obscurely named "Profile2" in the example from >> NPANDAY-450 actually has system-defined meaning and is not a byproduct of >> internal VS2010 internal project-specific naming as previously thought. >> >> As you can see from the directory listings below, the various profiles >> have >> meaning; Profile1, Profile2, Profile3, Profile4 - in terms of which >> specific >> combinations of platforms are supported. This is because some of the DLLs >> used to resolve APIs during compilation are not actually present on all >> platforms. (!) >> >> *Directory of c:\Program Files\Reference >> Assemblies\Microsoft\**Framework\.NETPortable\v4.0\**Profile\Profile1\** >> SupportedFrameworks >> *06/02/2011 09:18 PM 254 >> .NETFramework,Version=v4.0+,**Profile=All.xml >> 06/02/2011 09:18 PM 271 >> Silverlight,Version=v4.0+,**Profile=WindowsPhone.xml >> 06/02/2011 09:18 PM 252 Silverlight,Version=v4.0+.xml >> 06/02/2011 09:18 PM 199 Xbox,Version=v4.0+,Profile=** >> All.xml >> >> *Directory of c:\Program Files\Reference >> Assemblies\Microsoft\**Framework\.NETPortable\v4.0\**Profile\Profile2\** >> SupportedFrameworks >> *06/02/2011 09:18 PM 254 >> .NETFramework,Version=v4.0+,**Profile=All.xml >> 06/02/2011 09:18 PM 271 >> Silverlight,Version=v4.0+,**Profile=WindowsPhone.xml >> 06/02/2011 09:18 PM 252 Silverlight,Version=v4.0+.xml >> >> *Directory of c:\Program Files\Reference >> Assemblies\Microsoft\**Framework\.NETPortable\v4.0\**Profile\Profile3\** >> SupportedFrameworks >> *06/02/2011 09:18 PM 254 >> .NETFramework,Version=v4.0+,**Profile=All.xml >> 06/02/2011 09:18 PM 252 Silverlight,Version=v4.0+.xml >> >> *Directory of c:\Program Files\Reference >> Assemblies\Microsoft\**Framework\.NETPortable\v4.0\**Profile\Profile4\** >> SupportedFrameworks >> *06/02/2011 09:18 PM 271 >> Silverlight,Version=v4.0+,**Profile=WindowsPhone.xml >> 06/02/2011 09:18 PM 252 Silverlight,Version=v4.0+.xml >> >> Therefore, it would seem appropriate to use the<profile> configuration in >> the compile plugin to select the corresponding combination of libraries so >> that unsupported APIs would not be undesirably exposed during compilation >> with NPanday. >> >> For example: >> >> <plugin> >> <groupId>org.apache.npanday.**plugins</groupId> >> <artifactId>maven-compile-**plugin</artifactId> >> <extensions>true</extensions> >> <configuration> >> <profile>.NETPortable;**Profile2</profile> >> >> <frameworkVersion>v4.0</**frameworkVersion> >> >> </configuration> >> >> </plugin> >> >> Using the more specific<profile> name will allow us to precisely control >> which libraries are needed during compile time. >> >> Taking this approach would move responsibility of the >> TargetFrameworkAttribute value to the compiler-plugins.xml file, to obtain >> the value of ".NETPortable,Version=v4.0,**Profile=Profile2" to be used >> when >> generating the assembly attributes, rather than taking it from the >> frameworkName mojo property as it is today. Further, we could make the >> target framework display name such as "Portable Library" defined by >> compiler-plugins.xml >> as well, eliminating the frameworkDisplayName from the compiler mojo. >> >> What do you think? >> >> tc, >> -john. >> > > -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA
