Re: [jbosstools-dev] Diffenerent interpretation of NamingStrategy methods.
by Dmitry Geraskov
Emmanuel Bernard wrote:
>
> On 10 août 09, at 11:31, Max Rydahl Andersen wrote:
>
>>
>>>> It's a clusterfuck, sorry about that. We are all wrong except
>>>> Max-the-manager. Oh the irony ;)
>> heey! :)
>>>> logicalColumnName is the name by which a column should be referred
>>>> in metadata descriptors (like unique constraints, indexes etc). I
>>>> don't think a user needs to use the logical mapping in HBM files
>>>> (the metadata structure don't require it contrary to annotations).
>>>> Anyway, the logical name should never appear in a physical column
>>>> name, so HbmBinder #fail.
>>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4077
>>>>
>>>> I've attached a patch and applied it to trunk. It probably needs a
>>>> quick test on your side and can be retrofitted to older versions.
>> Doesn't this change the behavior radically ? ...and how should our
>> validator know which sequence of calls it should use ...i hate bugs ;0)
>
> No it does not because realistically, doing an implementation
> of logicalColumnName like the one in this test has no usecase.
> What does the validator do exactly? I'm not clear how it should use
> the NS.
The Dali's validator checks that the table/column you are references
exists. When user uses NamingStrategy the name of the table/column are
different from default one, so we need to change this check according to
the NamingStrategy altering. To do this we need to know exactly how
Hibernete will do the conwersion of default/specified name to db-object
name.
>
>>
>> Looking in fisheye this change were done almost 4 years ago...
>> http://fisheye.jboss.org/changelog/Hibernate?cs=8918
>> for http://opensource.atlassian.com/projects/hibernate/browse/ANN-176
>> where it seems to be done very deliberately ?
>>
>> are you sure this is a proper change ?
>
> Of course, I always do things deliberately but then I dont' remember.
> In this case, I did fix the user bug by adding the
> mapping.addColumnBinding() calls. I think back in the days, I thought
> the logicalColumn should also be passed toNS.columnName. I think it is
> wrong today.
> In practice, MC.logicalColumn is almost always idempotent if the
> column name is not null. That's why we have never seen any impact.
>
>>>> FTR
>>>> Hibernate Annotations uses a different naming strategy than core
>>>> for backward compatibility reasons.
>>>> JPA defaults are not Hibernate Core defaults
>>>> http://anonsvn.jboss.org/repos/hibernate/core/trunk/annotations/src/main/...
>> Yes, but that we will just pick up automatically since it does not
>> change the sequence of calls done to the namingstrategy.
>>
>> Anyway, for now we'll just focus on the JPA behavior since that is
>> the most relevant for JPA Project validation at least ;)
>>
>> /max
>
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
16 years, 11 months
Maven Publishing Goals on Server Edit
by Daniel Green
Hello!
It would be cool if the user, on the server edit page, could specify
maven goals to be used for generating the ear or war file to be
published. Right under the "Ant Publisher Properties" there's some
room... Is this a feasible goal? I'd be willing to put time into
developing it. As of now, deploying has been a gigantic pain when
using maven. I've found myself fighting with eclipse for days now...
Obviously not all projects would be maven enabled, so perhaps checking
for m2eclipse nature or a pom.xm before building that way. The latter
may be best. How feasible is this?
Thank you for hearing my idea,
Daniel.
16 years, 11 months
Diffenerent interpretation of NamingStrategy methods.
by Dmitry Geraskov
Hi, guys,
I tried to generate ddl from console configuration using my
NamingStrategy and found at least 2 differences between them.
My NamingStrategy has 3 significant(for this issue) methods:
public class TestNamingStrategy extends DefaultNamingStrategy{
public String propertyToColumnName(String propertyName) { return
"PTCN_"+propertyName;}
public String columnName(String columnName) {return "CN_"+columnName; }
public String logicalColumnName(String columnName, String
propertyName) { return "LCN_"+super.logicalColumnName(columnName,
propertyName);}
}
-----------------------------------------------------------------------
Mapped class is pretty simple:
@Entity
public class Customers implements java.io.Serializable {
@Id @Column(name="id") private int id;
@Column(name = "specified_column") private String specified_column;
...
}
-----------------------------------------------------------------------
Class mapped as:
<class name="r.Customers">
<id name="id" type="int"/>
<property name="specified_column" column="specified_column" />
</class>...
===========================================
Generated ddl for jpa console configuration is
create table Customers (
CN_id int4 not null,
CN_specified_column varchar(255),
primary key (CN_id)
);
-------
for core:
create table Customers (
PTCN_id int4 not null,
CN_LCN_specified_column varchar(255),
primary key (PTCN_id)
);
Are this differences expected?
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
16 years, 11 months
Dependency Question
by Rob Stryker
Currently the ESB project ui plugin contains a dependency on common,
which as we all know is where xmodel and many other things are mashed
together. This dependency is due only to the need for the JBDS icon in
the new ESB wizard.
Questions:
1) Is the requirement of using an icon reason enough to have a dependency?
2) OR should the ESB project just copy this single icon into their own
plugins?
3) OR should the ESB project have its own icon for the wizards rather
than using the JBDS red globe icon?
4) Should the JBDS red globe icon belong in a more light-weight "core"
ui plugin which has no dependency on xmodel and all sorts of other large
pieces of our infrastructure?
16 years, 11 months
Plugin name suggestions
by Rob Stryker
In order to finish JBIDE-4320 (ESB project virtual component / module
factory) we need to settle on a plugin name for the superclasses for
this. Currently the plugin is named
org.jboss.ide.eclipse.as.wtp.override.core but obviously we'd need
something better to describe the plugin.
16 years, 11 months
Re: [jbosstools-dev] [Fwd: [JBoss Tools (users)] - Project MYPROJECT doesn't have KB nature.]
by Max Rydahl Andersen
Victor, please remember to reply-all and not just me ;)
Victor V. Rubezhny wrote:
> In old CA we've used a knowledge base that had all the data on
> tags/attributes/enumerations stored in XML-formatted files for each TLD and
> schema that might be used by a user. There were the tons of XMLs for all
> the known TLDs/Schemas we have had to support. Many of these XMLs were
> generated by the converter program but finally almost all of them were
> edited by the hand to specify some default tag attributes or default
> attribute values or descriptions etc. It was really hard to support and
> renew all this staff.
>
Ok. Don't we have a way of "enhancing" the completions today in case the
metadata is not complete ?
or is that just not relevant anymore ?
> Of course, as the second part of CA there was a dynamic part which proposed
> a user with dynamic things like actions, path, images and other dynamic
> values within the project.
>
Yes...but these does not require a builder nor nature to be in place do
they ?
We should try and fail gracefully in case of missing information...
btw. now that the "global" cache is gone are the completions as good as
before ?
Are there some things missing compared to before which we could get from
the old knowledge base but
not the new ?
> As the result of CA refactoring we turned to use dynamic KB generation
> depending on the libraries used in the project. All the special things (such
> as predefined values, default tag attributes , default attribute values and
> so on) are stored in slightly compact difference XMLs, but all the other
> things are generated automatically for each library used in the project.
>
Okey....
> We saved the disk space (because we don't need to store the tons of
> information on each Tag library in the world) and the time (because we don't
> need to prepare XMLs for each new library by the hand), but now we need a
> builder that's doing this work for us on startup and on the fly if a user
> adds some new library to its project.
>
We do cache these things, right ? If we do this per project aren't we
going to add a massive overhead ?
> Probably you're right and I'll be able to start KB-builder (and prepare the
> .project file) when the CA will generate an error. But the builder takes a
> time to parse all the libraries used in the project and its dependencies,
Yes, but then why not have the code completion show a completion that
says: "Enable JSF(?) code completion on this project" in
case it is not there and if users select that install the builder/nature
? btw. can't we avoid having these builders/natures
if we already got one of our jsf/seam/you-name-it builders/validators
already installed ? Just trying to avoid creating
too many events.
> so
> I suppose that the kosher way is to set up a builder and KB-nature at
> project startup, but not when a user wants to be prompted with something.
>
Well, for existing projects there is no such thing as "project startup" ....
/max
16 years, 11 months
svn rights
by Dmitry Geraskov
I can't delete attached file in svn.
As I remember I had the rights before.
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
16 years, 11 months
Re: [jbosstools-dev] [Fwd: [JBoss Tools (users)] - Project MYPROJECT doesn't have KB nature.]
by Max Rydahl Andersen
> New CA requires a new nature ID and a new builder to be present in .project
> file. So, it won't work for existing projects created by the previous
> versions of JBoss Tools.
>
That is not really acceptable - we can't break users projects this way.
There need to be backwards compatible support
or at least someway to easily upgrade ?
Any reason why we don't use the same nature ID and builder ? Or at least
have the old builder/nature be able to be used
too ?
> At the moment the only way to enable the JSF CA is to make the following
> changes to the .project file:
>
> 1. Add the following build command to the<buildSpec> section of
> .project file:
>
>
>
> <buildCommand>
>
>
> <name>org.jboss.tools.jst.web.kb.kbbuilder</name>
>
> <arguments>
>
> </arguments>
>
> </buildCommand>
>
>
>
> 2. Add the following nature to the<natures> section of .project file:
>
> <nature>org.jboss.tools.jst.web.kb.kbnature</nature>
>
> Also, all the required tag libraries (TLDs and schemas) are to be present at
> classpath to allow the KB-builder to see and use them.
>
Not sure what this means ? What is the difference from before ?
/max
16 years, 11 months
