Going from ArchiveAssert to AbstractPathAssert and/or the underlying Path

[klausbrunner]

It's nice to be able to assert the existence of a JAR:

        assertThat(result).project().hasTarget().withJarFile();

However, I'd like to get a hold of the actual JAR file and run some more detailed assertions on it that ArchiveAssert doesn't cover. It's not clear how I would do that - I'd expect some way to go at least to Jupiter's AbstractPathAssert or even the actual Path of the JAR artifact.

Right now I basically duplicate what's already inside ArchiveAssert.withJarFile() to get to the JAR:

        Model model = projectResult.getModel();
        String jarName = model.getArtifactId() + "-" + model.getVersion() + ".jar";
        Path jar = result.getMavenProjectResult().getTargetProjectDirectory().resolve("target").resolve(jarName);
        // now do stuff with it

It's just about 3 lines of code, but seems a bit awkward and not very DRY-ish. Is there an easier way of achieving this that I've missed?

[khmarbaise]

First if you miss assertions here..please name them...best would be a real use case to show their usage... makes it easier to understand ...

I know that those parts are at the moment limited because I haven't yet really thought in detail about it...

One thing which is not clear to me...because as far as I know JUnit Jupiter has no AbstractPathAssert?? Only assertj ? Do I misunderstand a thing here?

Currently only .withFile(..) returning AbstractPathAssert Hm...

Currently thinking about returning access to entries, filtering entries etc. in the archives (for jar,ear,...) and make it possible to assert... on the content of them.....but I have to really thinking in more depth about that... maybe you can give some useful cases?

[klausbrunner]

One thing which is not clear to me...because as far as I know JUnit Jupiter has no AbstractPathAssert?? Only assertj ? Do I misunderstand a thing here?

Oh, my fault, it's from AssertJ of course!

Currently thinking about returning access to entries, filtering entries etc. in the archives (for jar,ear,...) and make it possible to assert... on the content of them.....but I have to really thinking in more depth about that... maybe you can give some useful cases?

Yes, I think it's generally not necessary to add additional assertions, but to make it easy to plug in existing ones (like those from AssertJ). In my particular use case I actually had to examine the binary content of the raw JAR file and permissions set on it. That's not a very common use case for sure, but getting to the file itself should cover a lot of cases people may have.