sample bump version numbers? (parked) #39
Conversation
|
Nice, thanks for putting this together. We're a little light on tests in the samples right now. We'll have to do an extensive review or complete #32 before I'd feel super comfortable blanket updating everything like this. (We're uncomfortable enough we've actually made it a policy not to upgrade unless a sample requires it.) Is your PPS a mention that you did check everything, or that you only checked the JBoss samples? |
|
No I actually ran all samples on my local machine. But don't let that be your guiding principle, the presence of tests lacking was something I noticed as well. I wouldn't have a problem doing them if you could appreciate that. On the whole subject of automated updates: I can understand some initial reservations and respect that. Personally I'm not really opinionated on the matter, either way manual/visual confirmation of the changes would be a smart thing given the relative infancy of the feature. For one, plugins only appear to concern globally defined ones, not the ones in the project. And I'm sure that some nested outdated dependencies from user profile didn't get picked up either. Ancient has been complaining about Which really brings me to my last point, the very first post I made in these Pedestal environments on github, was an issue with the Now I'm curious about one thing: I had to This is what it always ends up with, unless (in this case service) I exclude it at the correct package doing the overruling: Immutable and JBoss are something I didn't have problems with earlier, now it seems that there is an issue with hornetq not finding Update: guess I'm not the only one with logger conflicts For the rest, info on resolution of conflicts or :exclude is scarce, I imagine if a package is the only one referencing it, and there isn't a conflict to begin with (but an earlier exclude to have it work with other packages) you'd probably have to remove the exclude again. Anyway, guess that's why you should probably always do these things (updating references) manually to begin with, on project-level by hand (which probably proves your point best). Also user local machine configurations may cause issues which could mistakenly be seen as a project (dependency) issue while perhaps it is not. Perhaps it's best to treat global user with bit more care than I have done in the past. Perhaps the essential, and all the other packages put under separate profiles to keep the tree clean. |
|
Ho! Quite a few changes working their way in here. Could we separate the notion of upgrading versions from other incremental improvements to the samples? On the 0.2.0 front, we probably want to do that in a second pass, as we should upgrade/migrate to 0.2.0 style projects there. I'd like to isolate that change from the rest of this as it is a slightly riskier change. We've also moved around some of the logging dependencies, so that should be revisited.
The inclusion of logging frameworks and dependency collisions seems to be a general problem in the ecosystem. I'm really curious if Timbre alleviates some of this, because I too find this quite annoying. It's rough: in the absence of a collision, you need the dependency somewhere, but as soon as a second library needs it too, 💥. In the case you mention above, wouldn't it be more correct to exclude slf4j-api from the extra libraries pulling it in and specify our own version? We'll have to see how it looks post-0.2.0. |
|
What I've experienced using Luminus (which bootstrapped with Timbre as logger) and used quite a few times, it was a smooth logging experience of It-just-works™ Perhaps for those who are more dependent on larger enterprise/legacy Java systems, Also, I don't know the motivation for the initial choosing of
So yes it would seem so. It does not rely on log4j which relieves you from the native dependency that you now have with log4j (needs to be on the os/platform present). If you guys have no clear reasoning behind log4j, I would probably very well have gone with Timbre, unless it really needs to be heavy lifting, then take the industry practice.
Right, I noticed while I was going through testing the samples more in depth, that you did the bump.
Yeah sure. I had hardly used it before, realize I can
Of course. You are correct, I failed to realize that would be easiest. |
Now that's something I didn't know, my other actions were also captured. Silly, explains why this got littered. Did a proper reset and commit now. |
|
There's still one thing that kind of bugs me about upgrading dependencies in the samples. The samples are an artifact of using app-template or service-template, which carry along their own library versions, right? Upgrading the versions in generated samples but not the versions in the templates creates a scenario where the set of dependencies in a sample is completely different from the templates themselves. Maybe we should be starting at the template's dependency versions and working our way down? |
|
I wrote a whole bunch to end up thinking: shouldn't we perhaps just use tags or branches to split off at major bumps? The app-tutorial uses tags for progress in a follow-along type of tutorial - the type where you need to ensure that the tools and documents are really in sync because the user must duplicate what you do in their own environment, and may choose to do that at any moment in time, so the current at that time versions should be there? Am I making sense? This can get so hairy thinking about these things sometimes, I've been around a few loops already but keep finding angles and stuff lol. Anyway these samples are more like working examples of how you could approach things, with useful comments and clear unambiguous start-up procedure to fire up a running example out of the box unless you'd want a With node.js I can travel back to tag I hope so anyway, reasoning dependencies and second guessing if you guys had plans for things, how the development path of pedestal will be, release cycles or degree in which experimental things might always be some part of it for the foreseeable future, or instead perhaps want it just stabilized asap. That makes for a lot of options to take into account so I have to fill in a lot of blanks ><. Or I'm completely missing the point you are trying to make though, that happens a lot too :D I just got the idea that at any time the user wants a running sample out of the box working that reflects the most current situation at any moment in time. Cheers, |
No grand plans in terms of the samples, just trying to keep it simple. Since we have so little time to work on Pedestal we try really hard to minimize work on samples that don't need to change (hence why I might be a bit more dismissive about not doing something 😉).
I think for now a tagging system would be overkill. It wouldn't hurt too much to add a tag when we jump to 0.2.0, but otherwise I think it'd be more work than benefit. Since I'm big on consistency, I think our highest priority right now should be re-generating projects with 0.2.0 templates. Is that something you'd be interested in helping with? It also wouldn't hurt to take a swing at upgrading dependencies in app and service templates. (A corollary of this is, do you mind if we park this issue for now and revisit it by bringing in fresh 0.2.0 templates/dependencies?) |
|
Ah. I finally see now, I get what I was overlooking with the sub-project organization in the main pedestal app. Roger.
Sure, got time and motivation enough... the rest I can learn.
Sounds like a plan. So want to open up an issue on this? I'll have a look at what would need updating in the templates still and have a look at which sample projects could be bumped first, what need fixing and what not. Not much is that broken to begin with but I don't know what changes got implemented exactly. So regenerating is a good idea probably. |
|
Yeah go ahead and open an issue with an initial tasks list ( Maybe something like:
|
I did a clean reset of the fork and updated referenced dependency version numbers using
lein ancientnot using automated upgrade, manually checked dependency tree free of conflicts withlog4jexclusions in the offending package.Refrained from updating to 0.2.x branch to keep a clean separation in tact.