[alesj]

Though honestly, keeping track of your resources and explicitly unmounting is not that hard - I don't see why it is such a burden.

This is actually what we're doing currently.
And so far the latest VFS version doesn't seem to be bad in cleaning up after itself. :-)

[alesj]

They should not be limited to a single global static list.

Hmmm, here practice proves you wrong. ;-)
We already went by this approach and it didn't work out - see below.

And it's not appropriate for an archive deployer to explicitly manage nested archives of a type with which it is not familiar or authoritative over.

They can do the reverse, simply state the ones they are not able to support from the global ones.
Which is usually a small set, whereas you can easily miss some that you do.

[alesj]

I think the quick/easy fix would be a mistake here.

I'm not looking for a quick&easy&dirty fix here.
I'm simply looking for an old API mapping to the new functionality.

How you glue those "assembled" or temp or what-ever-you-wanna-call-them resources,
I don't really care, all I need is the old API.
Which shouldn't be that difficult to support, or,
if it is difficult, then there is something wrong with the new API.

The issue is if I don't have this old API present in VFS or some other top level project/artifact,
it means I have to re-write a lot of MC's tests, which is definitely something I don't wanna do or have time for.

[dmlloyd]

"alesj" wrote:

They should not be limited to a single global static list.

Hmmm, here practice proves you wrong. ;-)
We already went by this approach and it didn't work out - see below.

And it's not appropriate for an archive deployer to explicitly manage nested archives of a type with which it is not familiar or authoritative over.

They can do the reverse, simply state the ones they are not able to support from the global ones.
Which is usually a small set, whereas you can easily miss some that you do.

The issue probably stemmed from the fact that archives were always auto mounted. With the new system, archives that are not recognized/supported by any deployers or classloaders or whatever are simply ignored and treated as regular files. We should never need to worry about a global list because the various deployers will always pick up what's theirs.

[dmlloyd]

"alesj" wrote:

I think the quick/easy fix would be a mistake here.

I'm not looking for a quick&easy&dirty fix here.
I'm simply looking for an old API mapping to the new functionality.

How you glue those "assembled" or temp or what-ever-you-wanna-call-them resources,
I don't really care, all I need is the old API.
Which shouldn't be that difficult to support, or,
if it is difficult, then there is something wrong with the new API.

The equivalent you want is probably "VFS.mountTemp()".

"alesj" wrote:

The issue is if I don't have this old API present in VFS or some other top level project/artifact,
it means I have to re-write a lot of MC's tests, which is definitely something I don't wanna do or have time for.

Like Jason said - the first thing we're doing is porting over the VFS tests. Once that's done we'll be looking at the greater integration question. As we discussed in the meeting, if you don't want to do this work, you don't have to (Jason and I are the ones to whom the work was assigned) - but if you do, that's great as well. In terms of the tests, if that's the only reason for the API, then just duplicate the API in the tests. Tests are not a sufficient reason to keep an API around, no matter how inconvenient it is.

That said, if you want to use the mountTemp() API instead, that's even better.

[alesj]

The issue probably stemmed from the fact that archives were always auto mounted. With the new system, archives that are not recognized/supported by any deployers or classloaders or whatever are simply ignored and treated as regular files. We should never need to worry about a global list because the various deployers will always pick up what's theirs.

There is only one deployer that probably needs to recognize it,
and that's structure deployer - JarStructure.
I guess we can drop it ... I'll check once we have something more working.

[ropalka]

"alesj" wrote:

it means I have to re-write a lot of MC's tests, which is definitely something I don't wanna do or have time for.

IMHO this is a responsibility of the person doing the refactoring.

Generally speaking refactoring is always about functional and passing tests. If someone is doing API refactoring and he's not refactoring and running the tests in each refactoring iteration then it's not refactoring. I'd call it "experiment" or "prove of concept research"
that has high probability to fail at the end of day :(