Bugzilla – Full Text Bug Listing
| Summary: | [api] review and revise plug-in, type, and extension point ID naming | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P1 | CC: | ekuleshov, robert.elves, steffen.pingel, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | 2.0 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mik Kersten
Here are the plug-in renames that I have had pending and would like to do now that we are changing all our IDs. These need to be robust to future changes so I'm making all UI things get .ui in case we need to create ..core components down the road. Please comment ASAP because I'd like to get the change done now so that the sources are usable. Moves: * ..mylyn.aspectj -> to sandbox * ..mylyn.ide -> ..mylyn.ide.ui * ..mylyn.java -> ..mylyn.java.ui * ..mylyn.resources -> ..mylyn.resources.ui * ..mylyn.team -> ..mylyn.team.ui * ..mylyn.web -> ..mylyn.net.ui * ..mylyn.doc -> ..mylyn.help.ui Creations: * ..mylyn.net.core (Top-level plug-in httpclient, WebClientUtil, etc) * ..mylyn.pde.ui (PDE bridge) * ..mylyn.ant.ui (Ant Bridge) * ..mylyn.validator.ui (1.4 compatible plug-in that checks VM version and for old installs of org.eclipse.mylar plug-ins) (In reply to comment #1) > Here are the plug-in renames that I have had pending and would like to do now > that we are changing all our IDs. Are we going to keep CVS history after those renames? > * ..mylyn.web -> ..mylyn.net.ui I think "net" is a bad name and "web" is more representative for its current content. > * ..mylyn.validator.ui (1.4 compatible plug-in that checks VM version and for > old installs of org.eclipse.mylar plug-ins) I'd suggest to call it "compatibility". Validator can be confusing with WTP's validation framework. (In reply to comment #2) > Are we going to keep CVS history after those renames? I will request for the moves to preserve history and hope that we do get to keep it. But it's really important that we end up with naming that doesn't change down the road (e.g. needing to split something into .core and .ui will be nearly impossible from this point on). > > * ..mylyn.web -> ..mylyn.net.ui > > I think "net" is a bad name and "web" is more representative for its current > content. Yes, this one bugs me too. But what about ..mylyn.net.core as our top-level for libraries, our own utilities, etc? That seems like the best name given SDK, JDK, and Apache naming, so calling it ..mylyn.web.core seems a bit weird? > > * ..mylyn.validator.ui (1.4 compatible plug-in that checks VM version and for > > old installs of org.eclipse.mylar plug-ins) > > I'd suggest to call it "compatibility". Validator can be confusing with WTP's > validation framework. Yes, validator is weird. "compatibility" seems ideal to me given that the SDK uses it, so if other are happy let's go with ..mylyn.compatibility.ui. I am not sure if we would ever end up with a ..compatibility.core, but I guess we could end up with something like a ..compatibility.registry so the .ui suffix seems reasonable since this thing will have to pop up a dialog to the user. > > * ..mylyn.web -> ..mylyn.net.ui
>
> I think "net" is a bad name and "web" is more representative for its current
> content.
net is consistent with java.net but Eugene has a point here and it is not any closer related to mylyn.net.core than other plug-ins. How about this:
mylyn.web -> mylyn.web.ui
mylyn.io.core
In the near future cancelable I/O stream will also be part of the core plug-in and io seems more generic than net.
Just a side note regarding the web/net/io naming: As I was looking for the web connector code, I was rather confused by the other components having "web" in its name. Therefore, I would object against "web". Just my 2 cents Jörg (In reply to comment #3) > > > * ..mylyn.web -> ..mylyn.net.ui > > I think "net" is a bad name and "web" is more representative for its current > > content. > Yes, this one bugs me too. maybe just make it *.web.ui > But what about ..mylyn.net.core as our top-level for libraries, our own > utilities, etc? That seems like the best name given SDK, JDK, and Apache > naming, so calling it ..mylyn.web.core seems a bit weird? The following classes don't belong to anything *.net and not too much to *.io *.core.IStatusHandler.java *.core.MylarStatusHandler.java *.internal.core.util.DateUtil.java *.internal.core.util.XmlStringConverter.java *.internal.core.util.ZipFileUtil.java (In reply to comment #5) > As I was looking for the web connector code, I was rather confused by the other > components having "web" in its name. Therefore, I would object against "web". Joerg, those are *.tasks.web (for web connector) and *.web (for web resource tracking), though latter probably makes more sense to be called *.context.web. It doesn't seem like merging those two will be a good idea, because there are cases when some need *.web but not *.tasks.web BTW, it does make sense to rename into *.tasks.web.ui Steffen: I'm leaning against IO because that has a very strong connotation of file IO, and this plug-in will be abstract web IO, and other web related facilities Please note that I have strong preference for not having our plug-in names get to 6 segments if possible (hence we don't use ..mylyn.context.java or ..mylyn.tasks.bugzilla). Also, I want to avoid a ..mylyn.core and ..mylyn.ui because that can be really confusing. * org.eclipse.mylyn.web.core (Apache libs, e.g. httpclient, WebClientUtil) * org.eclipse.mylyn.web.ui (client UIs, favicons, etc) * org.eclipse.mylyn.web.tasks (genetic web connector, OK not to have this be .ui because it is not a framework, web.ui and tasks.ui are the framework; parallel to ..mylyn.monitor.usage) Regarding utilities like the DateUtil, those I'm moving into monitor.core.util which is our top-level dependency and it makes sense for it to have those 3 classes. If we have a bunch of util classed down the road we can create a ..mylyn.util.core or ..mylyn.common.core. Thoughts on the ..mylyn.web.* convention? It does seem like a better name since we're doing more in those plug-ins then just abstracting protocols (as with .net stuff). (In reply to comment #8) > * org.eclipse.mylyn.web.core (Apache libs, e.g. httpclient, WebClientUtil) > * org.eclipse.mylyn.web.ui (client UIs, favicons, etc) > * org.eclipse.mylyn.web.tasks (genetic web connector, OK not to have this be .ui > because it is not a framework, web.ui and tasks.ui are the framework; parallel > to ..mylyn.monitor.usage) > Thoughts on the ..mylyn.web.* convention? where org.eclipse.mylar.web fit into that? > Regarding utilities like the DateUtil, those I'm moving into monitor.core.util > which is our top-level dependency and it makes sense for it to have those 3 > classes. +1 org.eclipse.mylar.web -> org.eclipse.mylyn.web.ui However, note that the ..web.ui package is in flux because we are still trying to figure out where to draw the line on our Web UI API (e.g. does favicons go in there, etc) without adding too much stuff that's beyond the SDK. So some of the current stuff in Web UI is unused by the distro, but I'm hoping that it will be useful for PHP and similar tools that want web resource structure bridges. Either way I'm confident that we'll have some stuff in web.ui. OK, so it sounds like everyone is happy with httpclient and the other dependencies moving into ..mylyn.web.core. It'll make things obvious, which is nice. Then we can still keep the org.eclipse.mylyn bundle, but it'll return to being like it was prior to 1.0, where it has no source or libraries (just branding, etc). One nice effect of this is that clients that reuse the core libraries won't need to get all the ..web.core libraries (as Eugene points out on bug 191774). Done. I made some additional changes to add ..team.cvs and renamed the Ant feature to be ..ide.ant. The refactoring that still remains is of the error handling, and that should get rid of the last 2 classes left in org.eclipse.mylyn. Once that's done I'll update the porting guide: http://wiki.eclipse.org/index.php/Mylar_Porting_Guide (should be done early-ish Monday). (In reply to comment #11) > Done. I made some additional changes to add ..team.cvs May I ask what for? mylar.team.ui still dependends on eclipse.team.cvs plugins > and renamed the Ant feature to be ..ide.ant. Another weird one, considering naming of Eclipse ant plugins: org.eclipse.ant.core_3.1.200.v20070522.jar org.eclipse.ant.ui_3.2.100.v20070511.jar (In reply to comment #12) .. > May I ask what for? mylar.team.ui still dependends on eclipse.team.cvs plugins It should not depend on ..eclipse.team.cvs. We just need to de-couple the LinkedTaskInfoAdapter class that you contributed and all should be good. If you have ideas for that please post them on bug 191793. > > and renamed the Ant feature to be ..ide.ant. > > Another weird one, considering naming of Eclipse ant plugins: > > org.eclipse.ant.core_3.1.200.v20070522.jar > org.eclipse.ant.ui_3.2.100.v20070511.jar Our Ant UI Bridge is coupled to mylyn.ide, so I decided not to take up a top-level part of the mylyn namespace for it at this point. I realize that this is not parallel with PDE and struggled with it some, but I think that it is the more clear tradeoff. |