RE: eclipse compiler
Rolf, In looking through the M2 CompilerMojo, I found that it just wraps Jason van Zyl's Plexus Compiler package. (http://plexus.codehaus.org) That appears to support 'eclipse' as a compiler variation, so I'm thinking you can just set the compilerId parameter to 'eclipse' instead of the default 'javac' instead of using the 'executable' parameter I suggested before. I'm cc-ing the mailing list on this, to see if we can get verification from the plugin authors. Jay _ From: Rolf Strijdhorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 11:17 PM To: Jay H. Hartley Subject: Re: eclipse compiler Thanx Jay By the way I am using M2 But does this mean I can just insert: org.eclipse.jdt.core.JDT CompilerAdapter or do I need to include the complete path to the compiler or ( a lot of ors) is it enough to include the jar that contains the compiler in the classpath? Rolf On 2/8/06, Jay H. Hartley [EMAIL PROTECTED] wrote: Rolf, If you are using Maven 2, set the executable parameter for the compile:compile goal: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html For a description of how to set compiler parameters, see http://maven.apache.org/plugins/maven-compiler-plugin/howto.html For Maven 1, set the maven.compile.executable property in one of the various properties files: http://maven.apache.org/maven-1.x/reference/plugins/java/properties.html http://maven.apache.org/maven-1.x/reference/plugins/java/properties.html Hope this helps, Jay -Original Message- From: Rolf Strijdhorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 11:25 AM To: Maven Users List Subject: eclipse compiler hi I am wondering is het possible to assign a different compiler. I want to use the eclipse compiler for my builds. thanx Rolf
RE: eclipse compiler
Rolf, If you are using Maven 2, set the executable parameter for the compile:compile goal: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html For a description of how to set compiler parameters, see http://maven.apache.org/plugins/maven-compiler-plugin/howto.html For Maven 1, set the maven.compile.executable property in one of the various properties files: http://maven.apache.org/maven-1.x/reference/plugins/java/properties.html Hope this helps, Jay -Original Message- From: Rolf Strijdhorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 11:25 AM To: Maven Users List Subject: eclipse compiler hi I am wondering is het possible to assign a different compiler. I want to use the eclipse compiler for my builds. thanx Rolf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compiling Multiple Source Trees
Alternatively, if the mock objects are intended for use in multiple
projects, define them in their own project. They can then be deployed like
any other project artifact and can be used in test cases for multiple other
projects. When deploying the final application, exclude this jar in the same
way you would exclude junit.jar.
This was the route I took rather than hassle with maven.xml scripting or
plug-in writing. Stick with the one-artifact-one-project model as much as
possible.
Jay
-Original Message-
From: Arik Kfir [mailto:[EMAIL PROTECTED]
Sent: Monday, October 10, 2005 3:35 PM
To: Maven Users List
Subject: Re: Compiling Multiple Source Trees
Are these classes used in your test cases? If so, I think the simplest
solution would be to put them in src/test/java.
Test classes are not put in your final distribution/jars.
On 10/11/05, Allison, Bob [EMAIL PROTECTED] wrote:
I would like to set things up in a project to compile a set of mock
objects stored in src/mock/java into target/mock-classes. These
classes should NOT be included into target/classes, since these
classes are not part of the distribution artifact. They need to be
assembled into a jar with a classifier of -mock for use in other
project's unit tests.
I am looking at two possible ways of doing this:
1) Write a plugin which extends AbstractCompilerMojo. If I do this, I
guess I need to add the compiler plugin as a dependency. I also need
to figure out how to populate the List and Set parameter objects
(source roots, classpath, includes, excludes) in the plugin
configuration element.
2) Add some information to the compiler plugin configuration to add a
second execution. To do this, I need to figure out how to specify new
values for the expressions such as ${project.compileSourceRoots}
since the actual plugin parameters are read only.
Does anybody have any suggestions on how to do either of these options
or perhaps another option to consider?
-
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]
RE: [m1 or 2] Odd project structure... how much pain will this be?
It sounds to me like two types of documentation are needed. One is the/an
ideal Maven Way of setting up a consultant's multi-client project,
assuming you are starting fresh and know you will be using Maven. I
personally think that Maven is ideal for exactly that kind of environment,
but then I'm already among the converted. :-)
The second task is providing migration examples, such as those sought in the
original query on this thread. This is substantially harder, because the
starting points can vary rather dramatically. The question comes up often on
this list, so perhaps the best thing to do is provide a centralized FAQ-type
page in the documentation with examples and solutions drawn directly from
the list.
The simplest first approach might be just a list of links to the appropriate
threads in the list archives. Add it to the Migrating from Ant section of
the existing documentation, perhaps. Fleshing those out and cleaning them up
would of course be great, but people are busy. Adding a link in the
documentation each time a new variant of the migration question comes up
would be relatively quick and might be sufficient.
I notice Strategy for migrating from Ant builds is one of the items listed
as needed documentation for M2. I did a quick search on migrate ant in the
archives and turned up a reasonable starting set, most of which are for M1.
I haven't moved to M2 yet myself, but if there are no strong objections,
I'll take a shot at assembling and organizing the links for the gurus to
look over and decide whether they are helpful as-is or in need of cleaning.
The best thing would be for the people who asked for the help originally to
write up and submit what it was they finally did that worked for them...
assuming they did go with Maven in the end. This is probably too much to
expect, but if we had a centralized set of links for the migration problem
it would make it easier to send follow-up emails to the originator later and
perhaps find out what happened. Exit interviews are quite useful when trying
to improve marketing.
Jay
-Original Message-
From: Andy Glick [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 25, 2005 4:16 PM
To: users@maven.apache.org
Subject: Re: [m1 or 2] Odd project structure... how much pain will this be?
Brett Porter wrote:
Is it worthwhile publishing a few documents that show how various
project types would be set up for m2, like this?
- Brett
On 9/24/05, Kenney Westerhof [EMAIL PROTECTED] wrote:
On Fri, 23 Sep 2005, Eric Biesterfeld wrote:
You're pretty much set up for maven use, except for the 'overlay' system.
I'll demonstrate using maven2.
I see:
/base/pom.xml - base project
/base/client/pom.xml - grouping project for all clients, has parent
../pom.xml /base/client/X/pom.xml - project for client X, has parent
../pom.xml
As you compile the client/a/java/* to the base/target/ I expect those
classes don't 'overlay' existing ones, because your build will break -
the base classes are always newer than the client/a sourcefiles.
So now you get 1 + count(clients) jars. For each client, that's 2
jars. If you can live with that, then so far it's easy. If not, you
can add an 'assembly' goal to each client/a/pom.xml (ofcourse
configuration specified in client/pom.xml) to merge the two jars.
Btw, each client/a/pom.xml has a dependency on base/pom.xml.
For the property/html overlay: the property part (which is probably
going to end up in a jar /META-INF/ somewhere?) the assembly plugin
and/or the resources plugin could take care of that.
You need to use the unpack goal to unpack the base dependency into
client/a/target/classes/ (${project.build.outputDirectory} (or another
location if they shouldn't end up in the jar).
This goal is bound to the 'generate-resources' lifecycle phase.
Then maven2 will copy your client a's resources to the same location,
overwriting the other ones.
Or you could just specify a resources section in the client a pom
that has '../../html' in it. Be sure to specify that section before
the resources section that defines the client a resources.
That order will have the effect of client a's resources overwriting
the existing ones.
But it would ofcourse be best to have disjunct sets of resources for
base and the client projects, so that the client projects just 'add'
to the base project, not change it's behavior.
Maybe you can factor out the common features in the client projects,
and make projects for each of those features.
Then each client project just depends on the features that are
appropriate for that client. But it's probable that this won't work in
your particular case.
So, here are some ideas. Hope it helps!
I've worked at a number of shops that followed development practices similar
to these, where they had base project contents and by customer
customizations.
So, yes, I think that publishing documents, or even full or partial project
mockups that demonstrated various strategies for the
RE: Working with Branches
In Maven 1 properties: maven.scm.tag=BRANCH_TAG_NAME See: http://maven.apache.org/reference/plugins/scm/properties.html In Maven 2 POM: scm ... tagBRANCH_TAG_NAME/tag ... /scm See: http://maven.apache.org/maven2/maven-model/maven.html#class_Scm I haven't used Maven 2 myself yet, but that's what the docs say. Jay -Original Message- From: Jon Strayer [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 20, 2005 2:32 PM To: Maven Users List Subject: Working with Branches Today, for the first time ever, I needed to branch a project in CVS. How do I access that branch with Maven? - 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: Multiproject site navigation question
Our approach is to have a dedicated documentation sub-project, with just xdocs. The multiproject parent project has little if anything in it, so the default navigation is fine. One of the links then leads to Documentation. That project then has a customized navigation.xml linking together all the root-level documentation for the multiproject. You mention that you need to have the documentation as part of the root web site. Would having it one link down but clearly labeled at the top of the sub-project list satisfy the need? Jay -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 8:54 PM To: Maven Users List Subject: Re: Multiproject site navigation question Wendy Smoak wrote: From: dan tran [EMAIL PROTECTED] Wendy, from maven-site-plugin doco, you dont create nagivation.xml at the root. Let the multiproejct:site generate it for you. I have a bunch of user-supplied documentation that I need to link in, and I need it to be part of the root website. AFAICT, to do that I need to make a navigation.xml file. True? Thanks, FWIW, I struggled with this on a couple of projects and ended up finding it easier and more flexible to just maintain navigation.xml at each level. One thing that can make it slightly easier to manage the common elements (assuming you have these) is to use XML entities. Have a look at the commons-build project http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/ that defines a setup shared by Jakarta Commons components. The navigation.xml file there and in all of the commons subprojects refer to an external dtd that defines xml entities corresponding to the shared menu items. This is a little convoluted - maybe not maven best practice - but works and is not that hard to maintain once you have it set up. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem targeting two platform builds with Maven 2.0
I'm a bit confused by the initial problem posed in this thread. This may
expose a fundamental misunderstanding of Java on my part, but if so I'd like
it cleared up by this fine group sooner rather than later.
I routinely build a project for a CDC target using a Sun J2SE 1.3 boot class
path, and run the same class files on Sun J2SE VMs (1.3, 1.4 and 1.5) and
IBM's J9 CDC VM (1.3). Using the CDC classpath would probably be better
since that's the more restrictive environment, but the point is that Java
class files are portable. As long as you build to byte code compatible with
the oldest VM and comply with the API of the most restrictive environment,
the class files should run on any VM regardless of what your classpath looks
like when you compile, right? This has always been my understanding, and has
also been my experience. Optimizing doesn't appear to affect this, either.
So, if the source code is truly unchanged, why not always compile with the
oldest and/or most restrictive JDK libraries, and run it wherever you want?
Have the optimizing compilers gotten so much better that it's worth the
extra hassle of maintaining two sets of distribution jars? Do newer VMs run
notably slower with older byte code, again enough to be worth the
maintenance hassle?
Are you using an ahead-of-time compiler to go all the way to executables?
Even then, I'd think the build solution would be to javac to a jar you could
use anywhere then AOT the jar to your embedded target. Is there JNI, in
which case you have all the usual non-Java problems with target platform
portability?
What am I missing?
Jay
Yes, this is supported through profiles in alpha-3. You can try it from SVN
today, or wait for the release next week. Some of the repository support may
still need some work, so we'd be interested to hear your experiences.
Cheers,
Brett
On 6/17/05, Shane Isbell [EMAIL PROTECTED] wrote:
By separate executions, I mean separate executions of xml.pom[myproject].
On 6/16/05, Shane Isbell [EMAIL PROTECTED] wrote:
Say the project structure is something like
myproject
---pom.xml
+--subproject 1
---pom.xml
+--subproject 2
---pom.xml
In this case, the pom.xml[myproject] is the parent project. What I
am trying to find out is if there is way to type
m2 {target -CDC} install
and have this target request proprogated to pom.xml[subproject 1]
and pom.xml[subproject 2]. Separate executions of m2 {target -CDC}
install and m2 {target -J2SE} install are ok as long as the
repository handles separate versions of the JAR.
Can this be done through the profile?
Thanks,
Shane
On 6/16/05, Brett Porter [EMAIL PROTECTED] wrote:
This sounds more like a profile solution, where the developer
picks which one they want to use.
m2 --profile=CDC package
m2 --profile=j2se package
You said earlier you wanted to have a parent project that would
build both, though. Can you elaborate on that? This is the part
that is not currently supported, the profile executions must be
separate.
Thanks,
Brett
On 6/17/05, Shane Isbell [EMAIL PROTECTED] wrote:
Hi Brett,
The use case is as follows: Each sub project has a single set of
source files. The developer sets a target flag to CDC or J2SE.
Depending on the flag, the build tool compiles the Java source
files under either CDC or J2SE. In the case of CDC, the build
tool uses a different bootclasspath during compilation. Next.
the build tool packages the classes within a jar file, appending
myfile-platform.jar, where platform is either CDC or J2SE,
depending on the target. End.
The reason that I do not want to split these into separate
projects is that the source files are the same. If a developer
modifies, say the CDC source, it is not reflected in the J2SE
source, which leads to versioning problems. Given that I am
compiling with different bootclasspaths, I do not believe that
the solution that you outlined below would work. I will however,
look into it.
Regards,
Shane
On 6/16/05, Brett Porter [EMAIL PROTECTED] wrote:
In Maven, a POM is a unit of work, so a project must have just
one.
Usually, targetting multiple platforms involves setting up
multiple projects.
pom.xml - parent that has modules/ for the following:
+- foo-common/pom.xml - shared information
+- foo-j2se/pom.xml - j2se specific build, depends on
+foo-common
+- foo-cdc/pom.xml - CDC specific build, depends on foo-common
Does this suit your situation? What are the actual differences
between the two platforms?
We currently have a new solution for environmental specifics
in
alpha-3 (profiles), however these are not intended to be used
to build multiple
