cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Plugin Version Control Workflow
Date Wed, 08 Jan 2014 03:39:50 GMT
+1 on emulating node/npm

"cordova install" reads cordova.json or cordova section of package.json
(which contains all dependencies for plugins and platforms) to download and
add from heaven (oops I meant the cloud :-) )



On Tue, Jan 7, 2014 at 1:33 PM, Brian LeRoux <b@brian.io> wrote:

> we may want to emulate node/npm here
>
> `npm install`
>
>
> On Tue, Jan 7, 2014 at 10:20 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Definitely a config.xml thing.
> >
> > I don't think anyone's fiddling. If you want to take it on, that'd be
> > awesome. Mark the issue as assigned to yourself (just gave you JIRA
> perms)
> > and have at it! :)
> >
> > Idea for implementing this:
> > 1. Get "cordova plugin add" at add a <dependency> tag to config.xml
> > 2. Add a "cordova plugin sync" command that adds/removes plugins based on
> > what's in config.xml
> >
> >
> >
> > On Tue, Jan 7, 2014 at 9:12 AM, Ross Gerbasi <rgerbasi@gmail.com> wrote:
> >
> > > Sooooo I think we are all cool on this. Adding this feature does not
> stop
> > > anyone from checking in those folders if they desire.
> > >
> > > How can I help make this happen? Or is someone already fiddling with
> > this?
> > > Last activity on the issue was a month ago (
> > > https://issues.apache.org/jira/browse/CB-4624)
> > >
> > > Then again does this still require some choices to be made? I know
> there
> > is
> > > a lot of talk of config.xml and cordova.json and what goes where but I
> am
> > > assuming this is a config.xml thing.
> > >
> > >
> > > On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > I think we're talking somewhat at cross purposes.
> > > >
> > > > One of my goals with the CLI is to make the ./platforms and ./plugins
> > > > directories build artifacts, meaning that you could delete them (or
> > check
> > > > out a new copy of your project that does not include them) and
> restore
> > > them
> > > > fully with a couple of commands.
> > > >
> > > > Currently the two commands would have to be: cordova platform add
> <all
> > > your
> > > > platforms> and cordova plugin add <all your plugins>. The latter
is
> > > > unfortunately long, and we hope to fix that by allowing you to
> specify
> > > > required plugins for the project in the top-level app config.xml
> file,
> > so
> > > > that the second command becomes simply "cordova plugin add" or
> "cordova
> > > > plugin add --deps" or whatever we decide it should be.
> > > >
> > > > Why I say we're talking at cross purposes is that there's nothing
> about
> > > any
> > > > of this that stops people from checking some or all of the
> ./platforms
> > > > directory into their source control. They'll have to spend some
> effort
> > > > maintaining it, as Cordova updates various files, but that's the case
> > if
> > > > you have custom edits to the native code whether you put it in
> version
> > > > control or not.
> > > >
> > > > I mention the 99% of Cordova users because at some point it becomes
> > > > impractical to support 100% with the tool. There's always going to be
> > > some
> > > > esoteric use cases that will require some hand-holding to work with
> the
> > > > CLI.
> > > >
> > > > We have tried to extract most of the things that used to require
> tweaks
> > > to
> > > > the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into
> > > preferences
> > > > that can be set from config files. If there are tweaks that are
> needed
> > by
> > > > more than a few users and are not covered by preferences, then they
> > > should
> > > > be added as new preferences.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <
> > kant2002@googlemail.com
> > > > >wrote:
> > > >
> > > > > Dan, Ross.
> > > > >
> > > > > I complexly agree with both of you. My workflow - my problems. I
> > wrote
> > > > > about it just so you have background about needs of developers like
> > me.
> > > > > When I read about number 99% CLI developers, I understand that I
am
> > > from
> > > > > the not mentioned 1%. And tone of the discussion for me sounds like
> > > that
> > > > 1%
> > > > > would not be taken into consideration.
> > > > >
> > > > > Right now I have 2 small issues which would be important for you
> only
> > > if
> > > > > you keep you ./plugins, ./platforms source code in VCS. Don't think
> > > that
> > > > > they are valuable enough for you when you main use-case is keep
> > > ./plugins
> > > > > and ./platforms outside of VCS, so I better implement them myself
> and
> > > > > contribute back to the Cordova.
> > > > >
> > > > > What is not clear to me, are such contributions would be welcome
or
> > > not,
> > > > > since it is for only 1% of people?
> > > > >
> > > > > Andrey K.
> > > > >
> > > > >
> > > > >
> > > > > 2014/1/7 Ross Gerbasi <rgerbasi@gmail.com>
> > > > >
> > > > > > Hey Andrey,
> > > > > >
> > > > > > Much like you said 99% of the users will want to ignore platforms
> > and
> > > > > > plugins from version control. Making this work properly would
not
> > > stop
> > > > > > someone from including them if they wanted to. If your workflow
> is
> > > > better
> > > > > > including those folders you would have no problem doing so.
> > > > > >
> > > > > > Ideally though if you can keep your custom code off in plugins,
> > even
> > > if
> > > > > > they are not public plugins, would be ideal. Also as Dan
> mentioned
> > > you
> > > > > can
> > > > > > look into hooks to help modify platforms as needed.
> > > > > >
> > > > > > Again though if you find checking everything in easier thats
cool
> > but
> > > > the
> > > > > > CLI should be setup in a way that we do not need to.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <moore234@yahoo.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Andrey,
> > > > > > >
> > > > > > > I have worked on two small, simple Cordova applications,
but we
> > > still
> > > > > at
> > > > > > > times had to modify platform specific code.  Not much,
but some
> > > > > > > (AppDelegate.m for the iOS app, and the DroidGap subclass
for
> > > > > > Android--this
> > > > > > > is a 2.9.x project for now).
> > > > > > >
> > > > > > > Here's my solutions to your issues.
> > > > > > > * if you need to modify native plugin code, you should
fork the
> > > repo
> > > > > and
> > > > > > > manage your changes via a git project, not in your project.
> > > > > > >
> > > > > > > If you use a recent enough version of Cordova, you can
even
> pull
> > > > > plugins
> > > > > > > off git branches ( see
> > > https://issues.apache.org/jira/browse/CB-4981)
> > > > > > so
> > > > > > > you could have different versions of your apps for different
> > > clients
> > > > > pull
> > > > > > > different branches of the same plugin.
> > > > > > >
> > > > > > > * if you need to modify code under platforms, use an
> > > > after_platform_add
> > > > > > > hook, and keep your customized platform files elsewhere
in your
> > > > project
> > > > > > > tree.
> > > > > > >
> > > > > > > This way, you aren't version controlling everything, just
what
> > > you've
> > > > > had
> > > > > > > to change.  Of course, when the Cordova platform changes
> > underneath
> > > > you
> > > > > > > (perhaps a new method is added to AppDelegate.m, and the
> version
> > > you
> > > > > have
> > > > > > > in source control overwrites that), you need to check these
> files
> > > > > > > carefully.  But when you version control everything and
you
> > > upgrade,
> > > > > you
> > > > > > > have to merge in your custom changes into the new Cordova
code
> in
> > > the
> > > > > > same
> > > > > > > careful manner, plus you are carrying around everything
else
> > under
> > > > > > > platforms.
> > > > > > >
> > > > > > > Of course, I'm a big believer in the CLI, having everyone
use
> the
> > > > > entire
> > > > > > > CLI toolchain, and treating everything under platforms
and
> > plugins
> > > as
> > > > > > > derived code that you can replace at any time.  If this
isn't
> how
> > > you
> > > > > > > develop (if you prefer the 'native project dev' workflow,
for
> > > > example),
> > > > > > > then this may not work for you.
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Dan
> > > > > > >
> > > > > > > PS Can you explain how keeping all the code in source control
> > makes
> > > > > your
> > > > > > > merges as you move from Cordova version to Cordova version
> > easier?
> > > >  To
> > > > > > me,
> > > > > > > that would seem to make them more difficult.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > > > > kant2002@googlemail.com> wrote:
> > > > > > >
> > > > > > > About plugin and platform version control.
> > > > > > > I heard a lot about that, and confused why you think that
> > everybody
> > > > > would
> > > > > > > like to remove ./plugins and ./platforms folders from source
> > > > control. I
> > > > > > do
> > > > > > > agree that this is most likely the case for the simple
> > applications
> > > > and
> > > > > > for
> > > > > > > the maybe 99% of current Cordova users, but I don't believe
> that
> > > this
> > > > > is
> > > > > > > truly important for the Cordova as the ecosystem for the
> > > > cross-platform
> > > > > > of
> > > > > > > the mobile development.
> > > > > > >
> > > > > > > Let me explain why I think that keep ./platforms and ./plugins
> > > under
> > > > > > source
> > > > > > > control very important. I would base my reasoning on my
current
> > > > project
> > > > > > > needs.
> > > > > > > I currently develop 2 similar products for different clients
> from
> > > the
> > > > > > same
> > > > > > > domain. I understand that in future I will have another
clients
> > > from
> > > > > same
> > > > > > > problem domain which would like to have similar applications,
> > just
> > > > with
> > > > > > > different design. So I take the route of having 1 product
line
> > and
> > > > > > > customization of that product line for each client, depends
on
> > > their
> > > > > > needs.
> > > > > > > This is client facing application, so I would like to cover
as
> > much
> > > > > > mobile
> > > > > > > platforms as possible with minimum amount of efforts.
> Currently I
> > > > > support
> > > > > > > only Android and iOS platforms, but envision that my clients
> will
> > > > > expand
> > > > > > to
> > > > > > > the Windows Phone soon, and maybe I will force them to
support
> > > Tizen
> > > > in
> > > > > > > next year if that platform would be world-wide popular.
> > > > > > > I position my self as
> > > > > > > a) heavy Cordova user
> > > > > > > b) middle/low platform specific development. (I have to
go deep
> > in
> > > > each
> > > > > > > platform, but that's not priority for me as Cordova users)
> > > > > > > I maintain 3 Git branches. 1 branch for core product and
2
> > branches
> > > > for
> > > > > > > each client. In each branch I keep, platform specific code
for
> > the
> > > > > > > application (cordova-platform-ios/android code), Cordova
> plugins
> > > > code +
> > > > > > > plugins developed specifically to this application.
> > > > > > > I definitely sure that I will need to add some functionality
to
> > the
> > > > > core
> > > > > > > platforms, either iOS or Android which will benefit the
my
> > > > > application. I
> > > > > > > would try to push to the core Cordova as much as I can,
but
> > > possible
> > > > > that
> > > > > > > not all contribution would be useful for the Cordova. Either
> way
> > I
> > > > plan
> > > > > > for
> > > > > > > update to next version of Cordova (3.4, or 3.5 whenether).
To
> > keep
> > > my
> > > > > > > changes, which I add to current version of Cordova (3.3)
and
> make
> > > > > update
> > > > > > to
> > > > > > > 3.4 and later easier I keep all code in the source control
to
> > make
> > > > all
> > > > > my
> > > > > > > future merges easier. Same rules apply to the plugins,maybe
I
> add
> > > > some
> > > > > > > code/fixes to plugins, or not don't matter - I have to
plan for
> > > that.
> > > > > > > I would like to contribute to Cordova everything what will
> > benefit
> > > > the
> > > > > > > community to meet my selfish goals:
> > > > > > > I want to make my upgrade path as straightforward as possible,
> > for
> > > > > > platform
> > > > > > > code and for plugins code.
> > > > > > >
> > > > > > > Maybe I was too verbose, but that was just to explain that
I
> plan
> > > to
> > > > > > align
> > > > > > > my long-term goals with Cordova's long-term goals. I try
to
> gave
> > > more
> > > > > > > explanation, so you guys could plan not only for people
which
> > > create
> > > > > > > projects which are working on the specific version of Cordova,
> > but
> > > > also
> > > > > > for
> > > > > > > the guys which want to nurture their product together with
> > Cordova.
> > > > > > >
> > > > > > > I plainly don't see:
> > > > > > > a) how I could work on my product not keeping ./platforms
and
> > > > ./plugins
> > > > > > > directories in the source control, and
> > > > > > > b) why I should don't use Cordova CLI to update contents
of my
> > > > > > ./platforms
> > > > > > > and ./plugins folders. I think that these tool has a good
fit
> for
> > > > basic
> > > > > > > housekeeping of the files/plugins. Don't want to manually
> fiddle
> > > with
> > > > > > > content of plugins for each platform and use plugman/cordova
> > > > > executables
> > > > > > to
> > > > > > > do the job.
> > > > > > >
> > > > > > > Hopefully I was enough verbose to explain why I have needs
> what I
> > > > have
> > > > > > now,
> > > > > > > and not too verbose so you flood in details.
> > > > > > >
> > > > > > > To summarize my input is:
> > > > > > > 1. Keep tools that way, that it could work either when
> ./plugins,
> > > > > > > ./platforms in source control, or when these folders not
in the
> > > VCS.
> > > > > > > 2. Take into account that people may want to customize
Cordova
> > > > > > distribution
> > > > > > > and have path to future upgrades.
> > > > > > > 3. I want to take responsibility for some burden which
this way
> > > could
> > > > > > > potentially create for you guys,
> > > > > > >
> > > > > > > Andrey Kurdyumov.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2014/1/7 Braden Shepherdson <braden@chromium.org>
> > > > > > >
> > > > > > > > I've wanted to add Cordova plugin dependencies to
the app's
> > > > top-level
> > > > > > > > config.xml for a long time, but it's never reached
the top of
> > my
> > > > > > > > priorities. I think with that support, we can avoid
checking
> in
> > > > > > > ./plugins/
> > > > > > > > and ./platforms altogether for 99% of app developers.
If it
> > > doesn't
> > > > > > solve
> > > > > > > > anyone's use case, I'd love to hear about it.
> > > > > > > >
> > > > > > > > Braden
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <
> > > rgerbasi@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > CB-4624 is exactly what I am looking for. I am
not sure if
> it
> > > > > should
> > > > > > be
> > > > > > > > > config.xml or some other config file, it probably
doesn't
> > > matter
> > > > > much
> > > > > > > > when
> > > > > > > > > it comes down to it. Is there any rules currently
in place,
> > > like
> > > > > CLI
> > > > > > > > > doesn't touch config.xml?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve
<
> > > > > > agrieve@chromium.org
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > I think https://issues.apache.org/jira/browse/CB-4624
is
> > the
> > > > > > > relevant
> > > > > > > > > > issue
> > > > > > > > > > here. Please add comments to it if it's
not spec'ed or
> good
> > > > > enough.
> > > > > > > > > >
> > > > > > > > > > Also related is
> > > https://issues.apache.org/jira/browse/CB-5006-
> > > > > > > meant
> > > > > > > > to
> > > > > > > > > > address local repos of plugins.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey
Kurdumov <
> > > > > > > > > kant2002@googlemail.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > Would be very helpful if you change
formatting of the
> > > plugins
> > > > > > > > manifest
> > > > > > > > > > > files (android.json, ios.json). Currently
it is print
> all
> > > > JSON
> > > > > > > string
> > > > > > > > > to
> > > > > > > > > > > the big single line, which difficult
to merge when
> > needed.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Carlos Santana
<csantana23@gmail.com>

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