[
http://jira.codehaus.org/browse/MGWT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203046#action_203046
]
Richard Allen edited comment on MGWT-131 at 12/16/09 9:31 AM:
--------------------------------------------------------------
First, understand that we are already using a customized gwt-maven-plugin to
work around this issue, an issue related to a comment I made on MGWT-75, and to
put the source for the projects in the reactor (i.e., the listed {{<module>}}
s) on the classpath for GWT 2.0 Development Mode without having to list the
directories using build-helper-maven-plugin (i.e., less configuration, easier
to maintain). Therefore, if you are set against allowing GWT compile to be used
with pom projects, so be it, it's not slowing us down. As an effort to
contribute back to the community, I commented on this issue to help you and
others that might use your plugin.
However, I find it odd that you would rather restrict the use of your plugin to
specific use cases then simply adjust your fix to make it an option -- chosen
by default if you wish.
Now, for the questions related to our project structure.
The webapp project is a pom project with no source that uses the {{<modules>}}
tag to list each project in the build to form a maven multi-module build. The
benefit of a multi-module build is that it allows our developers to change code
in any of the projects and run one command line to re-build the war to test.
The webapp project also configures plugins (specifically the
maven-resources-plugin, maven-dependency-plugin, gwt-maven-plugin, and
maven-assembly-plugin) to copy the src/main/webapp directories from the
war-type dependencies into the webapp/war/ directory, copy the dependencies
(using Maven dependency management) into the webapp/war/WEB-INF/lib/ directory,
execute the GWT compile, and build the WAR file (actually, the war file is only
built if not running GWT Development Mode). Because the webapp project uses the
{{<modules>}} tag to form a multi-module build, it cannot be a war project.
Only projects with packaging of type 'pom' can use the Maven {{<modules>}} tag.
The only source code we copy from other projects into the webapp/war/ directory
is the src/main/webapp/ of war type projects (the web modules, like
project2-feature1-module from the example above). I have already explained that
we have chosen not to use packaging of type 'war' in those projects because
maven-war-plugin war overlays are significantly slower, due to the fact that
each fractional war project is made into a war file, installed into your local
repo, then, when building your final war, extracted into a directory, then
merged into the final war. That process is absurdly slow for the number of web
modules that we have.
The projects that have {{.gwt.xml}} files in them, which can be any of the
projects including the typical jar projects as well as the projects with a
src/main/webapp directory (the web modules, like project2-feature1-module from
the example above), have a JAR built and installed in the typical fashion,
which includes {{.class}} files, and the files from src/main/resources.
Additionally, we build and install a JAR with a classifier of "gwt" that has
the Java source code (not the Java bytecode) and any other resource files that
are in src/main/java and src/main/resources. We put the {{.gwt.xml}} files and
the GWT {{public}} folder in src/main/java.
There are reasons behind all of this.
The JAR with a classifier of "gwt" is very similar to a "-sources.jar" built by
Maven using the maven-source-plugin. The reason we don't just use the sources
JAR is because you can't process the files before they go into the sources JAR,
which sometimes we want to do. The sources JAR is just that, the source. All
"gwt" JARs are excluded from the WEB-INF/lib directory of the final war to
avoid having duplication with the static files from the GWT {{public}} folder
that GWT compile places in the root of the war file, and to avoid having Java
source code in the final war (makes the war file smaller). We put the
{{.gwt.xml}} files and the GWT {{public}} folder in src/main/java so they get
included in the "gwt" classifier JAR, where they are needed, but not in the JAR
with no classifier, where they are not needed an would only contribute to bloat
of the final war file.
If a GWT module only has code that is used on the client, meaning all of the
code will be compiled to JavaScript and placed in the root of the war, then we
only reference the "gwt" classifier JAR in our {{<dependencies>}}. If it has
server-side code also, then we reference both the "gwt" classifier JAR and the
JAR with no classifier in our {{<dependencies>}}, but the "gwt" classifier JAR
is excluded from the WEB-INF/lib of the final war, therefore only the
{{.class}} files end up in the WEB-INF/lib of the final war, thereby avoiding
war file bloat.
Using project1 from above as an example, another alternative would be to give
the project1/webapp/pom.xml packaging of type 'war', and move the {{<modules>}}
tag into the project1/pom.xml. This would mean you would do your multi-module
build from the project1/ directory instead of the project1/webapp/ directory.
However, there is a problem with this due to the capabilities of the
maven-war-plugin. As I just explained, I want to exclude some JARs from the
WEB-INF/lib directory of the final war to avoid war file bloat and avoid Java
source code in my war (additionally I avoid any classpath trouble in my servlet
container). The maven-war-plugin allows you to configure excludes from the
final {{.war}} file, but not from the exploded war (i.e., the webapp/war/
directory). For us, this presents a problem.
To make development as fast as possible and as close as possible to production
environment, we use GWT 2.0 Development Mode with the {{-noserver}} option.
Typically, to use the {{-noserver}} option, you have to first run a GWT
compile, then copy files generated by GWT, and your server-side code, over to
your servlet container. That means you have two steps before you can test, and
the first must execute a GWT compile, which is slow. We run Tomcat as our
deployment servlet container, and to avoid this slow, two-step process for
development, we simply copy a {{context.xml}} file over to Tomcat with a
{{docBase}} that points back to the webapp/war/ directory, which is the same
directory that GWT Development Mode uses.
In the end, with our current setup, we have a large multi-module build, where
all you have to do is change to the webapp/ directory, and execute one Maven
command to build the project without a GWT compile, deploy the {{context.xml}}
to Tomcat, and run GWT Development Mode with all projects in the classpath.
Meaning you can change UI code in any one of the multiple projects and simply
refresh your browser to see the changes. Or, you can execute one Maven command
from the webapp/ directory to build the final war file with a GWT compile.
was (Author: richard.allen):
First, understand that we are already using a customized gwt-maven-plugin
to work around this issue, an issue related to a comment I made on MGWT-75, and
to put the source for the projects in the reactor (i.e., the listed
{{<module>}}s) on the classpath for GWT 2.0 Development Mode without having to
list the directories using build-helper-maven-plugin (i.e., less configuration,
easier to maintain). Therefore, if you are set against allowing GWT compile to
be used with pom projects, so be it, it's not slowing us down. As an effort to
contribute back to the community, I commented on this issue to help you and
others that might use your plugin.
However, I find it odd that you would rather restrict the use of your plugin to
specific use cases then simply adjust your fix to make it an option -- chosen
by default if you wish.
Now, for the questions related to our project structure.
The webapp project is a pom project with no source that uses the {{<modules>}}
tag to list each project in the build to form a maven multi-module build. The
benefit of a multi-module build is that it allows our developers to change code
in any of the projects and run one command line to re-build the war to test.
The webapp project also configures plugins (specifically the
maven-resources-plugin, maven-dependency-plugin, gwt-maven-plugin, and
maven-assembly-plugin) to copy the src/main/webapp directories from the
war-type dependencies into the webapp/war/ directory, copy the dependencies
(using Maven dependency management) into the webapp/war/WEB-INF/lib/ directory,
execute the GWT compile, and build the WAR file (actually, the war file is only
built if not running GWT Development Mode). Because the webapp project uses the
{{<modules>}} tag to form a multi-module build, it cannot be a war project.
Only projects with packaging of type 'pom' can use the Maven {{<modules>}} tag.
The only source code we copy from other projects into the webapp/war/ directory
is the src/main/webapp/ of war type projects (the web modules, like
project2-feature1-module from the example above). I have already explained that
we have chosen not to use packaging of type 'war' in those projects because
maven-war-plugin war overlays are significantly slower, due to the fact that
each fractional war project is made into a war file, installed into your local
repo, then, when building your final war, extracted into a directory, then
merged into the final war. That process is absurdly slow for the number of web
modules that we have.
The projects that have {{.gwt.xml}} files in them, which can be any of the
projects including the typical jar projects as well as the projects with a
src/main/webapp directory (the web modules, like project2-feature1-module from
the example above), have a JAR built and installed in the typical fashion,
which includes {{.class}} files, and the files from src/main/resources.
Additionally, we build and install a JAR with a classifier of "gwt" that has
the Java source code (not the Java bytecode) and any other resource files that
are in src/main/java and src/main/resources. We put the {{.gwt.xml}} files and
the GWT {{public}} folder in src/main/java.
There are reasons behind all of this.
The JAR with a classifier of "gwt" is very similar to a "-sources.jar" built by
Maven using the maven-source-plugin. The reason we don't just use the sources
JAR is because you can't process the files before they go into the sources JAR,
which sometimes we want to do. The sources JAR is just that, the source. All
"gwt" JARs are excluded from the WEB-INF/lib directory of the final war to
avoid having duplication with the static files from the GWT {{public}} folder
that GWT compile places in the root of the war file, and to avoid having Java
source code in the final war (makes the war file smaller). We put the
{{.gwt.xml}} files and the GWT {{public}} folder in src/main/java so they get
included in the "gwt" classifier JAR, where they are needed, but not in the JAR
with no classifier, where they are not needed an would only contribute to bloat
of the final war file.
If a GWT module only has code that is used on the client, meaning all of the
code will be compiled to JavaScript and placed in the root of the war, then we
only reference the "gwt" classifier JAR in our {{<dependencies>}}. If it has
server-side code also, then we reference both the "gwt" classifier JAR and the
JAR with no classifier in our {{<dependencies>}}, but the "gwt" classifier JAR
is excluded from the WEB-INF/lib of the final war, therefore only the
{{.class}} files end up in the WEB-INF/lib of the final war, thereby avoiding
war file bloat.
Using project1 from above as an example, another alternative would be to give
the project1/webapp/pom.xml packaging of type 'war', and move the {{<modules>}}
tag into the project1/pom.xml. This would mean you would do your multi-module
build from the project1/ directory instead of the project1/webapp/ directory.
However, there is a problem with this due to the capabilities of the
maven-war-plugin. As I just explained, I want to exclude some JARs from the
WEB-INF/lib directory of the final war to avoid war file bloat and avoid Java
source code in my war (additionally I avoid any classpath trouble in my servlet
container). The maven-war-plugin allows you to configure excludes from the
final {{.war}} file, but not from the exploded war (i.e., the webapp/war/
directory). For us, this presents a problem.
To make development as fast as possible and as close as possible to production
environment, we use GWT 2.0 Development Mode with the {{-noserver}} option.
Typically, to use the {{-noserver}} option, you have to first run a GWT
compile, then copy files generated by GWT, and your server-side code, over to
your servlet container. That means you have two steps before you can test, and
the first must execute a GWT compile, which is slow. We run Tomcat as our
deployment servlet container, and to avoid this slow, two-step process for
development, we simply copy a {{context.xml}} file over to Tomcat with a
{{docBase}} that points back to the webapp/war/ directory, which is the same
directory that GWT Development Mode uses.
In the end, with our current setup, we have a large multi-module build, where
all you have to do is change to the webapp/ directory, and execute one Maven
command to build the project without a GWT compile, deploy the {{context.xml}}
to Tomcat, and run GWT Development Mode with all projects in the classpath.
Meaning you can change UI code in any one of the multiple projects and simply
refresh your browser to see the changes. Or, you can execute one Maven command
from the webapp/ directory to build the final war file with a GWT compile.
> Plugin attempts to compile projects with 'pom' packaging
> --------------------------------------------------------
>
> Key: MGWT-131
> URL: http://jira.codehaus.org/browse/MGWT-131
> Project: Maven 2.x GWT Plugin
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Fedora 11, Java 1.6.0_16, Maven 2.2.1, GWT 1.7.1
> Reporter: Daniel Scott
> Assignee: nicolas de loof
> Priority: Minor
> Fix For: 1.2
>
>
> When the GWT compile goal is enabled for projects which have the 'pom'
> packaging type, maven attempts to compile the project and fails because no
> source code is available. The compilation should be disabled by default for
> projects which have the 'pom' packaging type.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
