If by any chance module jar timestamp determines the order then I may
have reasonable explanation: when RE build runs in ips profile and
creates IPS enabled distribution, we also "normalize" all the module
jars (with few signed jar exceptions) using jar pack and unpack so that
we can ship packed jar files in installer distributions. As the result,
most jars will have timestamp that is reset at the time they are
normalized which is approximately the time of corresponding packager
module build.
In normal developer build external jars preserve their timestamps and
those build in GlassFish workspace will have the timestamp determined by
module build order and not by packaging order...
Thanks,
Snjezana
Bobby Bissett wrote:
> Hi all,
>
> We've had a couple upgrade issues that happened only in promoted
> builds instead in the trunk. For instance, some issues such
> as GLASSFISH-15195 and GLASSFISH-15576 always happened if I built from
> the branches and not from the trunk.
>
> The only difference was that the order of inhabitants returned from
> the getInhabitants call was changed, and some upgrade modules failed
> because they didn't explicitly declare other modules that needed to
> run first. Since the problem never happened in the trunk, it makes
> sense that developers wouldn't see the problem (and would repeatedly
> mark the bugs as not-reproducible).
>
> Tom to the rescue:
> http://java.net/jira/browse/GLASSFISH-15195?focusedCommentId=148935&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_148935
> <http://java.net/jira/browse/GLASSFISH-15195?focusedCommentId=148935&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_148935>
>
> Anyway, I'm thinking I should go through the upgrade forcing each of
> the 16 upgrade classes to go first to make sure they properly make
> their dependencies run first. But if there are problems, I'm not sure
> they need to be fixed in 3.1 if there's a way to know they won't
> happen out in the wild.
>
> Thus, what determines the order of the values returned from that call,
> and why would it be different in, for instance,
> the https://svn.java.net/svn/glassfish~svn/tags/3.1-b37
> <https://svn.java.net/svn/glassfish%7Esvn/tags/3.1-b37> branch and not
> the trunk of the workspace?
>
> Thanks,
> Bobby
>
--
Oracle <http://www.oracle.com>
Snjezana Sevo-Zenzerovic
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment