Hi Atsushi, They're pretty important. Unfortunately in my travels it looks like a lot of third party jars have dependencies on other jars. Jeremy
-----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:39 AM To: Discussions related to Mono for Android Subject: Re: [mono-android] warning: with 4.2.8 you will have to remove android-support-v4.jar build item 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 _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
