Look into replacing the manual classpath generation with a simple wildcard

[hugithordarson]

We're currently generating a classpath file that contains a list of all the jars inside Contents/Java. We should be able to replace this with a wildcard.

[hugithordarson]

Not planning on doing this anytime soon

[paulhoadley]

Not planning on doing this anytime soon

Why not? Is it hard?

[hugithordarson]

In theory, no, not hard. It should be enough to just copy the jars into a flat structure (wildcards on the classpath don't enter subfolders) and set the classpath to APPROOT/Resources/Java/*.

But what got me thinking is that we lose control over classpath ordering, which is something I think Wonder cares about, what with all the patches and WO overrides. A classpath wildcard just gives us alphabetical ordering which might not be what we want.

[paulhoadley]

which is something I think Wonder cares about

Yeah. To be fair, it's something I occasionally care about, too, for stuff like overriding the version of a transitive dependency that I can't change directly, say. I hadn't considered ordering—I think that pretty much kills this idea, doesn't it?

Also: on ordering, how is vermilingua doing that? Because the generated UNIXClassPath.txt seems wildly different to a wolifecycle classpath. I forgot to open a ticket for that observation earlier, because I glossed over it, not considering that it defined the runtime ordering. Should we look at that?

[paulhoadley]

Actually, eyeballing it, the UNIXClassPath.txt in a wolifecycle build looks sorted alphabetically. Is this something that vermilingua actually fixes?

[hugithordarson]

Oh… Good catch! Yeah, vermilingua apparently better preserves the classpath generated by maven (i.e. if you change the dependency order in your pom.xml it gets reflected in the generated classpath). I don't remember how deeply I dug into this when writing the plugin, I'm just calling the Maven API's MavenProject.getArtifacts() and trusting it to do the right thing :).

At a glance it also seems the classpath generated by vermilingua is in line with the classpath generated by Eclipse when launching in development (using a plain java launch configuration), which I think should be desirable?

[hugithordarson]

…this all at least probably means that classpath ordering doesn't really matter that much WRT Wonder. After all, ERXApplication spends half it's code doing classpath reordering on application launch :)

[paulhoadley]

But it also means I must be lying to myself when I say:

it's something I occasionally care about, too, for stuff like overriding the version of a transitive dependency that I can't change directly

I suspect what I've been relying on is merely dependency overriding rather that dependency ordering. Phew, for a minute there, I thought I was going mad.

In any case, I imagine what vermilingua is doing is better than wolifecycle, so let's just back away slowly from this ticket now.