Change By: Tony Chemit (27/Dec/13 8:10 AM)
Description: One problem of outputJarVersion attribute is the combination with  â€œexcludeTransitive”  *excludeTransitive* . If the transitive is not excluded, I found the code will by default set  â€œoutputJarVersion”  *outputJarVersion*  to true. This means that all the figured-out depended jars are of version-based update policy. 

This also means that the time-based update will never work, since all the down-stream jars are still by default of version-based.

I encountered one situation. My application depends on A.jar, which depends on B.jar. I specified A.jar not output jar version. But I cannot control B.jar. My project
 didn’  didn' t configure to generate a new explicit version number for every build. Then, after I update the baseline, and run my application, the JNLP client download a new A.jar, but still to use the old-versioned B.jar in my local cache. I got a hybrid & in-sync running instance!

Also, I think we should remove this attribute from the each jar resource. Instead, we support a top-level
 â€œoutputJarVersions”  *outputJarVersions*  for the whole pom file. Unfortunately, there is a bug report to say  â€œexcludeTransitive† *excludeTransitive*  is not supported but no resolved yet. Refer: http://jira.codehaus.org/browse/MWEBSTART-184.
I think the attribute
 â€œoutputJarVersion† *outputJarVersion*  under every  â€œJarResource† *JarResource*  is kind of dangerous to use. Because it is under every JarResource, in theory, the user can specify it as true and then some Jar resource is of version-based update policy, which is the default policy. At the same time, for other jar resources, they can be specified as false, which means time-based update policy (based on last update time of the depended jar file).

So, this means that for an application, some of its depended resource will be update w.r.t. last update time, and others will be updated based on version. This kind of mix is very dangerous!
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply via email to