[m2] artifactId macro in parent pom substitutes twice in child's generated site?
Hi,
First, congratulations to the m2 developers for a great release. I've been a
maven user since 1.0-beta-4 with embedded ant scripts, through beta-10, 1.0and
1.1, and am truly impressed with the leap forward that m2 provides.
I'm trying to migrate to m2 and have encountered an apparent glitch. In my
parent pom I have defined the scm entry as:
scm
connectionscm:cvs:pserver:[EMAIL PROTECTED]:/bar:${artifactId}/connection
urlhttp://foo/viewcvs/viewcvs.asp/bar/${artifactId}/url
/scm
Child poms do not contain a scm entry.
Assume the first child project's artifactId is child1. I expect the CVS
information to be displayed as:
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/bar co child1
Instead I get:
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/bar co child1/child1
It seems that the ${artifactId} is being substituted too many times. Is this
a bug, or am I attempting something that M2 is not designed to support?
Thanks for any insight,
Mark
Re: [m2] artifactId macro in parent pom substitutes twice in child's generated site?
Ok, that makes sense. Thanks for the quick answer!
On 11/3/05, Brett Porter [EMAIL PROTECTED] wrote:
When the SCM URL is inherited, it automatically appends the artifact
ID by default.
- Brett
On 11/4/05, Mark Langley [EMAIL PROTECTED] wrote:
Hi,
First, congratulations to the m2 developers for a great release. I've
been a
maven user since 1.0-beta-4 with embedded ant scripts, through beta-10,
1.0and
1.1, and am truly impressed with the leap forward that m2 provides.
I'm trying to migrate to m2 and have encountered an apparent glitch. In
my
parent pom I have defined the scm entry as:
scm
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/bar:${artifactId}/connection
urlhttp://foo/viewcvs/viewcvs.asp/bar/${artifactId}/url
/scm
Child poms do not contain a scm entry.
Assume the first child project's artifactId is child1. I expect the
CVS
information to be displayed as:
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/bar co child1
Instead I get:
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/bar co child1/child1
It seems that the ${artifactId} is being substituted too many times. Is
this
a bug, or am I attempting something that M2 is not designed to support?
Thanks for any insight,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class Cast exception trying to use org.apache.jasper.JspC
We had the same problem two weeks ago. Upgrading Tomcat to 5.0.28 made it go
away.
Mark Langley
CaseBank Technologies Inc.
http://www.casebank.com
-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: November 8, 2004 10:54 AM
To: Maven Users List
Subject: Class Cast exception trying to use org.apache.jasper.JspC
Hey all,
Having an issue trying to pre-compile JSP's for Tomcat5.
Rather than repeating, below is a post back in March with the same problem.
I may just be having a difficult time going through the mailing list and
using google - I just can not find a solution. Any help would be greatly
appreciated! (note: my maven.xml is slightly different, but same problem).
-D
===
Todays task: pre-compiling JSPs...
I have the following in my maven.xml:
goal name=compile-jsp
ant:path id=jspc.classpath
ant:path refid=maven.dependency.classpath/
ant:pathelement path=${maven.build.dest}/
/ant:path
ant:taskdef name=jasper2 classname=org.apache.jasper.JspC
classpathref=jspc.classpath/
ant:jasper2
package=${pom.package}.jsp
destDir=${maven.war.src}
uriroot=${maven.war.src}
srcdir=${maven.war.src}
classpathref=jspc.classpath
ant:include name=**/*.jsp/
ant:exclude name=**/includes/**/*.jsp/
/ant:jasper2
/goal
I have as dependencies:
servlet-api,jasper-compiler,jasper-runtime,jsp-api,catalina-ant,catalina
-deployer
Running this same ant script using just ant, everything works great
(using the Tomcat 5 deployer distribution). Under Maven however, i get a
ClassCast Exception. My guesses here is that the version of Ant packaged
with Maven (im using RC1) and the org.apache.jasper.JspC are not
compatible.
So is there another way to run this from maven? For example can I
replace the Ant jars in $MAVEN_HOME$/lib ? Can I create a build.xml file
that is called from Maven in a separate JVM to accomplish this?
I've tried using the ant:jspc task inside maven.xml, but that is causing
errors as well, and i'm not interested in compiling pages for tomcat 4.
Any suggestions would be greatly appriciated.
jc
==
-
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: Class Cast exception trying to use org.apache.jasper.JspC
Here's the maven.xml fragment that we use. I'm afraid I can't help any
further if this doesn't work - after several failed attempts this is the
approach that finally worked for us with Tomcat 5.0.28.
Mark Langley
CaseBank Technologies Inc.
http://www.casebank.com
project
default=build-all
xmlns:maven=jelly:maven
xmlns:j=jelly:core
xmlns:u=jelly:util
xmlns:ant=jelly:ant
xmlns:velocity=jelly:org.apache.commons.jelly.tags.velocity.VelocityTagLibr
ary
xmlns:deploy=deploy
...
!--
- The next three goals are used to pre-compile jsp pages into servlets.
- This code is lifted from
- http://wiki.codehaus.org/maven/CreatingWebApplications
--
preGoal name=war:webapp
j:set var=precompileJsp value=${precompile.jsp}/
j:if test=${precompileJsp == 'true'}
echo message=Precompiling JSPs. Set precompile.jsp=false in
build.properties if you're impatient!/
attainGoal name=precompile-jsp/
/j:if
j:if test=${precompileJsp == 'false'}
echo message=JSPs are NOT being precompiled! Is this a production
build???/
/j:if
/preGoal
postGoal name=war:webapp
j:set var=precompileJsp value=${precompile.jsp}/
j:if test=${precompileJsp == 'true'}
j:set var=target
value=${pom.getPluginContext('maven-war-plugin').getVariable('maven.war.web
app.dir')}/
u:available file=${maven.build.dir}/web-fragment.xml
u:loadText var=fragment
file=${maven.build.dir}/web-fragment.xml/
ant:replace file=${target}/WEB-INF/web.xml token=lt;!-- [INSERT
FRAGMENT HERE] --gt; value=${fragment}/
/u:available
/j:if
/postGoal
goal name=precompile-jsp description=Precompile all JSPs into java
classes, and then into classes prereqs=war:load,java:compile
j:set var=warSource
value=${pom.getPluginContext('maven-war-plugin').getVariable('maven.war.src
')}/
ant:mkdir dir=${maven.build.dir}/jspc/
ant:mkdir dir=${maven.build.dir}/jspc-processed/
ant:mkdir dir=${maven.build.dir}/jspc-classes/
j:set var=jspOutDir value=${maven.build.dir}/jspc/
j:set var=jspClassesOutDir value=${maven.build.dest}/
ant:path id=jspc.classpath
ant:fileset dir=${java.home}/../lib
include name=tools.jar/
/ant:fileset
ant:fileset dir=${tomcat.home}/bin/
include name=*.jar/
/ant:fileset
ant:fileset dir=${tomcat.home}/server/lib
include name=*.jar/
/ant:fileset
ant:fileset dir=${tomcat.home}/common/lib
include name=*.jar/
/ant:fileset
ant:path refid=maven.dependency.classpath/
ant:pathelement path=${maven.build.dest}/
/ant:path
ant:taskdef name=jasper2 classname=org.apache.jasper.JspC
classpathref=jspc.classpath/
ant:java
taskname=jspc
className=org.apache.jasper.JspC
failonerror=true
fork=yes
ant:classpath refid=jspc.classpath/
!-- ant:arg value=-help/ --
ant:arg value=-webapp/ant:arg value=${warSource}/
ant:arg value=-d/ ant:arg value=${jspOutDir}/
ant:arg value=-l/
ant:arg value=-p/ ant:arg
value=your.package.path.here/
ant:arg value=-die/
ant:arg value=-uribase/ ant:arg value=${warSource}/
ant:arg value=-uriroot/ ant:arg value=${warSource}/
ant:arg value=-webinc/ant:arg
value=${maven.build.dir}/web-fragment.xml/
ant:arg value=-trimSpaces/
/ant:java
ant:javac
srcdir=${jspOutDir}
destdir=${jspClassesOutDir}
debug=${maven.compile.debug}
deprecation=${maven.compile.deprecation}
optimize=${maven.compile.optimize}
classpathref=jspc.classpath/
/goal
-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: November 9, 2004 1:38 PM
To: Maven Users List
Subject: RE: Class Cast exception trying to use org.apache.jasper.JspC
Tried Tomcat 5.0.28, same problem.
Using Maven 1.0 final and related plugins, tried Tomcat 5.0.27 libs, 5.0.28
libs, 5.0.29-beta libs, all the same problem.
Using commons-el, jasper-runtime, jasper-compile, jsp-api, servlet-api libs
from the tomcat distributions.
Struts 1.1 libs.
commons-lang 2.0, commons-digetser 1.5, commons-validator 1.0.1,
commons-beanutils 1.6.1, commons-logging 1.1-dev.
Please Help! Confused why having a problem with this, tomcat4.1 works fine.
-D
-Original Message-
From: Mark Langley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 09, 2004 9:27 AM
To: 'Maven Users List'
Subject: RE: Class Cast exception trying to use org.apache.jasper.JspC
We had the same problem two weeks ago. Upgrading Tomcat to
5.0.28 made it go
away.
Mark Langley
CaseBank Technologies Inc.
http://www.casebank.com
-Original Message-
From: Darren Hartford [mailto:[EMAIL PROTECTED]
Sent: November 8, 2004 10:54 AM
To: Maven Users List
Subject: Class Cast exception trying to use org.apache.jasper.JspC
Hey all,
Having an issue trying to pre-compile JSP's for Tomcat5.
Rather than repeating, below
RE: Maven and Development Process
If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - 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: Maven and Development Process
Speaking only for myself - I manage a corporate development environment with 14 developers working on about 30 modules in various stages of legacy maintenance, active development, RD experiments, etc. The set of developers responsible for each module is different, as is the set of dependencies that each project requires. And several modules will often be combined to produce one war artifact, which means that versions of any common dependencies had better match. It's much easier to define employee contact details in developers.ent, a master list of dependencies (internal and external) in dependencies.ent, and then add specific items by reference to each project (e.g.: developerdev-johndoe;/developer and dependencydep-log4j;/dependency). This allows me to maintain details of each item in exactly one place (the .ent file), and have them automatically updated in the 5, 10, or 15 projects that might happen to need them. This is particularly useful for dependencies - I can guarantee that any module using log4j links to version 1.2.8, then enforce that they migrate simultaneously to 1.2.9 with a one-line change. The maintenance time goes way down this way, and as a side benefit our project.xml files are shorter and much more comprehensible. I'm not sure why you would consider entities a workaround - they allow you to define a master list of resources, pick and choose which resources fall into each project, and keep everything synchronized. One could always implement the same capability within Maven, but that seems like unnecessary duplication of effort. The XML parser is giving you this functionality for free - might as well take advantage of it. Mark -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 4:13 PM To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - 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: Build problem related to test distribution
We also desire to make test utility classes (primarily Mock Objects) available for use in testing of dependent projects. The approach of creating XYZ.jar and XYZ-tests.jar artifacts from project XYZ seems to be the best approach to this. Subsequent projects could then prescribe XYX-tests.jar as a test-dependency in their project.xml if needed. I don't think this runs counter to any of the arguments presented on the WhyYouCantCreateMultipleArtifactsInOneProject wiki page. Packaging an additional jar from the test code need not impact any of the plugins (except for a new test:deploy goal), and the build settings need not change. There is no risk of recreating the multi-project plugin within a single project. Alternate suggestion #1 of distributing test code inside a production jar is not a realistic solution in many (most?) environments. Alternate suggestion #2 of creating a new XYZ-test-support project creates a circular dependency - I can't test XYZ without the support classes, and I can't build the support classes without XYZ. I am curious to learn if the concept of a XYX-tests.jar artifact has been discussed before, and if so, why it would be rejected. Thanks, Mark -Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: September 16, 2003 3:35 AM To: Maven Users List Subject: Re: Build problem related to test distribution On Mon, 15 Sep 2003, Gil César Faria wrote: Hello everybody! I have a basic project where I have some general utility classes used by all other maven projects. Inside this general project, i have some abstract test classes that should be used within all other test classes of all projects. All test classes, including those abstract classes are under test directory. When maven builds the distribution for this general project, it only includes the source classes, not the test classes. But when i try to build other projects that depends upon this general project, i cannot compile the tests because the abstract test classes cannot be found. I am not sure about the best solution for this problem and would like an advise from our more maven experienced coleagues: Can i generate more than one artifact (jar) for a single project ? some kind of source distribution and test distribution ... No http://wiki.codehaus.org/maven/WhyYouCantCreateMultipleArtifactsInOneProject Should i generate only a single jar with all source and test classes inside it ? Don't see why not. The test class isnt a class for testing the artifact, rather a part of you general stuff. Bear in mind that the testcase class will be included if you end up building war or uberjars. Should i create a new project to hold only the abstract test classes, and include it as a dependency for all other projects ? This is also a solution. Currently you can only state _dependencies_ for a project so it doesn't add much value, but with a later version you can state runtime/testtime dependencies and then it might be a good idea to have it as a separate project. Guess the rest of your questions are answered by now? :) Should i redefine dist:build to create a test distribution ? There is an automated way to tell maven that the test classes should be considered as a dependency ? There is another way to organize my project classes to solve this problem? Can I define source dependencies and test dependencies separatelly? Any other suggestions? Thanks in advance! Trygve - 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]
