You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Kessler CTR Mark J <ma...@usmc.mil.INVALID> on 2019/04/26 11:29:25 UTC
Version property (was: Let's bump Royale version to 1.0)
> 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?
-Mark K
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com.INVALID]
Sent: Friday, April 26, 2019 2:44 AM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0
I do not have an opinion on what technical/marketing criteria we use to decide which release to call 1.0. I'm not working directly with users/customers.
I do not currently have time/energy/budget to work on any of the things folks think need to be done to get to 1.0 and barely have enough time to work on getting the next release out. So someone else will have to supply the time/energy/budget to get these tasks done.
I do have an opinion based on a practical aspect. So far, we have not had the release scripts properly generate the right version number for the NPM artifacts. That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5. So I would say we should not call this next release 1.0 and wait until the release automation can correctly version all artifacts with the right version number before we pick one to call 1.0. With any luck I'll get the automation running next week and will ask for someone to volunteer to test drive it.
-Alex
Re: Version property (was: Let's bump Royale version to 1.0)
Posted by Mark Thomas <ma...@apache.org>.
I have no idea why this has been sent to me personally. I assume some
form of addressing error.
Mark
On 29/04/2019 16:41, Alex Harui wrote:
> @Mark, I'm assuming you want something in the output that identifies the actual versions used. In Royale, you may also need to identify the version of the transpiler as well, and maybe the version of Google Closure. If you want to propose (or better yet, implement) a PAYG way to do that in Royale, please do so. If other folks think this will be useful, please speak up so we get a sense of how important it is. A simple hack may be to embed the pom.xml file in your output as a string if you are using Maven. If you use Ant, you could grab the SDK version from build.properties or embed the flex-sdk-description.xml file.
>
> @Carlos, I couldn't understand your scenario. Feel free to start a separate thread on it. The key aspect, as a guess, is trying to avoid code that assumes that an instance is a subclass of a particular base class instead of an implementation of an interface.
>
> HTH,
> -Alex
>
> On 4/29/19, 7:29 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> @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
> (<ma...@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:aharui@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" <ma...@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
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C94fddf253e6b4a8b6ec208d6ccaf1219%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921449642861921&sdata=I4BGFaXHFOuk5lClNTySl6g0k%2Fo%2FM8weJkivqJQkgs8%3D&reserved=0
>
>
extending IUIBase with interfaces (was: Re: Version property (was:
Let's bump Royale version to 1.0))
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
initial problem is: I want to add to all jewel components (that use to have
UIBase as common class) a new interface and implement the methods. In
concrete interface is: IClassSelectorListSupport
So the expected result should be to make all Jewel components implement
IClassSelectorListSupport, but to avoid repeat code in all classes we need
a root for all the components.
Perfect point would be UIBase, but we can't add at that point for PAYG
reasons.
Current solution in Jewel is to create StyledUIBase that is
public class StyledUIBase extends UIBase
implements IClassSelectorListSupport
but this makes other classes like jewel Group that extend html Group have
UIBase in the hierarchical chain instead StyledUIBase, so we need to make
Group as this:
public class Group extends org.apache.royale.html.Group implements
IClassSelectorListSupport
same for
public class DataContainerBase extends
org.apache.royale.core.DataContainerBase implements
IClassSelectorListSupport
This make we have 3 classes that are duplicating the same exact code
implementing in the same maner addClass, removeClass, etc..
what can we do for this cases?
Hope is more clear now,
thanks
El lun., 29 abr. 2019 a las 17:41, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
> @Carlos, I couldn't understand your scenario. Feel free to start a
> separate thread on it. The key aspect, as a guess, is trying to avoid code
> that assumes that an instance is a subclass of a particular base class
> instead of an implementation of an interface.
>
> HTH,
> -Alex
>
> On 4/29/19, 7:29 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> @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
>
> --
Carlos Rovira
http://about.me/carlosrovira
Re: Version property (was: Let's bump Royale version to 1.0)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
@Mark, I'm assuming you want something in the output that identifies the actual versions used. In Royale, you may also need to identify the version of the transpiler as well, and maybe the version of Google Closure. If you want to propose (or better yet, implement) a PAYG way to do that in Royale, please do so. If other folks think this will be useful, please speak up so we get a sense of how important it is. A simple hack may be to embed the pom.xml file in your output as a string if you are using Maven. If you use Ant, you could grab the SDK version from build.properties or embed the flex-sdk-description.xml file.
@Carlos, I couldn't understand your scenario. Feel free to start a separate thread on it. The key aspect, as a guess, is trying to avoid code that assumes that an instance is a subclass of a particular base class instead of an implementation of an interface.
HTH,
-Alex
On 4/29/19, 7:29 AM, "Carlos Rovira" <ca...@apache.org> wrote:
@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
(<ma...@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:aharui@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" <ma...@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
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C94fddf253e6b4a8b6ec208d6ccaf1219%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921449642861921&sdata=I4BGFaXHFOuk5lClNTySl6g0k%2Fo%2FM8weJkivqJQkgs8%3D&reserved=0
Re: Version property (was: Let's bump Royale version to 1.0)
Posted by Carlos Rovira <ca...@apache.org>.
@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
(<ma...@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:aharui@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" <ma...@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
RE: Version property (was: Let's bump Royale version to 1.0)
Posted by Kessler CTR Mark J <ma...@usmc.mil.INVALID>.
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:aharui@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" <ma...@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
Re: Version property (was: Let's bump Royale version to 1.0)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 4/26/19, 4:29 AM, "Kessler CTR Mark J" <ma...@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
-Mark K
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com.INVALID]
Sent: Friday, April 26, 2019 2:44 AM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0
I do not have an opinion on what technical/marketing criteria we use to decide which release to call 1.0. I'm not working directly with users/customers.
I do not currently have time/energy/budget to work on any of the things folks think need to be done to get to 1.0 and barely have enough time to work on getting the next release out. So someone else will have to supply the time/energy/budget to get these tasks done.
I do have an opinion based on a practical aspect. So far, we have not had the release scripts properly generate the right version number for the NPM artifacts. That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5. So I would say we should not call this next release 1.0 and wait until the release automation can correctly version all artifacts with the right version number before we pick one to call 1.0. With any luck I'll get the automation running next week and will ask for someone to volunteer to test drive it.
-Alex