Re: [ajdt-dev] Feedback requested: AJDT versioning

[Andy Clement <andrew.clement@xxxxxxxxx>]

Interesting discussion - i'll just chip in with some thoughts.

> I do think there's a legacy relating to the JDKs and AJ versioning, which isn't that helpful and it would be more informative for an IDE tool for it to relate to it's JDT counterpart.

Actually the AJDT version isn't in any way related to the AspectJ or
Java version it has just ended up apparently looking like that
(possibly another reason to entirely jump to a new level !).  AJDT was
just going up minor releases as eclipse releases went up and it
happened that at Eclipse 3.4 the AJDT version became 1.6 (Eclipse 3.3
had 1.5.X, Eclipse 3.2 had 1.4.X and Eclipse 3.5 is currently looking
at 1.7.X).

> I think we should increment major versions when the user would expect them, for example:
> - an indication to new users that there is something new, worthy of being in a New and Noteworthy document (i.e. 3.5 has N&Ns, but 3.4.2 naturally doesn't).  I think we should increment the major number when that changes (the change to the JDT weaving would therefore have been 1.6.x -> 1.7.  In AJ, the intro of @DeclareMixin would have equally been a notable change).
> - an indication of API changes.  I think this is more of an issue for AJ than AJDT, although I guess it would be good to be able to be able to update AJDT core without updating the cross refs view etc.  I suspect those should update independently really.
> We could have had a major version change when the weaving service was introduced.  As far as I understand, it was a significant change to the API for people adopting AJDT, but probably more important to them would have been the change in documentation.  We should ensure that AJ and AJDT are UI and API-predictable for adopters.

I do think we should have thought harder about upping the version
number with the introduction of JDT weaving - but as the currently
policy fixed the major and minor numbers based on the eclipse level we
took the easy option.

I don't really want to get into a debate on the AspectJ version number
as I do like that it matches the Java level.  The interface between
AJDT and AJ is hardly ever likely to be used by anything else so
effectively it is internal API.  I'm not against someone trying to use
it to integrate AJ into another tool - and then I'd be more careful
about API changes - but I don't see the value in being cautious for no
reason.

> I would be interested to hear feedback from people working on MyEclipse, JBuilder, and other Eclipse-based IDE distros.  So far, it seems that no-one has done anything to annoy any of them, but that probably means that neither is building commercial products on top of AJDT.

The other IDEs that drive AspectJ do not go anywhere near the detailed
interfaces that AJDT uses, and they continue to work because the
AJBrowser tool drives those and tests them.  But that interface is
simply 'here compile these files and give me a model back'.  I did
accidentally break pointcut doctor a while back, but there haven't
been enough shouts to get that working again so it hasn't bubbled to
the top of my todo list.  Anyone using pointcut doctor?

> Most significant in terms of adopters is probably SpringSource's commercial offerings, which I've heard we have connections to ;)
>
> I'd suggest that Spring give some input of requirements.

:) The creation of the org.aspectj.matcher jar and the splitting of
matching and weaving is driven by requirements that came out of
SpringSource - where users exploiting Spring AOP just want the
matching code and then to rely on dynamic proxies for advice
invocation.  We work closely with Spring IDE and Spring Framework -
and any work items coming out of these discussions are tracked in
public bugzilla.

> Going forwards, I think it would be good, both with AJ and AJDT to have some ability to push new API and even have some risk of breaking someone's use of assumed API.  An example I discovered is the change I'd like to see on the weaveinfo messages.  That change would impact Spring users, and it's something I'd consider part of clarifying the API to, in that case the AJ weaver.

How do you see the weaveinfo change as impacting spring users?

I think any requirement to document the public interface of AspectJ -
the compiler or the weaver, has to be partly driven by whether it is a
sensible use of time.  At the moment I don't see enough people using
it that it is worth having to create (and maintain) a document like
this.  I do think the javadoc across the codebase could be greatly
improved and I'd like to think we can do that as we go along and
revisit older areas.  The lack of sensible doc here occasionally
causes a problem - for example when a user wants to write their own
classloader exploiting the ltw infrastructure we have, but that
doesn't seem to happen very often.

> While it may be a bit more overhead for the build management, I think it would be good to create the room to be bolder.  To a great extent, I'd say that AJ and AJDT only operate a maintenance branch, where the e3.5 code during the last year ought to be something that stimulates more adventurous input.
>
> Perhaps a good aim for e4 would be to release AJDT builds with the milestone builds, from an advanced branch.

What would you consider is more adventurous input?  If someone wants
to come along and write a code analyzer that does extra static
analysis of if pointcuts to reduce runtime tests, that's fine - I'd
take that contribution - I think Alex V asked for some work in this
area the other day.  If someone else wants to allow more pointcut
tests to move to runtime in order to reduce the number of types we
search for at weave time (that can lead to cantFindType errors) then
I'm fine with taking that too.

And I would agree with you that we play things relatively safe with
AJDT and AJ - so everyone can rely on the next version being better
than the last.  However, during AspectJ 1.6 releases I have completely
rewritten the bytecode manipulation code to reduce the weaver size by
25%.  And JDT weaving has come out and turned AJDT on its head, with
everything being possible now where our hands were tied previously.
The existence of the test suites enables these radical modifications.

> As for 3.4 vs 3.5, that's a challenge.  What are the plans after 3.5 is released?  Will the 3.4 release (i.e. 1.6.x as currently stands) get new features back ported, or just requested bug fixes for people stuck on an old release until MyEclipse, JBuilder, Rational etc update to 3.5?

I imagine the story will be the same as usual.  Main development will
switch to AJDT 1.7.x for Eclipse 3.5.  Compiler upgrades will continue
to be fed into 1.6.x builds and AJDT features may get back ported if
there is enough interest.  Surprisingly I didn't see much interest in
having the massive incremental build improvements back ported from
AJDT 1.6 for Eclipse 3.4 to AJDT 1.5 for Eclipse 3.3.  I raised this
bug to collect input from anyone wanting back porting but didn't get
any interest

https://bugs.eclipse.org/bugs/show_bug.cgi?id=252021

so I'm glad we didn't invest too much time in that.  We do our best
for those users stuck on older eclipse based tools, like the Rational
suite - and fixes for that are usually what trigger service releases
of the older AJDT levels.

Andy.

2009/4/22 Neale Upstone <neale@xxxxxxxxxxxxxxxx>:
> I agree with Martin on the API point to the extent that there should be
> binary compatibility for the minor versions.
>
> I don't think that the 1.x version number is seen as 'immature' any more
> than I really think that Mylyn is mature due to it being v3.1 or TPTP being
> better than YourKit cos it's a higher version.
>
> I do think there's a legacy relating to the JDKs and AJ versioning, which
> isn't that helpful and it would be more informative for an IDE tool for it
> to relate to it's JDT counterpart.
>
> I think we should increment major versions when the user would expect them,
> for example:
> - an indication to new users that there is something new, worthy of being in
> a New and Noteworthy document (i.e. 3.5 has N&Ns, but 3.4.2 naturally
> doesn't).  I think we should increment the major number when that changes
> (the change to the JDT weaving would therefore have been 1.6.x -> 1.7.  In
> AJ, the intro of @DeclareMixin would have equally been a notable change).
> - an indication of API changes.  I think this is more of an issue for AJ
> than AJDT, although I guess it would be good to be able to be able to update
> AJDT core without updating the cross refs view etc.  I suspect those should
> update independently really.
>
>
> In addition, let's look backward and forwards:
>
> We could have had a major version change when the weaving service was
> introduced.  As far as I understand, it was a significant change to the API
> for people adopting AJDT, but probably more important to them would have
> been the change in documentation.  We should ensure that AJ and AJDT are UI
> and API-predictable for adopters.
>
> I would be interested to hear feedback from people working on MyEclipse,
> JBuilder, and other Eclipse-based IDE distros.  So far, it seems that no-one
> has done anything to annoy any of them, but that probably means that neither
> is building commercial products on top of AJDT.
>
> Most significant in terms of adopters is probably SpringSource's commercial
> offerings, which I've heard we have connections to ;)
>
> I'd suggest that Spring give some input of requirements.
>
> Going forwards, I think it would be good, both with AJ and AJDT to have some
> ability to push new API and even have some risk of breaking someone's use of
> assumed API.  An example I discovered is the change I'd like to see on the
> weaveinfo messages.  That change would impact Spring users, and it's
> something I'd consider part of clarifying the API to, in that case the AJ
> weaver.
>
> While it may be a bit more overhead for the build management, I think it
> would be good to create the room to be bolder.  To a great extent, I'd say
> that AJ and AJDT only operate a maintenance branch, where the e3.5 code
> during the last year ought to be something that stimulates more adventurous
> input.
>
> Perhaps a good aim for e4 would be to release AJDT builds with the milestone
> builds, from an advanced branch.
>
> In that respect, it seems that defining the API more rigorously would help.
> Perhaps it's worth doing a bug triage, and tagging [api] to get a sense of
> what we may be holding back on due to breakage concerns.
>
> I think we could and should be bolder and look to the long term with the
> e3.5 stream, especially in preparation for e4, were I see no reason not to
> expect significant changes in IWorkspace, IWorkbench, IProject etc.
> Minimally for e4, I hope to be seeing native support in JDT for test source
> and output folders, and support for flexibility in the location of .project
> .settings etc.  These will impact AJDT.
>
> As for 3.4 vs 3.5, that's a challenge.  What are the plans after 3.5 is
> released?  Will the 3.4 release (i.e. 1.6.x as currently stands) get new
> features back ported, or just requested bug fixes for people stuck on an old
> release until MyEclipse, JBuilder, Rational etc update to 3.5?
>
> Cheers,
>
> Neale
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 22/04/2009 07:47, Martin Lippert wrote:
>
> Hi!
>
> Just a thought that came into my mind when reading through this:
> Traditionally the versioning schema is somehow related to API compatibility.
> So changing only the minor version number means to have binary
> compatibility, changing the major version means to break compatibility.
> Haven't thought about what that means to the options you presented, but
> maybe this provides some guidance...?!?
>
> Just some thoughts,
> -Martin
>
>
> Andrew Eisenberg wrote:
>
> Hi all,
>
> Because of the major changes that have occurred in AJDT over this last
> year, we are considering bumping up the major version number soon.
> This would most likely be for around the release of Galileo in late
> June.  This change in versioning would symbolize a new level of
> maturity of AJDT
>
> However, before deciding on a new versioning scheme, we'd like to
> discuss the options with the community and come up with something that
> is indicative of AJDT's maturity, but at the same time would not be
> confusing to new or existing users of the tool.
>
>
> Option 1:
> Next AJDT for Eclipse 3.4 becomes AJDT 2.0
> Next AJDT for Eclipse 3.5 becomes AJDT 3.0  (was AJDT 1.7)
>
> Benefits: this gives us a lot of room to increment AJDT's minor
> version numbers for 3.4, and we can continue to increment the major
> version every year for the next release of Eclipse
> Disadvantages: breaks away from the tradition of incrementing minor
> versions in step with Eclipse and micro versions throughout the year.
> Could be confusing for existing users.  Also, AJDT 3.0 would not be
> significantly different from 2.0 (in fact they should be mostly the
> same except for changes specific to Eclipse 3.5).
>
> Options 2:
> Next AJDT for Eclipse 3.4 becomes AJDT 2.6.6
> Next AJDT for Eclipse 3.5 becomes AJDT 2.7.0
>
> Benefits: continues with the tradition of keeping minor versions in
> step with Eclipse minor versions
>
> Disadvantages: What happened to 2.0 and to 2.5?  Could be confusing
> for new users.
>
> Option 3:
> Keep as is
> Next AJDT for Eclipse 3.4 becomes AJDT 1.6.6
> Next AJDT for Eclipse 3.5 becomes AJDT 1.7.0
>
> Benefits: Each version of AJDT is only an incremental improvement over
> the last one, and so perhaps bumping up the major version is not
> justified.
>
> Disadvantages: AJDT has changed significantly over the past year, that
> perhaps this is justified.
>
> Your input on this issue is greatly appreciated.  Also, other
> possibilities will be considered if someone suggests them.
>
>
> thanks,
> --a
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
>