This is very similar to what we have done with out portal that consists
of 70+ maven projects that produce libraries, servlets, portlets and
batch jobs.
The batch jobs include:
- A batch job that is run on a third party's server that extracts data
from another 3rd party's database and puts the data into our server.
- A batch job that is triggered by a portlet to run a data upload that
takes 40 minutes to validate and update the database once the portlet
has accepted the data and done a preliminary validation of 3 files that
the user specified.
We did not have any Maven issues using the assembly plug-in to build the
resulting artifacts.
On 30/12/2010 3:16 PM, Steve Cohen wrote:
After a very frustrating couple of days trying to understand the new
features of the assembly plugin, let me try to specify what I am
TRYING to do and see if there isn't a better (i.e. more mavenish) way
of doing it. Maven is flexible as long as you don't stray too far out
of the beaten path.
I am supporting two main applications in this system.
One is a fairly standard war file that runs under Tomcat. It isn't
really a web application, but from this perspective, one might as well
assume that it is.
Pretty easy.
The other is a not really standard zip file that contains a standalone
java application. The standalone application deals with batch
processes pertaining to the backend database that is used by the "web
application". While there may be other ways to organize this code,
let's say that this mode of organization is an unalterable requirement.
Not unusual. Batch is not going away for some tasks that are either long
running or need to be scheduled to run without user intervention..
The two applications share some modules - for database access, and for
contacting some external web services of which both applications are
clients at various points.
We call them "libraries".
The structure I use is that each module is a separate Eclipse project
and a separate SVN project. Each project is ultimately descended from
a parent POM that governs which dependency version to use for each
dependency and which plugin version to use.
We do not put dependency management in the parent but that is just my
decision - not necessarily universally regarded as the best choice by my
team but .....
Since some of the modules need to be "owned" by both of the
applications, they aren't actually owned by either. Instead, I try to
treat them as much like third-party jars as possible. They are
installed into the local repository and then used as appropriate.
They aren't quite as stable as most third-party jars, they are
evolving to different degrees, along with the main applications.
Libraries again. I would not tolerate the use of unreleased code in a
production dependency. Write the library, test it and deploy it as a
SNAPSHOT until it is ready to release.
Just because we wrote it does not mean that we don't have to do it
right. Deploy it as a release once you are ready to release the modules
that it supports or you are sure that it will not change. No local
repositories - everything goes into Nexus as soon as the programmer is
willing to warranty its perfection.
This applications of this system can be built both in m2eclipse and by
a server process that builds automatically after getting pristine
source from svn.
We are happy to go from the Nexus release repo into production but I can
see the value of testing from the svn to ensure that programmers are
behaving professionally and committing properly. We are pretty fortunate
to have guys who actually care about quality.
As far as building the "webapp", that presents no problems. But the
standalone batch process application presents many problems. Besides
the module jars and third party jars that it needs to package into the
zip file, it also needs to package in some configuration files that
will ultimately live on the server file system.
We put the config files in the jar which is enough to get them on the
classpath and we do not need to change them after they are released.
For this purpose, I have been using the assembly plugin. I have a
configuration that works, for the most part, using the
assembly:assembly goal, which is now deprecated. I have tried to
build using the recommended way (using the single goal and the
<useAllReactorProjects> tag) and I ran up against mind-boggling
difficulties which I wasn't able to resolve. (See
http://www.mail-archive.com/users@maven.apache.org/msg115460.html)
Evidently my system is enough out of the norm that this won't work for
me.
We have a very simple assembly and I do not understand why you need
anything special just to build a batch job.
So, to make a long story short, I'm looking for a better way to
organize this system that would fit more with Maven. I find it
aggravating that what would be a simple thing to lay out with make or
ant is seemingly almost impossible to achieve in Maven - especially
since I am trying to convert my organization into using Maven. I
don't know if I'm dealing with bugs, or with things that Maven was
never designed to be able to do in the first place.
Forget everything that you know about Ant. It is a great software but it
is not a good model for Maven.
Does this relate to your situation?
Ron
Example assembly for a batch job - jar-with-dependencies-assembly.xml
This project includes 3 xml configuration files and a properties file.
They are all in the project at the top level of the "src" folder(same
level as "com").
<assembly>
<id>jar-with-dependencies</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory></outputDirectory>
<outputFileNameMapping></outputFileNameMapping>
<unpack>true</unpack>
<scope>runtime</scope>
</dependencySet>
</dependencySets>
</assembly>
Here is the <build> section from the POM
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>jar-with-dependencies-assembly.xml</descriptor>
</descriptors>
<archive>
<manifest>
<mainClass>com.x.ourproject.contractrenew.main.ContractRenewBatchMain</mainClass>
<packageName>com..x.ourproject..contractrenew.main</packageName>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
