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

Dan Allen dan.j.allen at gmail.com
Mon Aug 10 12:21:45 EDT 2009


On Mon, Aug 10, 2009 at 7:54 AM, Max Rydahl Andersen <
max.andersen at redhat.com> wrote:

>
>    Again, we need to start a wiki page for this :-)
>>
>>
>>  One thing that should help is that we know integrate with m2eclipse
>> allowing you to at least use maven.
>>
>> I still don't know (haven't had time to look into it) how we are going to
>> handle (in any IDE) that there are
>> multiple deployment/configuration descriptors in one project - most
>> non-jbosstools-tools assumes
>> a specific structure (i.e. persistence.xml is in META-INF and not called
>> something else) - but maybe
>> maven's profile feature can be used for it....something to explore at
>> least.
>>
>
> I think Maven 2 profiles are the answer, or at least to cover 90%. A tool
> should be able to do property replacement between Maven 2 properties and the
> replacement tokens in the files. I'm not sure if this is m2eclipse's
> responsibility or JBoss Tools (users really don't need to know the details
> here). This works because Maven 2 behavior is predictable and well defined.
> With Ant, it's just wild west which files get filtered and where the tokens
> come from. And the Seam 2 examples use Ant in the most gnarly way.
>
> As for the last 10% (or however many edge cases there are), we can address
> those on a case-by-case basis in a way that impacts the tooling the least.
> In the worst case scenario, you have to comment out some code in the source
> files to support one app server or the other. But I think this is acceptable
> in small amounts given that once you decide to target an app server, you
> keep using the same one while developing (so it's not something you have to
> do over and over).
>
> Let's just push profiles as far as they are willing to go. We'll be Maven
> ninjas by the time the examples are all setup, no doubt.
>
> Maven profiles doesn't solve this afaik. It only generates the "right"
> layout in the deployment location which is an area an IDE ignores.
>
> If Maven has support for maintaining an "intermedate" location that the IDE
> think is the actual source/resource being deployed will work.
>
> Again - I need to play more with this, but a few months ago it was still a
> problem (i.e. the IDE just become a fancy notepad :)
>

I get that Maven is putting the resolved file in the build directory. 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). This would be precisely
like Eclipse properties. Clearly Eclipse is able to offer paths that
"extend" properties, so why can't the files which Maven marks as
"filterable" work in the same way? Yes, it will be a dynamic thing happening
in the editor, but still, you have both parts, it's just a matter of putting
them together. (Note that I'm saying I know how, I'm just saying if I knew
Eclipse).

And if you happen to be missing a property in the pom.xml file, when then
Eclipse will just say "sorry, I can't proceed without a value".

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090810/31d0efa7/attachment.html 


More information about the seam-dev mailing list