[prev in list] [next in list] [prev in thread] [next in thread] 

List:       turbine-dev
Subject:    RE: Maven Plugin for Turbine (META)
From:       Henning Schmiedehausen <hps () intermeta ! de>
Date:       2004-05-28 13:02:47
Message-ID: 1085749367.19096.35.camel () forge ! intermeta ! de
[Download RAW message or body]

Hi Lester, 

thanks for trying out and your feedback	

On Thu, 2004-05-27 at 21:45, Lester Ward wrote:
> > If you find bugs or want enhancements, feel free to send your
> > suggestions to the developer list or directly to me (I prefer the
> > developer list because there are more eyes and I have an archive).
> 
> Ran this on Win32 with rc3. Seems fine.
> 
> Doc Issue: Couldn't download torque-gen-3.1.1-dev.jar. Handling this is
> mentioned in the installation page, but that section of the doc should
> probably be moved to the part of the Getting Started page where you actually
> run turbine:deploy.

The torque-gen-3.1.1-dev should be on ibiblio or will be there soon.
Then I want to update the docs so that the torque-plugin can be
downloaded from there.

> 
> Issue: I set maven.appserver.home=d:\programming\tomcat-4.1.24. This, of
> course, hoses everything because of the single backslashes. The errors don't
> happen until turbine:deploy is run, however. You might want to have
> turbine:setup check that the directory actually exists.

Noted. There is somewhere in the docs, that you must use "/", not "\".
This is more of a java/maven/ant issue than a META issue. 

> 
> Question: I notice that you don't setup the "resources" directory that the
> TDK sets up (it contains css, ui/skins, etc.). Any reason?

I don't use it. :-) I setup a styles directory, because all my webapps
use styles/foostyle.css and images/fooimage.png. Actually, it is a good
idea to add this for switching over from the TDK. Noted.

> 
> Comment: Good documentation, overall. I'm doing some non-standard stuff with
> the deployment, and found the docs very easily explained the best way to
> override stuff. I tend to use Eclipse, and so used the inplace concept. This
> was not entirely sufficient for my purposes, however. To me, to be truly
> "inplace" means not having to call turbine:deploy more than once. In other
> words, I do it once to set up the project, but never do it again, and then
> set up eclipse to work out of the resulting directories automatically. This
> includes changing code, config and templates.

> To this end, I start with a setup.properties as follows (and then never use
> turbine:deploy beyond the first time):
> 
> turbine.app.package = com.tagaudit
> turbine.app.inplace = true
> turbine.app.inplace.dir = src/webapp
> 
> turbine.plugin.src.templates = src/webapp/templates
> turbine.plugin.src.conf = src/webapp/conf
> 
> This puts everything into the webapp automatically (assuming a retargeting
> of Eclipse to put class files in the correct place, which I do with an
> eclipse postgoal). I then use a statement like this in my Tomcat server.xml:
> 
>          <Context path="/turbinesample"
>             docBase="D:\p4\turbinesample\main\src\webapp"
>             reloadable="true" crossContext="true"
>          /> 
> 
> Anyway, the point of all this is that when I attempt this with the plugin,
> the initial turbine:deploy gives me the following:
> 
> File...... C:\Documents and
> Settings\lward\.maven\plugins\maven-turbine-plugin-1.1-dev\plugin.jelly
> Element... copy
> Line...... 354
> Column.... 55
> Warning: Could not find file
> D:\p4\templates\turbinesample\conf\turbinesample-web.xml to copy.
> 
> This appears to be (ultimately) due to this line in
> plugin-resources\maven\turbine-2.3\project.properties:
> 
> maven.war.webxml = conf/@TURBINE_APP_NAME@-web.xml
> 
> I think this should be:
> 
> maven.war.webxml = @TURBINE_PLUGIN_SRC_CONF@/@TURBINE_APP_NAME@-web.xml
> 
> There are a couple more such issues in that same file, though I'm not
> bothered by them. (For example, there are a couple of places that use
> "target" that should really use "${maven.build.dir}". Naturally, I can just
> change the resulting project.properties in my own project to work around
> such problems, since turbine:setup is only run once.
> 
> Other than that issue, changing the turbine.plugin.src.* properties like
> this seems to work fine. The initial call to turbine:deploy properly deals
> with the fact that it is trying to copy some directories and files (e.g. the
> templates) to themselves with no worries (Ant probably gives you this for
> free).

Ok. Getting feedback from IDE users is very important for me, mainly
because I don't use an IDE. :-) I will read this carefully when I come
back from holidays in two weeks (currently I'm just skimming over your
mail).

Thanks a lot for your feedback.

	Regards
		Henning



-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/
 
RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honourable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
                       --Michelle Levesque, "Fundamental Issues with
                                    Open Source Software Development"


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]