Setting the publish state on modules via the internal Server class (haven't
found a public API for that) yields different results depending on the
server adapters.

I'm currently with extremely limited internet/computer access. I'll resume
my experiments and update the status on this issue in about a week or so.
(Only if mosquitoes spare my life in the coming days)
Le 2 août 2013 19:32, "Giormov, Dimitar" <dimitar.gior...@sap.com> a écrit :

> Hi,
>
> Or you can simply do nothing.
> Once the code of the project is changed, the resource change listener will
> detect the change and will mark the module for republish. (there will be a
> label saying [republish] next to the module and the server as far as I can
> remember. So the user can decide whether he/she wants to republish at this
> stage or later. And if the user wants to enable auto republish, it can be
> done in the server editor. Auto republish works only if the server is
> already started I think.
>
> Best regards,
> Dimitar
>
> Message: 1
> Date: Fri, 02 Aug 2013 16:57:39 +0800
> From: Rob Stryker <rob.stry...@redhat.com>
> To: Fred Bricon <fbri...@gmail.com>
> Cc: "General discussion of project-wide or architectural issues."
>         <wtp-dev@eclipse.org>
> Subject: Re: [wtp-dev] How to hint an IServer it should publish stuff?
> Message-ID: <51fb7483.1040...@redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> As far as I know, there is no API to ensure a publish does not start the
> server.
>
> You could, however, try to set the module publish state to one of the
> IServer constants indicating an unknown state. This wouldn't force the
> server to publish immediately, but it would tell the server that a
> publish is needed (without forcing the publish to occur).
>
> I would see this as a bug in the glassfish adapter. IT should support a
> publish without a start, but, I suppose it's entirely up to them how to
> handle their adapter.
>
> On 07/31/2013 05:46 AM, Fred Bricon wrote:
> > Hi,
> >
> > I have this bug report in m2e-wtp[1], where calling IServer.publish()
> > [2] causes some adapter(s) (GlassFish at least) to start stopped
> > server instances. I must say I find that behavior questionable, but I
> > can't control how 3rd party server adapters work. Anyways, is there a
> > recommended way to tell the stopped IServer instance it *should*
> > publish, in a way it -most likely- wouldn't start the server?
> >
> > And if you ask why I force server publication in that resource
> > listener, it's to support dynamic war overlay [3] (changes in overlay
> > project are automatically published in main web app)
> >
> > So if you have any pointers, please let me know. Thanks,
> >
> > Fred.
> >
> > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413987
> > [2]
> >
> https://github.com/eclipse/m2e.wtp/blob/master/org.eclipse.m2e.wtp.overlay/src/org/eclipse/m2e/wtp/overlay/internal/servers/OverlayResourceChangeListener.java#L83
> > [3] http://maven.apache.org/plugins/maven-war-plugin/overlays.html
> >
> >
> > --
> > "Have you tried turning it off and on again" - The IT Crowd
>
>
>
> ------------------------------
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
>
> End of wtp-dev Digest, Vol 102, Issue 1
> ***************************************
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Reply via email to