[Design of JBoss Eclipse IDE (dev)] - Re: WAS: Hibernate Tools not forward compatible with WTP (@h
by dlmiles
Unfortunately I don't have the answers to making it easy for a new user to get started (over and above an all-in-one archive).
The way I see the Eclipse architecture is that each feature should principally be distrubuted in isolatation first. "Runtime only" version that is the way nature intended.
You are already in no-mans-land when you start distributing anything between an all-in-one and runtime only and thats a hiding to nothing in the future with with permutations of platform and feature sets and to this I can't really offer anything.
There maybe suggestions that can be made to update manager development team on this, for example if after a platform restart (or -clean) a new feature/plugin is detected and it can not be activated (due to missing dependancies) then they get a prompt on screen offering was to resolve that problem by locating and downloading those missing dependancies.
The way I see the new user problem at the moment is that the platform does not help them enough when a pre-requisite problem occurs. When I think that issue should be in their face to deal with (or ignored) as soon as its detected, even little things like notification confirming a new plugin was detected and is activated giving the user positive feedback their unzip worked correctly.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962269#3962269
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962269
18 years, 5 months
[Design of JBoss Eclipse IDE (dev)] - Re: WAS: Hibernate Tools not forward compatible with WTP (@h
by mculpepper@jboss.com
Just read over the thread and the comments in Hibernate JIRA...
To make a "runtime-only" bundle of Hibernate Tools (or any of JBossIDE's components) would be a relatively easy thing to do from the perspective of our build process. The only issue that comes to mind is the "further" confusing of multiple types of downloads... imagine now that we will have:
- Bundle downloads for win32+linux (eclipse+all components plugins/features+dependencies)
- ALL downloads (all components plugins/features+dependencies)
- 8-10 standalone component downloads (component plugins/features + dependencies)
- 8-10 "Runtime" downloads (component plugins/features ONLY)
So basically that pumps up the number of files to the low 20s. If we re-use our download matrix/guide methodology we can probably structure the page in such a way where it isn't as confusing, but for users who are just browsing our sourceforge page they would be SOL =).
Anyway, I'm not saying "no", I think we just need to discuss the best way of going about doing this. This discussion also prompts me to ask another question: Should we rethink the way we are distributing releases? Most eclipse plugins only package themselves as "runtime" plugins, and then maybe have a "Bundle" that includes dependencies, but no where near the level of granularity in component/dependencies that we do. Would users suffer to much if we threw that out the window?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962259#3962259
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962259
18 years, 5 months