On 2012-08-14, at 7:37 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Really the usual stuff - that we then need to specify the version of
the IDE to use quite specifically, and we have to change the project files when the IDE
updates. Furthermore, typically changes to IDE project files tend to get forgotten.
I dont think there is a better way though.
I suppose it also relates to whether Cordova is a progressive enhancement (you can write
a browser app, and reuse it as a native app) or whether it's a strand in it's own
right.
That is some we'll have to think about. I don't think that the fundamental
purpose of Cordova is progressive enhancement. Getting it's full value means using the
Cordova API which means breaking with web deployment. It's more about having the means
for writing completely portable (across mobile platforms) applications using HTML5. Now I
can see a scenario where you share code with a web application (and that's interesting
enough to warrant an exploration because I think it's a problem that a lot of
dev's have or will have), but generally speaking, the move is uni-directional
(web->hybrid).
On 13 Aug 2012, at 16:54, Marius Bogoevici wrote:
> Pete, can you voice your misgivings specifically?
>
> I'll begin: I have mixed feelings about SCM. The idea on a typical Android
SDK/iOS project is that project sources will be checked in. However, these are not typical
projects, given how they are really rather thin wrappers, basically the result of a
"getting started" process, so we could just go away with a tutorial, like we did
with Forge. The main difference is that, unlike the Forge stuff, once the Cordova
projects are generated, the current generated projects can stay as they are (I don't
see this as very easy to break ATM) unless we change the index files.
>
> On top of that, I have made changes to the original 'getting started', so I
wanted to capture that as well. My motivations of putting this in SCM is
>
> a) To have a baseline on the structure
> b) To show the customizations that need to be made to generated projects (customized
entry points for Android/iOS, using the alternative indexes)
>
>
>
>
> On 2012-08-13, at 11:39 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>> But I don't have a better answer right now. I'm just calling it out as a
(major) issue.
>>
>> On 13 Aug 2012, at 16:39, Pete Muir wrote:
>>
>>> I really don't like keeping the project files in SCM.
>>>
>>> On 13 Aug 2012, at 14:24, Marius Bogoevici wrote:
>>>
>>>> All,
>>>>
>>>> I added a candidate structure for the hybridized TicketMonster - it's
based on the Aerogear kitchensink with the added twist that we keep separate index files
for each device, and then refer directly to those files from the wrapper code. While not
ideal, this allows to keep separate configurations (i.e. dependencies for each device) and
avoid manual changes after opening a particular device project.
>>>>
>>>> An alternative would be to use maven to construct
target/www-<device> folders and use symlinks to those. I don't like it because
>>>>
>>>> - doesn't work well with the web configurations;
>>>> - you can't easily create fixes from Xcode/Android SDK to the web app
code, because you need to run the build phase manually after.
>>>>
>>>> Let the reviews begin!
>>>>
>>>> Here it is:
>>>>
https://github.com/jboss-jdf/ticket-monster/pull/6
>>>> _______________________________________________
>>>> jdf-dev mailing list
>>>> jdf-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>>>
>>>
>>> _______________________________________________
>>> jdf-dev mailing list
>>> jdf-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>>
>