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.
____________
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, ...
____________
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.
