[ODLPARENT-117] nexus.opendaylight.org to proxy an external SNAPSHOT Maven repo, for lastnpe.org EEA Created: 15/Sep/17 Updated: 24/Jan/18 Resolved: 19/Sep/17 |
|
| Status: | Resolved |
| Project: | odlparent |
| Component/s: | General |
| Affects Version/s: | 2.0.5 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Michael Vorburger | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| External issue ID: | 9170 | ||||||||
| Description |
|
[I'm not sure which project to file this issue under; it's really linuxfoundation.org infrastructure related, not "odlparent" (code) specific... is this more of a helpdesk@ than a BZ kinda thing? Or can we have a LF JIRA about this instead of this BZ?] In the context of ODLPARENT-116 for ODL to be able to use the external null annotations (EEA; see e.g. http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_external_null_annotations.htm) coming together from the http://lastnpe.org in the build of some ODL projects, I would have to frequently cut releases of https://github.com/lastnpe/eclipse-null-eea-augments/tree/master/libraries and often deploy to Maven central (as I have on https://repo1.maven.org/maven2/org/lastnpe/eea/, once). However, this is likely going to be a major PITA, especially in the early days and during ongoing dev cycles (it will be different as the EEA repo becomes more mature later, and when we cut ODL releases with it later as well). Therefore, in an ideal world it would be neat if http://nexus.opendaylight.org could proxy some (TBD) external Maven repo where I would continuously deploy (CD, e.g. using travis-ci.org) SNAPSHOT EEA JARs to from https://github.com/lastnpe/eclipse-null-eea-augments/tree/master/libraries (e.g. on Bintray.com, or wherever). Requires https://github.com/lastnpe/eclipse-null-eea-augments/issues/14 |
| Comments |
| Comment by Stephen Kitt [ 15/Sep/17 ] |
|
Umm... Can't you use local EEAs to work things out before pushing them upstream and releasing? |
| Comment by Michael Vorburger [ 16/Sep/17 ] |
|
> use local EEAs to work things out before pushing them upstream and releasing? Yeah of course that will work (once it's all set up correctly; working on that...) for local development, BUT: Once (later..) I'll want to start enforcing null safety in the build (opt in), when I refine some EEA for something being coded in a Gerrit, that EEA change will have to go "live", so the build of projects who opted in to enforcement doesn't break. In an ideal world, especially in the early days, this would avoid having to having to release EEA updates as releases to Central all too frequently. |
| Comment by Robert Varga [ 17/Sep/17 ] |
|
I really dislike us depending on third-party snapshots – that really is bringing our release flexibility down. Why is stabilizing upstream first and then pulling it into ODL not a feasible approach? |
| Comment by Stephen Kitt [ 18/Sep/17 ] |
|
(In reply to Michael Vorburger from comment #2) So how's that going to work for general users of EEA, other than ODL? Will everyone be expected to use snapshots? It seems to me the EEA project needs to figure out some way of allowing null-checks with local supplements to cover such cases, instead of relying on changes flowing upstream at the same rate as downstream development. |
| Comment by Michael Vorburger [ 19/Sep/17 ] |
|
https://lists.opendaylight.org/pipermail/odlparent-dev/2017-September/001340.html has concluded that is not something which OpenDaylight will want to do. If needed, the best alternative I can think of is to either release lastnpe.org EEA very frequently to central, or to have SNAPSHOT EEA in ODL, e.g. in infrautils, as a sort of "incubator" while waiting for lastnpe.org to release say monthly to Maven central. I'll probably start to do the latter as and when the need to have this arises. Therefore closing this issue. |
| Comment by Michael Vorburger [ 19/Sep/17 ] |
|
> Why is stabilizing upstream first and then pulling it into ODL not a feasible approach? Just for velocity. I would likely have to very frequently cut releases of lastnpe/eclipse-null-eea-augments and often deploy to Maven central. > So how's that going to work for general users of EEA, other than ODL? Will everyone be expected to use snapshots? Nope, just those who want the very latest bleeding edge. As for any library. > It seems to me the EEA project needs to figure out some way of allowing null-checks with local supplements to cover such cases, instead of relying on changes flowing upstream at the same rate as downstream development. Forget about EEA... thanks to my https://github.com/lastnpe/eclipse-external-annotations-m2e-plugin it's actually EXACTLY the same as for any Maven dependency to any library, or whatever. I had actually worked (hard, last year) to even make "workspace resolution" possible - works very nicely. The only problem then is builds. PS: But I would rather not sink time in further debating this. I think what I'll do is offer a first suggested contribution to odlparent based on which whoever is interested in this work can use EEA-based null analysis in Eclipse IDE and with a -P mvn CLI profile for local builds - only. I want to get some experience with that. Optional opt-in regular (Jenkins, not local -P) build time enforcement is then a later step. As only that would really require this, I would like to pause this discussion until then. |