objectteams-dev http://dev.eclipse.org/mhonarc/lists/objectteams-dev/maillist.html objectteams-dev en-us Fri, 03 May 2013 17:55:11 GMT Fri, 03 May 2013 17:55:11 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) objectteams-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/objectteams-dev/maillist.html [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00017.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.2" is in the past, but the release is not m... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.2" is in the past, but the release is not marked as completed. If it is completed, it should be marked as completed; if it has been postponed, it should be given a new target date. ]]> Fri, 05 Apr 2013 04:00:12 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00017.html emo@xxxxxxx (portal on behalf of emo) [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00016.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.1" is in the past, but the release is not m... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.1" is in the past, but the release is not marked as completed. If it is completed, it should be marked as completed; if it has been postponed, it should be given a new target date. ]]> Fri, 05 Oct 2012 04:00:07 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00016.html emo@xxxxxxx (portal on behalf of emo) [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00015.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.0" is in the past, but the release is not m... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "2.1.0" is in the past, but the release is not marked as completed. If it is completed, it should be marked as completed; if it has been postponed, it should be given a new target date. * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Thu, 05 Jul 2012 04:00:08 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00015.html emo@xxxxxxx (portal on behalf of emo) [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00014.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no next/future release of this project. All Eclipse projects... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Fri, 05 Aug 2011 04:00:03 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00014.html emo@xxxxxxx (portal on behalf of emo) [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00013.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no next/future release of this project. All Eclipse projects... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled. ]]> Tue, 05 Jul 2011 04:00:04 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00013.html emo@xxxxxxx (portal on behalf of emo) [objectteams-dev] Project meta data is out of date for tools.objectteams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00012.html Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "0.7.2" is in the past, but the release is not m... Stephan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * The date for release "0.7.2" is in the past, but the release is not marked as completed. If it is completed, it should be marked as completed; if it has been postponed, it should be given a new target date. ]]> Sat, 05 Mar 2011 05:00:04 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00012.html emo@xxxxxxx (portal on behalf of emo) Re: [objectteams-dev] Requesting exception for patch feature shipped by Object Teams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00011.html Hi, me again, As comments on bug 330312 mostly converge on strict rules, I must renew my request. Some of yesterday's comments mean BIG PANIC for the Object Teams project. For that reason it is difficult for me to keep emotions out off this, but I'll try. ... Hi, me again, As comments on bug 330312 mostly converge on strict rules, I must renew my request. Some of yesterday's comments mean BIG PANIC for the Object Teams project. For that reason it is difficult for me to keep emotions out off this, but I'll try. Some comments say that some gurus should help the Object Teams project to find a better architecture that achieves the same without doing bad things. Please understand that after more than 7 years of intensively studying the alternatives and engineering a solution that finally is well maintainable, I am not very confident that anybody will just wipe away the conflict after glancing at the issue for a little while. Do you have any suggestions how this idea could be made real? Some comments say, that the rules should not only be applied to the release train but to any release. This raises the question whether being at Eclipse is actually a viable option for the Object Teams project. Until yesterday I thought we're overdue for graduation, today we're nowhere. David said, the fact that the JDT is open-source does not mean it's OK to fork that code, because this may have bad impact on the JDT and the community. So let's weigh the alternatives: (a) the fork happens within the community and we all join forces for minimizing any risks involved. Or: (b) the fork is forced to move away from Eclipse.org and both sides just mind their own business. What's the effect on collaboration? What's the message sent to the public? As Jeff mentioned on the bug, part of this is about enabling innovation (thanks Jeff). In this one question I'd like to generalize (following my point in https://bugs.eclipse.org/330312#c12 ): To some degree the Object Teams project represents a significant part of the software engineering research of the past decade: Advances in programming language design based on Java. There are *countless* languages in this field, *many* of which would deserve a JDT-qualitity IDE. Where are they? Will any be attracted to Eclipse if a pioneer is forced to withdraw? (Yes, I know there is one brave exception: AspectJ, which had the luck of support by IBM). What's the message Eclipse sends to academia? Regarding the risks I can only invite you to specifically discuss the situation of Object Teams and the JDT/Core. I insist in saying that things look different if you put aside global principles and really look at the specifics (after all this is a request for an exception). Please let's define a controlled experiment, in which the damage incurred (if any) and the benefits produced will be evaluated so that we all learn together and maybe draft a map of some uncharted waters. Lot's more to say but I'll shut up for now. may I hope for some courage? Stephan ]]> Wed, 17 Nov 2010 19:26:35 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00011.html stephan@xxxxxxx (Stephan Herrmann) Re: [objectteams-dev] [tools-pmc] Requesting exception for patch feature shipped by Object Teams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00010.html While I don't have an official approval, there has always been very close cooperation, to the extent that the JDT/Core team recently invited me to help them as a new committer in their team. I will certainly discuss issues with the colleagues from JDT/Cor... Hi Doug and listeners, Thanks for commenting. On Tuesday, November 16, 2010 04:44:43 pm Doug Schaefer wrote: > I have to agree with Gunnar and Dani Megert. You can't patch another > project on the train without their approval. While I don't have an official approval, there has always been very close cooperation, to the extent that the JDT/Core team recently invited me to help them as a new committer in their team. I will certainly discuss issues with the colleagues from JDT/Core. > You are essentially > forking the JDT, which is fine on it's own, but the JDT team owns the > JDT that's on the train I think we all agree that the JDT must have full control over what's installed when a user selects "Eclipse Java Development Tools". This is not affected by our patch feature (unless via a bug in the aggregator). > and need to own the patch. I'm not 100% sure what you are saying by this. Is that a legal statement? A statement that the JDT/Core must retain the option to publish patches without interfering with other patches? A statement about responsibility and blame assignment? I'd love to answer more specifically, once I better understand what you mean. > And at the end of > the day you need to work with the JDT team to provide a mechanism so > that there isn't a patch/fork, I have reasons to believe that this is impossible. Should I elaborate? > or at least a patch that the JDT team is happy with. I will discuss this. > Or find another way to release Object Teams that > doesn't involve the train. Is there a specific guarantee associated with the train that you see violated by the fact of using a patch feature? Interestingly, nobody spoke up when I initially announced this on various channels (incl. the attached mail). If possible, could you point out where you see that users of the train could be negatively impacted by this specific patch? Note, that in this request I'm not asking for general permission that patching should be fine in all cases, but I'd like to demonstrate that our particular patch does no harm. thanks for your time, Stephan
--- Begin Message ---
  • From: Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>
  • Date: Sun, 3 Oct 2010 14:44:42 +0200
  • User-agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; )
Hi Tools PMC, 
hi Mentors,

I would like the Object Teams Project to join Indigo during the M3 frame.

It appears that we will set a precedent in some regards, so I'm asking you
what should be the suitable forum for discussion.

I've created a wiki page [1] for our preparation for Indigo, where some
issues are marked red - they might call for some discussion, specifically:

"API
 o todo: document non-standard usage 
    o usage of internal classes 
    o aspect binding to bundle 
      o decapsulation 
      o interception 
    o patch feature for org.eclipse.jdt.core ..."

Technically, both the usage of a patch feature and the OT/Equinox
technology create non-standard dependencies/relationships.
We want to be as open as possible, which is why I also filed bug 316702 [2]
which aims at a very general solution, not just for Object Teams.
I'd love to see a lively discussion on that bug, BTW.

On a more formal notion, which of these issues will require approval
by some body of the Eclipse community, and which body would that be?

thanks,
Stephan


[1] http://wiki.eclipse.org/OTIndigo
[2] (against p2): https://bugs.eclipse.org/316702 
     "More feedback on what's installing"

--- End Message ---
]]> Tue, 16 Nov 2010 16:24:32 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00010.html stephan@xxxxxxx (Stephan Herrmann) [objectteams-dev] Requesting exception for patch feature shipped by Object Teams http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00009.html Dear Tools PMC, (Cc: our Mentors) Bug 330288 [1], which is actually a technical bug in the b3 aggregator has triggered a discussion in bug 330312 [2], which may or may not significantly influence the future of the Object Teams project. I've actively tried ... Dear Tools PMC, (Cc: our Mentors) Bug 330288 [1], which is actually a technical bug in the b3 aggregator has triggered a discussion in bug 330312 [2], which may or may not significantly influence the future of the Object Teams project. I've actively tried to trigger this discussion for a long time and I appreciate that it is happening now. However, if the rules proposed by Gunnar will be enforced in the near future, perhaps as a pre-requisiste for participating in the release train, this would potentially rule out our (Object Teams) participation in the train. Therefor, and in order to keep special case considerations out off that discussion, I precautionarily request an exception from those future rules. If relevant I will ask you (the Tools PMC) to forward this request to the Planning Council. I believe I have sufficient arguments for justifying this exception. Please let me know, where and how I should communicate these arguments. Thanks for considering, Stephan [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=330288 Indigo repository does not include all the versions of jdt.core [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=330312 Rules for project patches in the train ]]> Tue, 16 Nov 2010 13:34:08 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00009.html stephan@xxxxxxx (Stephan Herrmann) [objectteams-dev] On joining Indigo http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00008.html Hi Tools PMC, hi Mentors, I would like the Object Teams Project to join Indigo during the M3 frame. It appears that we will set a precedent in some regards, so I'm asking you what should be the suitable forum for discussion. I've created a wiki page [1] fo... Hi Tools PMC, hi Mentors, I would like the Object Teams Project to join Indigo during the M3 frame. It appears that we will set a precedent in some regards, so I'm asking you what should be the suitable forum for discussion. I've created a wiki page [1] for our preparation for Indigo, where some issues are marked red - they might call for some discussion, specifically: "API o todo: document non-standard usage o usage of internal classes o aspect binding to bundle o decapsulation o interception o patch feature for org.eclipse.jdt.core ..." Technically, both the usage of a patch feature and the OT/Equinox technology create non-standard dependencies/relationships. We want to be as open as possible, which is why I also filed bug 316702 [2] which aims at a very general solution, not just for Object Teams. I'd love to see a lively discussion on that bug, BTW. On a more formal notion, which of these issues will require approval by some body of the Eclipse community, and which body would that be? thanks, Stephan [1] http://wiki.eclipse.org/OTIndigo [2] (against p2): https://bugs.eclipse.org/316702 "More feedback on what's installing" ]]> Sun, 03 Oct 2010 12:44:57 GMT http://dev.eclipse.org/mhonarc/lists/objectteams-dev/msg00008.html stephan@xxxxxxx (Stephan Herrmann)