Problem with org.jboss.tools.common.model.ui plugin
by Jiri Peterka
Hi guys,
I have following problem with JBT plug-in dependencies and hope you
could help me. Simply I can't import
org.jboss.tools.common.editors.ObjectMultiPageEditor. This specific
issues is here since one of recent JBT (3.1) version.
There are simple steps to reproduce.
1. Have JBDS 3.0.0 GA or JBT 3.1 installed
2. Create plugin to test this problem
3. Import org.jboss.common.model.ui on Dependencies tab
4. In plug-in dependencies (Package Explorer)
org.jboss.tools.common.model.ui is missing and for example
ObjectMultiPageEditor (org.jboss.tool.common.editor) can't be imported
Strange is that plugin is here and I can see this plugin in Plug-in
registry, plugin can be added as dependency and it has exported packages
I needed but it's not present in Plug-In Dependencies (Package Explorer)
and can't be imported in the source code. In some earlier JBT 3.1 this
worked.
Any help appreciated, regards
--
Jirka
14 years, 8 months
- 4
- 8
Re: [jbosstools-dev] Hibernate multiversions support
by Max Rydahl Andersen
Moved to jbosstools-dev - not just for internal discussion.
/max
----- "Vitali Yemialyanchyk" <vyemialyanchyk(a)exadel.com> wrote:
> Max,
>
> Here I try to accumulate my thoughts about the problem:
>
>
>
> I’m trying to analyze conception of using other process to Hibernate
> multi versions support and decoupling. I’m suspecting we could choose
> not optimal way for implementation, this is very important decision,
> we should analyze all aspects, why we’ll select a way and technologies
> which java provide. I suspect we can stay in bounds of 1 JVM process
> using classloaders, we should just separate Hibernate jars from
> Hibernate Tools. The idea is to have some “imbedded container” with
> some particular Hibernate version and the user can provide his own
> “container” with his project classpath. This container should interact
> with Hibernate Tools via some circumspect interface (more precise
> Hibernate Tools should interact with container via such interface) (I
> imagine this interface in one place -> currently it diffused all over
> Hibernate Tools – so general purpose no Hibernate imports in Hibernate
> Tools ) and should in general case use Hibernate classes via it string
> names – some particular container implementation can use Hibernate
> classes directly.
>
>
>
> So IMO good start point not implement code generation and query
> execution firstly – good start point is decouple Hibernate interaction
> from Hibernate Tools, good start point is to implement such container
> – firstly it could use Hibernate directly and then via it classes
> name.
>
>
>
> Using other process I can dig into interprocess interaction details
> which could became rather complex - practically this interprocess
> interaction turns into container interface implementation and decouple
> from Hibernate class imports.
>
>
>
> The container interface for Hibernate Tools outline:
>
> 1) Code generation – input: db connection, java classes, output dir;
> output: signal when sources are generated;
>
> 2) Query execution – input: query string; output: list of objects;
>
> 3) Code completion – input and output - ?;
>
> 4) Object relations resolution (for Mapping Diagram);
>
> 5) Error display/handling;
>
> 6) Possibility of external configure for Hibernate configuration (i.e.
> additional mapping files, add/remove jars into classlib);
>
> 7) Handling of Hibernate session;
>
> 8) Should be extendable;
>
> The container should work in its sandbox which Hibernate Console
> Configuration provide (use classes, jars, resources which Hibernate
> Console Configuration provide with its classpath).
>
> The question is which is a way to organize such sandbox? -> IMO
> possible to use just class loader not other process… Moreover -> when
> we define such interface – we free to choose which sandbox
> implementation is more preferable -> “class loader” or other process.
>
>
>
>
>
> Agenda:
>
> Hibernate Tools – use in general only Eclipse and Java core libs,
> interact with so called “Hibernate Container” via predefined
> interface;
>
> “Hibernate Container” works in its own classpath sandbox – provide
> information for Hibernate Tools with strings and files – in “ideal”
> case;
>
>
>
>
>
> Here is our discussion – to remember purpose why this necessary and
> what using of other process just “ idea of separation ” for “ user
> wishes to use another version than the builtin ”.
>
> Also, Max, please point the jira issue – is it
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-1160?
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
> <vitali> I have some questions about multiple hibernate version
> support - it look like first priority issue?
>
> <@max_at_hibernate> its one of the issues we need to look into for the
> next major release.
>
> <@max_at_hibernate> since with Hibernate 3.5 things becomes harder to
> ensure works consistently (as the move to 3.3 have shown)
>
> <vitali> as I remember you told about execution in different thread
> idea, but it is not clear for me - cause currently we are using some
> specific version of Hibernate (3.3.2) - the idea is to substitute it
> with any Hibernate version - as the user select? this sould be
> configurable via GUI? the user should dpwnload hiberante jars and
> point the place?
>
> <@max_at_hibernate> the user is supposed to have hibernate configured
> in his project if he wishes to use another version than the builtin.
>
> <@max_at_hibernate> the idea I had was execute qeries and code
> generation in a separate *process* not just different thread.,
>
> <vitali> so builtin version exist. "separate *process*" – exactly - I
> remember.
>
> <@max_at_hibernate> My current thinking is to have a flag on the
> console configuration wether external process should be used or not.
>
> <@max_at_hibernate> the biggest problem will be the mapping diagram,
> but for now we could just say that requires internal process to work.
>
> <@max_at_hibernate> code completion could also become tricky - but
> could probably be done by launching a debug process which we could
> call out to for the completions.
>
> <@max_at_hibernate> alternatively reading code and mapping files and
> building the metadata manually - but that would be a massive work.
>
> <@max_at_hibernate> the cool thing is if we do this we could decouple
> us from Hibernate and even support other JPA implementations for parts
> of our functionallity.
>
> <vitali> "external process" - I can imagine this for code generation,
> but to build console configuration - this look rather complex task - I
> sure this possible but now I do not see how to easy implement it with
> small changes - possible to use files to interprocess communicate?
>
> <@max_at_hibernate> it is not a small change - its a big one.
>
> <@max_at_hibernate> should be done in a branch probably to not break
> things for everyone else ;)
>
> <@max_at_hibernate> not sure what you mean with files to interprocess
> communicate ?
>
> <@max_at_hibernate> you would need the process to run in the
> background - ready to execute the things the user needs.
>
> <@max_at_hibernate> i.e. for queries.
>
> <@max_at_hibernate> code generation would just be a separate launch.
>
> <vitali> " you would need the process to run in the background - ready
> to execute the things the user needs." - a! I remember I did something
> with some other project – so I have the example!
>
> <vitali> for queries it ok - clear, but for ConsoleConfiguration -
> it's contains hibernate Configuration
>
> <vitali> from my point of view -> it is necessary to pass this class
> from one process to other
>
> <@max_at_hibernate> and for what do you need the console configuration
> ? ..
>
> <@max_at_hibernate> not for querying, not for codegen
>
> <@max_at_hibernate> only for the mapping diagram and the outline
>
> <@max_at_hibernate> both could be something we generate by launching
> the external process and generate some data that represents it in a
> canoncial form...
>
> <vitali> I'll try to rethink all above... I'll create jira issue for
> this.
>
> <@max_at_hibernate> vitali - I think there already is one, right ?
>
> <vitali> I remember it should be - but I review issues which assigned
> to me and can't find it - will look one more time
>
> <@max_at_hibernate> note, doing this for code gen and querying doesn't
> mean that we could still try using console configuration inprocess for
> things that arent moved to external yet.
>
> <vitali> generally is necessary to have some start point - about
> ConsoleConfiguration -> Configuration and SessionFactory - imo these
> sould be in some canonical form - may be I did not understood you
> correctly - it look like your imagene this in other way...
>
> <@max_at_hibernate> don't think so ;) What do ou mean ?
>
> <vitali> uff... may be I miss something - but how you display correct
> tree items for Console Config? imo these should be from user selected
> Hibernate jars
>
> <@max_at_hibernate> vitali - i'm saying that part is the hard one, but
> you don't *need* them to actually execute queries or generate code.
>
> <@max_at_hibernate> need *it* I mean.
>
> <vitali> so you propose "execute queries and generate code" as start
> point?
>
> <@max_at_hibernate> yes
>
> <vitali> ok
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
> Vitali
--
/max
14 years, 9 months
- 1
- 0
- ← Newer
- 1
- Older →