Displaying #maven-dev/2017-04-08.log:

Sat Apr 8 06:19:27 2017  hboutemy:stephenc: whoohooo! thank you!
Sat Apr 8 07:57:59 2017  stephenc:hboutemy: yep. I'm probably going to leave it a week before I start kicking ass for 3.5.1 ;-)
Sat Apr 8 09:40:39 2017  hboutemy::)
Sat Apr 8 10:14:50 2017  rfscholte:Joined the channel
Sat Apr 8 13:30:10 2017  stephenc:rfscholte: a storm of releases it seems
Sat Apr 8 13:30:22 2017  stephenc:We wait ages for one and then surefire, archetype and core all come at once
Sat Apr 8 13:31:01 2017  rfscholte:not really true for archetype
Sat Apr 8 13:32:03 2017  rfscholte:did a release about two months ago, which broke quite a lot (so it is still used....)
Sat Apr 8 13:32:10 2017  stephenc:Way to ruin a good joke
Sat Apr 8 13:32:14 2017  rfscholte:fix is confirmed
Sat Apr 8 13:32:26 2017  rfscholte:;)
Sat Apr 8 13:32:57 2017  stephenc:We need to do up a plan of community changes
Sat Apr 8 13:33:15 2017  stephenc:I want to formalise community testers
Sat Apr 8 13:33:24 2017  rfscholte:sounds good to me
Sat Apr 8 13:33:33 2017  stephenc:As a role recognised by the project
Sat Apr 8 13:34:16 2017  stephenc:I also want to *at least* halve the steps to release core
Sat Apr 8 13:37:25 2017  rfscholte:I think we can automate#31 :)
Sat Apr 8 13:38:20 2017  stephenc:But do we want to automate that step?
Sat Apr 8 13:39:20 2017  stephenc:Jan 9th was when I reset master
Sat Apr 8 13:39:43 2017  stephenc:3 months to get the reset to release
Sat Apr 8 13:39:52 2017  stephenc:For a volunteer project
Sat Apr 8 13:40:04 2017  stephenc:I think it is quite an achievement
Sat Apr 8 13:40:14 2017  rfscholte:absolutely!
Sat Apr 8 13:40:43 2017  stephenc:If we can not fall down and keep a cadence the community will grow again (I hope)
Sat Apr 8 13:41:15 2017  rfscholte:think so too
Sat Apr 8 13:41:30 2017  stephenc:But what I want to start is getting less "big steps" from community to committer
Sat Apr 8 13:42:10 2017  stephenc:Every role we can recognise and create in between makes the ramp easier
Sat Apr 8 13:42:58 2017  stephenc:Tester is one
Sat Apr 8 13:43:55 2017  stephenc:I think we should recognise participation in other forms
Sat Apr 8 13:45:04 2017  stephenc:Maybe call out knowledgeable users that contribute to the user's list
Sat Apr 8 13:46:28 2017  stephenc:Need to think about what kinds of recognition to provide
Sat Apr 8 13:46:56 2017  stephenc:Could even be "good answer" badges
Sat Apr 8 13:48:21 2017  stephenc:"The Maven PMC would like to recognise your contributions to the community by awarding you the title of MVP"
Sat Apr 8 13:48:37 2017  rfscholte:yeah, but I'm not sure if we will get enough response right now. Maybe start with some Maven releases to awake the community. Hopefully that will trigger some.
Sat Apr 8 13:49:09 2017  stephenc:Perhaps
Sat Apr 8 13:50:12 2017  stephenc:In any case we should be looking to create ways for people to help
Sat Apr 8 13:52:16 2017  rfscholte:anyone experience with relocations? http://maven.apache.org/guides/mini/guide-relocation.html
Sat Apr 8 13:53:18 2017  rfscholte:seems it's only administrative, like Maven is not forwarding you automatically to the other artifact
Sat Apr 8 13:55:50 2017  rfscholte:http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000670.html refers to this page as "It's fairly straightforward to rename artifacts in Maven"
Sat Apr 8 13:59:58 2017  stephenc:The big issue I see is that it is for a single version only
Sat Apr 8 14:00:40 2017  stephenc:I'd like to be able to publish the relocation poms for matching versions over a couple of releases
Sat Apr 8 14:01:24 2017  stephenc:Eg esp if doing maintenance mode as there may be releases at the old coordinates
Sat Apr 8 14:02:01 2017  stephenc:Also some people use tooling and may not know there is something to upgrade to without a new relocation pom
Sat Apr 8 14:02:32 2017  stephenc:And finally the most important reason to keep publishing relocations: transitive dependency graph
Sat Apr 8 14:02:44 2017  stephenc:A -> B
Sat Apr 8 14:02:53 2017  stephenc:C -> B
Sat Apr 8 14:03:09 2017  stephenc:My project depends on A, B and C
Sat Apr 8 14:03:20 2017  stephenc:Now B relocated to D
Sat Apr 8 14:03:31 2017  stephenc:I update my dependency of B to D
Sat Apr 8 14:04:34 2017  stephenc:Now if it was My -> A:1.0, B:1.3, C:1.1
Sat Apr 8 14:04:54 2017  stephenc:And A:1.0 -> B:1.1
Sat Apr 8 14:05:09 2017  stephenc:C:1.1 -> B:1.0
Sat Apr 8 14:05:42 2017  stephenc:I would have been getting A:1.0, B:1.3 and C:1.1 as my dependencies
Sat Apr 8 14:06:27 2017  stephenc:If I upgrade to B:1.4 (which is a relocation pom) then all is ok, we get B:1.4 which resolves to D:1.4
Sat Apr 8 14:06:40 2017  stephenc:But I have a warning in my pom about the relocation
Sat Apr 8 14:07:16 2017  stephenc:So I silence the warning by replacing dependency on B with dependency on D
Sat Apr 8 14:07:49 2017  stephenc:Except now Maven *does not know* that B 1.4 has been relocated to F
Sat Apr 8 14:08:03 2017  rfscholte:aha!, you're right
Sat Apr 8 14:08:05 2017  stephenc:So now I get B1.1
Sat Apr 8 14:08:27 2017  stephenc:Because Sep conflict will pick the highest
Sat Apr 8 14:08:35 2017  stephenc:curses phone
Sat Apr 8 14:08:58 2017  stephenc:So we need to let D flag itself as a relocation of B
Sat Apr 8 14:09:28 2017  rfscholte:Maven5?
Sat Apr 8 14:09:39 2017  stephenc:Or we need to keep deploying relocations of B and only warn about the relocation if it is not fixing a transitive dep
Sat Apr 8 14:09:56 2017  stephenc:And Maven 5 (with my PDT) would fix it
Sat Apr 8 14:10:13 2017  rfscholte:not sure if relocation is often used and if it is worth resolving this properly
Sat Apr 8 14:10:59 2017  stephenc:So I think for the [,5.0.0) we should have an option to deploy relocation poms in the install/deploy plugins
Sat Apr 8 14:11:23 2017  rfscholte:that's what I'm thinking of
Sat Apr 8 14:11:50 2017  stephenc:And change the relocation warning to info if you also have the dependency pulled in via transitive
Sat Apr 8 14:12:59 2017  stephenc:We'd want a list of GA's that are relocations of the current artifacts
Sat Apr 8 14:13:17 2017  stephenc:And install/deploy them
Sat Apr 8 14:13:51 2017  stephenc:Perhaps with some version transformation via regex patter substitution
Sat Apr 8 14:15:22 2017  stephenc:rfscholte: do you think you could file a JIRA at least describing the above issue with relocation poms in the 4.0.0 model?
Sat Apr 8 14:20:37 2017  rfscholte:me must :)
Sat Apr 8 14:21:57 2017  rfscholte:I'll prepare the issues, add your comments when required
Sat Apr 8 17:17:34 2017  hboutemy:rfscholte: stephenc: on relocations, I'm quite sure we need to put info in metadata.xml, not only in pom.xml
Sat Apr 8 17:29:19 2017  jasonvanzyl:Joined the channel
Sat Apr 8 17:31:17 2017  rfscholte:hboutemy: probably yes. The transitive example shows you cannot resolve with 1 to 1 mapping
Sat Apr 8 17:31:46 2017  hboutemy:exactly
Sat Apr 8 17:32:34 2017  rfscholte:however, checking metadata every time for a possible relocation is too expensive
Sat Apr 8 17:37:46 2017  hboutemy:do you really think it is that expensive? you mean network or CPU?
Sat Apr 8 17:39:12 2017  rfscholte:both, suddenly you must download every metadata for every artifact. Right now that's only done in case of snapshots
Sat Apr 8 17:40:32 2017  rfscholte:we should experiment with it to get the right figures
Sat Apr 8 18:15:13 2017  stephenc:The correct fix is the <provides> concept in the PDT
Sat Apr 8 18:15:26 2017  stephenc:At least to my thinking
Sat Apr 8 18:16:57 2017  stephenc:That gives you the info that *this nearer dependency* is a replacement for that one. No extra lookups, and less in fact as the PDT gives you the trees for all immediate dependencies so you do not need to fetch the transitive hull
Sat Apr 8 18:17:19 2017  stephenc:But that is a 5.0.0 solution
Sat Apr 8 18:17:50 2017  stephenc:Right now the metadata is the only place we could stash such "provides" information
Sat Apr 8 18:18:26 2017  stephenc:I.e. Relocations are push notifications but pull consumption (at least for pre-5.0.0)
Sat Apr 8 20:42:37 2017  tibor_:Joined the channel

Comments