If I was doing this, I would have either a single JAR that contains all the
customer's classes (After all, the classes are packaged as
com.solbright.adinventory.etlf.customer, so they won't interfere with each
other), or simply create separate packages for the core jar, and for each
customer, and have each customer as a separate project that depends upon the
core.jar.
But, that's not how this project is structured, and I have to make it
compatible with what we produced from before. Maybe we should start this
project from scratch structured the correct way. Maybe this shouldn't be a
Maven project, but we were told that Maven is superior to Ant, so someone
decided that all of our projects must now be Maven builds no matter how
difficult or problematic that becomes.
The problem with many projects is that they start out with a poorly thought
out architecture and then quickly evolve into a mess as people quickly
attach kludges to keep the project working. Maven gives a certain discipline
to the project structure:
"We need to do be able to do this by tomorrow!"
"Sorry, we can't. Maven can't build the project if you do that."
"Well, let's give ourselves a bit more time and design what we need to
do properly."
Small projects can quickly grow up into big messes because someone didn't
think things through before making changes.
On Thu, Jun 18, 2009 at 12:47 AM, Anders Hammar <and...@hammar.net> wrote:
> It's your call. Just please understand that even if it's possible
> doesn't make it the right way of doing things.
>
> I tried to think of issues with this approach (other than the
> versioning thing I already mentioned) and the only thing I can think
> of is if you have different dependencies for your customers' jar
> files. That's not possible as you only have one pom for all jars.
>
> /A
>
> On Wed, Jun 17, 2009 at 22:03, David Weintraub<qazw...@gmail.com> wrote:
> > Yes, this is an Ant project going over to Maven by order of High Lord of
> All
> > Matters Important. One of the things I have to do is keep the final
> output
> > as close to the Ant build's output as possible. Since I am the "Maven
> > maven", I am the one stuck with this task and not the developer.
> >
> > There are separate jarfiles for each client, and a "core" jarfile that
> > contains only the common jars. I was originally thinking of creating
> > directories for each client and treating them as modules, but the
> developers
> > vetoed the idea of moving the java files into each client. They want the
> > Java files all together.
> >
> > Treating each client's jar as an assembly made things a bit simpler since
> I
> > can build each Jar with the required classfiles in separate execution
> > sections. Otherwise, I would have to define separate directories for each
> > client, and then try to define a pom.xml which would build the jarfile
> for
> > that client from the compiled code that is in the main project's
> directory.
> >
> > I finally created an assembly file that defined the zipfile into a
> similar
> > format the original Ant build produced.
> >
> > On Wed, Jun 17, 2009 at 2:42 PM, Anders Hammar <and...@hammar.net>
> wrote:
> >
> >> Only so that you don't forget, the general Maven rule is "one project,
> >> one artifact". You could use classifiers to create more than one
> >> artifact for a project, but I don't really see the benefit. Have
> >> several projects is not bad (I think), it makes your code base
> >> structured. Changes to one customer's code will then only affect that
> >> customer's project and making it possible to make a new release for
> >> just that customer. If you mix all customers' code in one project you
> >> will get a new version for all customers (while only one of them has
> >> really changed). Not very clean I think.
> >> The assemblies goes in separate projects.
> >>
> >> Just my two cents,
> >> /Anders
> >>
> >> On Wed, Jun 17, 2009 at 19:41, David Weintraub<qazw...@gmail.com>
> wrote:
> >> > Thanks. It took me a while to figure this out. At first, I tried to
> >> create a
> >> > separate <plugin> for each client. However, only the first one
> executed.
> >> > Then, I tried to add a new <execution> definition to the
> maven-jar-plugin
> >> > artifact, but kept getting errors. I finally realized that each
> >> <execution>
> >> > needed its own "id".
> >> >
> >> > This created the separate jars that were needed. Now, I have to create
> an
> >> > assembly for each of these clients.
> >> >
> >> > On Wed, Jun 17, 2009 at 5:45 AM, losa <mgl...@hotmail.com> wrote:
> >> >
> >> >>
> >> >> You can use the maven-jar-plugin for generating more than one jar
> file
> >> >> filtering the classes you want to include.
> >> >>
> >> >> Example:
> >> >> <plugin>
> >> >> <groupId>org.apache.maven.plugins</groupId>
> >> >> <artifactId>maven-jar-plugin</artifactId>
> >> >> <executions>
> >> >> <execution>
> >> >> <phase>package</phase>
> >> >> <goals>
> >> >> <goal>jar</goal>
> >> >> </goals>
> >> >> <configuration>
> >> >> <classifier>my-client</classifier>
> >> >> <includes>
> >> >>
> >> >> <include>**/pkg1/MyClass.class</include>
> >> >> </includes>
> >> >> <excludes>
> >> >>
> >> >> <exclude>**/pkg2/MyClass.class</exclude>
> >> >> </excludes>
> >> >> </configuration>
> >> >> </execution>
> >> >> </executions>
> >> >> </plugin>
> >> >>
> >> >> The generated jar will be copied o your repository. Then, when you
> need
> >> to
> >> >> use the jar from another project, you can include the dependency like
> >> this
> >> >>
> >> >> <dependency>
> >> >> <groupId>${project.groupId}</groupId>
> >> >> <artifactId>theJarName</artifactId>
> >> >> <version>theJarVersion</version>
> >> >> <classifier>my-client</classifier>
> >> >> </dependency>
> >> >>
> >> >>
> >> >> More information at:
> >> >> http://maven.apache.org/plugins/maven-jar-plugin/index.html
> >> >> http://maven.apache.org/plugins/maven-jar-plugin/index.html
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/How-to-create-many-jars-in-package-phase--tp23646150p24070227.html
> >> >> Sent from the Maven - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > David Weintraub
> >> > qazw...@gmail.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > David Weintraub
> > qazw...@gmail.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
David Weintraub
qazw...@gmail.com
