Re: understanding how configs are "mavenized"

Adam:

> That did it, thanks for the advice!

Good stuff - sorry, it's not terribly intuitive yet, and the doc lags
behind a bit :-) But breaking it up into two projects does enforce the
re-usability nicely...

> I was indeed combining the "app-timewarp" and "timewarp project"
> concepts. I have now split up the project, resulting in an app-timewarp
> project with my java files, jsp's, and a project.xml with minimal
> dependencies. I have marked this as a SNAPSHOT version in the
> project.xml, and I build it by executing "maven jar:install". This also
> fixed my jsp problem that I had reported earlier. In previous posts, I
> had to specify a "src/webapp" directory for my webapps (maven default)
> instead of "src/jsp/struts" like the example projects. Now that this is
> an "app-" project, I moved the jsp's back to the src/jsp/struts
> subdirectory, and they are properly packaged into the resulting jar (and
> ultimately into the war).

Ah - I was wondering if that was the same issue possibly...

> I also have a "timewarp" project, which has a build.properties file, a
> keel.properties file, and a project.xml. In this project.xml, I have
> specified dependencies to app-timwarp (snapshot version) as well as a
> bunch of other goodies, like app-crud, auth, etc. In this directory, I
> issue the "maven war" command, and I see that my
> app-timewarp-SNAPSHOT.jar is picked up from the local repository. The
> war file works as expected.
> 
> My final question is a practical working question. What is normal
> development process now? I suspect that I will issue a "maven eclipse"
> command in the app-timewarp project, and will make changes to my java
> files and jsp files from within eclipse on my app-timewarp project.

maven eclipse is really only necessary when the classpath changes. What
I do is define "Run External Program" links in Eclipse, so I can do a
"maven jar:install-snapshot" on my module, then just move to the "war"
project and run the "maven war" the same way (with a command from within
Eclipse). This way I can work entirely from within Eclipse for the most
part. There are also a couple of Eclipse plugins for Maven, but to be
honest I haven't found them much help so far.

> However, my "maven war" builds take a few minutes to complete. What is
> the most efficient way to develop and test? It seems like a long process
> to issue the maven jar:install command, switch directories, issue the
> maven war command, and deploy the war to test the next chunk of code.
> Any practical guidelines for decreasing the development/test cycle?

Well, the uberjar and war process are not that quick, no question. There
are no doubt optimizations we can do, but the first thing to try is to
localize the unit tests to the app-* jar, e.g. if you have a series of
unit tests in app-timewarp that excercise things, then you basically
work "within" the app-timewarp project until a set of tests are running
clean. Then you do the "whole 9 yards" of building the webapp.

One issue that cropped up with Maven is that what we've been calling
"unit tests" really aren't - they're *integration* tests, which is why
most of the current keel modules have maven.test.failure.ignore=true in
their build.properties - this is actually not recommended, as normally a
"maven jar" (or jar:install-snapshot) will run the unit tests, and only
create and install the jar *if* all unit tests are passing.

In our case, for the moment at least, you have to do the whole "uberjar"
build and then run the tests from *that* project (e.g. where you build
the war), which is tedious.

So, ideally we should be working towards a "test-driven" development
cycle I believe, where the normal process is to work with app-xxx until
it's testing clean, then build the war/uberjar only for the purposes of
integration testing (less frequently then unit testing).

HTH!

Mike

> 
> Regards,
> 
> Adam
> 
> 
> 
> On Sun, 2005-03-13 at 13:50, Michael Nash wrote:
> > Adam:
> > 
> > I've made a start at documenting the two different "types" of Keel
> > project when using Maven here:
> > 
> > http://keelframework.org/release/HEAD/docbook/keel-doc/html_chunk/manual/ch13.html#d0e5918
> > 
> > I'm not 100% sure, but I think it may be that you've got one project
> > trying to be "both", from what you describe.
> > 
> > E.g. if you're writing a webapp, there's going to be an "app-xxx"
> > module, where you have your models, your UI files, etc. This app-xxx is
> > turned into app-xxx-version.jar and made available in your local (only)
> > repository with a "maven jar:install".
> > 
> > Then you've got a second project, which is where you actually put
> > app-xxx together with the Keel services it needs. There's no code in
> > this project, no JSP,s nothing - just a project.xml and a couple of
> > config files (at least a keel.properties, probably a build.properties).
> > 
> > This is where you'd do a "maven war" to assemble the finished app and
> > create a war file.
> > 
> > On Sun, 2005-03-13 at 12:18, Adam Rossi wrote:
> > > I have been trying to get an existing project to play in the new
> > > mavenized environment, but I am running into some problems, I think due
> > > to my lack of understanding of how all the pieces now fit together.
> > > 
> > > I am having trouble getting the following configurations to get picked
> > > up in the war file:
> > > 
> > > conf/client/struts/struts-config.xml - this file has my struts forwards,
> > > which should get folded in to the consolidated struts-config.xml. For
> > > me, only associated projects like app-crud have the forwards in the
> > > final war file, but my project entries in this file are not getting
> > > picked up.
> > 
> > Where do you have your entries? They should be in conf/client... within
> > an "app-something" module. The conf/client dir in the module where you
> > run a "maven war" will not be used.
> > > 
> > > conf/server/logkit.xconf, system.xconf - these files are not getting
> > > carried over into the war file. The merged.config in the war file does
> > > not have any of my "stuff" from these files, but the dependency apps
> > > like app-crud are working properly.
> > > 
> > > xdoclet persistent stuff: I had a bunch of xdoclet stuff in my java
> > > persistent classes, which ant used to pull out and automatically
> > > generate persist-name.xconf files, which would then get folded into the
> > > merged file. Now with my "maven war" process, these files are not
> > > getting created, and when I look at the persistent menu in app-crud, I
> > > do not see my app's schema.
> > 
> > A "maven war" will not do this - application code should always be in a
> > module that's generated with a "maven jar", which is where the plugin
> > will run the appropriate xdoclet/Fortress processes to extract the
> > configuration. The config then gets included in the app-xxx-version.jar
> > file, where it is later extracted by the "war" (actually the "uberjar")
> > process and bundled into the uberjar for the finished application (this
> > is true for both webapps and standalone apps)
> > 
> > > Any guidance on how to get these configuration items to flow through to
> > > the war would be greatly appreciated. I have read the documentation, but
> > > I have not found the relevant section which describes the structure of
> > > configuration.  The odd thing is, I have (I think) faithfully copied the
> > > structure and layout of other apps in CVS, such as app-crud, and
> > > app-poll, but what is apparently working there is not working for me.
> > 
> > I hope the above helps, I may be on the wrong page as far as what the
> > problem is!
> > 
> > Mike
> > 
> > > 
> > > Regards,
> > > 
> > > Adam
> > > 
> > > 
> > > http://keelframework.org/documentation.shtml
> > > Keelgroup mailing list
> > > [email protected]
> > > http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
> > 
> > http://keelframework.org/documentation.shtml
> > Keelgroup mailing list
> > [email protected]
> > http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
> 
> 
> http://keelframework.org/documentation.shtml
> Keelgroup mailing list
> [email protected]
> http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com

http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com