Is this related to the difference between <resource-file> targets in
config.xml and plugin.xml?
In config.xml, <resource-file> target attribute values are relative to
the base platform directory. In plugin.xml, they are relative to
app/src/main in the base platform directory.
Would it be useful to document this?
-Terence
On 4/18/2018 10:28 AM, Joe Bowser wrote:
Looks good. I'll do a quick sanity check later today, but it should be
fine.
On Wed, Apr 18, 2018 at 5:26 AM, julio cesar sanchez <jcesarmob...@gmail.com
wrote:
I've sent a PR for the Android Studio detection problem, it just makes
isAndroidStudioProject return true, removed the non Android Studio
tests/files (or updated some to be Android Studio tests)
https://github.com/apache/cordova-android/pull/437
That wont fix incompatible plugins, but at least will point to the bad one
or the bad one won't work, instead of pointing to the next one to be
installed.
What I say about the mapping is we have a check for .java and .xml, and we
copy those files to the new location, I don't think we should expect plugin
authors to map other files, I'll try to send another PR for that when I
have time, but if you feel we need to do a release before that, feel free
to do it.
2018-04-18 0:03 GMT+02:00 Steven Gill <stevengil...@gmail.com>:
Joe or myself don't currently have the time to fix this problem and
probably won't for the foreseeable future. Plugin maintainers can send
PRs
to cordova-android adding their mapping if they want or update their
plugins.
But I'd like to get this release out because of the bug fixes that have
landed and because the release train should keep rolling. A future
release
can happen with those fixes once PRs come in
On Tue, Apr 17, 2018 at 2:59 PM, Joe Bowser <bows...@gmail.com> wrote:
On Tue, Apr 17, 2018 at 2:54 PM, julio cesar sanchez <
jcesarmob...@gmail.com
wrote:
Yeah, but our plugins work because we have put some code to copy our
files
to a new location instead of updating the paths in the plugins'
plugin.xml.
This is handled for what our plugins need, but not for all the
possible
cases, so I don't think it's ok to make a patch to just make our
plugins
work but don't do the same for other allowed files. If we didn't
update
the
core plugins for the new path we shouldn't ask users to do it in
their
plugins.
Fair, we should really be updating all our plugins and figuring out how
to
remove the patch. The last thing I want to see is this code growing
like
a cancer, which it very well could. I don't think we should be
delaying
the release because of third party plugins not being able to be
installed.
Also there is the problem I told you about the false positive making
it
think it's an Eclipse project and making our plugins fail to install
if
they are installed after a plugin with the previos problem.
Yeah, that's a pretty major failure that we never saw when we were
testing
7.0. I don't think this should delay the release either unless a PR
arrives that fixes this.
2018-04-17 23:30 GMT+02:00 Joe Bowser <bows...@gmail.com>:
I disagree. We have our core plugins installing and uninstalling
without
issue currently, and we can't babysit everyone with their third
party
plugins. The community needs to come up with a plan on deprecating
the
old
project structure and communicating that to the third party plugin
maintainers.
On Tue, Apr 17, 2018 at 2:28 PM, julio cesar sanchez <
jcesarmob...@gmail.com
wrote:
Before doing an Android release we should fix the problems with
plugins
installs, people is not updating because of it
2018-04-17 3:31 GMT+02:00 gandhi rajan <gandhiraja...@gmail.com
:
Hi Steve,
Can you please have a look at this PR -
https://github.com/apache/cordova-docs/pull/811
It's related to Cordova doc changes.
On Tuesday, April 17, 2018, Steven Gill stevengil...@gmail.com
wrote:
Going to aim to do a release this week. Let me know if there
are
any
PRs
I
should look at.
--
Regards,
Gandhi
"The best way to find urself is to lose urself in the service
of
others
!!!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
