search

google-code-export / wro4j

Automatically exported from code.google.com/p/wro4j
1 stars 1 forks source link

is there a way to configure where buildContext.properties is stored? #863

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. run wro4j as a maven task using the following:
                        <configuration>
                            <targetGroups>default</targetGroups>
                            <minimize>true</minimize>
                            <destinationFolder>${project.build.directory}/${project.build.finalName}/wro/</destinationFolder>
                            <contextFolder>${basedir}/src/main/webapp/</contextFolder>
                            <wroFile>src/main/resources/wro.xml</wroFile>
                            <wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>
                            <ignoreMissingResources>false</ignoreMissingResources>
                        </configuration>

2. wro4j puts buildContext.properties in /tmp/.wro4j/ 
3.if multiple people write to that file, we have permissions issues

can this be configured to not use java.io.tmpdir?

(wro4j v 1.7.2)

Original issue reported on code.google.com by ab...@digitalantiquity.org on 30 Mar 2014 at 1:22

GoogleCodeExporter commented 9 years ago 
I would like to understand better your use case. Why would more than one people 
would write to that file? How would configuring that folder outside of 
java.io.tmpdir solve this issue?

Original comment by alex.obj...@gmail.com on 31 Mar 2014 at 7:41

GoogleCodeExporter commented 9 years ago 
well. basically we have four developers on a unix box.  for security reasons 
our umask is set to default to group. each developer may be responsible for 
deploying our application.  The wro4j task is part of the deploy profile in 
maven, thus each user must wipe the file every time they deploy, or they get 
write-permission errors on the file. This file is really dependent on a build, 
you're making the assumption that this only gets used once system-wide 
per-reboot. Why not put it in the target directory?

Original comment by ab...@digitalantiquity.org on 31 Mar 2014 at 4:23

GoogleCodeExporter commented 9 years ago 
It would be possible to move those to target. The reason why I didn't that in 
the first place, is to not polute the target folder with junk files which 
doesn't really make any sense to the end customer. This storage is actually 
optional, it isn't meant to be used if incremental build is supported, since 
the temporary storage is provided by maven itself.

I would like to not make this configurable, since it adds unnecessary 
configuration option which user shouldn't really worry about.

Original comment by alex.obj...@gmail.com on 31 Mar 2014 at 4:32

GoogleCodeExporter commented 9 years ago 
Alternately, you might consider time-stamping the file or making it marked as 
temporary, so, ideally it goes away at the end of the JVM run.

Original comment by ab...@digitalantiquity.org on 31 Mar 2014 at 4:47

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 8 Apr 2014 at 9:55

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 18 Jun 2014 at 11:07