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.
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
>