Hi Jeremy,
Unlike InputJar, ReferenceJars cannot be "embedded" - honestly I never
thought about scenarios where ReferenceJars are widely required among
many projects.
If there are not a small need for that feature, we will consider
implementing something like "EmbeddedReferenceJar" for that.
Thanks for the feedback as usual!
Atsushi Eno
Jeremy A. Kolb - ARA/NED wrote:
What about reference jars? If A library project depends on 3 jars + and input
jar do we still have to copy the reference jars to the project that uses the
library or are they packaged up too?
-----Original Message-----
From: monodroid-boun...@lists.ximian.com
[mailto:monodroid-boun...@lists.ximian.com] On Behalf Of Atsushi Eno
Sent: Tuesday, October 23, 2012 11:05 AM
To: monodroid@lists.ximian.com
Subject: [mono-android] warning: with 4.2.8 you will have to remove
android-support-v4.jar build item
Hello,
tl;dr: after updating to 4.2.8 preview, you might see a build breakage to your
existing project that references Mono.Android.Support.v4.dll and contains
android-support-v4.jar as AndroidJavaLibrary.
In that case, removing the AndroidJavaLibrary item is needed.
----
Starting from version 4.2.8, new "embedded jar" feature will allow us
(everyone) to embed the jar into the binding dll, which will automatically add the jar to
application package (as if we specified AndroidJavaLibrary). This should reduce
complicated procedure to pass the library to both binding and app projects.
This won't happen unless you specify "EmbeddedJar" build action to binding jar
file. You can still use InputJar. (Though starting from 4.2.8 it will be the default
action for jar files in Jars directory.)
We applied this to our Mono.Android.Support.v4.dll so now it this dll embeds
android-support-v4.jar.
This change however causes side effect; any project that has reference to older
android-support-v4.jar will not build unless you remove it.
The reason is explained at bug #7946 but here I copy the entire text:
----
This is not a bug but explicitly designed behavior. We should NOT remove
whatever users specified *arbitrarily*. That rather brings confusion to users
and it should be always user who decide which to leave into app package and
which to discard.
To make it clear, when the jars, one in the dll and others in app projects, are
IDENTICAL (which means both have identical name
*and* identical content), they don't result in conflict. For any *other* cases,
you should be *aware* that the jar is *inconsistent* with the actual jar which
is being used in the application.
You are seeing the error message because you use *inconsistent*
support-v4 jar.
EmbeddedJar feature is not specific to Mono.Android.Support.v4.dll.
Any user bindings fall into the same *possibly conflicting* situation.
You will get furious if we arbitrarily determine that "your jar in the application
is extraneous" while it might be *newer* (!) especially in such scenario like this:
the application also uses newer jar as AndroidJavaLibrary to invoke new API feature, and
it fails because we silently drop the newer jar due to this *wrong* assumption.
Of course there is no deterministic way to identify *which* library is actually
newer, and there is no chance to actually use the application jar if you have
to stick to the dll, which is not *always* true - users could use different
binding dll.
We made the error message very clear to indicate what to do: you have to either
alter the dll or remove the application jar (or any conflicting jar in other
dll).
Hence the current behavior is the only way to assure valid jar packaging.
Regardless of whether we embed the jar into the dll or not in this version,
such possibly-mismatching jar-vs-dll issue could have happened, so canceling
EmbedJar is worse choice.
Hope this explanation makes sense.
Atsushi Eno
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
