If it does work to put the values in a sibling file to strings.xml,
you can use <source-file> to copy you own file into res/values which
will then not be re-added on each prepare.
On Wed, Jan 8, 2014 at 8:02 PM, Ross Gerbasi <rgerb...@gmail.com> wrote:
> Hello all, back on this Android plugin resource issue again.
>
> My original plan to ask users to edit strings.xml has hit a wall. Currently
> I have an entry in my plugin.xml that looks like this
>
> <config-file target="res/values/strings.xml" parent="/resources">
> <string name="app_launch_voice_trigger">hello cordova</string>
> <string name="app_launch_voice_prompt">prompt question</string>
> </config-file>
>
> If I ask the user to then go edit strings.xml thats all well and good until
> they do a build. As soon as they build again the plugin adds these back in
> and the file ends up looking like this
>
> <?xml version='1.0' encoding='utf-8'?>
> <resources>
> <string name="app_name">AppName</string>
> <string name="app_launch_voice_trigger">customized voice
> trigger</string>
> <string name="app_launch_voice_prompt">customized question</string>
> <string name="app_launch_voice_trigger">hello cordova</string>
> <string name="app_launch_voice_prompt">prompt question</string>
> </resources>
>
> This negates whatever the user has entered, and causes all kinds of
> trouble. Does anyone have any other ideas on how to manage this? I need a
> way to allow a user to customize strings.xml, I would love for this to be a
> config in config.xml but having something added and telling the user to
> edit it would be at least something.
>
> The only option I can think of right now is to remove the string.xml config
> stuff from plugin.xml and tell users they have to manually edit strings.xml
> to even get there project to compile. In other words if they do not go add
> the triggers themselves it would not compile. Would be really nice to find
> a way around that though. Any ideas?
>
> thanks!
>
>
>
> On Thu, Jan 2, 2014 at 9:17 AM, Ross Gerbasi <rgerb...@gmail.com> wrote:
>
>> In your glass.xml example would you then advice a developer to edit
>> plugins/res/xml/glass.xml? I don't fully understand how plugman is going to
>> work with this setup. Would glass.xml be copied to
>> platforms/android/res/xml/glass every time you did a build? I am assuming
>> it will only be appended when you add the platform.
>>
>> I am sorry for the "other users" confusion. I am not saying anything about
>> per user apps or multiple apps at all. When I say users i mean multiple
>> developers. If you have a team of 5 developers all working on an app
>> together and they are sharing the source code for your project. They all
>> need to be in sync with plugins and any config variables plugins will carry
>> with them. Ideally the plugins folder and the platforms folder would be
>> ignored from version control so that really leaves config.xml to hold these
>> variables. I still think we need some system in place for a plugin to get
>> variables from config.xml and apply them before every build.
>>
>>
>>
>>
>> On Thu, Jan 2, 2014 at 5:36 AM, Axel Nennker <ignisvul...@gmail.com>wrote:
>>
>>> you are right. The variable stuff is not working as I expected. Sorry for
>>> the confusion.
>>> I made another error because I thought that "<resource-file" was already
>>> available but it is not.
>>> I thought that
>>>
>>> <plugin ...>
>>> <platform name="android" >
>>> <resource-file src="glass.xml" dest="xml/glass.xml" />
>>> </platform>
>>> </plugin>
>>>
>>> was available and that plugman would move glass.xml from to
>>> plugins/res/xml/glass.xml and then replace a variable inside glass.xml
>>> with
>>> a specified value. That way the value would stay in
>>> plugins/res/xml/glass.xml when you remove the platform. And then it would
>>> be moved to platforms/android/res/xml/glass.xml again when you re-add the
>>> platform.
>>>
>>> I appended this code to
>>>
>>> /usr/local/lib/node_modules/cordova/node_modules/plugman/src/platforms/android.js
>>> "resource-file":{
>>> install:function(el, plugin_dir, project_dir) {
>>> var src = el.attrib.src;
>>> var target = el.attrib.target;
>>> var dest = path.join("res", target);
>>> common.copyFile(plugin_dir, src, project_dir, dest);
>>> },
>>> uninstall:function(el, project_dir) {
>>> var target = el.attrib.target;
>>> var dest = path.join("res", target);
>>> common.removeFile(project_dir, dest);
>>> }
>>> }
>>>
>>> Now the resource file "glass.xml" is copied to
>>> platforms/android/res/xml/glass.xml
>>>
>>> -Axel
>>>
>>> I still do not understand the "user" part of your last email because
>>> cordova is helping developers to build one app for many users. Everyone of
>>> your glass users gets the same app and if Glass lets not allow you to
>>> specify the listen command other than at build-time then you cannot change
>>> it without building a per-user app, right?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2014/1/1 Ross Gerbasi <rgerb...@gmail.com>
>>>
>>> > Other users would be team members that are working on the project with
>>> you
>>> > via git or svn or something.
>>> >
>>> > Just to confirm if you run cordova platform remove android in your
>>> example
>>> > then run cordova platform add android again it applies the variable to
>>> the
>>> > new android project?
>>> >
>>> > So the whole thing would be
>>> >
>>> > cordova create GlassApp
>>> > cd GlassApp
>>> > cordova platform add android
>>> > cordova plugin add plugin_id --variable key=value
>>> > cordova platform remove android
>>> > cordova platform add android
>>> >
>>> > You see the variable applied in the new android project?
>>> >
>>> > If this does work like you say what would you then suggest if the user
>>> then
>>> > wants to change this value? They have to remove and re-add the plugin
>>> > again? it just seems like this should be in config.xml.
>>> >
>>> >
>>> >
>>> > On Wed, Jan 1, 2014 at 2:32 PM, Axel Nennker <ignisvul...@gmail.com>
>>> > wrote:
>>> >
>>> > > I don't understand the "other users"-part.
>>> > >
>>> > > Not sure about the "mess" part. I looked at the plugman code and it
>>> looks
>>> > > ok.
>>> > > The plugin in <project_root>/plugins/glass_root has the modified
>>> resource
>>> > > files with "OK Glass" or whatever.
>>> > > It should not matter whether you add the plugin before or after the
>>> > > platform. Cordova takes the files from <project_root>/plugins and
>>> applies
>>> > > them to the platform files.
>>> > >
>>> > > My project layout is as this:
>>> > > <project_root>
>>> > > - src/plugins/glass_root
>>> > > - src/www
>>> > >
>>> > > This (src) is all that is in my source code repository. Now I have an
>>> ant
>>> > > script that creates the project, adds the platform and the plugins.
>>> > > cordova create GlassApp
>>> > > # and move src/www to www
>>> > > cordova platform add Android
>>> > > cordova plugin add plugin_id --variable key=value
>>> > >
>>> > > Afterwards the <project_root> looks like this (in addtion to the src
>>> > > dirctory)
>>> > > - www
>>> > > - plugins/plugin_id/res/values/glass.xml
>>> > > - platforms/android/...
>>> > >
>>> > > Now you can build the app and run it (for one "OK Glass" phrase). If
>>> you
>>> > > need a second/third phrase you need to uninstall the plugin and
>>> reinstall
>>> > > it with the new phrase. Did you mean this with "other users"?
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > 2014/1/1 Ross Gerbasi <rgerb...@gmail.com>
>>> > >
>>> > > > Variable was a mess. You can add a variable when you add a plugin
>>> so if
>>> > > you
>>> > > > worked this way all was ok
>>> > > >
>>> > > > -- create cordova project
>>> > > > -- add android platform
>>> > > > -- add plugin with variable
>>> > > >
>>> > > > but if you do it on a different order like
>>> > > >
>>> > > > -- create cordova project
>>> > > > -- add plugin with variable
>>> > > > -- add android platform
>>> > > >
>>> > > > Essentially if you removed your android project and re-add it after
>>> you
>>> > > > have the plugin, everything goes to hell.
>>> > > >
>>> > > > It doesn't work properly. It also isn't a good solution in the long
>>> run
>>> > > as
>>> > > > we are hoping in the future to ignore plugins and platforms from
>>> > version
>>> > > > control. If that happens we would then have a plugin manifest that
>>> > would
>>> > > > install plugins for other users. We would then have to store any
>>> > > variables
>>> > > > in this manifest so other users can get an "exact" copy, just seems
>>> > like
>>> > > a
>>> > > > whole bunch of headaches. Ideally this needs to be a config
>>> variable.
>>> > > >
>>> > > > hope this all makes sense :/
>>> > > >
>>> > > >
>>> > > > On Wed, Jan 1, 2014 at 11:52 AM, Axel Nennker <
>>> ignisvul...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > Didn't you solve this with --variable?
>>> > > > > I never used --variable myself.
>>> > > > > -Axel
>>> > > > > Am 01.01.2014 18:24 schrieb "Ross Gerbasi" <rgerb...@gmail.com>:
>>> > > > >
>>> > > > > > That would work great if there was a way to set the property I
>>> need
>>> > > at
>>> > > > > > runtime. Currently there does not seem to be a way to set the
>>> app
>>> > > > launch
>>> > > > > > voice trigger string at runtime. Probably because Glass needs
>>> this
>>> > > > > trigger
>>> > > > > > before your application even launches. This trigger will show up
>>> > in a
>>> > > > > menu
>>> > > > > > inside glass so it must be parsing my application to find this.
>>> > > > > >
>>> > > > > > This is why I need that variable set at build time, because
>>> there
>>> > > does
>>> > > > > not
>>> > > > > > seem to be a way, via code, to set this property.
>>> > > > > >
>>> > > > > > I am not sure if you can see this link without being a glass
>>> > explorer
>>> > > > but
>>> > > > > > here it goes anyway
>>> > > > > > https://developers.google.com/glass/develop/gdk/input/voice
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > On Wed, Jan 1, 2014 at 11:18 AM, Axel Nennker <
>>> > ignisvul...@gmail.com
>>> > > >
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > I am not sure why you need to modify my_val at build time.
>>> Could
>>> > > you
>>> > > > > > please
>>> > > > > > > change your example so that you really need this at build
>>> time?
>>> > > > > > >
>>> > > > > > > If you want a "product name displayed in your glass app then
>>> you
>>> > > > could
>>> > > > > > use
>>> > > > > > > the <preference like in your example and fetch the value from
>>> the
>>> > > > > > > activity's extras. All preferences from config.xml are passed
>>> in
>>> > > into
>>> > > > > > your
>>> > > > > > > activity as extras. Just use getStringExtra("PRODUCT_NAME") to
>>> > get
>>> > > it
>>> > > > > and
>>> > > > > > > use the value "foo" in your activity/plugin.
>>> > > > > > >
>>> > > > > > > With this you do not need the "variable" at build time because
>>> > you
>>> > > > get
>>> > > > > it
>>> > > > > > > at run time.
>>> > > > > > >
>>> > > > > > > -Axel
>>> > > > > > >
>>> > > > > > > You get the extras in onNewIntent and in initialize.
>>> > > > > > >
>>> > > > > > > @Override
>>> > > > > > > public void onNewIntent(Intent intent) {
>>> > > > > > > Log.d(TAG, "NewIntent " + getIntent());
>>> > > > > > > Bundle extras = intent.getExtras();
>>> > > > > > > if (extras != null && extras.size() > 0) {
>>> > > > > > > for (String key : extras.keySet()) {
>>> > > > > > > Log.d(TAG, "KEY=" + key);
>>> > > > > > > }
>>> > > > > > > } else {
>>> > > > > > > Log.d(TAG, "onNewIntent intent does NOT have extras");
>>> > > > > > > }
>>> > > > > > > ......
>>> > > > > > > }
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > public void initialize(CordovaInterface cordova,
>>> CordovaWebView
>>> > > > > webView)
>>> > > > > > {
>>> > > > > > >
>>> > > > > > > Bundle extras = cordova.getIntent().getExtras();
>>> > > > > > >
>>> > > > > > > }
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > 2014/1/1 Ross Gerbasi <rgerb...@gmail.com>
>>> > > > > > >
>>> > > > > > > > Alrighty I can get on board with the separate xml file but I
>>> > was
>>> > > > not
>>> > > > > > > > concerned about the android build system parsing the res
>>> file I
>>> > > am
>>> > > > > > > worried
>>> > > > > > > > about cordova setting the res file prior to building. What
>>> > would
>>> > > be
>>> > > > > the
>>> > > > > > > > user workflow for this? Ideally it needs to be something
>>> like
>>> > > > > > > >
>>> > > > > > > > - run add plugin
>>> > > > > > > > - add preference to config.xml
>>> > > > > > > > - run build android project
>>> > > > > > > > - CLI, prior to executing build, modifies RES file with
>>> > > preference
>>> > > > > set
>>> > > > > > in
>>> > > > > > > > config.xml
>>> > > > > > > > - android project is built
>>> > > > > > > >
>>> > > > > > > > In order to do this we need some way of hooking into the
>>> build
>>> > > > > process
>>> > > > > > > from
>>> > > > > > > > a plugin.
>>> > > > > > > >
>>> > > > > > > > I like Andrews idea of allowing a config file to load a
>>> > variable
>>> > > we
>>> > > > > > would
>>> > > > > > > > also need a way to make this happen at build time possible
>>> via
>>> > a
>>> > > > > > 'build'
>>> > > > > > > > flag? We could then check that resource, see if there is a
>>> > > matching
>>> > > > > > > > element, if not add it. Something like this.
>>> > > > > > > >
>>> > > > > > > > plugin.xml
>>> > > > > > > > <config-file target="res/values/strings.xml" parent="/*"
>>> > > > > build="true">
>>> > > > > > > > <string name="my_val">{$PRODUCT_NAME}</string>
>>> > > > > > > > </config-file>
>>> > > > > > > >
>>> > > > > > > > config.xml:
>>> > > > > > > > <preference name="PRODUCT_NAME" value="foo" />
>>> > > > > > > >
>>> > > > > > > > Then you can combine this with Axels suggestion and just
>>> change
>>> > > the
>>> > > > > > > target
>>> > > > > > > > of the config-file to glass.xml and add it as a resource at
>>> > > plugin
>>> > > > > add.
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > On Wed, Jan 1, 2014 at 1:37 AM, Axel Nennker <
>>> > > > ignisvul...@gmail.com>
>>> > > > > > > > wrote:
>>> > > > > > > >
>>> > > > > > > > > Every res file is parsed by the Android build system at
>>> apk
>>> > > build
>>> > > > > > time.
>>> > > > > > > > > It is a good practice to group e.g. related string
>>> resources
>>> > in
>>> > > > > > > separate
>>> > > > > > > > > files instead of munching everything into strings.xml. It
>>> > > doesn't
>>> > > > > > > matter
>>> > > > > > > > > whether this is a non-cordova Android project or a cordova
>>> > > > plugin.
>>> > > > > > > > >
>>> > > > > > > > > Axel
>>> > > > > > > > > Am 31.12.2013 22:42 schrieb "Ross Gerbasi" <
>>> > rgerb...@gmail.com
>>> > > >:
>>> > > > > > > > >
>>> > > > > > > > > > When would this happen though? Resources seem to be
>>> applied
>>> > > > when
>>> > > > > > you
>>> > > > > > > > add
>>> > > > > > > > > a
>>> > > > > > > > > > plugin or when you add a platform and a plugin already
>>> > > exists.
>>> > > > We
>>> > > > > > > need
>>> > > > > > > > to
>>> > > > > > > > > > allow the user a chance to edit this file. Would this
>>> > > resource
>>> > > > be
>>> > > > > > > > copied
>>> > > > > > > > > > every build?
>>> > > > > > > > > >
>>> > > > > > > > > > The other issue I have with this is strings.xml is
>>> pretty
>>> > > > > standard
>>> > > > > > > for
>>> > > > > > > > > any
>>> > > > > > > > > > text in your android application, it seems a bit odd to
>>> > move
>>> > > > this
>>> > > > > > > > > > elsewhere.
>>> > > > > > > > > >
>>> > > > > > > > > > -ross
>>> > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > > > On Tue, Dec 31, 2013 at 2:31 PM, Brian LeRoux <
>>> b...@brian.io>
>>> > > > > wrote:
>>> > > > > > > > > >
>>> > > > > > > > > > > That's clean
>>> > > > > > > > > > > On Dec 31, 2013 12:09 PM, "Axel Nennker" <
>>> > > > > ignisvul...@gmail.com>
>>> > > > > > > > > wrote:
>>> > > > > > > > > > >
>>> > > > > > > > > > > > I suggest to introduce e.g. <resource-file
>>> > > src="glass.xml"
>>> > > > > > > > > > > > target="/res/xml/glass.xml/> for Android and other
>>> > > > platforms
>>> > > > > > that
>>> > > > > > > > > need
>>> > > > > > > > > > > it.
>>> > > > > > > > > > > > One platform already has it. Can't remember which.
>>> > > > > > > > > > > > Plugman would then add/remove that file.
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Axel
>>> > > > > > > > > > > > Am 31.12.2013 19:57 schrieb "Ross Gerbasi" <
>>> > > > > rgerb...@gmail.com
>>> > > > > > >:
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > > Thats not a bad idea, would we then inform the
>>> user
>>> > to
>>> > > > edit
>>> > > > > > the
>>> > > > > > > > > > > > plugin.xml
>>> > > > > > > > > > > > > after they add it? Remember we need user to be
>>> able
>>> > to
>>> > > > > > > customize
>>> > > > > > > > > > > > > PRODUCT_NAME somehow.
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > And editing strings.xml isn't horrible it just
>>> breaks
>>> > > > > > > abstraction
>>> > > > > > > > > of
>>> > > > > > > > > > a
>>> > > > > > > > > > > > > plugin. So if you edit it, then remove it it wont
>>> > > remove
>>> > > > > the
>>> > > > > > > > > entries
>>> > > > > > > > > > > you
>>> > > > > > > > > > > > > have modified. So when you add it again you have 2
>>> > and
>>> > > > that
>>> > > > > > > > throws
>>> > > > > > > > > an
>>> > > > > > > > > > > > > android compile error.
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > The other issue is with a team working together.
>>> If
>>> > we
>>> > > do
>>> > > > > not
>>> > > > > > > > want
>>> > > > > > > > > > > people
>>> > > > > > > > > > > > > checking plugins & platforms into source control
>>> then
>>> > > > other
>>> > > > > > > team
>>> > > > > > > > > > > members
>>> > > > > > > > > > > > > need to add all the plugins themselves and they
>>> would
>>> > > > then
>>> > > > > > need
>>> > > > > > > > to
>>> > > > > > > > > > > modify
>>> > > > > > > > > > > > > the xml file in the same way. Not major but again
>>> > just
>>> > > > > these
>>> > > > > > > > little
>>> > > > > > > > > > > > > branches that pop up. Would be cool if we could
>>> > tighten
>>> > > > it
>>> > > > > up
>>> > > > > > > > with
>>> > > > > > > > > > some
>>> > > > > > > > > > > > > solution.
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > On Tue, Dec 31, 2013 at 12:34 PM, Andrew Grieve <
>>> > > > > > > > > > agri...@chromium.org
>>> > > > > > > > > > > > > >wrote:
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > > Tough call on this one. I'm a bit wary of
>>> letting
>>> > > > plugins
>>> > > > > > > > install
>>> > > > > > > > > > > > hooks,
>>> > > > > > > > > > > > > > because that power could be abused.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > Maybe we could allow variables to be used by
>>> > > > plugin.xml.
>>> > > > > > > E.g.:
>>> > > > > > > > > > > > > > <config-file target="res/values/strings"
>>> > > > > > > parent="/*"><string
>>> > > > > > > > > > > > > >
>>> > name="my_val">{$PRODUCT_NAME}</string></config-file>
>>> > > > > > > > > > > > > > and in config.xml:
>>> > > > > > > > > > > > > > <preference name="PRODUCT_NAME" value="foo"
>>> />
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > That said, I don't think it's that bad to tell
>>> > users
>>> > > to
>>> > > > > > edit
>>> > > > > > > > > their
>>> > > > > > > > > > > > > > strings.xml file.
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > On Tue, Dec 31, 2013 at 11:50 AM, Ross Gerbasi <
>>> > > > > > > > > rgerb...@gmail.com
>>> > > > > > > > > > >
>>> > > > > > > > > > > > > wrote:
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > Hello all,
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > I am trying to work through the best solution
>>> to
>>> > > this
>>> > > > > > > problem
>>> > > > > > > > > > > figured
>>> > > > > > > > > > > > > it
>>> > > > > > > > > > > > > > > was smart to bring it up to everyone here.
>>> Maybe
>>> > > > there
>>> > > > > > is a
>>> > > > > > > > way
>>> > > > > > > > > > to
>>> > > > > > > > > > > > > handle
>>> > > > > > > > > > > > > > > this but I haven't come across it.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > This problem came up in my Google Glass plugin
>>> > but
>>> > > I
>>> > > > am
>>> > > > > > > sure
>>> > > > > > > > > > other
>>> > > > > > > > > > > > > > plugins
>>> > > > > > > > > > > > > > > will need to handle this also.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > In the strings.xml resource we need to set a
>>> > "voice
>>> > > > > > > trigger"
>>> > > > > > > > > > > element
>>> > > > > > > > > > > > > > which
>>> > > > > > > > > > > > > > > is used to start the app when you talk to
>>> glass.
>>> > > > There
>>> > > > > > > > doesn't
>>> > > > > > > > > > seem
>>> > > > > > > > > > > > to
>>> > > > > > > > > > > > > be
>>> > > > > > > > > > > > > > > any way to do this with code and this string
>>> > would
>>> > > be
>>> > > > > > > > different
>>> > > > > > > > > > for
>>> > > > > > > > > > > > > ever
>>> > > > > > > > > > > > > > > app out there. On top of that each voice
>>> trigger
>>> > > can
>>> > > > > > > > optionally
>>> > > > > > > > > > > have
>>> > > > > > > > > > > > > > > prompts that follow it, to get more user
>>> input.
>>> > > > > > Currently I
>>> > > > > > > > > just
>>> > > > > > > > > > > > inform
>>> > > > > > > > > > > > > > the
>>> > > > > > > > > > > > > > > user via documentation to go edit this xml
>>> file
>>> > > after
>>> > > > > > they
>>> > > > > > > > > > install
>>> > > > > > > > > > > > the
>>> > > > > > > > > > > > > > > plugin.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > This is not good though because once they do
>>> that
>>> > > it
>>> > > > is
>>> > > > > > > > > unhooked
>>> > > > > > > > > > > from
>>> > > > > > > > > > > > > the
>>> > > > > > > > > > > > > > > plugin add/remove workflow. if they remove the
>>> > > plugin
>>> > > > > > those
>>> > > > > > > > xml
>>> > > > > > > > > > > > > elements
>>> > > > > > > > > > > > > > > stay, and then if they add the plugin back
>>> > > everything
>>> > > > > > > starts
>>> > > > > > > > to
>>> > > > > > > > > > > > become
>>> > > > > > > > > > > > > a
>>> > > > > > > > > > > > > > > mess.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > Essentially I need a way to write to a xml
>>> > > resources
>>> > > > > > > before a
>>> > > > > > > > > > user
>>> > > > > > > > > > > > > does a
>>> > > > > > > > > > > > > > > build. I also need to be able to access a
>>> config
>>> > > > file,
>>> > > > > > > > probably
>>> > > > > > > > > > > > > > config.xml,
>>> > > > > > > > > > > > > > > in order to get the information to write to
>>> this
>>> > > > > > resource.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > I am thinking maybe we allow plugins to have
>>> > hooks
>>> > > > > also?
>>> > > > > > So
>>> > > > > > > > > each
>>> > > > > > > > > > > > plugin
>>> > > > > > > > > > > > > > > could have a hooks folder, which would then
>>> allow
>>> > > > every
>>> > > > > > > > plugin
>>> > > > > > > > > to
>>> > > > > > > > > > > run
>>> > > > > > > > > > > > > > > before build commands. I could then open that
>>> > > > resource,
>>> > > > > > > grab
>>> > > > > > > > > the
>>> > > > > > > > > > > > > element
>>> > > > > > > > > > > > > > > and write the value in there before every
>>> build.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > Plugins do offer the ability to get variables
>>> > > during
>>> > > > > add
>>> > > > > > > with
>>> > > > > > > > > the
>>> > > > > > > > > > > > > > > --variable flag, but i found this to be a huge
>>> > > mess.
>>> > > > > > > > Especially
>>> > > > > > > > > > > when
>>> > > > > > > > > > > > > > > dealing with plugins that have dependent
>>> plugins
>>> > > that
>>> > > > > > need
>>> > > > > > > > > > > variables.
>>> > > > > > > > > > > > > It
>>> > > > > > > > > > > > > > > also is a problem if you install the plugin
>>> then
>>> > > add
>>> > > > > > > platform
>>> > > > > > > > > > after
>>> > > > > > > > > > > > it
>>> > > > > > > > > > > > > > was
>>> > > > > > > > > > > > > > > looking for variables at the wrong time.
>>> Anyway
>>> > > this
>>> > > > > > ended
>>> > > > > > > up
>>> > > > > > > > > > being
>>> > > > > > > > > > > > no
>>> > > > > > > > > > > > > > good
>>> > > > > > > > > > > > > > > for me.
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > I am all for any suggestions, and I can dive
>>> into
>>> > > the
>>> > > > > CLI
>>> > > > > > > > code
>>> > > > > > > > > > and
>>> > > > > > > > > > > > try
>>> > > > > > > > > > > > > to
>>> > > > > > > > > > > > > > > hack together something to get it working but
>>> I
>>> > > would
>>> > > > > > love
>>> > > > > > > to
>>> > > > > > > > > get
>>> > > > > > > > > > > > some
>>> > > > > > > > > > > > > > > direction. Any ideas?
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > > > -ross
>>> > > > > > > > > > > > > > >
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
