Re: [mmt-dev] QVTo code reviews

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I've done a 3.2.0a build today, so if you'd like to pick up the results from https://hudson.eclipse.org/hudson/job/buckminster-mmt-qvto-branch-tests/ any ad hoc user testing would be invaluable. My access to simrel has just been removed because I'm 'inactive', so publishing is delayed. Once 3.2.0a is checked we can bump to 3.2.1.

Incrementing the plugins wasn't actually necessary. All Juno changes had been increased to 3.2. But none of the features had been. The plugins for Kepler could be decremented again if we warn people. Need to do so tomorrow if we do.

I've raised a Bugzilla for the code cleanup, mainly to document the difficulties I found.

I'm just starting to look at the duplicate warnings. I suspect it's just a matter of deleting redundant routines. But suddenly the JUnit tests fail on me again.
- problem 1: EGIT doesn't nirmalize line endings
- problem 2: QVTo tests use line.separator not project settings.
- solution, set all projects to Unix line endings, convert all line endings to Unix, change QVTo tests to Unix line endings.

You might want to check that the Help Contents is satisfactory without the auto-build. Javadoc links to a www, which is not yet populated. ZIP is in the Hudson artefacts.

    Regards

        Ed


On 21/08/2012 20:55, Sergey Boyko wrote:

Hi Ed,

 

Thank you very much for the dealing with Git and especially with Buckminster!  Migration of build config is really painful task, at least for me as I'm quite unfamiliar with Buckminster.

As for incrementing version of all plug-ins - generally it's not common operation in the absence of actual source changes. However I believe most dependencies used [3.x, 4.0) range and such changes are quite seamless for most consumers.

I'm going to start giving more time for the project than I did till now. I follow your intention of cleaning QVTo sources and I can do either a) or b) and review changes for another.

 

Maintenance 3.2 build is good suggestion. So we need 3.2 branch (and possibly separate build config on Hudson, right?).

 

Regards,

  Sergey.

On Mon, Aug 20, 2012 at 8:14 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Sergey

The QVTo build seems ready to go. A 3.3 I-build is already contributed to the aggregator. A 3.3 S-build is successfuil against platform and EMF milestones. Should be ready to go as soon as OCL S-build is promoted. [I bumped all the plugin number to guarantee new versions and avoid hazards whereby very few if any '3.2' changes caused a change to 3.2.]

What is your availability for participating in the QVTo project?

I'd like to at do a couple of tidy-ups.

a) Get rid of 500 compiler warning messages.

A quick play at inserting missing generics suggested that there were API risks if intuitively tight parameters were used and mandatory EcoreEnvironment was propgated back through callers, so I think that the safe solution is just class-level @SuppressWarnings.

b) Get rid of the duplicate library warning messages now that some QVTo operation are in OCL.

Will you be in a position to review these or should I just go ahead? The duplicate warnings could usefully go in the maintenance build which might provide the missing 3.2 R-build.

    Regards

        Ed Willink
_______________________________________________
mmt-dev mailing list
mmt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/mmt-dev

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5213 - Release Date: 08/21/12