12:52 p.m.
As per Tim DeBoer, there is a way for a server to to ping first before
starting. I never quite figured out how to do it, and some poor hapless
adopter on the mailing list kept asking and never got an answer, but
supposedly the server starts in a default 'unknown' state, and at some
point the server is given the opportunity to see if its already started.
As for project structure, the virtual component model is actually pretty
configurable. Perhaps we just need a UI to allow you to designate which
folders get deployed where... basically a UI for the
.settings/org.eclipse.wst.* files. But of course this would require
digging around in that layer of the code and also (probably) finding
more bugs when we try to do things that no one else's tried because
they've all been structuring their projects in the exact same fashion
but changing the folder name.
I never did like the servertools' notion of a module or deployed
resource. At no point does it allow the adopter to declare what's on the
server that's not in the workspace. I'm trying to get to the point,
however, where my server view will look like the one John and I had
discussed and where JMX features prominently, for listing of modules and
even for deployment instead of simply copying around the local disk.
But of course these changes take time... especially since half the work
I've done is in a google code repository somewhere and not yet in our
source tree ;)
I'm confident we'll overcome all of these issues eventually...
Max Rydahl Andersen wrote:
> Ok -- so I'll take this as an opportunity to rant. ;)
I'll bite...;)
> The WTP deployment framework suffers from a number of architecture,
> implementation, and process limitations. Based on good faith
> interactions with Eclipse WTP (mostly Rob, but sometimes me), the WTP
> team seems in no way interested in addressing these issues. In short:
I agree and usage of any Eclipse technology is becoming more and more
dangerous.
WTP is not the only area we have incredibly annoying issues - it is just
where it is most visible at the moment.
> * The WTP Servers view, and hence deployment, assumes that you have
> control over the target server. You start and stop the server directly
> from this view. If the server is already running, then the view has no
> way of finding this out. This is ridiculous: imagine trying to do team
> development on a shared server (say with a number of other applications
> already installed). How's that supposed to work? Everyone starts/stops
> the server at their own whim according the dictates of the tools?
> Ridiculous.
eh...isn't this not just a server adapter implementation issue ? The
"start"/"stop"
buttons can do anything - including just pinging the server to see if
it is already
started before doing its "local" start ?
> * You map one project--one server, and the project structure has to
> mirror the deployed archive structure. Too low level! I want the freedom
> to have resources wherever I want in my project (and perhaps even
> referenced projects), and I want a separate way of determining the
> deployed archive contents. I don't want to bind one project to one
> server: I want to deploy archives to a set of servers from the same
> project.
This one is actually one of my pet problems with any IDE out there.
I do not know of a *single* IDE that does this in a good way (i.e. one
that understands the structure of your files without having them in a
standard structure...)
If you got examples where this works well, please let me know.
Another similar issue (which is not WTP specific) is how to handle
configuration
files that is not correct at dev-time but has property replacement
tokens which
is only known at build/deploy time (via Ant magic).
> * Even though there's a tight mapping between one project--one server, I
> still can see the contents deployed on the server. Sure I can see the
> "module" name and it's current synch status, but I can't see what
is in
> the server. If I want to compare a file on the server with something in
> my workspace, I'm out of Eclipse to do so.
You actually can with our server adapter - look in File Filters node (yes
it has a bad name and does not include default setup - we need to fix
that)
> * The archives and projects are not reusable. Because they are tied
> directly to local environment details (server connections and
> classpath), it is difficult (yes, not impossible, but far more difficult
> than it has to be) to share and store these projects (say in version
> control, where I can easily repro the environment for any project
> version).
when you write archives, do you mean our project archives ?
About projects then I am actually pretty sure they are sharable our
adapter and/or default setup is just not using it - which it should.
> The alternative? Have a deployment descriptor (think something like
> "build.properties" for you plug-in developers out there) that specifies
> the contents for a specific deployment archive. Tools that let you build
> local versions of the specified archive and optionally deploy to a given
> set of target servers. A server view that can ping ports to first
> determine if the server is running... A server view that can show me
> what is on the server (not just my archive), and let me interact with
> those resources in a typical manner (that is, the server deployment
> space acts like a virtual file system).
Those things you mentioned there I believe is doable within WTP
boundaries.
The *problem* is that *everything* in eclipse eco-system related to
JEE is
dependent on WTP's skewed project model; we would have to reimplement
those
features. i.e. Dali JPA comes to mind. similar with the WS and SCA/SOA
tooling.
Note: I generally agree with your rant and that is why I always ask
for new features
to *support* WTP but not be *dependent* on it if possible.
/max
> </rant>
>
> -- John
>
> On Thu, 2008-10-30 at 11:15 +0100, Max Rydahl Andersen wrote:
>> Hi,
>>
>> I just bumped into subject and it looks like both Eclipse WTP and
>> possibly
>> our AS adapter is seriously broken on Ganymede when
>> it comes to JEE 5 EAR deployments ;(
>>
>> jboss-seam.jar only gets deployed if I force a full publish and even
>> then
>> it does not seem the lib folder that is being talked about in the id
>> is being created in the deployed archive.
>>
>> Any info about it would be appreciated.
>>
>
> _______________________________________________
> Soa-tools-list mailing list
> Soa-tools-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/soa-tools-list