Re: [m1] Conditional dependencies
From: Brett Porter [EMAIL PROTECTED] This is a bit dangerous. Agreed. :) But it works. 1) a project will have a different model depending on that property. It will ripple into needing to change other things like the final name of the built artifact to ensure you don't end up with one thing sometimes being something different Actually... that's the intent. We build a .war file, and it contains whichever JSF implementation you choose-- different .jar files in WEB-INF/lib, web.xml filtered one way or another, but the name of the .war file remains the same. (Remember that this is an existing Ant build...) This is a little bit of an unusual use case. It's understandable that you often depend on a spec dependency (for which we don't yet have great support) and an impl goes into the final bundle and the impl might change. Changing the API too is what is unusual. I agree... but that's the requirement. Anyway, in m1 the general approach to this is to have two projects that do the different bundling and build whichever you want, sharing the common code. I'm not sure if that's easily done when the api is changed though. I've just been introduced to the leave the project structure alone and put all the build files in a completely separate directory structure concept. Most of my problems (like building three artifacts out of a single source tree) might just go away. Reorganizing the project itself to suit Maven is definitely not something I want to have to push for. I replied in this fashion in another thread. I should also mention again that environmental changes to project builds are supported in Maven 2. (I missed your earlier responses, thanks for pointing them out.) Okay, okay... I'll look at m2 again. :) Last time it seemed like not enough of the plugins I needed were ready yet. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m1] Conditional dependencies
Wendy,
Jay, this turned out to work *perfectly*!
Glad to hear it, though I agree with Brett that it doesn't necessarily fall
in the category of Best Practice. I'm glad to hear Maven 2 will do a
better job of dealing with this kind of issue.
One concern was having duplicate artifacts with the same name but different
contents. If you haven't already, you might consider using the same property
in the artifact ID:
artfactIdmyproject-${maven.shale.jsf.impl}/artifactId.
You could also manipulate maven.final.name, I guess, but I think SNAPSHOT
builds already do this, so you could end up with conflicts if you did it in
the wrong place.
Similarly, you could sprinkle that property around in other places to cause,
for example, the site to deploy to a different location with a different
title and slightly different description.
Effectively you end up with two different object models that just happen to
share the same codebase.
Good luck,
Jay
-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 01, 2005 10:40 AM
To: Maven Users List
Subject: Re: [m1] Conditional dependencies
From: Jay H. Hartley [EMAIL PROTECTED]
2) Create two different parent project files, and have the extends
parameter depend on a property:
project
extends${jsf.project.file}/extends
Jay, this turned out to work *perfectly*!
project.properties:
maven.shale.jsf.impl.default=myfaces
-project.xml
extend${maven.shale.jsf.impl.default}-project.xml/extend
project.xml:
extend${maven.shale.jsf.impl}-project.xml/extend
And jsfri-project.xml or myfaces-project.xml declares dependencies on one
JSF implementation or the other.
So you can either set
maven.shale.jsf.impl = [myfaces | jsfri ] or leave it out and let it
default.
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m1] Conditional dependencies
Wendy,
I can't say I've had this exact problem, but I can think of two approaches
I'd consider:
1) Create a separate project, let's call it jsf. Have all the RI/MyFaces
jars listed in its dependency list. No code is involved, but the build
produces two artifacts, both uberjars (not that you'd use the deprecated
plug-in) that incorporate all the classes needed for each option. Then your
existing approach with single-jar substitution based on a property will
continue to work.
2) Create two different parent project files, and have the extends
parameter depend on a property:
project
extends${jsf.project.file}/extends
...
/project
Those base project files list the dependencies for the appropriate option.
You can use the same property to determine how to filter the web.xml file. I
did a quick test of this, and both ${pom.extends} and ${pom.dependencies}
appear to have gotten modified as I expected. I haven't verified that code
compilation, war bundling, etc. work, but since the object model appears
correct I would expect everything else to work.
I'm sure you could also script up a plug-in, but these two approaches seem
relatively simple to me with minimal modifications to your existing scripts.
Hope this helps,
Jay
-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent: Monday, August 29, 2005 9:15 PM
To: Maven Users List
Subject: [m1] Conditional dependencies
I'm working on a project that needs to compile and build with *either* the
JSF Reference Implementation *or* Apache MyFaces. This has to be
user-specified, at build time. In addition to compilation and including the
correct .jar files in a webapp, there's also a modification that must be
done to web.xml, commenting out a section if we're using the RI, leaving it
in place for MyFaces.
And I had it working by having the user specify which JSF api and
implementation .jar files to use, as properties:
maven.shale.jsf.api.jar=${maven.repo.local}/myfaces/jars/myfaces-jsf-api-1.0
.9.jar
maven.shale.jsf.impl.jar=${maven.repo.local}/myfaces/jars/myfaces-impl-1.0.9
.jar
or
maven.shale.jsf.api.jar=${maven.repo.local}/javax.faces/jars/jsf-api-1.1.jar
maven.shale.jsf.impl.jar=${maven.repo.local}/javax.faces/jars/jsf-impl-1.1.j
ar
But then I found out that for MyFaces, there is a *third* .jar file that
must be included in the .war file. So now (realizing that there's probably
no way I can avoid a bunch of scripting) I'm thinking of having the user
specify either:
maven.shale.jsf = [myfaces|jsfri]
or
maven.shale.jsf.ri = [true|false]
maven.shale.jsf.myfaces = [true|false]
Before I go any further with that, is there a precedent I should follow?
Alternately, because I can't specify a dependency in the project.xml file,
I already wrote 'myfaces-project.xml' which does nothing but declare the
dependencies so Maven will download them. Is it possible that the right
answer is to have a 'myfaces-project.xml' file in each directory and do
either
$ maven build-all
or
$ maven -p myfaces-project.xml build-all
depending on which JSF implementation you want to use? I'm not sure I want
to start down that path, given that there may eventually be multiple JSF
implementations from which to choose.
What would you do in this situation?
If you want to take a look at the files:
http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/
or
$ svn co http://svn.apache.org/repos/asf/struts/shale/trunk/ shale
(If you want to try to build it, read this first:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMavenBuild )
Thanks for any advice! I note that there is only one thread on this topic
in the archives... one post, with no replies.
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] Conditional dependencies
From: Jay H. Hartley [EMAIL PROTECTED]
2) Create two different parent project files, and have the extends
parameter depend on a property:
project
extends${jsf.project.file}/extends
That has promise! Thanks, I didn't know you could do that. :)
If it's not painfully obvious by this point, this is an existing Ant build
that I'm trying to reproduce with Maven.
After several days of fighting with it, I'm going to retreat to the position
of making the Maven build do something reasonably useful, and propose a
reorganization to get the project into a format that Maven is happier to
deal with.
Thanks for putting up with all the questions. :)
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] Conditional dependencies
This is a bit dangerous.
1) a project will have a different model depending on that property. It will
ripple into needing to change other things like the final name of the built
artifact to ensure you don't end up with one thing sometimes being something
different
2) you can only do this trick once. There is no multiple inheritence.
This is a little bit of an unusual use case. It's understandable that you
often depend on a spec dependency (for which we don't yet have great
support) and an impl goes into the final bundle and the impl might change.
Changing the API too is what is unusual.
Anyway, in m1 the general approach to this is to have two projects that do
the different bundling and build whichever you want, sharing the common
code. I'm not sure if that's easily done when the api is changed though.
I replied in this fashion in another thread. I should also mention again
that environmental changes to project builds are supported in Maven 2.
- Brett
On 8/31/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Jay H. Hartley [EMAIL PROTECTED]
2) Create two different parent project files, and have the extends
parameter depend on a property:
project
extends${jsf.project.file}/extends
That has promise! Thanks, I didn't know you could do that. :)
If it's not painfully obvious by this point, this is an existing Ant build
that I'm trying to reproduce with Maven.
After several days of fighting with it, I'm going to retreat to the
position
of making the Maven build do something reasonably useful, and propose a
reorganization to get the project into a format that Maven is happier to
deal with.
Thanks for putting up with all the questions. :)
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m1] Conditional dependencies
I'm working on a project that needs to compile and build with *either* the
JSF Reference Implementation *or* Apache MyFaces. This has to be
user-specified, at build time. In addition to compilation and including the
correct .jar files in a webapp, there's also a modification that must be
done to web.xml, commenting out a section if we're using the RI, leaving it
in place for MyFaces.
And I had it working by having the user specify which JSF api and
implementation .jar files to use, as properties:
maven.shale.jsf.api.jar=${maven.repo.local}/myfaces/jars/myfaces-jsf-api-1.0.9.jar
maven.shale.jsf.impl.jar=${maven.repo.local}/myfaces/jars/myfaces-impl-1.0.9.jar
or
maven.shale.jsf.api.jar=${maven.repo.local}/javax.faces/jars/jsf-api-1.1.jar
maven.shale.jsf.impl.jar=${maven.repo.local}/javax.faces/jars/jsf-impl-1.1.jar
But then I found out that for MyFaces, there is a *third* .jar file that
must be included in the .war file. So now (realizing that there's probably
no way I can avoid a bunch of scripting) I'm thinking of having the user
specify either:
maven.shale.jsf = [myfaces|jsfri]
or
maven.shale.jsf.ri = [true|false]
maven.shale.jsf.myfaces = [true|false]
Before I go any further with that, is there a precedent I should follow?
Alternately, because I can't specify a dependency in the project.xml file,
I already wrote 'myfaces-project.xml' which does nothing but declare the
dependencies so Maven will download them. Is it possible that the right
answer is to have a 'myfaces-project.xml' file in each directory and do
either
$ maven build-all
or
$ maven -p myfaces-project.xml build-all
depending on which JSF implementation you want to use? I'm not sure I want
to start down that path, given that there may eventually be multiple JSF
implementations from which to choose.
What would you do in this situation?
If you want to take a look at the files:
http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/
or
$ svn co http://svn.apache.org/repos/asf/struts/shale/trunk/ shale
(If you want to try to build it, read this first:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMavenBuild )
Thanks for any advice! I note that there is only one thread on this topic
in the archives... one post, with no replies.
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
