So it looks like for iOS plugman support there is one outstanding issue
Shaz has:
https://issues.apache.org/jira/browse/CB-2717
Re: default installation of iOS code into plugins folder.
Braden Anis can you comment? This looks like it would need a tweak in
the spec so I would like to get other
Same position as Braden. We can always add this later. There are more
urgent issues right now like fixing the uninstall action and plugin
dependencies.
On Mon, Apr 15, 2013 at 10:46 AM, Braden Shepherdson bra...@chromium.orgwrote:
Hrm. I don't see specifying it as so terrible. It would also
I like the idea, but I think we should make sure that it will work before
pulling out the plugins. E.g. plugin JS undergo a different transformation
with the new system than with Jake. I think they'll function fine if we
pluginstall it into our project *templates*, but for people performing
To summarize:
- yes plugman needs more work before we can utilize standalone plugins.
We have several committers working on this. There are issues filed in JIRA
(mainly assigned to Braden, Tim and me). With this being the blocker to
moving to a bare bridge implementation of Cordova, anyone is
Fil,
I have some issues filed for plugman: http://cl.ly/O7Th
I'd like to contribute but since we have many cooks here, I don't know if I
will be treading on some code that is going to change anyway. Some of them
filed are critical for iOS, but not labeled with 'future'. Can you take a
quick glance
CB-2727 CB-2719 https://issues.apache.org/jira/browse/CB-2719 are
resolved shaz (in master not future). I will take care of CB-2717 CB-2718
this week.
On Sun, Apr 7, 2013 at 11:59 AM, Shazron shaz...@gmail.com wrote:
Fil,
I have some issues filed for plugman: http://cl.ly/O7Th
I'd like to
Thanks Anis and Fil! If you need help, I suppose you could assign some
starter issues so I can get a feel for the codebase
On Sun, Apr 7, 2013 at 5:33 PM, Filip Maj f...@adobe.com wrote:
I will take a look Shaz. I'll update that in a separate thread where we
can put more discussion into task
Is there currently a list of plugins that can be moved, i can start to move
some, but don't want to repeat what someone has done already
On Apr 3, 2013, at 3:53 PM, Brian LeRoux b...@brian.io wrote:
Agree w/ Anis. Just move what can be moved and file up tickets for
that which cannot be done
We should slow this process down a little bit. Our next step should be to
structure the plugins in the existing repos so that the process of
relocating them to their individual repos is straightforward. Trying to do
it as we go will be messy and lead to the types of problems that prompted
Joe to
I should add that in the meantime, we can still test plugman and cli with
some non-core plugins—for instance, chrome-cordova
pluginshttps://github.com/MobileChromeApps/chrome-cordova/have
already been pluginized.
On Fri, Apr 5, 2013 at 3:00 PM, Max Woghiren m...@chromium.org wrote:
We should
On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren m...@chromium.org wrote:
We should slow this process down a little bit. Our next step should be to
structure the plugins in the existing repos so that the process of
relocating them to their individual repos is straightforward. Trying to do
it as
I've updated the CorePlugins update page and added my initial
observations regarding moving the plugins over. I do agree that it
does feel like we're putting the cart before the horse, but assuming
that we want a 3.0 release, I don't see another option.
I agree with a lot of what you said.
On Fri, Apr 5, 2013 at 3:13 PM, Joe Bowser bows...@gmail.com wrote:
On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren m...@chromium.org wrote:
We should slow this process down a little bit. Our next step should be
to
structure the plugins in the existing
Warning: ** I'm not suggesting it, I'm not proposing it ** but, I'll chime
in to say that we could still potentially ship 3.0 entirely using the new
plugin architecture but without splitting core plugins into individual
repos. We could move them out of cordova-js, but still keep them together
in
I agree that moving plugins into repos isn't tied to API audits, but
doesn't moving plugins gradually prevent our ability to do releases? E.g.
2.7 is missing two plugins since they were moved into different repos.
On Fri, Apr 5, 2013 at 4:20 PM, Brian LeRoux b...@brian.io wrote:
That synopsis
Those should be rolled back in by the COHO tool (using the plugman tool)
for the phonegap dist.
On Fri, Apr 5, 2013 at 1:24 PM, Andrew Grieve agri...@chromium.org wrote:
I agree that moving plugins into repos isn't tied to API audits, but
doesn't moving plugins gradually prevent our ability
Hey
I've started moving the various Android plugins into their
corresponding repositories, and it seems that these were made up, and
that they don't really correspond to what exists in the code today. I
don't think that it's realistic for us to get this done for 2.7
because there are certain
We can file infra requests to modify names / add more repos for plugins as
needed, so that shouldn't be an issue. Some plugins may not be completely
cross-platform (debug console, for example, will likely only have iOS
native code).
As for landing it all in 2.7: also not a big deal. We can try to
I think a good first pass is to plugin-ize what is plugin-izable and leave
everything else (platform specific code) as part of the 'core'
implementation. Things will never exactly be exactly the same across
platforms in my opinion.
On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser bows...@gmail.com
Agree w/ Anis. Just move what can be moved and file up tickets for
that which cannot be done in the immediate term / that is in the
'official' list of plugins.
On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI anis.ka...@gmail.com wrote:
I think a good first pass is to plugin-ize what is plugin-izable
Forgive me if this was already discussed, for the plugins:
1. cordova-plugin-device
2. cordova-plugin-network-information
deviceready event being dispatched will not be dependent on these two
anymore right? At least on iOS it is currently.
On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser
for netinfo, I think it's fine to not delay deviceready since we can just
set it to unknown at the start.
For device though, if we're not going to delay deviceready, then we should
remove the device symbol being exposed so that the only way to get to the
properties is through the async API. For
22 matches
Mail list logo
