#JavaDoctor / NG Parchment Support

141 messages Β· Page 1 of 1 (latest)

full meteor
#

Getting JavaDoctor into NeoGradle and making it read Parchment directly

#

@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

soft scroll
#

so we have the infra for ats in the future without needing to rework it again

full meteor
#

Okay but would I remove the abstraction over javaparser/spon for that?

#

and make the API depend on PSI?

soft scroll
#

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

full meteor
#

But I already have Javadoc integration πŸ˜…

#

I thought I'd just add the parameter stuff to javaDoctor instead hehehehehehe

soft scroll
#

and the at stuff too? LUL

full meteor
#

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

soft scroll
full meteor
#

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 πŸ€”

robust ember
#

We already have an option to supply the classpath

#

I think

soft scroll
#

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

full meteor
#

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
soft scroll
#

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)

full meteor
#

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

soft scroll
#

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

full meteor
#

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

neat compass
#

So this is looking into applying the parchment names at source level rather than binary level?

soft scroll
#

as i said, javadoctor uses param indexes never names

#

not even for generic types

full meteor
#

How do you merge existing javadoc parameters with new parameters?

soft scroll
#

uh?

full meteor
#

Well I suppose indexOf heh

#

Before:

#

After:

#

With parameter renames for x->newX, y->newY and javadoc only added for x and z

soft scroll
#

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

full meteor
#

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

soft scroll
#

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)

full meteor
#

Oh you mean as part of compiling NF itself?

#

So the javadoctor.json would be part of neoforge-universal?

soft scroll
#

mhhm

full meteor
#

Since it can't be generated in userdev. We're injecting before recompile runs, so no APs got applied yet

soft scroll
#

it's an AP applied in neodev

#

APs applied at userdev level are rather pointless since it's the last step anyways lol

full meteor
#

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 πŸ˜…

soft scroll
#

the javadoc IJ gave you is in AST format abolbstare

full meteor
#

Well, it wasn't hard to massage πŸ˜›

soft scroll
#

while you massage your AST my approach is written and unit tested πŸ˜›

full meteor
#

So is mine πŸ˜›

#

And in any case, writing APs is not fun work

soft scroll
#

you're implying dealing with IJ's apis is

full meteor
#

It isn't, but we have to bite that bullet in any case

soft scroll
#

(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

full meteor
#

Wait, Mixins that are source visible? How are we doing that??

soft scroll
#

ducker

full meteor
#

Do you have a link for me?

soft scroll
#

anyways whatever impl we decide on did you work on that replacement api already stabolb

full meteor
#

..... there's something missing in that repo. Can you guess what it is? πŸ˜„

soft scroll
#

docs? the tool wasn't ever used πŸ˜› it was waiting on a jdk bug fix for the longest time

full meteor
#

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.

robust ember
#

Are you guys talking Ducker again πŸ˜„

soft scroll
#

@full meteor what do you want from my life wrt the new repo

robust ember
#

All of your life will be sunken into it πŸ˜„

full meteor
#

@soft scroll nooo just what does need done to get that to publish like the other repos πŸ˜…

soft scroll
#

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)

full meteor
#

wtf do I know πŸ˜„

#

Also why are libraries "by other loaders" treated any differently from any other maven central library?

soft scroll
#

just repeating the same thing i've heard against fabric mixin and unpick Β―_(ツ)_/Β―

robust ember
#

I mean as maintainers I would be open to vote that rule away

#

I find it annoying

#

Mapping io can do what srgutil can

full meteor
#

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

soft scroll
#

anyways do we want to publish this on central

full meteor
#

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

soft scroll
#

markdown failure smh

#

also this is compiling with java 8, correct?

#

nope it's not

#

why no toolchain Stabby

full meteor
#

Heh now I obviously can't push anymore.

#

srgutils, another library with no readme πŸ˜„

soft scroll
robust ember
#

@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...

full meteor
#

It's actually fine, four eye principle or however that translates to english lol

#

maty shuld just push merge πŸ˜› stabolb

sonic tapir
molten pine
#

The four eyes principle: people with glasses are smarter than you, even if you have glasses too?

#

Hey, that rhymes

sonic tapir
#

I have glasses! does that mean I can push directly to main now thinkies

soft scroll
robust ember
#

Ah okey πŸ˜„

#

Configured for management by Toolchain team now

soft scroll
#

it's not published screm

#

where is it

#

feels like something ate it

full meteor
#

πŸ€”

soft scroll
#

Task :cli:publishPlainPublicationToForgeRepository
the task's run too

full meteor
#

Yeah I was about to ask, there's no publish repo defined, does your thing do that automatically? πŸ€”

soft scroll
#
    repositories {
        maven gradleutils.publishingMaven
    }
#

added it in ee42db07343bd65675506ec83baf8ac925a7a801

full meteor
#

Also funny, I can run that locally without having any credentials set πŸ€”

#

And it doesn't error or print anything, what?!

soft scroll
#

german issue

#

OH

#

i forgot to give it the creds

#

knew i forgot something pffft

robust ember
#

Lol

soft scroll
#

so annoying that gradle doesnΘ›t fail the taks if itΘ›s a 403

#

fuck diacritics

full meteor
#

Thank you maty!