On Aug 14, 2008, at 2:51 PM, Stephen Connolly wrote:
add the child modules in profiles, that way you need only activate
the profile(s) you want to build
My ability to explain the situation seems to be less than 0. We have
a single ear to start with. We need to end up with n+1 artifacts
where there are n app clients in the ear. Processing the ear takes a
long time. We always want all the n+1 artifacts whenever we build
this project. The existing code we're calling can generate all n+ 1
artifacts just fine, at once, in the project target directory.
However there's currently no way to get them all into the local maven
repo. Right now we're generating the artifacts corresponding to the
app clients with different artifactIds than the main artifact (the one
we can get into the local maven repo, this artifact corresponds to the
server side part of the ear). We're considering using classifiers
instead although this seems to distort the purpose of classifiers
although it looks like it would work around the problem.
I guess fundamentally there's a problem in that maven is asymetrical:
its pretty easy to take a bunch of artifacts and aggregate them into a
single artifact -- such as by using the ear plugin -- but there's no
way to take a single artifact and decompose it (with processing) into
a bunch of separate artifacts, in one project. Theoretically one
could do the processing lots of times in lots of projects and only
pick what you wanted each time but if the processing is very expensive
this is unworkable.
Anyway, I can't see how profiles would fit into this in any productive
way. If you see a way please explain in more detail.
thanks
david jencks
Sent from my iPod
On 14 Aug 2008, at 22:38, David Jencks <[EMAIL PROTECTED]> wrote:
On Aug 14, 2008, at 12:52 PM, Kathryn Huxtable wrote:
Sounds like a case for a parent pom and associated child POMs. -K
I've spent a lot of time trying to figure out a plausible way to do
that with no success so far. Processing the ear in the existing
project generates n+1 artifacts when there are n app clients, and
there's no obvious way to get just one without running the entire
deployment process and throwing away everything except the one you
want. If you have an idea how to use this situation with multiple
projects I'd love to know more.
thanks
david jencks
-K
On Thu, 2008-08-14 at 12:05 -0700, David Jencks wrote:
The fundamental problem we have is that we need to output several
different artifacts from a single maven project. Processing an ear
file that contains ee app clients results in one main artifact
for the
ear file and one artifact for each app client. Classifiers seem
like
the closest way in maven to deal with this, but if you have another
suggestion we'll enthusiastically investigate it.
thanks
david jencks
On Aug 13, 2008, at 6:31 AM, Brian E. Fox wrote:
The classifier is meant for things like sources, javadocs,
assemblies etc.
What you’re doing really should have separate artifacts, however
if
classifier does what you want, go for it. Just remember you’re
slightly
outside the normal use case ;-)
On 8/12/08 10:52 PM, "Lin Sun" <[EMAIL PROTECTED]> wrote:
Hi,
Yes, I agree classifier are meant for the same project. The
daytrader app clients are part of daytrader project, but with
their
own module id. A user can choose to have a standalone app
client in
a .jar file. Or a user can choose to have an app client
artifact
bundled in a .ear file. In the later case, a user would
only need
one deployment plan to deploy the .ear file onto the server,
thus it
is naturally for the user to think one would just need to run the
car-maven-plugin once to generate all the necessary plugin
artifacts.
It seems silly for us to recommend a user to run the car-maven-
plugin
three times for such an EAR project as daytrader. This is why
we
think maybe classifier could be used here...
Thanks,
Lin
On Tue, Aug 12, 2008 at 8:57 PM, Brett Porter
<[EMAIL PROTECTED]> wrote:
Classifiers are meant for the same project, built
differently. It
doesn't sound like that's the case here - the appclients are
different
modules. Is there a reason you can't actually use 3 artifact
IDs?
Cheers,
Brett
2008/8/13 Lin Sun <[EMAIL PROTECTED]>:
Hi,
I need some advice to see if we could use classifier to
solve a
prob
we have in Apache Geronimo.
We want to deploy our J2EE sample (called daytrader) onto
geronimo as
a geronimo plugin. The daytrader application contains
multiple
modules(one web module, one ejb module, 2 app clients
module),
as most
of EAR projects do. The daytrader geronimo plugin is built
using
the car-maven-plugin that is developed at Geronimo.
Basically, what
the car-maven-plugin does is to generate the plugin metadata
file,
deploy the daytrader module using geronimo's deployers,
package
all
the files into a plugin car file and install the car file
into
the
maven repository. The plugin has one artifact id, called
daytrader.
Soon, we found out there is a prob here. If there is only
one
artifact id, how can we start the app clients of daytrader?
Each app
client needs his own artifact id. We have only one maven
project
(which is daytrader here) but we really need 3 artifact ids.
I am wondering if it is possible to use classifier here.
Instead of
producing 1 artifact here, we produce the following
artifacts,
for the
daytrader project:
daytrader-2.2.-snapshot.car
daytrader-2.2-snapshot-appclient1.car
daytrader-2.2-snapshot-appclient2.car
Thoughts?
Lin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
