@Mark, if you use Maven, then artifacts in the poms are all what you need, so maven takes care of pulling all right dependencies you need.
@Alex, about extending IUIBase, my own experience is that beads are a very good way to extend/compose more code you need, but extending core interfaces like the one you said is not the case. Let me put you an example: For Jewel I use "StyledUIBase" that extends "UIBase" to add IClassSelectorListSupport, the css CRUD API (addClass, removeClass, etc..): public class StyledUIBase extends UIBase implements IClassSelectorListSupport This makes that some components are easy to extend but others need to be recreate. There are lots of cases in Jewel where I need to If you search in Jewel for implements IClassSelectorListSupport you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are implementing that class while, so they are not StyledUIBase in it's core are standard UIBase and at its level we implement the interface and add again all methods repeating the code. So we are duplicating that code all that times. I think this is one of the few things I don't like in Jewel, If you know some way to do this in a better way, I can change it thanks El lun., 29 abr. 2019 a las 12:36, Kessler CTR Mark J (<mark.kessler....@usmc.mil.invalid>) escribió: > Yeah just concerned with an official build number, or date, or > something with numbers we can use to identify a production app back to what > SDK was used to compile it. Imagine having an app released on production > and a user reports a problem. We would need to reproduce the problem in a > test environment. This would include using the same SDK to compile the > app. Currently in Flex, we can just access its version directly which > makes things faster. > > If the SDK doesn't have anything like this at the moment and we did > add that functionality in there, I would say let's just use a date field > since it could be automated. Something like YYYYMMDD type format. > > > -Mark K > > > -----Original Message----- > From: Alex Harui [mailto:aha...@adobe.com.INVALID] > Sent: Friday, April 26, 2019 12:02 PM > To: dev@royale.apache.org > Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale > version to 1.0) > > > > On 4/26/19, 4:29 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil.INVALID> > wrote: > > > So far, we have not had the release scripts properly generate the > right version number for the NPM artifacts. > > > This spurred a question for me. Is there a way to find out what > version number the SDK binaries are in code for Royale? Sort of like the > Flex SDK mx.core.FlexVersion or at least a build date? > > Not at this time. IMO, runtime versioning wasn't worth the cost of all of > those strings and code in the production app. Also, Royale was designed > from the beginning to try to be "version-agnostic". By using > loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces instead > of direct class references, there shouldn't be a need to deal with version > incompatibilities at runtime like Flex did with the Marshall Plan and > FlexVersion and more. > > Flex had to care about version incompatibilities because the fundamental > base classes were not loosely-coupled. Flex HelloWorld was 128K not just > because UIComponent was huge, but because UIComponent pulled in other > classes as init-time strongly-coupled dependencies. A good thing to think > about as you write Royale framework code is, "can every dependency be > easily replaced"? > > After we hit 1.0 (and hopefully find some volunteers to write regression > tests), then new APIs to existing classes will need to be considered > carefully and implemented in extensions. So there will be some extension > of IUIBase that has some new API instead of adding new APIs to IUIBase. I > have a personal preference to use long names instead of numbers, so the > extension will hopefully be called IUIBaseWithWhatever instead of IUIBase2. > > If you are asking about build-time versioning, we haven't done anything > there either. As long as there is no impact on production apps I think it > is fine for folks to contribute something if there is a need. > > My 2 cents, > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
