> I also think it should sub-shell to a platform script. We already have
> a `project template` folder in each platform. We can easily add a
> `plugin template` as well and write a quick create_plugin script.
>
> What do you guys think of the workflow I described above ? Any
> comments ? I can c
On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve wrote:
> Changes should sneak into dev, not master. Unless someone else messed
> something up, there shouldn't be any conflicts on master.
>
> I see what you're saying though. Sneaking a change into dev while you're
> testing would mess you up a bit.
Good point about "clobbers" not making a tonne of sense.
How about adding an alias:
For :
On Sat, Aug 31, 2013 at 12:57 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> > Is there any reason why the 'module name' isn't the plugin id (when
> loading
> > JavaScript):
> >
I'd like to do a release of plugins / tools tomorrow.
I can do the plugins, but probably someone more familiar with CLI / Plugman
should do them (Braden or Anis?).
I'm hoping we can end up with a "this week in Cordova" blog post with the
release notes by then end of it :)
On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny wrote:
>
>
>
> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
>>
>>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
>>> wrote:
>>>
>>> >
>>> >
>>> >
>>> > On Wed, Sep 4, 2013 at 2
Changes should sneak into dev, not master. Unless someone else messed
something up, there shouldn't be any conflicts on master.
I see what you're saying though. Sneaking a change into dev while you're
testing would mess you up a bit.
One option is to push after incrementing the version and writin
Personally, I don't think this should be built into the system; I see
nothing wrong with the workflow that Anis originally posted.
If all we ever did was write echo plugins, then this would make sense, but
IMHO, actually writing a plugin requires some time spent in each ./platform
As an example:
I
I don't think your attachment worked.
On Wed, Sep 4, 2013 at 5:03 PM, Brian LeRoux wrote:
> Composability being the big reasoning. Maybe that is a false consideration
> for our end users. I know I hate chatty tools (and I hate telling them to
> be quiet) and that could just be a preference from
I also think it should sub-shell to a platform script. We already have
a `project template` folder in each platform. We can easily add a
`plugin template` as well and write a quick create_plugin script.
What do you guys think of the workflow I described above ? Any
comments ? I can create jira iss
What is important is to make both quiet and verbose available. I don't
really have a strong opinion on the default. I do have a slight
preference for semi-verbosity by default.
On Wed, Sep 4, 2013 at 2:46 PM, Jonathan Bond-Caron
wrote:
> On Wed Sep 4 04:38 PM, Andrew Grieve wrote:
>>
>> You can a
On Wed Sep 4 04:38 PM, Andrew Grieve wrote:
>
> You can always use --quiet if you pipe our command and have it not output.
> Am I missing something about your use-case?
>
> We have a practical problem right now in that we get a lot of bad bug reports
> where we need to tell users to re-run with -
On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny wrote:
>
>
>
> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
>
>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
>> wrote:
>>
>> >
>> >
>> >
>> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve > >wrote:
>> >
>> >> Responses inline. For all of the
On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve wrote:
> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve
> wrote:
>
> >
> >
> >
> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve >wrote:
> >
> >> Responses inline. For all of them, I'll update the wiki to make things
> >> clear.
> >>
> >>
> >> On Tue
cd and rm don't make network requests. There's plenty of precedent for
outputting by default. zip, wget, rsync, apt-get, brew.
You can always use --quiet if you pipe our command and have it not output.
Am I missing something about your use-case?
We have a practical problem right now in that we ge
Composability being the big reasoning. Maybe that is a false consideration
for our end users. I know I hate chatty tools (and I hate telling them to
be quiet) and that could just be a preference from java scars.
Some very light reading attached from 'Classic Shell Scripting' regarding
UNIX tools p
Well, those aren't UNIX tools. Those are userland tools. (So are we, I
know.)
Imagine if `cd` output something every time you moved. Or rm was always
noisy. Super annoying. Anyhow, the book Classic Shell Scripting explains
this better than I. Recommended reading.
I'd rather our tools followed UNI
While I believe we could be able to specify everything with a single
parameter, I don't follow what problem we're trying to solve by doing so.
If I understand everything correctly we're comparing the following;
While both seem reasonable and I do like the first, this seems unnecessary.
O
The convention for UNIX tools is to be quiet by default and fail noisily. A
well writ script should exit quietly so you can chain commands. (Or pipe,
etc.)
I'd prefer we added a --verbose flag.
On Wed, Sep 4, 2013 at 12:35 PM, Braden Shepherdson wrote:
> I'd rather we call it -q and --quiet tho
I don't think that's really true for other similar tools.
E.g. "npm install" reports progress by default
E.g. "git clone" shows progress by default.
On Wed, Sep 4, 2013 at 3:51 PM, Brian LeRoux wrote:
> The convention for UNIX tools is to be quiet by default and fail noisily. A
> well writ scri
On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve wrote:
>
>
>
> On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve wrote:
>
>> Responses inline. For all of them, I'll update the wiki to make things
>> clear.
>>
>>
>> On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
>>
>>> For Strategy page:
>>>
>>> R
I'd rather we call it -q and --quiet though; that's a pretty common
convention for Unix tools.
On Wed, Sep 4, 2013 at 3:35 PM, Braden Shepherdson wrote:
> +1
>
>
> On Wed, Sep 4, 2013 at 3:31 PM, Andrew Grieve wrote:
>
>> I think this was discussed before but I can't find the thread.
>>
>> Is an
+1
On Wed, Sep 4, 2013 at 3:31 PM, Andrew Grieve wrote:
> I think this was discussed before but I can't find the thread.
>
> Is anyone not in favour of making the tools verbose by default and having a
> --silent flag instead?
>
> Makes it much easier to get good debug reports and lets users kno
+1 to silent flag
On Wed, Sep 4, 2013 at 12:31 PM, Andrew Grieve wrote:
> I think this was discussed before but I can't find the thread.
>
> Is anyone not in favour of making the tools verbose by default and having a
> --silent flag instead?
>
> Makes it much easier to get good debug reports an
I think this was discussed before but I can't find the thread.
Is anyone not in favour of making the tools verbose by default and having a
--silent flag instead?
Makes it much easier to get good debug reports and lets users know when
slow things are taking place.
Not quite, since the checked-out directories generally don't have the
".git" suffix; you'd have to override git's normal naming behavior when
cloning these.
I think that's quite a bit of delicate magic we don't need. I think src
might be a better name, if we wanted to go with a single parameter.
On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve wrote:
> Responses inline. For all of them, I'll update the wiki to make things
> clear.
>
>
> On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
>
>> For Strategy page:
>>
>> RE: Weekly Releases -- do we skip a release if there is nothing
>> signi
Responses inline. For all of them, I'll update the wiki to make things
clear.
On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
> For Strategy page:
>
> RE: Weekly Releases -- do we skip a release if there is nothing significant
> to push, or do we release so long as there is at least one pa
Here's another use-case:
- You have a github account
- You have one plugin per repo
- URLs look like: https://github.com/MobileChromeApps/AppBundle.git
- You want AppBundle to depend on
https://github.com/MobileChromeApps/zip.git
- You want this to work when you've got your plugins checked out for
Cool. Thanks.
Done!
On Wed, Sep 4, 2013 at 1:25 PM, Andrew Grieve wrote:
> Taking a look.
>
>
> On Tue, Sep 3, 2013 at 2:19 PM, Axel Nennker wrote:
>
>> Hi,
>>
>> could a committer please look at this pull request and maybe merge it into
>> master if ok?
>>
>> thanks
>> Axel
>>
>> https://github.com/apache/c
I'm not convinced that all use cases cannot be handled with a single
attribute. Maybe url / path are the wrong names, maybe a single src="".
On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson wrote:
> Sure, I can work with path="" instead. What happens if (when) a user
> supplies both?
>
>
> On
Taking a look.
On Tue, Sep 3, 2013 at 2:19 PM, Axel Nennker wrote:
> Hi,
>
> could a committer please look at this pull request and maybe merge it into
> master if ok?
>
> thanks
> Axel
>
> https://github.com/apache/cordova-plugman/pull/19
> https://issues.apache.org/jira/browse/CB-4430#comment
Sure, I can work with path="" instead. What happens if (when) a user
supplies both?
On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve wrote:
>
>
>
> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson
> wrote:
>
>> I believe the current logic is "a plugin with this ID is already
>> installed, so s
On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson wrote:
> I believe the current logic is "a plugin with this ID is already
> installed, so stop". That interacts badly with different versions.
>
> Braden
>
>
> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny wrote:
>
>> .. but either way if we add
I like the --force idea. I think we'll want that anyways for plugins that
didn't write their tags right.
On Wed, Sep 4, 2013 at 10:24 AM, Michal Mocny wrote:
> I really don't want to have to be semantically valid for version
> dependencies amongst contributors working on the bleeding edge on
>
I like where this is generally going, but I want to correct one mistake
Michal made. There /is/ a way to know which directory above a plugin is the
root. The code uses git to find the .git directory, which is taken to be
the root from which the subdir is relative. That means that in the case of
url
I believe the current logic is "a plugin with this ID is already installed,
so stop". That interacts badly with different versions.
Braden
On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny wrote:
> .. but either way if we add support for filesystem-relative paths and they
> work when fetching the
Jeffrey's point at the start of this thread is that he isn't using a git
repo locally, so there is no .git folder to find.
On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson wrote:
> I like where this is generally going, but I want to correct one mistake
> Michal made. There /is/ a way to know
.. but either way if we add support for filesystem-relative paths and they
work when fetching the original plugin either from git or locally, then we
are done.
As an aside, when a plugin lists its dependency as explicitly from a git
url, can the user somehow override that to install from a local c
I really don't want to have to be semantically valid for version
dependencies amongst contributors working on the bleeding edge on
unreleased branches. I'd be fine with just leaving the semantically
invalid engine values and make the dependency on "dev" implicit. However,
I would also support an
Maybe a plugin template ships with each platform, and when you "plugin
create" it merges the template for each platform you have installed?
That would mean you have to add all interested platforms before creating a
plugin.
-Michal
On Wed, Sep 4, 2013 at 10:22 AM, Ian Clelland wrote:
> On Tue,
I originally supported #1, because it makes development easier -- during
development, if you add features, you can update cordova-core from
"3.8-rc1" to "3.9-rc1", and then you can work on a corresponding plugin
that declares a dependency on "3.9-rc1".
Without doing this, you need to have your plu
On Tue, Sep 3, 2013 at 11:50 AM, Braden Shepherdson wrote:
> On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
> > Two new features could be useful from cli:
> > a) Create an initial plugin from a template
> > cordova plugin create [path] [name]
> >
> > e.g.
For now, yes, but we could extend that without breaking anything, no?
Right now url="../etc" would be invalid, so we could safely add support
for urls with leading "..", and make that relative to current plugin.
url="." would still do what it does today, but could likely be deprecated
along with
Because for the hosted case, the URL points to where the repo is, not to
where the plugin is.
On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny wrote:
> If URL can be relative, why do we need a new path parameter? All we would
> need is to treat leading ./ or ../ as relative to the plugin not root
id = pkgId + '_' + now.toISOString() will contain milliseconds
On Tue, Sep 3, 2013 at 11:33 PM, Andrew Grieve (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/CB-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757432#comment-13757432
+1 #2
On Wed, Sep 4, 2013 at 3:24 AM, Joe Bowser wrote:
> +1 for #2
>
> On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI wrote:
> > +1 for number 2
> >
> > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote:
> >> +1 for #2 as well
> >>
> >>
> >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson >
+1 Michal echoes my thoughts
On Wed, Sep 4, 2013 at 1:31 AM, Michal Mocny wrote:
> Volunteer maps well to hows its been done implicitly. If you cannot take a
> given week, find a sensible replacement.
>
> Rotation among willing folks makes some sense in terms of passing down of
> knowledge.
>
48 matches
Mail list logo
