https://pantsbuild.org/ logo
Powered by
#general
  • f

    fast-megabyte-33579

    04/12/2016, 5:15 PM
    if I use --no-cache-compile-read it works "as I would expect"
  • f

    fast-megabyte-33579

    04/12/2016, 5:16 PM
    oh no it doesn't
  • e

    enough-analyst-54434

    04/12/2016, 5:16 PM
    I made an error in anlysis above. You must place the dependency on the 3rdparty anotation processor (and your hack resources target), in every target owning sourcecode with the annotation to be processed
  • e

    enough-analyst-54434

    04/12/2016, 5:17 PM
    Since all targets are now compiled in isolation
  • f

    fast-megabyte-33579

    04/12/2016, 5:17 PM
    so in this instance that's just the "entity" target?
  • e

    enough-analyst-54434

    04/12/2016, 5:17 PM
    yup
  • f

    fast-megabyte-33579

    04/12/2016, 5:17 PM
    that makes sense
  • e

    enough-analyst-54434

    04/12/2016, 5:19 PM
    If you get the error again, you want to fire up 
    ./pants server
    and look at the stdout - classpath - for the target, should have both the 3rdparty jar and the local resources target dir
  • f

    fast-megabyte-33579

    04/12/2016, 5:19 PM
    well currently 
    compile
    is just doing nothing even if I change my resource file
  • f

    fast-megabyte-33579

    04/12/2016, 5:19 PM
    Copy code
    18:19:21 00:00   [compile]
18:19:21 00:00     [compile-jvm-prep-command]
18:19:21 00:00       [jvm_prep_command]
18:19:21 00:00     [compile-prep-command]
18:19:21 00:00     [compile]
18:19:21 00:00     [zinc]
18:19:21 00:00     [jvm-dep-check]
18:19:21 00:00   [complete]
               SUCCESS
  • e

    enough-analyst-54434

    04/12/2016, 5:22 PM
    If this is modern pants, artifact caching is on for everything IIUC, so there may be a related caching bug and if so you'll need to blow away your local artifact cache
  • e

    enough-analyst-54434

    04/12/2016, 5:22 PM
    I've lost track of where that lives by default
  • f

    fast-megabyte-33579

    04/12/2016, 5:22 PM
    I have 
    local_artifact_cache = %(pants_bootstrapdir)s/artifact_cache
  • e

    enough-analyst-54434

    04/12/2016, 5:23 PM
    k - try mv 
    ~/.cache/pants/artifact_cache /tmp
    then
  • e

    enough-analyst-54434

    04/12/2016, 5:24 PM
    And use a clean-all on the run to make sure .pants.d caching is nuked as well
  • b

    bored-art-40741

    04/12/2016, 5:25 PM
    Zinc compilation isn't invalidated by changing resources
  • f

    fast-megabyte-33579

    04/12/2016, 5:27 PM
    ok, I forced a recompile by trivially changing one of the .java file, but my 
    resource
    file isn't being included in the output jar, and it's no longer reading it to find the annotation processor (I called it something that didn't exist)
  • f

    fast-megabyte-33579

    04/12/2016, 5:28 PM
    thanks for your help, I'm going to poke a bit more
  • e

    enough-analyst-54434

    04/12/2016, 5:28 PM
    k
  • e

    enough-analyst-54434

    04/12/2016, 5:29 PM
    Now that the use of 
    annotation_processor
    is hopefully more clear - you could just bastardize it
  • e

    enough-analyst-54434

    04/12/2016, 5:31 PM
    ie: kill the resource file you created, change the entity target to an 
    annotation_processor
    target (an comment the hell out of the hack) and set its 
    processors
    attribute to 'com.querydsl.apt.jpa.JPAAnnotationProcessor'
  • e

    enough-analyst-54434

    04/12/2016, 5:32 PM
    ... but that might not work - so probably nevermind. There is a chicken-egg issue there
  • e

    enough-analyst-54434

    04/12/2016, 5:32 PM
    Oh - same chicken/egg issue with the local file hack anyway
  • e

    enough-analyst-54434

    04/12/2016, 5:33 PM
    If you can just jar up the resource in a single-file jar and throw that up on your local nexus + add 3rdparty dep
  • e

    enough-analyst-54434

    04/12/2016, 5:33 PM
    That will be the most straightforward way to get moving
  • e

    enough-analyst-54434

    04/12/2016, 5:35 PM
    The problem with the resources target approach is I was assuming the resources target would get processed by pants before your entity target, but I think that's wrong and it gets processed at the same time - which is too late for javac (IOW: the resources target will not be on the entity target classpath during compilation)
  • f

    fast-megabyte-33579

    04/12/2016, 5:35 PM
    ahh
  • e

    enough-analyst-54434

    04/12/2016, 5:35 PM
    Sorry for the run-around!
  • f

    fast-megabyte-33579

    04/12/2016, 5:37 PM
    I miiiiight just remove our use of this library
  • f

    fast-megabyte-33579

    04/12/2016, 5:38 PM
    I don't particularly fancy supporting custom jars for ever
1...115411551156...2420Latest