[Design of JBoss Tools (dev)] - Re: Incorporate Hibernate Search into Hibernate Tools idea
by sannegrinovero
cool! I would like to use a tool like that.
anonymous wrote : 2) automatic annotation creation for some entity/entities - at least in the simplest case - @Indexed & @Field
What do you mean by "automatic"? I don't think it's possible to find a way to guess the correct positions and options for a Field annotation; maybe from the queries but it seems to me quite hard.
anonymous wrote : 4) as one more idea - it would useful if all of these has some common switch in interface which is not very bind to Lucene;
you refer to an interface update to the luke tools? what's wrong with being tightly coupled to Lucene for a tool like this?
anonymous wrote : b) possible to view list of entities for the index (@Indexed), possible to view hierarchy of index entities relation (@ContainedIn and @IndexedEmbedded)
I would highly appreciate a view like the Hibernate Tools mapping diagram, showing the resulting index fields and how they are mapped to the entities.
anonymous wrote : 5) may be some functions which will help adjust index for better search result and performance - it is similar for clause 3 but not exactly the same;
A practical use case?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203138#4203138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203138
17 years, 2 months
[Design of EJB 3.0] - Re: Versioning
by ALRubinger
"wolfc" wrote : Since everything we build is consumed by some other project/component, the proposal is moot. ;-)
Aha, I said "directly consumed". :) I stand by the proposal because
1) The JIRA process will closer reflect what we're actually doing
2) Not upgrading stuff for name's sake both saves time and makes for less errors.
"wolfc" wrote : Components need a qualifier to make sure that nothing unstable ends up in the supported chain. I want to get to a point were we can say use a version range [1.0,1.1) and not worry about it any more.
Qualifiers are doing nothing for us in practice. In actuality, we have the following criteria for any release:
* Passes EJB3 Integration TestSuite 100%, except for known issues and transient failures
* Passes TCK 100%
* No regression in AS TestSuite
* Passes module Unit Tests 100%
Nowhere along there am I checking that all dependencies are of some particular qualifier.
"wolfc" wrote : As for the versioning I agree we need some more transparency there, but we can't create a scheme that's too complicated for users to follow. Since an user doesn't have to find out which component is failing, it'll be reported against our 'global' affected version. Likewise the 'global' fixed version should report the released version. So version per component doesn't sound like a solution to me.
Users won't even go that far; they'll report EJB3 problems against their AS version. Or get the version wrong. Either way we'll typically correct "Affects Version" in the JIRA most of the time, same with "component".
Regardless of what users are reporting, the problem remains that we currently don't have a scheme in JIRA which correctly models what we're doing. We *do* have version-per-component. To pretend we don't in JIRA is incongruent.
One fundamental disagreement we have is that I *do not* believe:
anonymous wrote : For any GA release, all dependencies must also be a least GA level
I stated our release criteria for ejb3-as-int above. However, a particular component may be implementing some new feature that isn't mature enough to be GA. Take for example:
* I start building ejb3-async to fulfill EJB 3.1 requirements of @Asynchronous invocations
* At release time, ejb3-async is 1/2 completed.
* All the requirements for ejb3-as-int to be released are fulfilled, and we can even preview 1/2 the support of the new ejb3-async module.
ejb3-async isn't even complete, so it's not a GA. Does that mean that ejb3-as-int is also not a GA? Why not; it's both more stable and more feature-rich than the previous release. Hmm, so I should promote ejb3-async to GA? But it's not complete. (Start cycle again)
That's the philosophical argument. Here's the practical one:
I don't want to re-release perfectly good binaries, and update the entire dependency chain, just to get a qualifier promotion that we ignore anyway.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203137#4203137
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203137
17 years, 2 months