Bugzilla – Full Text Bug Listing
| Summary: | Deploy jcommon-1.0.16-CQ7581.jar (example subset dependency) | ||
|---|---|---|---|
| Product: | [LocationTech] JTS | Reporter: | Jody Garnett <jody.garnett> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | NEW --- | QA Contact: | |
| Severity: | trivial | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | 25 | ||
I'm not familiar with Nexus, but I was assuming that projects could publish artifacts themselves. Thanh, can you help us out? Thanks I just sent a long email to the location tech mailing list expressing confusion over state of play with nexus. Should I open up individual tickets or stop by the weekly office hours? Denis I may be able to publish myself, currently I cannot sign into the nexus. Unfortunately to publish to repo.locationtech.org you need to use your HIPP instance because currently we block connections from outside Eclipse infrastructure. Details on how to push to repo.locationtech.org can be found here https://wiki.eclipse.org/Services/Nexus (replace instances of eclipse.org with locationtech.org). In order to push single jar files though using deploy-file we need a place where the project can place the jar file which HIPP can also reach. For Eclipse projects we typically recommend they put the files in their designated spaces in /shared/ putting a jar and a pom.xml there. Typically using build.eclipse.org shell access to perform this step. Denis, would LocationTech be able to have this sort of access too or would we need to come up with another method to allow projects to push single jars to repo.locationtech.org? (In reply to Jody Garnett from comment #3) > Denis I may be able to publish myself, currently I cannot sign into the > nexus. This is by design. Currently the way Nexus is used at Eclipse is there is no user accounts and only a single deployment account that's shared by all the HIPP instances, only HIPP has the credentials. > Denis, would LocationTech be able to have this sort of access too or would > we need to come up with another method to allow projects to push single jars > to repo.locationtech.org? We've agreed that for third party content, attaching the artifact to a bug like this is the best course of action (for now). I would need a POM file for it. Jody, can you create and attach one? For my own documentation, here is an example: https://repo.eclipse.org/service/local/repositories/eclipse-releases/content/org/eclipse/jdt/org.eclipse.jdt.annotation/1.1.0.v20140129-1625/org.eclipse.jdt.annotation-1.1.0.v20140129-1625.pom Thanks Dennis I will create a pom.xml file shortly - however we should mark this issue as dependent on bug 27. (Which identifies several issues with our current repository URLs and internal structure) Sadly my research found a conflict between the proposed solution (encoding CQ in version number for clarity) and maven central guidance on the matter. Research: * https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates Provides the following guidance on forks (which is what the CQ subset produces): --- However if the project does maintain a presence on Central, then if there's a fork you have two choices: B1) get the original project to upload the artifacts in their own groupId (unlikely since there's a reason it was a fork) B2) upload them under your the forked project groupId (presumably one you own and appropriate for the fork) --- Following this guidance we would end up distributing: * groupid: org.locationtech.jcommon * artifact: jcommon * version: 1.0.16 Since in this case we are already in communication with the jcommon PSC, and they have acknowledged the distribution issue associated with three classes (obtained from a newsgroup posting) I expect we could ask permission to distribute using a 1.0.16-CQ7581 version number. Note this issue has been shared with the architecture committee via https://bugs.eclipse.org/bugs/show_bug.cgi?id=441637 My general impression is that eclipse projects use Orbit (a non maven repository) to host CQ subset jars. PROPOSAL For those joining the conversation now - the proposal is to use the following dependency: <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16-CQ7581</version> </dependency> Since maven passes on transitive dependences, the following would result in the download of 1.0.16-CQ7581. <dependency> <groupId>org.locationtech.example</groupId> <artifactId>library</artifactId> <version>0.1-SNAPSHOT</version> </dependency> Java developers making use of our example library above would need to use add the repository https://repo.locationtech.org/content/groups/releases/ If they wished to use the original jcommon jar they would use "excludes" (to avoid transitive dependencies) <dependency> <groupId>org.locationtech.example</groupId> <artifactId>library</artifactId> <version>0.1-SNAPSHOT</version> <exclusions> <exclusion> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16-CQ7581</version> </exclusion> </exclusions> </dependency> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> </dependency> Or "provided" which is more reliable and covers any transitive dependencies. <dependency> <groupId>org.locationtech.example</groupId> <artifactId>library</artifactId> <version>0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16-CQ7581</version> <scope>provided</provided> </dependency> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> </dependency> ALTERNATIVE Failing that projects *may* be consider their own repository of third party dependencies (to strictly control use during the release process). https://repo.locationtech.org/content/groups/example/releases/ This would be a risky approach (a bit terrifying from a configuration control perspective) but may be less work and preferable for interaction with the wider java world. <dependency> <groupId>org.locationtech.example</groupId> <artifactId>library</artifactId> <version>0.1-SNAPSHOT</version> </dependency> When the example library is published to the wider java world developers would end up downloading the original jcommon jar from maven central (possibly requiring a "works with" CQ). The danger is any any user of the https://repo.locationtech.org/content/groups/example/releases/ repository could not be sure which jar they ended up with for jcommon-1.0.16. Specifically this approach would break the maven repository model - hence the risk. (In reply to Jody Garnett from comment #8) > My general impression is that eclipse projects use Orbit (a non maven > repository) to host CQ subset jars. > > PROPOSAL > > For those joining the conversation now - the proposal is to use the > following dependency: > > <dependency> > <groupId>jfree</groupId> > <artifactId>jcommon</artifactId> > <version>1.0.16-CQ7581</version> > </dependency> Have you considered how this would interact with version ranges? Consider the following: <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>[1.0,1.1)</version> </dependency> Now, whoever specified this range would be really surprised to just get the CQ-approved subset (which may lack some required classes). Of course, this can happen only if repo.locationtech.org is among the repos searched and there is no genuine version 1.0.16 (which is, AFAIK, considered to be than 1.0.16-CQ7581 [1]) in any of the repos, but using a version qualifier to squeeze in a fork in between the non-fork versions to me seems like a bad idea in general. In other words: Please follow the Maven Central guidelines. [1] <http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html> My understanding is that CQ7581 is considered a qualifier and does not take part in version comparisons. Double checking the link you provided ... yes that is correct (specifically to account for version ranges) (In reply to Jody Garnett from comment #10) > My understanding is that CQ7581 is considered a qualifier and does not take > part in version comparisons. > > Double checking the link you provided ... yes that is correct (specifically > to account for version ranges) Not sure if I understand you correctly, but qualifiers are part of version comparisons: 1.2.3-alpha-2 < 1.2.3 But irrespective of whether 1.2.3-alpha-2 is less or greater than 1.2.3, the crucial bit is that a version like 1.0.16-CQ7581 is within a range of [1.0,1.1) and someone using the jfree:jcommon groupId/artifactId might be quite surprised if artifacts within this range don't follow the compatibility promises as made by the jfree project, i.e., that micro-releases won't remove API classes. (Disclaimer: I don't know whether the jfree project has any such policy, but I think the general problem is clear.) Point noted - that is a serious drawback to the 1.0.16-CQ7581 proposal. This would leave us following the "choose your coordinate" guidance (cited above) resulting in: * groupid: org.locationtech.jcommon * artifact: jcommon * version: 1.0.16 Or further constrained by locationtech project: * groupid: org.locationtech.udig.jcommon * artifact: jcommon * version: 1.0.16 Neither of which is ideal. (In reply to Andreas Sewe from comment #11) > But irrespective of whether 1.2.3-alpha-2 is less or greater than 1.2.3, the > crucial bit is that a version like 1.0.16-CQ7581 is within a range of > [1.0,1.1) and someone using the jfree:jcommon groupId/artifactId might be > quite surprised if artifacts within this range don't follow the > compatibility promises as made by the jfree project Thanks for the clarification Andreas, I am still struggling to figure out a way to set up the location tech repositories with a minimum disruption to both the developers and users of these projects. I may have another idea, deploying using a classifier, and managing the use of these classifiers with a dependency management profile: <profiles> <profile> <id>release</id> <~-- Dependency management overrides limiting build --> <~-- to versions approved by the CQ process --> <dependencyManagement> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <classifier>CQ7581</classifier> <version>1.0.16</version> </dependency> </dependencyManagement> </profile> </profiles> <~-- project dependency control --> <dependencyManagement> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> </dependency> </dependencyManagement> I expect this is the correct approach. Reference: * http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html (In reply to Jody Garnett from comment #13) > (In reply to Andreas Sewe from comment #11) > > But irrespective of whether 1.2.3-alpha-2 is less or greater than 1.2.3, the > > crucial bit is that a version like 1.0.16-CQ7581 is within a range of > > [1.0,1.1) and someone using the jfree:jcommon groupId/artifactId might be > > quite surprised if artifacts within this range don't follow the > > compatibility promises as made by the jfree project > > Thanks for the clarification Andreas, I am still struggling to figure out a > way to set up the location tech repositories with a minimum disruption to > both the developers and users of these projects. > > I may have another idea, deploying using a classifier, and managing the use > of these classifiers with a dependency management profile: Yes, classifiers seems like a good way to encode the "subset" nature of the dependencies. AFAIK, Maven never treats a non-classified dependency as equivalent to a classified one, as something with a "sources" or "javadoc" classifier (the two most common classifiers in the wild) is certainly not equivalent to the JAR containing the .class files. > <profiles> > <profile> > <id>release</id> > <~-- Dependency management overrides limiting build --> > <~-- to versions approved by the CQ process --> > <dependencyManagement> > <dependency> > <groupId>jfree</groupId> > <artifactId>jcommon</artifactId> > <classifier>CQ7581</classifier> > <version>1.0.16</version> > </dependency> > </dependencyManagement> > </profile> > </profiles> > <~-- project dependency control --> > <dependencyManagement> > <dependency> > <groupId>jfree</groupId> > <artifactId>jcommon</artifactId> > <version>1.0.16</version> > </dependency> > </dependencyManagement> I am not sure this works, though. If I interpret your intention correctly, you are tryinh to allow your clients to retain their dependency of > <dependency> > <groupId>jfree</groupId> > <artifactId>jcommon</artifactId> > <version>1.0.16</version> > </dependency> Only if you are somehow in "release" mode and enable the profile, then this should automatically be switched to the classified version. I haven't tested whether this is really what happens. However, even if it is, it won't have an effect on jfree:jcommon:1.0.16's dependencies. For any combination of groupId:artifactId:version there is one POM and its not under your control. Thus, enabling the profile won't have effect on your clients' transitive dependencies (i.e., jfree:jcommon:1.0.16's direct dependencies). Anyway, I am not an expert on all the intricacies of Maven dependency resolution, so why not ask on users@maven.apache.org or (here at Eclipse) on aether-users@eclipse.org, where Benjamin Bentmann can tell you exactly how Maven (and any other tool using Aether) will decide which dependency to pick based on your project's metadata? (In reply to Andreas Sewe from comment #14) > Yes, classifiers seems like a good way to encode the "subset" nature of the > dependencies. AFAIK, Maven never treats a non-classified dependency as > equivalent to a classified one, as something with a "sources" or "javadoc" > classifier (the two most common classifiers in the wild) is certainly not > equivalent to the JAR containing the .class files. Agreed, I will write this up as the direction. > I am not sure this works, though. If I interpret your intention correctly, > you are tryinh to allow your clients to retain their dependency of > > > <dependency> > > <groupId>jfree</groupId> > > <artifactId>jcommon</artifactId> > > <version>1.0.16</version> > > </dependency> > Agreed, the profile would not manage to correctly override... However I now remember a trick to alternate between two profiles depending on if a system property being true or false. GeoTools build uses this to alternate between Oracle JDBC driver and a Stub driver as we could not expect casual contributors to download and install optional oracle software just to compile. The effect on this change is: a) those downloading a standalone application from eclipse servers only receive IP approved software as reviewed by eclipse process b) those depending on artifacts for use as a library get a transitive dependency on jcommon 1.0.16 as published by the JFreechart team. Applying that solution here (for the record) results in: <!-- By default build restricted to dependencies approved by the CQ process --> <profile> <id>locationtech.publish-false</id> <activation> <property> <name>!publish</name> </property> </activation> <dependencies> <!-- Subset of jcommon-1.0.16 approved by CQ7581 --> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> </dependency> </dependencies> </profile> <!-- When publishing use dependencies in common circulation on maven central --> <!-- To use supply: -Dpublish=true on the command line during deploy:deploy --> <profile> <id>locationtech.release-true</id> <activation> <property> <name>release</name> </property> </activation> <dependencies> <!-- Original jcommon-1.0.16 published by JFreeChart project --> <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> </dependency> </dependencies> </profile> Added instructions on the LocationTech wiki: https://locationtech.org/wiki/The_Nexus#Build_Considerations (In reply to Denis Roy from comment #5) > We've agreed that for third party content, attaching the artifact to a bug > like this is the best course of action (for now). > > I would need a POM file for it. Jody, can you create and attach one? For > my own documentation, here is an example: > https://repo.eclipse.org/service/local/repositories/eclipse-releases/content/ > org/eclipse/jdt/org.eclipse.jdt.annotation/1.1.0.v20140129-1625/org.eclipse. > jdt.annotation-1.1.0.v20140129-1625.pom Based on your example pom.xml, here is a pom.xml to use: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16</version> <classifier>CQ7581</classifier> </project> If this could be deployed to : https://repo.locationtech.org/content/repositories/releases/ Aside: In today's project meeting we debated between using the "releases" or "third party artifacts" repository. I would prefer to have less repositories in the mix to make locationtech projects easier for project teams to integrate. In response to the aside: I think having a 'snapshot' repository and a 'releases' repository for LocationTech project dependencies, while having a third, 'CQ Approved Transitive Dependency' repository makes sense. Users of a library could point to the 'releases' repository to allow their build process to pull down any released LocationTech project as a dependency. If they wanted to get the most up-to-date development version of the project (which often as a consumer of GeoTrellis we need to do) a user could add the 'snapshot' repository to their build system and allow for snapshots to be brought into the build. However, the 'CQ Approved Transitive Dependency' repository would be very different: it would only be used when the project was being built for bundled distribution, by LocationTech members. There would be no reason for any user of a LocationTech library, who was using a build tool to pull that specific project's or projects' JARs down, to have access to a possibly-modified transitive dependency. If we have project specific repositories for 'snapshot' and 'release', which would each be aggregated by a proxy LocationTech-wide maven repository as discussed in the meeting, then it makes sense to me to have another LocationTech-wide (internal) repository of CQ-approved dependencies that we would use in the build profiles of the process to bundle stand-alone code for download. |
Created attachment 6 [details] Test case StyledText.java As an initial experiment with repo.locationtech.org can I ask that the attached common-1.0.16-CQ7581.jar be deployed. I would normally repo.locationtech.org (in mvn settings.xml file) and then use a command similar to the following to deploy: mvn deploy:deploy-file -DgroupId=jfree -DartifactId=jcommon -Dversion=1.0.16-CQ7581 -Dfile=jcommon-1.0.16-CQ7581.jar -Dpackaging=jar -DrepositoryId=locationtech -Durl=dav:repo.locationtech.org Applications making use of this subset would then use: <dependency> <groupId>jfree</groupId> <artifactId>jcommon</artifactId> <version>1.0.16-CQ7581</version> </dependency>