[buildtools] Issue 4578 - Make uap3:AppExtension.Id configurable for Microsoft Edge builds

tests/AppManifest.xml.expect

 <?xml version="1.0" encoding="utf-8"?>
 
 <Package
   xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
   xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
   xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
   IgnorableNamespaces="uap3">
 
   <Identity
     Name="EyeoGmbH.AdblockPlus"
@@ skipping 23 matching lines @@
         AppListEntry="none"
         DisplayName="Adblock Plus"
         Square150x150Logo="Assets\logo_150.png"
         Square44x44Logo="Assets\logo_44.png"
         Description="Adblock Plus is the most popular ad blocker ever, and also supports websites by not blocking unobstrusive ads by default (configurable)."
         BackgroundColor="red">
       </uap:VisualElements>
       <Extensions>
       <uap3:Extension Category="windows.appExtension">
         <uap3:AppExtension Name="com.microsoft.edge.extension"
-          Id="EdgeExtension"
+          Id="1.0"

[Sebastian Noack, 2016/12/16 11:20:11]

I wonder whether we should extend the tests to create, both a release and
development build. Vasily, what do you think?

[Sebastian Noack, 2016/12/19 15:30:20]

As discussed offline, the tests would be much less trivial when testing both
scenarios, release and development builds, as we can no longer just compare the
file contents, or if we'd do we would need two almost identical sample output
files, with a lot of duplication. On the other other hand, parsing the XML might
be preferable anyway, as the tests will be tolerant of whitespaces for example
and as another side effect we'd automatically make sure that the XML is actually
valid. However, this would arguably be out of the scope of this change.

[Sebastian Noack, 2016/12/19 17:19:52]

Fine with me. I just got the impression, when we talked in person, that you were
not convinced of this approach (neither was I). So I wanted to avoid blocking
this change just because of a controversial and slightly unrelated refactoring.
But I won't hold you back either. ;)

[wspee, 2016/12/21 14:15:51]

The xml file is generated by rendering a template. Which is a simple and
effective way to do it, but prone to xml validity errors. So it makes sense the
very the validity of the xml file (IMHO).

Unfortunately it's not that simple to verify a dynamically generated xml file. I
have used an approach that works well for testing websites, verifying various
aspects of the document via xpath.

This way you don't have to write a completely separate second implementation to
generate the file but still can test for key aspects of the document while at
the same time ensuring xml validity.

Unfortunately this cannot be done with the build in ElementTree package. Instead
I had to depend on lxml which depends on c libxml2 which (afaik) cannot be
installed with tox.

Is this acceptable? Is there a way to install lxml via tox? How should i
document the depency?

[Sebastian Noack, 2016/12/21 15:54:15]

lxml can be installed using pip, and so also via tox. However, you'd need to
have the build dependencies installed (globally) before you run tox. This is
something we should avoid, as it partially defeats the purpose of tox, which is
that you only need one tool which then automatically installs and runs
everything else in an ad-hoc environment.

Also IIRC, libxml2/lxml is a rather error-tolerant parser, which comes handy in
most situations, but not so much when writing tests where you want to strictly
validate the XML.

I wonder why ElementTree from the corelib isn't sufficient. It supports XPath,
but I suppose you are using some more advanced syntax, that isn't supported in
the corelib? I suppose with a little bit of boilerplate it might be possible to
workaround that limitations. Or if really necessary, there are a couple XPath
implementations in pure Python, we could use without any native build
requirements.

But I'm undecided, whether XPath is much better than using the DOM directly. You
would need more code when using the DOM, but on the other hand across your XPath
expressions you have quite a bit of duplication, which you wouldn't have if
using the DOM an putting all intermediate nodes into variables. Though, it's
hard to judge which would be more preferable before seeing the resulting
implementation.

           PublicFolder="Extension"
           DisplayName="Adblock Plus">
           <uap3:Properties>
             <Capabilities>
               <Capability Name="websiteContent"/>
               <Capability Name="browserStorage"/>
               <Capability Name="websiteInfo"/>
               <Capability Name="browserWebRequest"/>
             </Capabilities>
           </uap3:Properties>
         </uap3:AppExtension>
       </uap3:Extension>
       </Extensions>
     </Application>
   </Applications>
 
 </Package>