So I am a little unclear how different this proposal is from what we
support today with directory deployment.
With directory deployment the IDE and glassfish share the application
directory (IDE compiles in it and GF loads classes from it) so there
is no need for war packaging, transfer to the server type of action at
each iterative deployment cycle.
With netbeans being capable of leveraging directory deployment, we are
pretty much doing what you described below (except we don't use a
virtual file system but just an exploded directory structure that the
IDE and GlassFish have agreed upon).
So the war file redeployment is *very* fast when you use netbeans with
glassfish, I see no reason why other IDEs could not leverage that
directory deployment feature.
Is there something else you would want to see ?
On Nov 2, 2007, at 1:47 AM, glassfish_at_javadesktop.org wrote:
> I absolutely agree.
> However, the server doesn't need to be able to load classes
> dynamically. The proposed changes do not entail that it does. The
> server could still reload the whole application on each update. The
> improvement would still be that only the files get transmitted to
> the server that have been modified. The server could then assemble a
> new deployment based on the existing one and the modified Increment
> and then deploy this new, self-assembled application archive in the
> traditional way.
>
> The proposal to get rid of the need for physical deployment-unit
> assembly does not require dynamic class definition reloadin either.
> The server could still act in the classical sense and reload an
> application in total for each update, but a good deal of time could
> be saved if IDEs didn't need to physical assemble an application
> before deployment. The only need for this is because the development
> arrangements of application artifacts differs from the deployment
> structure and because IDEs have no means to provide servers with
> virtual deployment units.
>
> My imagination is such that a server would be able to deploy an
> application by being provided with a link to a virtual filesystem
> location. At this location, the server would expect to find a
> correct application archive atructure. The top level directory would
> have to contain a META-INF directory with an application.xml file in
> it...
> An IDE would provide the server with a virtual filesystem link that
> leads back to a virtual filesystem service provided by the IDE
> itself. If the server requested to receive a directory listing for
> his deployment link, the IDE would return a correct application
> archive structure. If the server consequently tried to access the
> META-INF/application.xml file, it would again connect to the IDEs
> virtual filesystem service and request this file. The IDE would
> consult it's project configuration to resolve the META-INF/
> application.xml file to a project location myproject/meta/
> deploymentdescritors/application-config1.xml.
>
>
> Of course, the need to do full redeployments on server-side would
> still be time consuming but the development experience would be much
> better. Test the virtual deployment caps that are implemented in
> Eclipse for Tomcat 6 webservers and you will see how perfect the
> approach is.
> BTW: the approach to physically build a deployment unit should
> survive also for deployments that are outside the scope of the code-
> deploy-test cycle.
> [Message sent by forum member 'wtff' (wtff)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243442
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>