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.
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.
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.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan