> I gather you decided not to have a git.version file at the root and you > added that info into the jar manifests, so where do you have that > information for the tar.gz assemblies?
We do have it in the tarball root for the real release -- the source tarball (ASF policy considers source releases as the sole official release). For the binary convenience artifacts, we don't include it at the root, but the jars have the info if people go digging. > Even the Java-only components have vastly different dependencies and > version cycles and don't necessarily need to be released at the same time > the core-java component is released. So far, we don't have releases that > span multiple components. For example, the core-java library may be > several versions ahead of the hive or pig components. Sure, that makes sense. I would still consider aligning their release processes though. If they stay separate, each component release would need its own release manager, its own voting cycle, its own publish and announcement process, etc, and that can be a lot of administrative overhead. On Wed, Jul 31, 2019 at 7:07 PM leerho <[email protected]> wrote: > Gian, > Thanks! > > > > https://github.com/apache/incubator-druid/pull/6482. > > > The discussion about the traceability of the GA back to the final RC is > interesting. > I gather you decided not to have a git.version file at the root and you > added that info into the jar manifests, so where do you have that > information for the tar.gz assemblies? > > Also, it is more work upfront, but you might find that in the long run, you > > enjoy switching the project to a single repo with a multi-module Maven > > build. We do this in Druid and it works quite well. It makes it way > easier > > to do patches and releases that span multiple modules. > > > The DataSketches library is not like a single product with components that > are released together. Some of our "components" have different life-cycles > and versioning. Also, we have C++ / Python repositories that don't fit > well with Maven, which is all about Java. > > Even the Java-only components have vastly different dependencies and > version cycles and don't necessarily need to be released at the same time > the core-java component is released. So far, we don't have releases that > span multiple components. For example, the core-java library may be > several versions ahead of the hive or pig components. > > Definitely doing as much as possible in the build system (whether Maven or > > Gradle) is a good thing, IMO, since they tend to reward living in their > > worlds. Also the more verifications you can push into the build tool, the > > better. > > > I agree. > > GPG ? > > > You are correct. The .asc signature is generated with GPG. > > > > > On Tue, Jul 30, 2019 at 5:22 PM Gian Merlino <[email protected]> wrote: > > > Hey Lee, > > > > You might find this PR useful, it is where we Apache-fied the Druid POM: > > https://github.com/apache/incubator-druid/pull/6482. It helps highlight > > the > > specific areas that are relevant to Apache-fying a build. > > > > Also, it is more work upfront, but you might find that in the long run, > you > > enjoy switching the project to a single repo with a multi-module Maven > > build. We do this in Druid and it works quite well. It makes it way > easier > > to do patches and releases that span multiple modules. > > > > > So it seems that eventually, either we need to go whole hog having > Maven > > do > > > everything, which seems overly complicated, or consider moving to > Gradle > > > (which I am not familiar with either, but it seems lots of teams are > > moving > > > that way). > > > > Definitely doing as much as possible in the build system (whether Maven > or > > Gradle) is a good thing, IMO, since they tend to reward living in their > > worlds. Also the more verifications you can push into the build tool, the > > better. > > > > In Druid we have also been considering moving to Gradle: > > https://github.com/apache/incubator-druid/issues/7866. However we are > > still > > using Maven for now and may be for some time to come, since it seems the > > benefits of switching to Gradle are definitely noticeable, but not huge. > > > > > - It doesn't appear that the Nexus artifacts require a GPG signature > only > > > the DIST assembly requires GPG, which the script is handling. So why > do > > we > > > need the gpg-plugin? > > > > IIRC it's because Sonatype's Central Repository (where the Maven-ready > > artifacts ultimately end up) requires GPG signatures. > > > > > - It is not clear to me when a profile should be used (e.g., for > deploy) > > vs > > > using the deploy process as part of the pom main build lifecycle. > > > > I've found profiles to be most useful when you want something like "mvn > > package" to do different things based on a profile. e.g. having a profile > > to apply strict checks that takes extra time, having a profile to build > > extra assemblies, etc. > > >
