It's not a secret anymore!*
The moose likes Websphere and the fly likes Editions and Versions in VisualAge for Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "Editions and Versions in VisualAge for Java " Watch "Editions and Versions in VisualAge for Java " New topic
Author

Editions and Versions in VisualAge for Java

Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi,
I has some queries regarding Versions and Editions feature of VisualAge for Java.
The online doc says that when the code is saved, invariably a new edition is created.Assume that we have created 2 editions for a method, and then we version the class with the latest(second) edition of the method.Will the version know/keep into account the previous(first) edition of the method?
I believe versioning a class means freezing the changes for that class.So the Developer shouldn't be allowed to change the editions for any of its program elements using the "Replace With.." option for this Version; i.e. Version should be immutable.Infact, once a class has been versioned for a particular edition, all the previous editions of the methods should be removed automatically or it should be allowed to be removed by the Developer (with proper rights!).Is this how Versioning works in VA4J?
Also, when editions for methods,classes,etc. are created, the timestamp for that edition is captured.However, we see that VA4J shows the timestamp only for class,package and project in the workspace.Why does it not do the same for the methods and the fields?Is it not misleading, if the class shows a previous edition timestamp and its method and fields have another timestamp?The Developer could incorrectly assume that no changes has been made in the program elements after the timestamp shown by the class, which may not be the case.In short, I would like a feature which keeps me informed on the latest changes done to the program elements in the workspace itself.
Lastly, is there a feature to un-version (or say demote) a class?It is quite possible that a particular version is not of the quality that was expected.So instead of creating a new Version, will it not be better to un-version and then freeze it as the same version?
Would like to hear your views on this
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited July 06, 2001).]


<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
Again, I'm new with VAJ, but here is my understanding of the answers to your questions. Until you master versioning, it probably pays to work with Windows - Show Edition Names enabled.
"The online doc says that when the code is saved, invariably a new edition is created."
Right. at least when you save a method. When you modify a method in your workspace and save it, VAJ creates automatically creates a new edition of that method in the repository. The old edition of the method still exists in the repository, too. To see what happens to the new edition of the method, consider what happens to the class containing the method.
If the class in your workspace containing that method was already an open edition, it now contains the new edition of the method instead of the old edition of the method. This open edition is stored in the repository.
If the class in your workspace containing that method was a versioned edition, that version of the class cannot be modified. So VAJ automatically creates an open edition of class, with method just modified replaced by the new edition of that method. This open edition is stored in the repository. The old version of the class is still in the repository, untouched, with the old version of the method.
If the containing package in your workspace is versioned, VAJ must create some new edition of the package to contain the new open edition of the class. In VAJ-Professional, this new edition of the package will be an open edition. (VAJ-Enterprise handles this differently.) This new edition is stored in the repository.
Likewise for the project, if the workspaces contains a versioned edition of the project instead of an open edition.
"Assume that we have created 2 editions for a method, and then we version the class with the latest(second) edition of the method.Will the version know/keep into account the previous(first) edition of the method?"
No. The new version of the class will not know of the previous edition of the method (except possibly that it remembers which is the "previous edition" if you use "Replace with Previous Edition" on the method).
When you save a method, the resulting open edition of the class in both the workspace and the repository knows only of the newly saved edition of the method. It is no longer associated with the previous edition of the method. If you version this open edition of the class, it continues to know only of the new edition of the method.
What about the old edition of the method? Well, if the class was previously versioned with an old edition of the method, then that version of the class will continue to refer to the old edition of the method. Otherwise, the unused edition of the method reposes in the repository in case you decide you want to refer to it in the future.
"I believe versioning a class means freezing the changes for that class."
It freezes changes for *that version* of the class. The next time you try to modify anything in the versioned class, a new open edition will be created, and your modifications will be made there. The versioned edition will remain in the repository unchanged.
Changing a versioned class/package/project means creating a new open edition of that class/package/project and making the changes there, leaving the versioned edition of the class/package/project untouched. This happens automatically for classes, packages, and projects in VAJ-Professional. (As I recall, it happens automatically for classes in VAJ-Enterprise. But in VAJ-Enterprise, it can require additional actions for packages and projects, or can result in the automatic creation of scratch editions, which are editions not in the repository.)
"So the Developer shouldn't be allowed to change the editions for any of its program elements using the "Replace With.." option for this Version; i.e., Version should be immutable."
The versioned edition immutable. If you apply "Replace With..." to a method in a versioned edition of a class, VAJ creates a new open edition, leaving the versioned edition of the class unchanged.
"Infact, once a class has been versioned for a particular edition, all the previous editions of the methods should be removed automatically or it should be allowed to be removed by the Developer (with proper rights!).Is this how Versioning works in VA4J? "
Uh-oh! You are talking about "proper rights". I think that notion applies only to VAJ-Enterprise. I've been talking only about VAJ-Professional, for simplicity. If we were talking about VAJ-Enterprise and team development, I would have had to talk about releasing, ownership, and scratch editions in the discussion above. Let's keep this discussion on for VAJ-Professional only. Back to the question.
Once you replace a method in a class with a different edition, the previous edition of the method is no longer used by the this edition of the class. However, if some previously versioned edition of the class refers to the old edition of the method, then the old edition of the method needs to be kept in the repository as long as that versioned edition of the class is kept in the repository.
Now, at some point, you will want to clean out your repository. As I recall, Compact Repository permanently removes everything from the repository that is not part of a versioned PACKAGE! Everything! It removes open editions of packages. It removes open editions of classes. It removes versioned editions of a class, if that version is not included in a versioned edition of a package. And it removes all the editions of methods that are not part of a version of a class that is referenced in a versioned edition of a package. So you don't want to Compact Repository without following the recommended preparatory steps to ensure that you keep what you want to keep, and get rid of what you want to be rid of.
You can also purge objects, which simply makes them invisible until you either restore them, or remove them using Compact Repository.
"Also, when editions for methods,classes,etc. are created, the timestamp for that edition is captured.However, we see that VA4J shows the timestamp only for class,package and project in the workspace.Why does it not do the same for the methods and the fields?Is it not misleading, if the class shows a previous edition timestamp and its method and fields have another timestamp?The Developer could incorrectly assume that no changes has been made in the program elements after the timestamp shown by the class, which may not be the case.In short, I would like a feature which keeps me informed on the latest changes done to the program elements in the workspace itself."
Open editions are named by the time at which the open edition was created, not the time at which the object, or a subordinate, was last modified. If you think of it is the time at which something was modified, you will be misled. Sometimes, you find yourself working on several open editions at once. It would be very confusing if the name of an open edition changed every time you edited it.
One way to find out what changes have been made recently is to compare to a earlier edition.
Methods have edition names, but the edition name is always the time the edition was created, which, for a method, is always the time the method was saved creating that edition. To see it, right-click on the method and select Properties.
"Lastly, is there a feature to un-version (or say demote) a class?It is quite possible that a particular version is not of the quality that was expected.So instead of creating a new Version, will it not be better to un-version and then freeze it as the same version?"
No, it is not better to un-version. It is very bad to change a named version in any way, or to play games with the version naming that would make it appear you have done this. It is much better to say "Version 1.01 was bad. Don't use it. Use the fixed Version 1.01a instead." What happens if a copy of the Version 1.01 with the old content every got out to a customer, or into the hands of a developer handling a customer problem, or building a fix release? What happens you ever have to restore from a backup made with the content assigned to that version name?
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Hi John,
Thank you for the response.I was slightly tied up with my work.I will go through your note and will post any further queries that I might have.
Thanks once again,
Sandeep
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Editions and Versions in VisualAge for Java