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 entry as:
> >
> >
> > scm:cvs:pserver:[EMAIL
> > PROTECTED]:/bar:${artifactId}
> > http://foo/viewcvs/viewcvs.asp/bar/${artifactId}
> >
> >
> > Child poms do not contain a 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]
>
>
[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 entry as:
scm:cvs:pserver:[EMAIL PROTECTED]:/bar:${artifactId}
http://foo/viewcvs/viewcvs.asp/bar/${artifactId}
Child poms do not contain a 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: 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 ... -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 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 - 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
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: 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: 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, R&D 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.: &dev-johndoe; and &dep-log4j;). 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 -
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: 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]
