#JavaDoctor / NG Parchment Support
141 messages Β· Page 1 of 1 (latest)
@soft scroll bop
I'd probably start by making a bundle classifier version that cobbles it all together into one jar file? We need that to refer to it as a tool from NG
it's already a shaded cli tool. but I think you should focus on modularising the source processor
so we have the infra for ats in the future without needing to rework it again
Okay but would I remove the abstraction over javaparser/spon for that?
and make the API depend on PSI?
err I don't think you should do it in javadoctor lol, that repo is focused on javadocs and has more than the injector
just get me the api and stuff for the source modifier and I can handle the javadoctor integration
But I already have Javadoc integration π
I thought I'd just add the parameter stuff to javaDoctor instead hehehehehehe
and the at stuff too? 
Five minute job! I promise! π
But how would serviceloader help if the tool has to be a self-contained jar?
Thinking about how you would make use of an SPI
can ng not add additional libs to the cp?
Not at the moment, no
It's essentially doing a non-transitive artifact id resolution and uses the resulting JAR as the single executable jar
But TBH that could (and probably should) be fixed
Hm okay, I have a vague idea of how we could do that π€
yeah i'm not really sold on plonking all the source transformations together. sounds like a recipe for pain when updates to relevant projects (like ats) want to be done
It's just running a synthetic NeoForm execute task that we configure in Java anyway. So yes, we could simply allow for a list of extra dependencies. But I am not sure yet how that would help us for the default case where it should just work β’οΈ
The common platform isn't bad for two reasons in my opinion:
- we need parsing to update anyway when breaking Java updates happen. only having to update it once is a plus
- performance. we definitely don't want to repeat this step multiple times in front of recompile
yes 2. is solved by a classpath. 1. is solved by updating just the root transformer project (the one with the API and the likes)
Yeah true. We'll have a bad time with configuration of all that, I guess. And you already know my take on having too many GH projects
But the artifacts would be shipped individually
We should however try to avoid working on a generalized framework for weeks when the actual transform tasks would take us 2-3 days to implement
what do you think my take on "plonk it all together" is? :P. plus we'd need a new repo anyways, javadoctor is more than just applying javadocs, can't just keep throwing stuff on it, there's already like 5 projects
And I see a problem with splitting Method Parameters and Javadoc in that I also remap Parameters in javadoc π€
Well I suppose that could be solved by ordering transforms
So this is looking into applying the parchment names at source level rather than binary level?
as long as javadoctor happens after params it's fine
as i said, javadoctor uses param indexes never names
not even for generic types
Yes, I already have a tool. This Thread is to merge it with existing tooling and avoid toolsplosion.
How do you merge existing javadoc parameters with new parameters?
uh?
Well I suppose indexOf heh
Before:
After:
With parameter renames for x->newX, y->newY and javadoc only added for x and z
javadoc merging is at metadata level, not at source level, it doesn't parse existing docs. and i already have the code there to strip javadocs from the final patcjes
Hm, but that means we need to pull extra parameter metadata that matches the NeoForge version the project refers to in userdev, right?
And then have JavaDoctor merge it?
The approach I took pulls the parsed JavaDoc comments from PSI and then merges those with the new comments
recomp already has neo sources injected
if the neo sources are there then the AP-generated javadoctor.json metadata is there too. and javadoctor searches for that file when injecting too (besides the option for additional files which would be used for the parchment javadoctor metadata)
Oh you mean as part of compiling NF itself?
So the javadoctor.json would be part of neoforge-universal?
mhhm
Since it can't be generated in userdev. We're injecting before recompile runs, so no APs got applied yet
it's an AP applied in neodev
APs applied at userdev level are rather pointless since it's the last step anyways lol
Yes so the json would have to be in neoforge-universal, then gets injected into the source-jar we're processing. Got that so far
That still is more complicated than taking the javadoc IJ has already parsed for us anyway π
the javadoc IJ gave you is in AST format 
Well, it wasn't hard to massage π
while you massage your AST my approach is written and unit tested π
you're implying dealing with IJ's apis is
It isn't, but we have to bite that bullet in any case
(why did i put the popcorn away)
plus we're going to use mixins in neo at some point
and the AP handles javadocs on vanilla methods through mixins
Wait, Mixins that are source visible? How are we doing that??
ducker
Do you have a link for me?
..... there's something missing in that repo. Can you guess what it is? π
docs? the tool wasn't ever used π it was waiting on a jdk bug fix for the longest time
Yes, README.md π π π
I always get so confused when I am greeted by the code of conduct instead
Well the question I was trying to answer for my mental model: where does that fit into the toolchain?
Since without source visibility, there isn't much worth Javadoc-documenting in a Mixin.
Are you guys talking Ducker again π
@full meteor what do you want from my life wrt the new repo
All of it
All of your life will be sunken into it π
@soft scroll nooo just what does need done to get that to publish like the other repos π
also why are you using mapping io instead of srgutils
as of right now we have no policy regarding use of external libraries made by other loaders (read: don't)
wtf do I know π
Also why are libraries "by other loaders" treated any differently from any other maven central library?
just repeating the same thing i've heard against fabric mixin and unpick Β―_(γ)_/Β―
I mean as maintainers I would be open to vote that rule away
I find it annoying
Mapping io can do what srgutil can
unpick isnt on central I think
I can see problems with adding extra repos, but mappings io is on central
i just didn't know about srgutils
so, mappings io isn't needed for parchment in userdev, that's just for reverting parchment parameter names later if we want to use this down the line in NF-dev
anyways do we want to publish this on central
But using an in-house library we have anyway sounds fine, so I can replace that today
I'd say we don't need to, we just need it where all of our other tools are
so NG picks it up without further changes
But alright, TODO for today: [ ] mappings io -> srgutil
markdown failure smh
also this is compiling with java 8, correct?
nope it's not
why no toolchain 
because forgot π
Heh now I obviously can't push anymore.
srgutils, another library with no readme π
mhh, sounds intended /s
@soft scroll how about we bump him to full toolchain member
Instead of just ng7
?
Or is this project simply not configured to allow push access by the toolchain team, while he is already in it? I forgot what we set for him...
It's actually fine, four eye principle or however that translates to english lol
maty shuld just push merge π 
https://www.unido.org/overview/member-states/change-management/faq/what-four-eyes-principle
it's still called the four eyes principle
The four eyes principle: people with glasses are smarter than you, even if you have glasses too?
Hey, that rhymes
I have glasses! does that mean I can push directly to main now 
he is toolchain, but the repo has no team set
π€
Task :cli:publishPlainPublicationToForgeRepository
the task's run too
Yeah I was about to ask, there's no publish repo defined, does your thing do that automatically? π€
repositories {
maven gradleutils.publishingMaven
}
added it in ee42db07343bd65675506ec83baf8ac925a7a801
Also funny, I can run that locally without having any credentials set π€
And it doesn't error or print anything, what?!
Lol
so annoying that gradle doesnΘt fail the taks if itΘs a 403
fuck diacritics
https://github.com/neoforged/actions/actions/runs/7364757277 creds are being added

