Thanks for the response Stephen!
I didn't think we could exclude the copying of the actual sources
themselves. That makes good sense! I changed it to
`scripts/**/*.js,css/**/*.css` instead of what you had, and this finally
seems to get the behaviour I want ;) I really had no idea this existed. I
was looking at the regular <excludes> tags. Those didn't seem to solve the
problem for me.
I have one last problem that maybe you can help solve too? It concerns the
yuicompressor:compress goal again, but this time it's about css.
I'm trying to create two css aggregations - one for the public site and one
for the application part of the site.
If I make the output file
${project.build.directory}/${project.build.finalName}/css/public-all.css,
everything works.
[INFO] generate aggregation :
C:\Users\me\IdeaProjects\myapp-development\target\myapp-1.0\css\public-all.css
[INFO] public-all.css (32029b)
[INFO] generate aggregation :
C:\Users\me\IdeaProjects\myapp-development\target\myapp-1.0\css\application-all.css
[INFO] application-all.css (50446b)
But if I try and output the aggregated file to another subdirectory, such
as ${project.build.directory}/${project.build.finalName}/css/public/all.css,
it gives the following warning (which should honestly be an error...):
[INFO] generate aggregation :
C:\Users\me\IdeaProjects\myapp-development\target\myapp-1.0\css\public\all.css
[WARNING] all.css not created
[INFO] generate aggregation :
C:\Users\me\IdeaProjects\myapp-development\target\myapp-1.0\css\application\all.css
[WARNING] all.css not created
Here is the pom.xml part where I am specifying the aggregations. Why on
earth is this not working?
<aggregation>
<removeIncluded>false</removeIncluded>
<insertNewLine>true</insertNewLine>
<output>${project.build.directory}/${project.build.finalName}/css/public/all.css</output>
<includes>
<include>**/public/base.css</include>
<include>**/public/jquery.fancybox-1.3.4.css</include>
</includes>
</aggregation>
<aggregation>
<removeIncluded>false</removeIncluded>
<insertNewLine>true</insertNewLine>
<output>${project.build.directory}/${project.build.finalName}/css/application/all.css</output>
<includes>
<include>**/application/reset.css</include>
<include>**/application/text.css</include>
<include>**/application/960.css</include>
<include>**/application/jquery-ui-1.8.11.custom.css</include>
<include>**/application/base.css</include>
<include>**/application/jquery.jcrop.css</include>
<include>**/application/farbtastic.css</include>
</includes>
</aggregation>
I checked and these directories exist too. If I try and point to a
directory that doesn't exist, the yuicompressor:compress goal will fail. I
just don't understand why the build process actually succeeds given valid
directories, but it doesn't create the files in those directories. It makes
no sense :(
I thought that maybe it was a filesystem security problem, but that isn't
it either.
I am genuinely baffled as to why this doesn't work. I would appreciate any
assistance on this little problem too. After this, I'm good to go ;)
Ken
On Mon, Dec 5, 2011 at 4:39 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> <modelVersion>4.0.0</modelVersion>
> <groupId>localdomain.localhost</groupId>
> <artifactId>example</artifactId>
> <packaging>war</packaging>
> <version>1.0-SNAPSHOT</version>
> <build>
> <finalName>example</finalName>
> <pluginManagement>
> <plugins>
> <plugin>
> <artifactId>maven-release-plugin</artifactId>
> <version>2.2.1</version>
> <configuration>
> <releaseProfiles>release</releaseProfiles>
> </configuration>
> </plugin>
> <plugin>
> <artifactId>maven-war-plugin</artifactId>
> <version>2.1.1</version>
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>tomcat-maven-plugin</artifactId>
> <version>1.1</version>
> <configuration>
> <path>/</path>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.mortbay.jetty</groupId>
> <artifactId>jetty-maven-plugin</artifactId>
> <version>8.0.1.v20110908</version>
> </plugin>
> </plugins>
> </pluginManagement>
> </build>
> <profiles>
> <profile>
> <id>release</id>
> <activation>
> <property>
> <name>yui.compress</name>
> </property>
> </activation>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-war-plugin</artifactId>
> <version>2.1.1</version>
> <configuration>
> <warSourceExcludes>scripts/*.js</warSourceExcludes>
> </configuration>
> </plugin>
> <plugin>
> <groupId>net.alchim31.maven</groupId>
> <artifactId>yuicompressor-maven-plugin</artifactId>
> <version>1.1</version>
> <executions>
> <execution>
> <phase>prepare-package</phase>
> <goals>
> <goal>compress</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <nosuffix>true</nosuffix>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </profile>
> </profiles>
> </project>
>
> should do what you want... you get live in place development of the
> uncompressed scripts with tomcat:run or jetty:run... when you want to try
> the compressed scripts
>
> mvn -Prelease tomcat:run-war
> or
> mvn -Prelease jetty:run-war
>
> and when you make an actual release with the release plugin, it will be the
> compressed scripts that are bundled.
>
> Note: for the compressed scripts you need to use run-war not run as due to
> how the servlet containers work, there are limitations to what the servlet
> container plugins can do, and therefore the only way to get a true
> reflection of the final artifact (ie. the war file) is to run the war file
> and not in-place.
>
> HTH
>
> -Stephen
>
> On 5 December 2011 05:18, Ken Egervari <ken.egerv...@gmail.com> wrote:
>
> > Hi guys,
> >
> > I finally got one comment from someone that looks promising, but I'm not
> > how to do what he's suggesting since he didn't give an example:
> >
> > The reason you're having problems is because the copying of webapp
> > resources is done by the war
> > plugin<http://maven.apache.org/plugins/maven-war-plugin/>in the same
> > breath that it builds the war. It's not a different lifecycle
> > phase or even two different actions in the same phase. It's all part
> > of the war:war
> > goal <http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html>.
> >
> > There's a workaround, though. If you bind
> > war:exploded<
> > http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html>to
> > an earlier phase, like
> > prepare-package, then it will build your exploded webapp, and then you
> can
> > put something after that to modify the files that were built to the
> > exploded directory. Then war:war will package up the modified exploded
> > directory. (With newer versions of the war plugin, I believe you'll need
> to
> > set the useCache<
> > http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#useCache
> > >property
> > to get the desired behavior, though that doesn't seem to really be
> > what it's for, be wary.)
> > I know how to bind the `maven-war-plugin` to an earlier phase, but how to
> > bind just the war:exploded to an earlier phase as he suggests?
> >
> > Ken
> >
> >
> > On Sun, Dec 4, 2011 at 9:49 AM, Ken Egervari <ken.egerv...@gmail.com>
> > wrote:
> >
> > > I think there has to be a better way than using the excludes. I really
> > > don't want to be maintaining so many lists of javascript files... it'll
> > be
> > > way too much of a maintenance problem. I just want this "to work". My
> > > project is massive. There is at least 150 javascript files as it is,
> and
> > > probably another 100-150 to be created. I just can't do the maintenance
> > > work. I am doing this whole project just by myself, and it's massive.
> > >
> > > Ken
> > >
> > >
> > >
> > > On Sun, Dec 4, 2011 at 8:54 AM, Robert Scholte <rfscho...@codehaus.org
> > >wrote:
> > >
> > >>
> > >> What about warSourceExcludes[1]?
> > >>
> > >> Don't make the m-war-plugin responsible for copying these files but
> the
> > >> yuicompressor.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -Robert
> > >>
> > >>
> > >>
> > >> [1]
> > >>
> >
> http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceExcludes
> > >>
> > >>
> > >> > Date: Sun, 4 Dec 2011 08:44:28 -0500
> > >> > Subject: Re: YUI Compressor Maven plugin executed at wrong time and
> > >> tomcat plugin not using yui-compressor output
> > >> > From: ken.egerv...@gmail.com
> > >> > To: users@maven.apache.org
> > >> >
> > >> > Yes, I've been playing around with getting the
> development/production
> > >> part
> > >> > working, and I think I've got it.
> > >> >
> > >> > I am still having problems getting the yuicompressor:compress goal
> to
> > be
> > >> > called at the right time. The problem is that the war:war goal has a
> > >> bunch
> > >> > of actions backed into it, and I don't know a way to wire into it
> and
> > >> call
> > >> > the yuicompressor:compress goal just after it copies the
> webResources
> > >> > directory. If I can solve that, I think I am golden. But I don't
> know
> > if
> > >> > that can be done.
> > >> >
> > >> > Ken
> > >> >
> > >> >
> > >> > On Sun, Dec 4, 2011 at 4:02 AM, Stephen Connolly <
> > >> > stephen.alan.conno...@gmail.com> wrote:
> > >> >
> > >> > > this is a perfect use case for profiles.
> > >> > >
> > >> > > in the release profile you use yui-compress to copy them into the
> > war
> > >> > >
> > >> > > in a development profile you add warResources to construct the war
> > >> from the
> > >> > > direct sources....
> > >> > >
> > >> > > that (assuming the tomcat maven plugin is written right... jetty
> can
> > >> do
> > >> > > this for sure) will give development with live editing, and just
> > >> -Prelease
> > >> > > to get the compressed version
> > >> > >
> > >> > > - Stephen
> > >> > >
> > >> > > ---
> > >> > > Sent from my Android phone, so random spelling mistakes, random
> > >> nonsense
> > >> > > words and other nonsense are a direct result of using swype to
> type
> > >> on the
> > >> > > screen
> > >> > > On 4 Dec 2011 01:52, "Ken Egervari" <ken.egerv...@gmail.com>
> wrote:
> > >> > >
> > >> > > > I think I should just give up on this problem because I don't
> > think
> > >> Maven
> > >> > > > has the ability to solve it, and if it does, I have no idea
> where
> > >> to look
> > >> > > > for a solution and its clear nobody else writing java web
> > >> applications
> > >> > > > knows how to solve this problem :/
> > >> > > >
> > >> > > > I guess I am stuck with manually including each main file on
> each
> > >> page
> > >> > > > where it is used, or coding everything in an all.js manually :/
> > >> > > >
> > >> > > > Even if I can get Maven to properly call the YUI:compress goal
> at
> > >> the
> > >> > > right
> > >> > > > time, I still have maintain two lists of css and javascript
> files
> > >> for my
> > >> > > > application - one for the aggregations, and one for my
> freemarker
> > >> > > template
> > >> > > > that switches between using all the individual source files for
> > >> > > > development, or using the all.css/all.js for production.
> > >> > > >
> > >> > > > I genuinely don't see a nice solution to do what the Rails
> people
> > >> have
> > >> > > > conveniently got in place. I am totally flustered that the
> > >> Maven/Spring
> > >> > > > combo has no good for answer to this problem :(
> > >> > > >
> > >> > > > Ken
> > >> > > >
> > >> > > >
> > >> > > > On Sat, Dec 3, 2011 at 4:19 PM, Ken Egervari <
> > >> ken.egerv...@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > I think the problem is that there is no phase I can merge into
> > >> just
> > >> > > after
> > >> > > > > it prepares the war directory - at least not from where I can
> > see
> > >> in
> > >> > > the
> > >> > > > > life-cycle documentation. What is the phase name? Is it not
> any
> > >> of the
> > >> > > > > package or pre-package phases - it is still too early or too
> > late.
> > >> > > > >
> > >> > > > > Ken
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On Fri, Dec 2, 2011 at 5:16 AM, Jeff MAURY <
> > >> jeffma...@jeffmaury.com
> > >> > > > >wrote:
> > >> > > > >
> > >> > > > >> By default, the compress goal of the YUI maven plugin is
> bound
> > >> to the
> > >> > > > >> process-resources phase.
> > >> > > > >> So, you need to bind it to another phase after the war plugin
> > has
> > >> > > > produced
> > >> > > > >> the war directory structure the Tomcat plugin will use.
> > >> > > > >> I recommand you also customize the outputDirectory parameter
> of
> > >> the
> > >> > > YUI
> > >> > > > >> maven plugin because the default value does not comply with
> the
> > >> > > standard
> > >> > > > >> Maven War directory layout.
> > >> > > > >>
> > >> > > > >> Regards
> > >> > > > >> Jeff MAURY
> > >> > > > >>
> > >> > > > >> ---------- Forwarded message ----------
> > >> > > > >> From: fe.character.guide <fe.character.gu...@gmail.com>
> > >> > > > >> Date: Fri, Dec 2, 2011 at 7:17 AM
> > >> > > > >> Subject: YUI Compressor Maven plugin executed at wrong time
> and
> > >> tomcat
> > >> > > > >> plugin not using yui-compressor output
> > >> > > > >> To: users@maven.apache.org
> > >> > > > >>
> > >> > > > >>
> > >> > > > >> Hello everyone!
> > >> > > > >>
> > >> > > > >> I'm trying to get some basic maven build processes configured
> > >> > > correctly
> > >> > > > >> with my Java project, and beyond Stackoverflow, I'm not sure
> > >> > > > >> where else to turn.
> > >> > > > >>
> > >> > > > >> I'd like to compress all of my javascript files and aggregate
> > >> them
> > >> > > using
> > >> > > > >> YUICompressor, and I saw that there was a maven plugin to
> allow
> > >> me to
> > >> > > do
> > >> > > > >> this. I got it working for the most part.
> > >> > > > >>
> > >> > > > >> I am also using the Mojo tomcat plugin as well. When i go to
> > run
> > >> the
> > >> > > > >> tomcat:run goal, tomcat does not read from the target's
> output
> > >> > > > >> directory (this is where the YUI compressor put my javascript
> > >> files) -
> > >> > > > but
> > >> > > > >> rather, it reads from the actual source files in my
> "src/main/
> > >> > > > >> webapp/scripts" directory. Of course, the aggregated
> javascript
> > >> file
> > >> > > > >> (all.js) is not there. This makes sense, but is a big problem
> > >> for me.
> > >> > > > >>
> > >> > > > >> I have a few questions.
> > >> > > > >>
> > >> > > > >> 1. How can I get the tomcat plugin to read the target's
> output
> > >> folder
> > >> > > > that
> > >> > > > >> the yui compressor plugin created?
> > >> > > > >>
> > >> > > > >> 2. Do I have to run the yui compressor maven goal every time
> I
> > >> want to
> > >> > > > >> update my javascript files during development while my tomcat
> > >> instance
> > >> > > > is
> > >> > > > >> running?
> > >> > > > >>
> > >> > > > >> 3. How can tell Maven that I want to run the YUI compressor
> > AFTER
> > >> > > Maven
> > >> > > > >> copies over the `src/main/webapp` directory? Currently, Maven
> > >> runs the
> > >> > > > YUI
> > >> > > > >> compressor, but then overwrites all of the compressed css and
> > >> > > javascript
> > >> > > > >> files with the original source files, defeating the purposes
> of
> > >> > > > >> compressing
> > >> > > > >> them ;)
> > >> > > > >>
> > >> > > > >> 4. Is there a better way to achieve my objective rather than
> > >> using the
> > >> > > > YUI
> > >> > > > >> compressor? Essentially, my end goal is to be able to develop
> > >> > > JavaScript
> > >> > > > >> code in separate files and test my source files in
> development
> > >> mode
> > >> > > > >> without
> > >> > > > >> having to aggregate them... but I want to compress and
> > aggregate
> > >> the
> > >> > > > files
> > >> > > > >> and use the `all.js` script when the application is running
> in
> > >> > > > production
> > >> > > > >> mode.
> > >> > > > >>
> > >> > > > >> While the Rails people have certainly figured this out, this
> > >> seems to
> > >> > > > be a
> > >> > > > >> non-trivial thing to do with Maven and Spring.
> > >> > > > >> I would appreciate any and all assistance on how I can get
> this
> > >> > > running
> > >> > > > >> correctly. Thanks!
> > >> > > > >>
> > >> > > > >>
> > >> > > > >>
> > >> > > > >> --
> > >> > > > >> "Legacy code" often differs from its suggested alternative by
> > >> actually
> > >> > > > >> working and scaling.
> > >> > > > >> - Bjarne Stroustrup
> > >> > > > >>
> > >> > > > >> http://www.jeffmaury.com
> > >> > > > >> http://riadiscuss.jeffmaury.com
> > >> > > > >> http://www.twitter.com/jeffmaury
> > >> > > > >>
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: users-h...@maven.apache.org
> > >>
> > >>
> > >
> >
>
