Update:
I have created module java/commonapi in which proposal of UpdateHelper and UpdateProject (interface mentioned in my 
previous post) can be found. UpdateHelper is now of course just proxy of AntProjectHelper.

All comments are welcome, thanks.

1. UpdateHelper should not be in a Java-specific module. Probably it should not be a separate class at all; rather
enhance AntProjectHelper to cover this functionality.

2. The UH implementation in ant/freeform is I think superior as it automatically decides which schema to use when
writing: namely, the oldest schema against which the proposed XML validates (for best compatibility).

3. java/project is likely the proper place for the Java-specific helpers. Some are already there.

[jg3] The java/project is the correct place and the API will go there in NB 7.0 In NB 6.1 the code will be a friend API
to collect more feedback about it before making it public. I agree with Tomas M. about this.

> 1. UpdateHelper should not be in a Java-specific module.

Yes, you are right - I did so just to show how UpdateHelper and UpdateProject would look like so we could discuss it
better.

> Probably it should not be a separate class at all; rather enhance AntProjectHelper to cover
> this functionality.

Yes that's one possibility so if you think that I can do it so, I would probably implement it this way. The question
is how to "deliver" UpdateProject implementation to AntProjectHelper. I can think about these possibilities:
- during AntProjectHelper creation (some setter which can be called just once or better probably in
AntBasedProjectFactorySingleton.loadProject())
- put this implementation into project's lookup (probably not good idea at all)
- maybe utilize AntBasedProjectType?

I would prefer the first one but I don't know yet where's the best place to do it and how to do it. I will investigate
more and let you know. Jesse (or anybody else), if you have any idea please let me know, thanks.

>
> 2. The UH implementation in ant/freeform is I think superior as it
> automatically decides which schema to use when writing: namely, the oldest
> schema against which the proposed XML validates (for best compatibility).

Probably I don't know what you mean exactly but the project specific implementation of UpdateProject can behave so. I
guess that there should be some "typical" behaviour for project updating like to ask user if he/she wants to upgrade
project and so on, maybe some common implementation could be created - I will see later.

>
> 3. java/project is likely the proper place for the Java-specific helpers.
> Some are already there.

The motivation for this is exactly like Tomas Zezula wrote - all the classes should be moved to java/project later.

I might suggest creating an extended interface AntBasedProjectType2 with some methods giving optional update
information. Then when using such a factory, your APH would automatically behave sensibly when reading/writing different
project schemas. TBD what the exact behavior should be.

> I might suggest creating an extended interface AntBasedProjectType2

Yes, I agree. I'm going to create branch for ant/project (code_duplicates_96425) module and implement this change. I 
will let you know, thanks.

At least 2 problems here:

1) AntBasedProjectType is staless and so UpdatableAntBasedProjectType has to be stateless as well - now (in the branch 
code_duplicates_96425) it's not, my mistake; I would fix it, probably:
- using another interface (UpdateImplementation probably) which would have all the methods that can be found now in 
UpdatableAntBasedProjectType; UpdatableAntBasedProjectType itself would have only "createUpdateImplementation()" 
method which would be called from APH (and the result cached there as well), or
- try to create stateless UpdatableAntBasedProjectType, each its method would take UpdateContext which would be 
just "holder" for all needed parameters/data

I prefer probably the 1st possibility just because of what AntBasedProjectType does now.

2) there can be "cyclic calls" (is it a correct term for it?)  between APH and UpdatableAntBasedProjectType 
(UpdateImplementation respectively), have a look into e.g. UpdateHelper.getProperties(String) in J2SE project; I can 
think of about 3 possible solutions but have no idea which one is the best:
	- create UpdatableAntProjectHelper - this problem should be solved but another would probably appear - where 
and how it should be created and used etc.
	- create some "flag" just to ensure that no cyclic calls will be done
	- provide all the needed data to UpdateImplementation while calling from APH (using UpdateContext, see above)

I would probably prefer the 3rd possibility.

If I'm missing something or I'm wrong in some case, please let me know.

Thanks a lot.

Andrei, David and me have been discussing this situation and this is the result/proposal:

I'll create public final class AntProjectHelper.UpdateContext which will provide methods for getting APH properties 
needed for project update etc. (for more info see UpdateHelper in J2SEProject) and this UpdateContext will be provided 
to all methods of UpdatableAntBasedProjectType or to UpdateImplementation (not decided yet what I'll implement, see  
my previous comment). This is probably the best solution of this situation because one can later add any method to 
UpdateContext without breaking any existing code.

*** Issue 113895 has been marked as a duplicate of this issue. ***

I would like to complete this for NB 6.1.

Unfortunately not doable for NB 6.1.

Changing to TASK.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss