I don't know what you produced before, so I don't know what you need
to be compatible with. And I don't know what compatibility constraints
you have (or think you have). I'm merely suggesting a better Maven
approach and informing you of issues you could run into.

/A

On Thu, Jun 18, 2009 at 15:46, David Weintraub<[email protected]> wrote:
> 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 <[email protected]> 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<[email protected]> 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 <[email protected]>
>> 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<[email protected]>
>> 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 <[email protected]> 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: [email protected]
>> >> >> For additional commands, e-mail: [email protected]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > David Weintraub
>> >> > [email protected]
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >>
>> >
>> >
>> > --
>> > David Weintraub
>> > [email protected]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> --
> David Weintraub
> [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to