[seam-dev] Need advice on what and how to commit new build stuff for the booking sample app on WebSphere v7

[Max Rydahl Andersen]

>>     What I don't understand--and please bear with my naivety about
>>     Eclipse plugin development--is why we can't offer some sort of
>>     "smart" editor that is aware of the properties defined in the
>>     pom.xml file and can resolve them when it needs a value (such as
>>     the JTA data source name).
>     That is what I would like to do where we can - but will only work
>     for our editors and projects. We don't control all of the IDE -
>     sorry ;)
>     Anyway, the editor is just *one* part of this - then there is the
>     whole set of framework specific models in place, i.e. JSF and JPA
>     provided by WTP has their own little model which
>     expects things to be in a specific place and is not in any way
>     extendable in this area (afaik).
>
>     btw. jta datasource name is an example of something we don't
>     really need to resolve since it only exists at runtime....
>     what we want to control is that when you want to do Hibernate
>     queries from the IDE you use a persistence.xml that is configured
>     to run in J2SE;
>     but when deploying it should use the datasource name one - and
>     this is not controllable with a mere property replacement because
>     of how persistence.xml's are structured.
>
>
> We'll need to discuss this in real time to make sound progress, likely 
> JBossWorld. But I'll leave one statement/inquiry here.
>
> So you are saying that Eclipse basically has no native support for 
> property substitutions of any kind in project files? I just don't see 
> how the Eclipse developers missed this absolutely critical requirement 
> for an IDE. For as long as anyone has been developing Java EE web 
> applications, system administrators have been using all sorts of 
> voodoo magic property replacement to get any deployable build 
> artifact. Variations are just a huge fact of life. The IDE has to be 
> able to deal with that reality and stop living in it's own ideal world 
> that every value in a file is concrete.
I'm saying *all* IDE's I know does not have property replacements 
support - not even intellij. If they have I missed it and would really 
like to get pointed to an example/docs anything.

Please note there are two problems here: property 
replacement/understanding in editor/model and editors not being too much 
dependent on location of the file.
> Putting my problem solving hat back on, the best way I have found to 
> deal with this situation, from many years of having to get the IDE to 
> operate in the real world, is to have an environment switcher. It 
> tears through the project and replaces configuration files intended 
> for one app server with configuration files for another. Then, you can 
> edit them...but of course when you are all done tweaking them (with 
> permanent changes), you have to copy the files back to their source to 
> check them in. Otherwise, the changes are just temporary for your 
> immediate development needs.
yes, that is what I've been doing too - or simply not depend on the IDE :)

anyway, having such a environment switcher is "more or less" what the 
maven profile support does (except the destionation is always in the 
build result, anyone know if that can be changed/customzied?).
What would be nice is to (for those locations where it is possible) to 
do the "inverse operation" by simply comparing the src and destination 
and just do an intelligent merge ;)
> Am I missing some obvious way to work? Put Maven completely aside for 
> a moment and just focus on how to deal with different settings for 
> different environment in any Java EE project. How is the problem 
> solved? That is where we need to start when we discuss a solution.
The problem is unfortunately normally solved with what I normally refer 
to as Ant voodoo ;)

but yes, this is something better done face-2-face since its solution 
very much depend on what kind of 'property replacement' and what type of 
file you do it on.

/max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090812/f22b58a7/attachment.html