+1 for ONE manifest (though that being XML or JSON is the decision, I guess)
+1 for plugman create ;)
+1 for plugman publish ;)
hehe
On 23/03/2013, at 2:06 PM, Anis KADRI wrote:
> Yes, templates are definitely in the roadmap. A lot of people have
> requested it. The goal is to make it super e
And so the consensus seems to involve breaking down that logic in
cordova.js and cordova into multiple files inside a lib sub-directory. I
don't really like the idea but I don't really care either as long as the
same set of commands is available across platforms.
Hopefully, next time we will chang
Cool! Now we need to populate them at least as fast as it took to get them
created :-)
On Fri, Mar 22, 2013 at 5:54 PM, Andrew Grieve wrote:
> https://issues.apache.org/jira/browse/INFRA-5839
>
Yes, templates are definitely in the roadmap. A lot of people have
requested it. The goal is to make it super easy for plugin authors to make
their plugins install-able/discoverable.
I didn't ask for a second manifest. Right now plugin authors can register
plugins to the cordova universe via a web
Yeah exactly… I think it would a great bridge over the moat that has been built
up around plugin authoring over the last year or so…
- tommy
On 23/03/2013, at 1:46 PM, Michal Mocny wrote:
> Huge +1 to plugin templates.
>
> (we already have an app template, right?)
>
> -Michal
>
>
> On Fri,
Huge +1 to plugin templates.
(we already have an app template, right?)
-Michal
On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams
wrote:
> The barrier of having more config files is real and change is starting to
> cause fatigue amongst the plugin authors I deal with regularly.
>
> Having
The barrier of having more config files is real and change is starting to cause
fatigue amongst the plugin authors I deal with regularly.
Having said that, I think JSON would be a welcome change overall…
There really are not that many plugins that are set up with a plugin.xml yet
that I know o
Ah yes, I see what you are asking. The point being that phonegap build
would need to change to work with the new structure.
Its a fair point, and its important generally to not harm downstream
distributions on purpose, but I think we generally should do whats best for
cordova and give downstream
As long as the alerts for asking for permission (as an example) don't say
"index.html would like to use your position" or whatever it is without the
PhoneGap/Cordova API over the top…
On 23/03/2013, at 9:04 AM, Filip Maj wrote:
> +1 geo and websql deprecation
>
> I would wait on camera unti
I just mean that build expects config.xml to be in www, yeah?
On 23/03/2013, at 1:12 PM, Michal Mocny wrote:
> But isn't the app incomplete without the merges folder? Most apps probably
> don't use it, but for those that do, a zip of www isn't enough, you already
> need to ship more than just
Is it possible to do both? A generic map such that you can write a generic
app without platform considerations, but also provide a (less vocally
documented?) way to specify the platform values.
(I only suggest this because complaints about hybrid apps of late are that
they sometimes abstract too
I generally prefer json whenever possible as well, so if its feasible to
change I'de give that a +1, but I'm not sure how many plugins out there
already use the manifest based structure.
As far as creating a second manifest just to register with a universe, this
isn't unheard of may have benefits,
What spec is that? I would like to research that, I was not aware there was a
new one.
Thanks!
Sent from my BlackBerry Z10 smartphone.
From: Shazron
Sent: Friday, March 22, 2013 8:43 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: [Android] Plugins to send on the ice
But isn't the app incomplete without the merges folder? Most apps probably
don't use it, but for those that do, a zip of www isn't enough, you already
need to ship more than just the www folder. Creating an app folder would
actually make the situation easier I think.
project
- platforms
- ..
-
Dan, my brother showed me this (he is mechatronics student at UW). Is it
still on tomorrow?
On Fri, Mar 22, 2013 at 6:41 PM, Dan Silivestru wrote:
> +1
>
> Sorry I'm late to the game, I was judging frisbee throwing, pyramid
> climbing robots all day :-)
>
> https://twitter.com/confusement/statu
Mostly that they are not super critical / nobody dedicated to them
explicitly. I know you keep Mac alive (and well) and Jesse on Win7&8.. If
you guys want to continue that sure.
On Friday, March 22, 2013, Shazron wrote:
> What's the rationale for removing desktop platforms?
>
>
> On Fri, Mar 22,
https://issues.apache.org/jira/browse/INFRA-5839
Given that cordova-cli will be the end goal for people typing in commands,
I guess I don't really care what the scripts look like as long as they are
consistent.
So.. I guess I'd be fine to have build-release and build-debug as top-level
scripts. Since:
It would seem weird to me to have a top-lev
What's the rationale for removing desktop platforms?
On Fri, Mar 22, 2013 at 4:33 PM, Anis KADRI wrote:
> +1
>
>
> On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes wrote:
>
> > +1
> >
> >
> > On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill
> > wrote:
> >
> > > +1. I will create issues for coho in reg
Andrew: Capture API. But that's going away I reckon as well (there is a new
spec)
On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve wrote:
> What's the alternative to Camera?
>
>
> On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj wrote:
>
> > +1 geo and websql deprecation
> >
> > I would wait on camera
I would map them.
On Fri, Mar 22, 2013 at 2:35 PM, Don Coleman wrote:
> I'm looking at adding video quality to CaptureVideoOptions.
>
> Android has 2 options, iOS has 5.
>
> Should I attempt to map some generic high_quality, medium_quality,
> low_quality options to platform specific options or
What's the alternative to Camera?
On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj wrote:
> +1 geo and websql deprecation
>
> I would wait on camera until we actually do the api audit
>
> On 3/22/13 2:54 PM, "Joe Bowser" wrote:
>
> >Hey
> >
> >I'm currently looking through the plugins, and I'm think
Well at least if you're making changes to the BASH ones you're not breaking
the cscript ones unless you're changing the whole flow of operations.
Also as you mentioned node is a new dependency.
On Fri, Mar 22, 2013 at 4:45 PM, Filip Maj wrote:
> Well, we *should* be doing this regardless.. I'm
We do have brand new scripts written in node we're struggling to get approval
to show off.
Sent from my BlackBerry 10 smartphone.
From: Filip Maj
Sent: Friday, March 22, 2013 7:46 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: [cordova-cli] - rewrite Blackberry and An
Yeah the only issue with plugin.xml is that it's XML :-D
It would be so much easier to have it stored in JSON. We can make plugman
parse the XML from a remote source but I would rather store everything in
JSON.
Also there can be multiple versions of plugin.xml. I think that is a good
enough r
I like this solution to platform scripts, the only addition I would add is that
if the platform allows multiple targets, perhaps it could be possible to set a
default one that would be used instead of the timeout to first one (although I
suppose that makes first entry inherent default).
Sent fr
Well, we *should* be doing this regardless.. I'm super guilty of not doing
it. I really should get that VM installed.. Sigh.
On 3/22/13 4:42 PM, "Anis KADRI" wrote:
>Also worth pointing out that as much as node is cross-platforms you will
>have to consider/test both platforms every time you make
Actually, related to that and an outstanding request for cordova-cli to
accept a "--verbose" option: to add that option to all of these proposed
scripts.
On 3/22/13 3:55 PM, "Tommy-Carlos Williams" wrote:
>+1
>
>...however, currently the prompt is never shown when using the cli tools as
>they ar
Also worth pointing out that as much as node is cross-platforms you will
have to consider/test both platforms every time you make a modification to
the scripts. How often do you guys fire up your Windows bootcamp, VM or
partition to test a tiny change ? How much would you like that ?
On Fri, Mar
+1
On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes wrote:
> +1
>
>
> On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill
> wrote:
>
> > +1. I will create issues for coho in regards to this.
> >
> > -Steve
> >
> > On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote:
> >
> > > +1
> > >
> > > On 3/22/13 2:26
Can I just ask a question about this?
Is the config.xml supposed to be compatible with build.phonegap.com at all?
I ask because I could see a scenario where you might want to use the cli tools,
but still utilise build.phonegap.com for other platforms (or even for the ones
supported by the cli)
+1
I think that would be a good place for the check_reqs script
On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj wrote:
> One more addition: based on responses from the cordova-cli threads, it
> looks like we'll also add a `check_reqs` script to each platform (perhaps
> under /cordova/lib)
>
> On 3/2
+1
…however, currently the prompt is never shown when using the cli tools as they
are super-mega-secret-silent.
I only ever know that it wanted me to choose which emulator of the ones I have
available (android avd) when it times out and shows it as part of the error.
Something to keep in mind
Fyi next branches no longer in use and to be deleted soon..
On 3/22/13 3:52 PM, "Gord Tanner" wrote:
>Merged into next [1].
>
>I am currently at the pub and a beer or two in so I am not going to code
>to
>much. If someone wants to axe serve (or refactor it to just use ripple)
>that would be awe
Merged into next [1].
I am currently at the pub and a beer or two in so I am not going to code to
much. If someone wants to axe serve (or refactor it to just use ripple)
that would be awesome.
[1] -
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/heads/next
On Fri,
One more addition: based on responses from the cordova-cli threads, it
looks like we'll also add a `check_reqs` script to each platform (perhaps
under /cordova/lib)
On 3/22/13 3:10 PM, "Michael Wolf" wrote:
>I like this.
>
>mw
>
>On 3/22/13 6:03 PM, "Brian LeRoux" wrote:
>
>>YES. Do it.
>>
>>On
+1 for windows
On Fri, Mar 22, 2013 at 11:08 AM, Filip Maj wrote:
> +1 !
>
> On 3/22/13 10:34 AM, "Shazron" wrote:
>
> >+1
> >
> >
> >On Fri, Mar 22, 2013 at 10:33 AM, Jeffrey Heifetz
> >wrote:
> >
> >> +1
> >>
> >> On 13-03-22 1:32 PM, "Anis KADRI" wrote:
> >>
> >> >+1
> >> >
> >> >
> >> >On
+1
On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill wrote:
> +1. I will create issues for coho in regards to this.
>
> -Steve
>
> On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote:
>
> > +1
> >
> > On 3/22/13 2:26 PM, "Brian LeRoux" wrote:
> >
> > >Currently a release consists of some boilerplate:
To clarify - I don't mind if serve gets axed for now.
On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux wrote:
> Like that plan. Say we proceed and land it in 2.6 to feel out.
>
> On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote:
> > I'm fine with removing server. In my mind ripple is just a serve
+1
Sorry I'm late to the game, I was judging frisbee throwing, pyramid
climbing robots all day :-)
https://twitter.com/confusement/status/315162754619162625
On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj wrote:
> K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry +
> iOS not
On Fri, Mar 22, 2013 at 1:01 PM, Andrew Grieve wrote:
> Could you call requestFocusFromTouch() on your other component after the
> WebView calls it?
>
I was going to ask the same question.
I also got frustrated with methods being protected or private but there are
usually ways around it.
K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry +
iOS not tagged yet so we can land some more commits in cordova-cli
On 3/22/13 3:02 PM, "Brian LeRoux" wrote:
>Like that plan. Say we proceed and land it in 2.6 to feel out.
>
>On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wr
On merges in the root, in our internal implementation it was under www,
however this became problematic to devs understanding. It became far to
easy for root level www code to end up in merges. We even named ours
_platformOverrides to try and make it pretty explicit, but no one liked
the mixing t
I'm ok with ./merges at the same level as ./www but the config.xml
inside of ./www bugs me too. I think having a root level ./www just
works well mentally in that its obvious whats there, what it does, and
who it effects. The ./merges folder is really just stuff that gets
added to ./www in the righ
I like this.
mw
On 3/22/13 6:03 PM, "Brian LeRoux" wrote:
>YES. Do it.
>
>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote:
>> Hai gaiz!
>>
>> Main contention between the two "camps" in this debate is four vs eight
>> scripts.. But Brian points out that refactoring smaller bits of
>> functiona
Sounds good to me, though the prompting with a timeout seems a little
weird. If there is multiple I think it would be better just to prompt and
wait for a response
On Fri, Mar 22, 2013 at 3:03 PM, Brian LeRoux wrote:
> YES. Do it.
>
> On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote:
> > H
Sweet. Don't forget tests :)
On 3/22/13 3:02 PM, "Benn Mapes" wrote:
>I have added support for wp7 + wp8 on this branch and made a pull request
>to cordova-cli but I think it would be best to hold off merging it
>in until we decide what to do with the lib folder (i.e dynamically load
>platforms
Offline happens!
I think by default nobody needs ANY of our APIs but the transition to
that thinking will be the trick.
On Fri, Mar 22, 2013 at 1:07 PM, Michal Mocny wrote:
> Hmm, but then the versioning of the core plugins is tied to the version of
> your cordova-cli tool at install time?
>
>
Agreed +1
On 3/22/13 4:23 PM, "Brian LeRoux" wrote:
>Ya love it. =)
>
>On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj wrote:
>> Agree with everything Braden said
>>
>> On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote:
>>
>>>+1 for ./platforms becoming a build artifact.
>>>
>>>That is already how
+1 geo and websql deprecation
I would wait on camera until we actually do the api audit
On 3/22/13 2:54 PM, "Joe Bowser" wrote:
>Hey
>
>I'm currently looking through the plugins, and I'm thinking more and
>more that Android has at least two plugins that I would like to see no
>longer maintained
Given that plugins will be independently versioned once they break off
I think it will be a whole new world for where we focus our efforts
next year. I suspect most of what you propose will be without
contention.
On Fri, Mar 22, 2013 at 2:54 PM, Joe Bowser wrote:
> Hey
>
> I'm currently looking t
+1. I will create issues for coho in regards to this.
-Steve
On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote:
> +1
>
> On 3/22/13 2:26 PM, "Brian LeRoux" wrote:
>
> >Currently a release consists of some boilerplate:
> >
> >DISCLAIMER
> >LICENSE
> >NOTICE
> >README.md
> >changelog
> >
> >And t
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote:
> Hai gaiz!
>
> Main contention between the two "camps" in this debate is four vs eight
> scripts.. But Brian points out that refactoring smaller bits of
> functionality into their own script allows us to "have our cake and eat it
> to
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote:
> I'm fine with removing server. In my mind ripple is just a serve command
> on steroids. At this morning's meeting I believe some of the Googlers
> expressed concerns about axing out
I have added support for wp7 + wp8 on this branch and made a pull request
to cordova-cli but I think it would be best to hold off merging it
in until we decide what to do with the lib folder (i.e dynamically load
platforms when we call `cordova platform add foo` for the first time).
https://github
Ripple can do everything serve does right now and if you don't pass
enableRipple as a command arg it will just host your content exactly like
serve.
Should we just route the serve command to ripple?
On Fri, Mar 22, 2013 at 5:50 PM, Filip Maj wrote:
> I'm fine with removing server. In my mind r
Hey
I'm currently looking through the plugins, and I'm thinking more and
more that Android has at least two plugins that I would like to see no
longer maintained once we break them off of the main repository.
Geolocation:
---
Our Geolocation doesn't actually give us anything that
I'm fine with removing server. In my mind ripple is just a serve command
on steroids. At this morning's meeting I believe some of the Googlers
expressed concerns about axing out serve, so perhaps a prudent first step
would be to add Ripple as an `emulate` command and then we can take baby
steps to
Ripple is now ready to be integrated, currently I have it added as a
seperate ripple command in a personal branch [1]
Most of the work on Ripple was a much needed feature we knew we needed
(Device Selection via query string [2]) as well as adding the ability to
serve content from multiple director
Let's wait and see for the new BlackBerry repo. I think Jeff mentioned that
some scripts were written in node already.
On 22 March 2013 12:54, Filip Maj wrote:
> Just for clarity's sake, I want to point out that this would add a new
> dependency to cordova-android as a standalone project. Worth
Jesse, when you resolved this Jira item, I don't see that my pull request ever
got merged. Did you provide an alternate implementation, or is this a
won't-fix, or something else? I'm confused why the issue is marked resolved.
The reason I ask is because I'd like to get this fix into 2.6. Thanks!
Hai gaiz!
Main contention between the two "camps" in this debate is four vs eight
scripts.. But Brian points out that refactoring smaller bits of
functionality into their own script allows us to "have our cake and eat it
too". This, in turn, results in four + (a subset of the 8) = 10 scripts in
to
+1
On 3/22/13 2:26 PM, "Brian LeRoux" wrote:
>Currently a release consists of some boilerplate:
>
>DISCLAIMER
>LICENSE
>NOTICE
>README.md
>changelog
>
>And the guts:
>
>cordova-android.zip
>cordova-app-hello-world.zip
>cordova-bada-wac.zip
>cordova-bada.zip
>cordova-blackberry.zip
>cordova-cli.z
I'm looking at adding video quality to CaptureVideoOptions.
Android has 2 options, iOS has 5.
Should I attempt to map some generic high_quality, medium_quality,
low_quality options to platform specific options or just pass in platform
specific options?
Android:
EXTRA_VIDEO_QUALITY
0 low quality
Currently a release consists of some boilerplate:
DISCLAIMER
LICENSE
NOTICE
README.md
changelog
And the guts:
cordova-android.zip
cordova-app-hello-world.zip
cordova-bada-wac.zip
cordova-bada.zip
cordova-blackberry.zip
cordova-cli.zip
cordova-docs.zip
cordova-ios.zip
cordova-js.zip
cordova-mobil
makes sense to me; we'll likely want to query on that stuff eventually
On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny wrote:
> Should the universe just keep a copy of a plugin.xml so that it can have a
> list of plugin dependancies and everything? plugin.xml will already have a
> list of compati
Link to recording: http://my.adobeconnect.com/p5vaenqvrsc/
Let me know if any of you have issues viewing.
Cheers,
-Steve
On Fri, Mar 22, 2013 at 11:43 AM, Michal Mocny wrote:
> Here are the meeting notes:
>
> Meeting Notes
>
>
>1.
>
>Fil describing the tools
>-
>
> command li
Paraphrasing from meeting notes today:
* plugins are getting awesome treatment:
* universe
* dependencies
* versioning
* add/remove/upgrade
* access to native
* multiple plugins in one repo
* apps are getting some treatment:
* the app manifest has access to platform properties
* me
Paraphrasing our meeting notes today:
* currently www/ has to have config.xml inside it, docs inside it, README
etc
* merges folder is already a sibling of www/ but its logically part of the
app.
* So, why not move everything that isn't the actual assets of the app
itself out of www?
* Option
Ya love it. =)
On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj wrote:
> Agree with everything Braden said
>
> On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote:
>
>>+1 for ./platforms becoming a build artifact.
>>
>>That is already how we are attempting to roll in our project using the
>>cli, though
As Tommay pointed out, you need to create the cordova project structure in
the first place with some manner of tool..
On 3/22/13 11:58 AM, "tommy-carlos Williams" wrote:
>I don't have much to add except that I really like this about Grunt.
>
>However, it would get "interesting" with Cordova sinc
Hmm, but then the versioning of the core plugins is tied to the version of
your cordova-cli tool at install time?
I'm not opposed to installing cordova-core plugins by default which can
optionally be used as a fallback when or something, but I'm not sure that
every app you create should by default
Maybe a good first stab at this (and maybe this works already), is to
ensure multiple versions of CLI can be installed at the same time.
e.g.
/usr/loca/cordova-cli/2.4
/usr/loca/cordova-cli/2.5
/usr/loca/cordova-cli/2.6
The global symlink in /usr/local/bin would point to the latest, but your
pro
Agree with everything Braden said
On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote:
>+1 for ./platforms becoming a build artifact.
>
>That is already how we are attempting to roll in our project using the
>cli, though its not quite right yet.
>
>On 23/03/2013, at 5:26, Braden Shepherdson wrot
Yeah, this was a concern for me as well, but I figured I'd wait and see
what the pull request looked like to know whether it would be a hard thing
to maintain.
- Could you call requestFocusFromTouch() on your other component after the
WebView calls it?
On Fri, Mar 22, 2013 at 2:50 PM, Joe Bowser
Good question.
My intuition is saying for as long as 3.x is around we preload w/ core
plugins. We'll do as such w/ the PhoneGap distribution to minimize
pain. Once ppl are used to the tools they'll be asking for us to
default to none.
My thoughts where that we'd start that way w/ Cordova but that
It's under cordova-labs' jira branch.
Start at line 151 of jira.js [1]. Increment the num_callbacks var. Check
out the flow a little bit to get an idea of what you need to do. Then
copy/paste to add the new subtasks.
Cathc me on gtalk if you have more qs.
[1]
https://git-wip-us.apache.org/repos
If you previously cloned platforms and plugins into some global location,
you should be able to create a new HelloWorld app while offline, by using
--link (for both platforms and plugins).
Does that work?
On Fri, Mar 22, 2013 at 3:51 PM, Andrew Grieve wrote:
> Yep, my biggest concern is that w
Just for clarity's sake, I want to point out that this would add a new
dependency to cordova-android as a standalone project. Worth taking that
into consideration.
On 3/22/13 11:00 AM, "Anis KADRI" wrote:
>0
>
>
>On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote:
>
>> Thoughts? I'm down. But
Thats awesome ;)
On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote:
> Yeah Michal,
>
> That is the exact use case I had in mind. When we were a startup we
> couldn't afford mac's so just used linux and ripple for all our contract
> work and borrowed a friends macbook when we needed to compile
Yep, my biggest concern is that we are able to use CLI but still work
against master. I think braden's ask covers that though.
What good is working offline if you have no plugins? Are you suggesting
that we also include some set of plugins inside of cordova-cli?
On Fri, Mar 22, 2013 at 2:13 PM
Yeah Michal,
That is the exact use case I had in mind. When we were a startup we
couldn't afford mac's so just used linux and ripple for all our contract
work and borrowed a friends macbook when we needed to compile.
On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny wrote:
> Very interesting. Co
(1) That seems useful (eg. install plugin_foo and plugin_foo_test in one
command). Maybe, by default, omitting the `--name` parameter could install
all plugins found in the specified repo/hash.
(2) I think there's theoretical value in this, but cloning is somewhat
cheap so it's probably not wort
Huge +1.
Questions:
1. Could we allow installing multiple plugins/subdirectories from within
the same repo in one step. Support wildcards? (i.e. cordova plugin add
--repo=git --version=hash --name="*")
2. Should we cache git repos so we dont need clone over and over for each
plugin and app.
Very interesting. Combined with Bradens proposal to support pointing to a
local platform, looks very good.
Also note, offline isn't the only reason, platform support on a given
machine as well: ie, can "test" iPhone (sorta) on a linux box through
Ripple.
On Fri, Mar 22, 2013 at 2:15 PM, Brian L
+1 for ./platforms becoming a build artifact.
That is already how we are attempting to roll in our project using the cli,
though its not quite right yet.
On 23/03/2013, at 5:26, Braden Shepherdson wrote:
> We want this to stick around. One of my goals for the CLI is to make the
> platforms/f
I don't have much to add except that I really like this about Grunt.
However, it would get "interesting" with Cordova since the global is what
creates a project in the first place. I still think it could work and have the
global only responsible for creating dirs and setting up package.json stu
Should the universe just keep a copy of a plugin.xml so that it can have a
list of plugin dependancies and everything? plugin.xml will already have a
list of compatible cordova versions, right?
Then the universe can manage a reverse mapping if it wants fast access.
-Michal
On Fri, Mar 22, 2013
-1
I don't want anything public until we have a process to decide on what
we should or should not support. We've been burned in the past by
making certain things public, and then not being able to change those
methods because someone somewhere depends on it for their app.
Architectural flexibilit
Here are the meeting notes:
Meeting Notes
1.
Fil describing the tools
-
command line tools, readme from github
-
application assets are platform agnostic
-
platform, plugin, prepare, compile, build, emulate, serve
-
www/config.xml descripti
Hi Fil,
Since cordova-osx is functional now -- how do I add JIRA tasks to the
script (not sure where it is exactly) you used to add subtasks for a
release? I want to add "Update www/ application for OS X" and "Update
JavaScript for OS X" sub-tasks.
On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wro
I don't think we can put unused platforms in the Apache Attic - I think its
for complete projects AFAIK
http://attic.apache.org/
On Fri, Mar 22, 2013 at 11:22 AM, Lorin Beer wrote:
> +1
>
> @Jesse
> >The attic sounds like its where you put code you're ashamed of.
>
> I prefer to look at it as th
This has all of my +1s. Especially if our testing story is a dependent
plugin, this is way more convenient than two repos.
Braden
On Fri, Mar 22, 2013 at 2:19 PM, Brian LeRoux wrote:
> I'm into it.
>
> On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren wrote:
> > The main technical ask here is th
We want this to stick around. One of my goals for the CLI is to make the
platforms/foo subdirectories completely build artifacts. Native code, web
assets, JS code, all get copied on every prepare. That's not currently true
for native code, but it is for the rest.
Since we're doing that, we need th
+1
@Jesse
>The attic sounds like its where you put code you're ashamed of.
I prefer to look at it as the place to put code that you don't want getting
in the way, or biting guests to your home.
On Thu, Mar 21, 2013 at 11:49 PM, Jesse MacFadyen
wrote:
> +1 to negligence, or might it be ignoranc
I've messed around with programmatic view manipulation in native apps, on
droid and iOS primarily. There's no reason that I'm aware of that these
methods need to be private, and making sure that plugins/native code can
change the view layout is important for overall architecture flexibility.
It may
I'm into it.
On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren wrote:
> The main technical ask here is the ability to specify a plugin as { git
> repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
>
> On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
>
>> Would have the
omg I just realized this would fulfill offline use case vs lazy load vendoring
caching could be a future thing
might be a really nice path
On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner wrote:
> +1
>
> With this I would want to add the ability to add a platform to a project even
> if we don't h
That is, specify a *version* of a plugin that way.
On Fri, Mar 22, 2013 at 2:11 PM, Max Woghiren wrote:
> The main technical ask here is the ability to specify a plugin as { git
> repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
>
> On Fri, Mar 22, 2013 at 2:05 PM, B
It big. Certainly would be more efficient to lazy load, and cache so
offline works.
On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner wrote:
> There was some issues over download size for our cli, any idea what the size
> of all the platforms are?
>
> Sent from my iPhone
>
> On 2013-03-22, at 1:42 P
1 - 100 of 125 matches
Mail list logo
