Re: [WARNING] change the package name for custom implementations

Hi,
the solution that I proposed in the attached mail seemed too ugly to me
so at the end I have implemented the change the following way:
1) if MDR finds org.netbeans.implPackagePrefix tag (that can only be
attached to an outermost package), it searches for the implementation
using this prefix.
2) if the tag is not found, but the javax.jmi.packagePrefix is present,
MDR does the following:
	2a) if the packagePrefix is "javax.jmi", MDR assumes the implementation
package prefix is "org.netbeans.jmiimpl.mof"
	2b) if the packagePrefix starts with "org.netbeans.jmi", implementation
package prefix will be the same but the "jmi" is replaced by "jmiimpl" -
i.e. org.netbeans.jmiimpl....
	2c) if the packagePrefix is "org.omg" or starts with "org.omg.",
implementation package prefix will be the same but the "org.omg" is
replaced by "org.netbeans.jmiimpl.omg"
	2d) in all other case, implementation package prefix will be
packagePrefix + ".impl"
3) if the javax.jmi.packagePrefix is not present, implementation prefix
is "impl"

As a result of this change, all the implementation classes for MOF
metamodel elements moved from javax.jmi.model.impl to
org.netbeans.jmiimpl.mof.
I have updated the documentation however I was not able to update tests, 
as the people who wrote them did not check the source code of the 
"impl-classes" into the CVS.
Hopefuly we will fix this soon and all the sources will be put into the CVS.
Regards,
Martin

PS: Milan, I have updated also the tests as you hoped :)

Martin Matula wrote:
 > Hi,
 > till now if you provided implementation of derived attributes or
 > operations in your metamodel, you had to put it into
 > <model_package_prefix>.impl package. I would like to change it to
 > prevent problems with using standard packages like javax.* or org.omg.*.
 > The proposed solution is that MDR will look for implementations in
 > nbmdrimpls.<model_package_prefix> packages. For now I do not want to
 > have this configurable using tags as it would slow the MDR down. We may
 > introduce tags later if we find out that the impact on the performance
 > is not too big, but anyway, the proposed solution would be the default
 > one when no tags are used.
 > I would like to integrate this change tomorrow or during the weekend and
 > wanted to give you a chance to analyze the impact on your code and
 > comment, since this is a significant change.
 > Thanks,
 > Martin
 >