Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow some 'timestamp" without impacting the generated jar name also be worth considering?
Eric Bresie ebre...@gmail.com On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > In that case, we can probably remove the time stamp from MAVEN_VERSION > altogether in a follow-up fix, since it is never used for any released > version, including early access builds. Not a high priority though once > the entire publishing task is qualified by a property. > > -- Kevin > > > On 7/23/2020 10:26 AM, Joeri Sykora wrote: > > We have never had the need to publish snapshot versions. We do however > > publish early access builds quite regularly (e.g. 15-ea+6) for the > > versions that are in development. > > > > Op do 23 jul. 2020 18:44 schreef Kevin Rushforth > > <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>: > > > > The proposed fix will be to disable the maven publishing tasks by > > default, and to not set the project.version at all. So this will > > decouple the maven publishing tasks, and they won't interfere with > > normal developer or production builds. > > > > Joeri or Johan can confirm, but if they ever do upload a bundle for > > testing, I'm pretty sure they would use a SNAPSHOT designation (set > > manually). > > > > -- Kevin > > > > > > On 7/23/2020 5:55 AM, Eric Bresie wrote: > > > Is there a need for some further cleanup dependency between > > builds maybe to remove duplicate jars / modules with different > > time stamps? > > > > > > Rather than time stamp in these cases should it just use a > > SNAPSHOT designation instead? > > > > > > Eric Bresie > > > ebre...@gmail.com <mailto:ebre...@gmail.com> > > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth > > <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> > > wrote: > > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to > > track fixing > > >> the build.gradle to not include the time stamp, at least by > > default. > > >> > > >> -- Kevin > > >> > > >> > > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > > >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > > >>>>>> That could be prevented by removing line 1547: > > project.version = > > >>>>>> MAVEN_VERSION from the build script. > > >>>>> Interesting. That is only used for the maven "publishing" > > tasks, and > > >>>>> shouldn't affect the main build artifacts. I don't see the > > generated > > >>>>> version number showing up anywhere in the build output. It > > would be > > >>>>> easy enough to suppress this for non-production builds, but > > I'd want > > >>>>> to understand how it is causing problems. Does gradle (and > > thus the > > >>>>> NetBeans gradle plugin), assign some semantic meaning to the > > >>>>> project.version attribute? > > >>>> There is no semantic association. It is just the binding of the > > >>>> sub-projects together. Recent Gradle doesn't generate the jar > > files > > >>>> of the sub-projects if not asked for that specifically. Though > if > > >>>> javafx:base project is asked of it's main output it would be > > a jar > > >>>> file with a second precision suffix in it's name. Also if you > > ask for > > >>>> the dependencies of javafx:graphics it will list a dependency > > on a > > >>>> javafx:base base jar with the second precision suffix in its > > name. > > >>>> The jar file does not have to be exist, NetBeans still would > > able to > > >>>> find out the dependency between the two sub-projects, but > > these jar > > >>>> names shall be the same. So if these two queries happen in > > different > > >>>> times the jar name would not match. > > >>> Got it. We explicitly disable the jar task for each modular > > project, > > >>> since we don't need them, so we never would have noticed this. > > If I > > >>> enable them, I can see the jar files with the full version > number, > > >>> including the date string. > > >>> > > >>> I'll file a bug to fix it. I'll need to do it in such a way > > that won't > > >>> disrupt generating maven artifacts for testing (actual maven > > artifacts > > >>> for uploading won't be affected anyway), but it should be easy > > to do. > > >>> > > >>> -- Kevin > > >>> > > > >
