RE: [mylar-dev] Stand alone bug tracking

In the near-term my main concern is that 1.5 only compatibility will prevent some from contributing to Mylar. In the longer term yes, this tool should not be limited to the masses who are still stuck on 1.4. Also, the fact that there is no 1.5-based free software stack bothers me.

Next week we’ll try to set up a 1.4 compatible retroweaver/backport build and document progress on https://bugs.eclipse.org/bugs/show_bug.cgi?id=104601. Also, removing the 1.5 stuff from mylar.tasklist and mylar.bugzilla is not out of the question if that results in contribution to those components, but since that will be a pain we’ll wait to see what happens with Retroweaver.

Mik

From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: August 17, 2005 4:20 PM
To: Mylar developer discussions
Subject: [mylar-dev] Stand alone bug tracking

Mik,

1.4 source compatibility would come at a price higher than just rewriting
all of the very convenient generics and other language extensions. Mylar
itself depends on some 1.5-specific features like annotations, e.g. a future
release will allow you to declare the interest level of a key element via a
1.5 annotation on that element. So before exploring the source option I'd
like to understand what we would lose by only being 1.5 binary compatible
via Retroweaver, assuming that it works well and can be integrated into the
automated build.

I agree with Jeff Pound that it would be easier for community and will simplify build process if Mylar can sacrifice Java5 requirement (e.g. make it optional in runtime) and maintain JRE 1.4 support.

As for annotations backport175 (Apache 2.0 License) provides a good abstraction layer for both Java 5 and JavaDoc-based annotations.
You probably know that Java5 Annotations can be accessed from the earlier VM's (e.g. Mylar built on 1.4 can see annotations in plugins built on Java5 even without using Jva 5 API). That is how backport175 and Retroweaver support annotations. I happend to write an article about this before backport175 appeared. See http://www.onjava.com/pub/a/onjava/2004/10/20/asm.html

While I agree that it is important all Eclipse *Tools* projects to match the
platform's compatibility, I think that it is equally important for
*Technology* projects to not have this constraint so that we can be forward
thinking. But we're also focusing hard on Mylar easy to build on and
extend, so I would definitely like to hear more about whethre binary-only
compatibility will be a showstopper for people interested in contributing.

This is an important question and likely to come up again, so I think that
we can use it to kick off an FAQ...

It should be also taken into the consideration that using Java5 can slow down the adoption and narrow the end-user community. By choosing Java5 only approach you probably shifting mass user acceptance of the Mylar-based tool to about one year from now. That could be a huge loose for Eclipse platform, especially if competitors will implement this technology (and I believe they will).

regards,
Eugene