Bugzilla – Full Text Bug Listing
| Summary: | Define URL for maven stable / snapshot repositories | ||
|---|---|---|---|
| Product: | [LocationTech] JTS | Reporter: | Jody Garnett <jody.garnett> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| URL: | https://repo.locationtech.org/ | ||
| Whiteboard: | 27 | ||
|
Description
Jody Garnett
For reference here is email sent to the community list: ---- I was plesently surprised to see that repo.locationtech.org is already starting to fill up with a few project specific repositories, the structure of which had me a bit confused. While I cannot login to search the repositories there is one view available to explore: * https://repo.locationtech.org/index.html#view-repositories This shows: https://repo.locationtech.org/content/groups/geomesa https://repo.locationtech.org/content/groups/releases https://repo.locationtech.org/content/groups/snapshots https://repo.locationtech.org/content/repositories/geomesa-releases https://repo.locationtech.org/content/repositories/geomesa-snapshots I was kind of expecting two repositories - one stable and one for snapshots? A bit of research shows how CodeHaus does it, their "releases" repository is mapped to http://repository.codehaus.org (while they have nexus at https://nexus.codehaus.org/ ). I would like to correct this state of affairs as soon as possible so we can hand out https://repo.locationtech.org/ for use in build files? But if I am missing part of the story please let me know.... I was not quite sure of the structure of the initial geomesa snapshot repositories, it seems group and version information is being transposed: The structure: * geomesa/geomesa-accumulo1.4/1.0.0-SNAPSHOT/ * geomesa/geomesa-accumulo1.5/1.0.0-SNAPSHOT/ I would expect to be handled as: * org/locationtech/technology/geomesa/geomesa-accumulo/1.4-SNAPSHOT * org/locationtech/technology/geomesa/geomesa-accumulo/1.5-SNAPSHOT To prevent conflicts when this is eventually published to maven central. Research: * http://maven.apache.org/guides/mini/guide-central-repository-upload.html * https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates Looks like we do not need to worry, maven central has pretty clear publication guidelines. ----- Naming Conventions * groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. eg. org.apache.maven, org.apache.commons A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId. eg. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting * artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed.eg. maven, commons-math * version if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look.eg. 2.0, 2.0.1, 1.3.1 The only wrinkle is handling third-party dependencies where we only have a subset approved via the CQ process. With this in mind I would like to append the CQ to the version information. Example 1.0.16-CQ7581 as per bug 25 It looks like https://wiki.eclipse.org/Services/Nexus may answers some of my questions - offering: * https://repo.eclipse.org/content/repositories/releases/ * https://repo.eclipse.org/content/repositories/snapshots/ With that in mind I may assume that repo.locationtech.org intends to use: * https://repo.locationtech.org/content/groups/releases/ * https://repo.locationtech.org/content/groups/snapshots/ My hesitation on this one is a directory structure mapped to this specific implementation (of nexus). The use of group and version remain open. (In reply to Jody Garnett from comment #3) > It looks like https://wiki.eclipse.org/Services/Nexus may answers some of my > questions - offering: > > * https://repo.eclipse.org/content/repositories/releases/ > * https://repo.eclipse.org/content/repositories/snapshots/ > > With that in mind I may assume that repo.locationtech.org intends to use: > > * https://repo.locationtech.org/content/groups/releases/ > * https://repo.locationtech.org/content/groups/snapshots/ > To be clear Nexus aliases the word "repositories" with the word "groups". I've told in the past that it's better to always use "repositories" word. For example these 2 URLs are equivalent: https://repo.locationtech.org/content/repositories/releases/ https://repo.locationtech.org/content/groups/releases/ But the 1st one is the recommended one to use. I responded to some of your questions on the mailing list but I'll paste them here too for tracking. --- Regarding repo layout, the way we've been doing this until now is... typically we give every project their own set of "project-releases" and "project-snapshots" repositories and a group that contains both repositories. These URLs are URLs a project should use to push to Nexus and in some cases if a project wants to be very specific about what they are pulling they can use these to pull exact projects. The generic "releases" and "snapshots" groups are aggregates of all "project-releases" or all "project-snapshots" so these are the URLs we'd typically recommend projects use to pull from Nexus if they want 1 URL that contains everything. Regarding the structure, we do recommend projects use their org/locationtech/project namespace. Unfortunately we are not currently restricting projects from deploying to the wrong namespaces but it is something we are looking into via Eclipse bug https://bugs.eclipse.org/432018 Your answer concerns me a little bit: "These URLs are URLs a project should use to push to Nexus and in some cases if a project wants to be very specific about what they are pulling they can use these to pull exact projects." My understand is maven uses version information to be very specific about what what is being pulled, in order to recognise, mix and max, jars from a range of repositories and mirrors world wide. Simply swapping URLs and changing the version numbers would not necessarily affect a change (developers may already have jars cached locally from a different repository). I hope we are just having difficulty communicating and eclipse projects are not accidentally making life more confusing. (In reply to Jody Garnett from comment #5) > Your answer concerns me a little bit: "These URLs are URLs a project should > use to push to Nexus and in some cases if a project wants to be very > specific about what they are pulling they can use these to pull exact > projects." > > My understand is maven uses version information to be very specific about > what what is being pulled, in order to recognise, mix and max, jars from a > range of repositories and mirrors world wide. Simply swapping URLs and > changing the version numbers would not necessarily affect a change > (developers may already have jars cached locally from a different > repository). > > I hope we are just having difficulty communicating and eclipse projects are > not accidentally making life more confusing. Your understanding of Maven is correct. It's just some projects at Eclipse prefer to be even more specific, by using project specific URLs they can ensure that the set of possible dependencies being pulled are from an even smaller set. It's also useful to ensure in some cases that you might not have any surprise dependencies (dependencies that are available but you were not expecting your project to need it, by using project specific URLs this will cause a build failure). This isn't to say that your project must use the project specific URLs when pulling. You can use the generic URLs which aggregates all of the more specific ones. Okay so we have two motivations: * pull from a smaller set of dependencies (than maven central) * limit chance of surprise transitive dependencies I note that for this solution to work the project specific repository would need to be configured as the "mirror" of maven central. See the following: * http://maven.apache.org/guides/introduction/introduction-to-repositories.html * http://maven.apache.org/guides/mini/guide-mirror-settings.html I may have a third motivation, as an alliterative to CQ specific version numbers. Offering an answer the question about how to handle IP Team feedback when only a subset of a dependency is approved for distribution. A project (optionally) limiting itself to a project specific repository during final build could ensure it was only using dependencies that have been through IP review. In the case of bug 25 they would "host" the cut down jcommon jar - under the original version number. This would allow downstream developers (using maven dependences) to retrieve the "full" jcommon from maven central), while end-users that download a standalone application would be provided with a cut-down jcommon jar in accordance with CQ policies. As a strategy, this would be dangerous (but creative). It would allow a project like geogig an easier integration story for the developer community, while still making it possible to release a stand alone command line app. I guess it is a question of transparency: being explicit about the use of cut down jars in the jar version number VS ease of use as a library. As per email request I have notified the Architecture Committee of this discussion https://bugs.eclipse.org/bugs/show_bug.cgi?id=441637 Documented URLs provided here on LocationTech wiki: * https://locationtech.org/wiki/The_Nexus#Published_Repositories Since this issue was reported a third-party-artifact repository has been added: * https://repo.locationtech.org/content/repositories/thirdparty/ The intended use of this addition is not clear, the maven build system slows down by O(N*M) as each new dependency is checked against every new repository. We should not ask developers using our software to check several LocationTech repositories. |