cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Proposal: Change Android Project Directory Structure to Android Studio style
Date Wed, 18 May 2016 03:13:30 GMT
On Tue, May 17, 2016 at 5:35 PM, Richard Knoll <riknoll@microsoft.com>
wrote:

> Does that mean the plan is to provide a mapping from old file locations to
> new ones? For example, if I have this in my plugin.xml:
>
>     <config-file target="res/values/strings.xml" parent="" />
>
> Will the new cordova-android automatically convert the target value to the
> new location of "app/src/main/res/values/strings.xml"?
>


I'm pretty sure that config-file targets like that won't work properly, but
I think that source, resource and assets should.  I would have added that
as a resource file, since it's strings.xml.


>
> Thanks,
> Richard
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, May 17, 2016 3:51 PM
> To: dev <dev@cordova.apache.org>
> Subject: Re: Proposal: Change Android Project Directory Structure to
> Android Studio style
>
> @Richard: The changes to the Android files in cordova-common should allow
> for config-file, source-file and resource-file to work fine.  I already did
> something similar in February, but I should have checked it in on an
> Cordova-Android branch instead of the other repo.
>
> https://github.com/infil00p/cordova-android-studio
>
> @Parashuram: Does this drop the JAR is libs?  I couldn't quite tell from
> looking at the JS code doing the installation.  If it does, that won't
> change at all.
>
> On Tue, May 17, 2016 at 3:03 PM, Parashuram N <panarasi@microsoft.com>
> wrote:
>
> > This is an example -
> > https://github.com/ConnectSDK/Connect-SDK-Cordova-Plugin. This
> > actually has a hook that downloads and places the source code based on
> > the current directory structure.
> >
> > On 5/17/16, 2:53 PM, "Richard Knoll" <riknoll@microsoft.com> wrote:
> >
> > >We have a lot of plugin.xml elements that depend on the old file
> > structure. Tags like config-file, source-file, resource-file, etc. all
> > have target elements that take arbitrary paths to project files.
> > Looking at the new project structure, it seems like most of the
> > relevant folders have moved around. Does your proposal handle that or
> > do plugins need to update to reflect the new structure? I figure there
> > isn't much we can do for plugins that use hooks.
> > >
> > >Richard
> > >
> > >-----Original Message-----
> > >From: Joe Bowser [mailto:bowserj@gmail.com]
> > >Sent: Tuesday, May 17, 2016 2:07 PM
> > >To: dev <dev@cordova.apache.org>
> > >Subject: Re: Proposal: Change Android Project Directory Structure to
> > Android Studio style
> > >
> > >On Tue, May 17, 2016 at 2:01 PM, Parashuram N
> > ><panarasi@microsoft.com>
> > >wrote:
> > >
> > >> I think the proposal is great. Our gradle is pretty big, and it
> > >> does make sense to just do the defaults.
> > >> +1 (personally speaking) to this – will save soo much of my time as
> > >> +I
> > >> depend on this for my react-native-cordova-plugin adapter. Your
> > >> changes will make life so much easier ☺
> > >>
> > >> How do the plugins break? Will plugins have to make change? In a
> > >> way, it may make sense to do this with big changes at Google I/O –
> > >> that way, we just have 1 breaking change, and plugin authors have
> > >> to look at the changes just once.
> > >>
> > >
> > >Ideally they shouldn't break, but I can't guarantee that.  I do have
> > >to
> > change how plugins are installed in the Android cordova scripts, but
> > the cordova-common work abstracted all that out and made that easier.
> > A user who hasn't tweaked their app shouldn't notice the difference.
> > >
> > >That said, the users who have may notice stuff, and I have no idea
> > >how
> > Crosswalk would work with this yet.  It'd be good to work with them
> > once we have something more working.
> > >
> > >
> > >>
> > >> On 5/17/16, 1:55 PM, "Joe Bowser" <bowserj@gmail.com> wrote:
> > >>
> > >> >Hey
> > >> >
> > >> >I know people have been waiting for this for a very long time, but
> > >> >I wrote up a proposal to change the project so it's an Android
> > >> >Studio
> > project.
> > >> >Given that Android Studio is on 2.1.1, I think it's time we moved
> > >> >forward and changed things around.
> > >> >
> > >> >Proposal PR is here:
> > >> >https://github.com/cordova/cordova-discuss/pull/45
> > >> >
> > >> >Branch where Proof of Concept work is being done is here:
> > >> >https://github.com/infil00p/cordova-android/tree/studio_project_st
> > >> >ruc
> > >> >ture
> > >> >
> > >> >The main roadblock to doing this, of course is migration of
> > >> >plugins and custom code, as well as assets, but I think Android
> > >> >developers would welcome this change because we're acting more
> > >> >like a regular, normal Android project again and not some old,
> > >> >weird legacy/special
> > case thing.
> > >> >I've already did some exploratory work with the old
> > >> >cordova-android-studio version of cordova-common, and installing
> > >> >plugins works fine depending on what version of Cordova you're using.
> > >> >
> > >> >The other thing that has me stuck is all the functionality in the
> > >> >gradle files.  I would love to rip out a lot of the stuff we
> > >> >autogenerate in there, such as the settings.gradle file that
> > >> >caused me a huge headache earlier today when I tried to get
> > >> >importing to work.  It'd also be good to have a documented process
> > >> >on how we set the Application ID, since I can't quite figure out
> > >> >how we do that, and I know other people are struggling with that as
> well.
> > >> >
> > >> >This would be slated for Cordova-Android 6.0, and hopefully Google
> > >> >IO doesn't have too many surprises that break us.
> > >> >
> > >> >Joe
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message