Re: Building J2EE project
do you need to have the jars / wars without version numbers? ejb-jars work fine with a version number and you provide a context path for your web-app. application.xml looks something like this OnePort oneport-junitejb-1.0.jar appointment-1.0.jar pocweb-1.0.war pocweb ecaweb-1.0.war poc [EMAIL PROTECTED] wrote: The problem is when the ejb:install and war:install is called, an ejb jar and a war files are placed inside the local repository with a version number. Specifying maven.final.name does not help in this case. The ear:install will pick up the jar and war files from the local repository as specified under the dependencies in the pom. Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Nathan Coast <[EMAIL PROTECTED] To: Maven Users List <[EMAIL PROTECTED]> ar.com> cc: Subject: Re: Building J2EE project 12/12/2003 01:51 PM Please respond to "Maven Users List" sounds about right. I create a "project" project at the same depth as the same depth as the sub-projects. so the sub projects extend ../project/project.xml. this keeps the directory structure cleaner without any mixing of the parent project src, target whatever with the sub-project directories. to override the generated component name set the maven.final.name property in each project's build.properties [EMAIL PROTECTED] wrote: What is the best way to build a J2EE project? Currently, what I did was to create a main project folder to house 3 sub projects for building the ear, ejb jar and war files. Then I run the multiproject:install goal from the main project. Is the way I do it correct? By doing so, I got the ejb jar and war files in my ear file. However, I also got a version number tagged to my ejb jar and war files. How do I get rid of the version numbers? How do I add the security roles information in the application.xml file if I were to use the ear:generate-ear-descriptor goal? Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message. - 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] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message. - To unsubscribe, e-mail: [EMAIL
Re: Building J2EE project
The problem is when the ejb:install and war:install is called, an ejb jar and a war files are placed inside the local repository with a version number. Specifying maven.final.name does not help in this case. The ear:install will pick up the jar and war files from the local repository as specified under the dependencies in the pom. Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Nathan Coast <[EMAIL PROTECTED] To: Maven Users List <[EMAIL PROTECTED]> ar.com> cc: Subject: Re: Building J2EE project 12/12/2003 01:51 PM Please respond to "Maven Users List" sounds about right. I create a "project" project at the same depth as the same depth as the sub-projects. so the sub projects extend ../project/project.xml. this keeps the directory structure cleaner without any mixing of the parent project src, target whatever with the sub-project directories. to override the generated component name set the maven.final.name property in each project's build.properties [EMAIL PROTECTED] wrote: > What is the best way to build a J2EE project? > > Currently, what I did was to create a main project folder to house 3 sub > projects for building the ear, ejb jar and war files. Then I run the > multiproject:install goal from the main project. Is the way I do it > correct? > > By doing so, I got the ejb jar and war files in my ear file. However, I > also got a version number tagged to my ejb jar and war files. How do I get > rid of the version numbers? > > How do I add the security roles information in the application.xml file if > I were to use the ear:generate-ear-descriptor goal? > > > Regards, > Eng Hoe > App Dev-DCS > SGX-IT Division > > DID: (65) 62368963 > FAX: (65) 64388840 > email: [EMAIL PROTECTED] > > Confidentiality Caution > === > Privileged/Confidential Information may be contained in this message. If > you are not the addressee indicated in this message (or responsible for > delivery of the message to such person), you may not copy or deliver this > message to anyone. In such case, you should destroy this message and kindly > notify the sender by reply email. Opinions, conclusions and other > information in this message that is not of an official nature shall be > deemed as neither given nor endorsed by SGX unless indicated by an > authorised representative independent of this message. > > > - > 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] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building J2EE project
sounds about right. I create a "project" project at the same depth as the same depth as the sub-projects. so the sub projects extend ../project/project.xml. this keeps the directory structure cleaner without any mixing of the parent project src, target whatever with the sub-project directories. to override the generated component name set the maven.final.name property in each project's build.properties [EMAIL PROTECTED] wrote: What is the best way to build a J2EE project? Currently, what I did was to create a main project folder to house 3 sub projects for building the ear, ejb jar and war files. Then I run the multiproject:install goal from the main project. Is the way I do it correct? By doing so, I got the ejb jar and war files in my ear file. However, I also got a version number tagged to my ejb jar and war files. How do I get rid of the version numbers? How do I add the security roles information in the application.xml file if I were to use the ear:generate-ear-descriptor goal? Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message. - 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]
Building J2EE project
What is the best way to build a J2EE project? Currently, what I did was to create a main project folder to house 3 sub projects for building the ear, ejb jar and war files. Then I run the multiproject:install goal from the main project. Is the way I do it correct? By doing so, I got the ejb jar and war files in my ear file. However, I also got a version number tagged to my ejb jar and war files. How do I get rid of the version numbers? How do I add the security roles information in the application.xml file if I were to use the ear:generate-ear-descriptor goal? Regards, Eng Hoe App Dev-DCS SGX-IT Division DID: (65) 62368963 FAX: (65) 64388840 email: [EMAIL PROTECTED] Confidentiality Caution === Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that is not of an official nature shall be deemed as neither given nor endorsed by SGX unless indicated by an authorised representative independent of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Nope,
have a read of
http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Dependencies
and then you'll understand that you can place your jars in lib, and tell
maven not to use the local repo to find the file, instead you can override
the file location to be in ${basedir}/lib
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
[EMAIL PROTECTED] wrote on 12/12/2003 01:09:56 AM:
> Hi Dion, I haven't use this feature "jar overrides" so I don't how it
> works.
>
> Does "jar override" means that you specify in the dependency's field
"jar"
> your location instead of the default one made up by Maven?
>
>
>
>
>
>
> [EMAIL PROTECTED]
> 11/12/2003 14:00
> Please respond to
> "Maven Users List" <[EMAIL PROTECTED]>
>
>
> To
> "Maven Users List" <[EMAIL PROTECTED]>
> cc
>
> Subject
> Re: Réf. : The Dependencies are stored in CVS : Preparing Maven
> Repository Beforehand ???
>
>
>
>
>
>
> Why not use jar overrides, and point the jar override at ./lib?
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
>
>
>
> [EMAIL PROTECTED] wrote on 12/12/2003 12:41:58 AM:
>
> > Hi Nicolas, as I said in the mail, in previous projects that was the
way
>
> > we worked. But now, this project mandates that the libraries should be
> in
> > cvs. I can't get away from that.
> >
> > I definitely like the way Maven suggests to handle the dependencies.
> >
> > Thank you, Nicolas.
> >
> >
> >
> >
> >
> > [EMAIL PROTECTED]
> > 11/12/2003 12:42
> > Please respond to
> > "Maven Users List" <[EMAIL PROTECTED]>
> >
> >
> > To
> > "Maven Users List" <[EMAIL PROTECTED]>
> > cc
> >
> > Subject
> > Réf. : The Dependencies are stored in CVS : Preparing Maven Repository
> > Beforehand ???
> >
> >
> >
> >
> >
> >
> > Why don't use SNAPSHOT version for your dependency and on a local
server
> > store the jar who can't be in ibiblio. It seem to be the way method to
> > have latest version than storing them in CVS. With maven i think that
> lib
> > don't have to be in CVS because it have a mechanism to find them
> > automaticly.
> >
> > Nicolas
> >
> >
> >
> >
> >
> > [EMAIL PROTECTED]
> > 11/12/2003 12:33
> > Veuillez répondre à "Maven Users List"
> >
> >
> > Pour : Maven Users List <[EMAIL PROTECTED]>
> > cc :
> > Objet : The Dependencies are stored in CVS : Preparing Maven
Repository
> > Beforehand
> > ???
> >
> >
> > Hi all, I barely remember that somebody mentioned this subject but I
can
> >
> > find the thread anymore.
> >
> > The subject is about how do we handle our dependencies, if they are
> > stored in the CVS and every build gets a clean version of the whole
> > project from CVS. (I use explicitly CVS to avoid the word repository
> that
> > use later to refer to MAven repository).
> >
> > Let's say that any project contains a folder called: \lib where all
the
> >
> > dependencies are stored and refered from project.xml. Any developer is
> > asked to keep uptodate the libraries they are using.
> >
> > In my case, I have to kick off an external script to move all the
> > libraries refered in the project.xml to the corresponding location in
> the
> > Maven repository. This script is kicked off before I can run maven on
> the
> > project. Maven will expect to find all the dependencies in project.xml
> in
> > the maven repository.
> >
> > In previous projects, we used Maven central repository to store and
> > provide all the dependencies and it was updated by a single person
> > (project manager). If you wanted to get the latest version, you only
> > needed to clean your local repository and maven retrieved them again
> from
> > the central repository (remote repository). Now, the current project
> > mandates to store the dependencies in CVS.
> >
> >
> > I wonder whether the way I am currently handling the dependencies is
the
> >
> > most appropiate way or whether there is other ones.
> >
> > Thank you
> >
> > Marcial Rosales
> >
> >
> > -
> > 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]
>
-
Re: How to specify a subproject's navigation.xml
I'm using CVS HEAD, downloaded on 11/25/03. Even if I remove xdocs/navigation.xml entirely, the subproject/xdocs/navigation.xml file is not used to create the subproject's index. Instead, I get a default index. I'm using these properties: maven.multiproject.ignoreFailures=false maven.multiproject.navigation=aggregate maven.multiproject.type=jar maven.multiproject.includes=*/project.xml maven.multiproject.excludes=project.xml and taking the default value for maven.multiproject.aggregateDir. I'll install RC1 and see if I get the same thing. On Fri, 12 Dec 2003, at 11:15:15 [GMT +1100] [EMAIL PROTECTED] wrote: > Are you using RC1? > If so, the subprojects navigation.xml should be all that's used for the > subproject. > -- > dIon Gillard, Multitask Consulting > Blog: http://blogs.codehaus.org/people/dion/ > "Jefferson K. French" <[EMAIL PROTECTED]> wrote on 12/12/2003 09:51:09 AM: >> I'm having a hard time figuring out how to specify a navigation.xml >> file for my subprojects. When I do a multiproject:site, I find that my >> subproject's xdocs/navigation.xml file is ignored, and the main >> project's xdocs/navigation.xml file is used instead. >> >> Could someone who has gotten subproject navigation to work with a >> recent build of Maven please give me some hints? I've been searching >> through the archives and plugin docs, and I tried to emulate the >> WebShop example, but to no avail. >> >> Thanks for any pointers. >> >> Jeff >> >> -- >> mailto:[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] -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to specify a subproject's navigation.xml
Are you using RC1? If so, the subprojects navigation.xml should be all that's used for the subproject. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ "Jefferson K. French" <[EMAIL PROTECTED]> wrote on 12/12/2003 09:51:09 AM: > I'm having a hard time figuring out how to specify a navigation.xml > file for my subprojects. When I do a multiproject:site, I find that my > subproject's xdocs/navigation.xml file is ignored, and the main > project's xdocs/navigation.xml file is used instead. > > Could someone who has gotten subproject navigation to work with a > recent build of Maven please give me some hints? I've been searching > through the archives and plugin docs, and I tried to emulate the > WebShop example, but to no avail. > > Thanks for any pointers. > > Jeff > > -- > mailto:[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]
RE: How set maven.build.dest in project.xml ?
+1
I have had to integrate maven into projcet where for varous reasons, it was
easier to have maven build into a different directory
I think flexibility is the key, and also not being to rigind about such
things. I can see the need to justify the requirements, but as I say I have
used maven in 2 situations where is was *easier* at the time ot change the
name of the "target" folder. Not that it couldn't have been done another way
that didn't require that, but at the time it was (or would have been) easier
i.e. if I start work on an existing project with many members and the
project is not currently mavenized & I can't simply change it wholesale. I
want to gradually introduce maven but not disrupt the way people are
currently doing thaings
In fact by that argument, this feature will arguably enhance the adoption of
maven by making it easier to introduce maven into existing projects. That
was cerainly my case.
Matthew
> -Original Message-
> From: W. Sean Hennessy [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 12, 2003 8:32 AM
> To: 'Maven Users List'
> Subject: RE: How set maven.build.dest in project.xml ?
>
>
>
> The advantage being Maven would be able to service the
> requirement for one group's choice of "target" and another
> group's use of "build" for the name of the result tree without
> the need to instrument a directory rename or dir copy
> goal.
>
> Do I really care that much if all classes are output to "target/"?
> Personally it does not matter which to me.
> Would like to be able to accommodate a different name be it
> "build", "target", "diskimage", "bin", "cible" or "Ziel".
>
> My interest is in the flexibility to accomodate such changes.
> Given the bandwith and any level of confidence in my jelly
> skillset I would volunteer to contribute.
>
>
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 11, 2003 11:47 AM
> To: Maven Users List
> Subject: RE: How set maven.build.dest in project.xml ?
>
>
> On Thu, 2003-12-11 at 12:06, W. Sean Hennessy wrote:
> > Jason,
> >
> > Please, I beseech you to reconsider the "make target/ your only
> > choice" limitation. We acknowledge that a standard directory structure
> > facilitates maintenance. However, please, consider that the specific
> > folder naming could be defined as configurable items. We still
> > benefit from the existing directory the structure and the jelly
> > scripts behavior is preserved.
> >
> > "target/" becomes "${target-dir-nm}/" in build.xml and jelly.
> >
> > with
> > # --
> > # build.properties
> > # --
> > bin-dir-nm=bin
> > target-dir-nm=target
> > conf-dir-nm=conf
> > dist-dir-nm=dist
> > lib-dir-nm=lib
> > sql-dir-nm=sql
> > src-dir-nm=src
> > tst-dir-nm=test
> > web-dir-nm=web
> > xdoc-dir-nm=xdoc
> >
> > Thanks for your consideration.
> >
>
> Ok, in your opinion what would be the advantage of making these
> things above configurable? Do you really care that much
> if all classes are output to target/ ?
>
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be
> justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> -
> 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]
Re: AttainGoal question
Is this also the reason the console plugin fails when it tries to run a multiproject:goal a second time? On Thu, 11 Dec 2003, at 09:28:28 [GMT +1100] Peter Donald wrote: > On Thu, 11 Dec 2003 03:10 am, Lester Ward wrote: >> Can anyone tell me what the difference is between running a goal from the >> command line vs. having that goal called by an tag? Over the >> last few days, I've seen three problems where I could run a goal just fine >> from a command line, but if the same goal was invoked from an >> tag, various strange errors occur. >> >> Makes it very hard to track down the problem. I assume there is some sort >> of differnce between the way the goal is invoked that is the culprit. > AtainGoal starts a new session so if you do an attainGoal on a goal already > completed it will be reprocessed BUT pregoals and postgoals will not be > re-executed. Major PITA :) -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to specify a subproject's navigation.xml
I'm having a hard time figuring out how to specify a navigation.xml file for my subprojects. When I do a multiproject:site, I find that my subproject's xdocs/navigation.xml file is ignored, and the main project's xdocs/navigation.xml file is used instead. Could someone who has gotten subproject navigation to work with a recent build of Maven please give me some hints? I've been searching through the archives and plugin docs, and I tried to emulate the WebShop example, but to no avail. Thanks for any pointers. Jeff -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How set maven.build.dest in project.xml ?
The advantage being Maven would be able to service the requirement for one group's
choice of "target" and another
group's use of "build" for the name of the result tree without the need to instrument
a directory rename or dir copy
goal.
Do I really care that much if all classes are output to "target/"?
Personally it does not matter which to me.
Would like to be able to accommodate a different name be it "build", "target",
"diskimage", "bin", "cible" or "Ziel".
My interest is in the flexibility to accomodate such changes.
Given the bandwith and any level of confidence in my jelly skillset I would volunteer
to contribute.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 11:47 AM
To: Maven Users List
Subject: RE: How set maven.build.dest in project.xml ?
On Thu, 2003-12-11 at 12:06, W. Sean Hennessy wrote:
> Jason,
>
> Please, I beseech you to reconsider the "make target/ your only
> choice" limitation. We acknowledge that a standard directory structure
> facilitates maintenance. However, please, consider that the specific
> folder naming could be defined as configurable items. We still
> benefit from the existing directory the structure and the jelly
> scripts behavior is preserved.
>
> "target/" becomes "${target-dir-nm}/" in build.xml and jelly.
>
> with
> # --
> # build.properties
> # --
> bin-dir-nm=bin
> target-dir-nm=target
> conf-dir-nm=conf
> dist-dir-nm=dist
> lib-dir-nm=lib
> sql-dir-nm=sql
> src-dir-nm=src
> tst-dir-nm=test
> web-dir-nm=web
> xdoc-dir-nm=xdoc
>
> Thanks for your consideration.
>
Ok, in your opinion what would be the advantage of making these things above
configurable? Do you really care that much
if all classes are output to target/ ?
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational and technical order to
justify his work and to be
justified in it.
-- Jacques Ellul, The Technological Society
-
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]
aspectj injars
Hello. Is there any way to get the aspectj plugin to weave into previously compiled jars that I have set as s? I could do it with ant. So, I guess I could make a that runs the commands for the inJars command. Just wanted to check to see if anyone else had done this first. Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How set maven.build.dest in project.xml ?
> Ok, in your opinion what would be the advantage of making these things > above configurable? Do you really care that much if all classes are > output to target/ ? It is sometimes useful to have classes be output outside the project directory. This is more useful with docs than code, but I used to build directly into JBoss's deploy folder when debugging. This was much faster than doing a full deploy every time something changed, so helped debugging immensely. Naturally, I'd never do that on a build machine, just a dev box. (As far as docs go, our CruiseControl build process updates all of our products and overrides the build target for the docs to the main web server directory on the machine. We do this rather than use all the web deploy stuff, which I find irritating, buggy and slow.) It also is extremely useful when forced to integrate your project with project that is not Mavenized. Not all projects have the luxury of full control over all of the code they use. At one point, for example, we were using Jetspeed which used Ant for builds (though it has since been Mavenized) and for various reasons it was easier to override our project's build target. Sure, we probably .could. have done it differently, but speed mattered to us more than beauty at that point. Next, one of Maven's strengths is its configurability. In spite of the fact that there are some strongly followed conventions in Maven (e.g. "one project, one artifact"), Maven manages (mostly) to avoid the stigma of being a One True Way cult that drives people away by virtue of the fact that you can deviate from the One True Way any time you like. When I first started using Maven, I read the description of the recommended project structure. If I hadn't seen a phrase to the effect of "of course, you can override any of these paths if you like", I probably would never have started using Maven at all, even though at the time I would not have been able to justify why I would want to change them. Being able to configure everything except the build directory would severely weaken Maven in probably functional ways and definitely reputational ways. Lastly, it is very unclear to me what forcing /target buys you. Worse, it is even less clear what forcing /target buys _me_. Wordman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jalopy and UnsupportedOperationException
Has anybody encountered this Exception while formatting with Jalopy? Yoway Buorn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How set maven.build.dest in project.xml ?
On Thu, 2003-12-11 at 12:06, W. Sean Hennessy wrote:
> Jason,
>
> Please, I beseech you to reconsider the "make target/ your only choice" limitation.
> We acknowledge that a standard directory structure facilitates maintenance.
> However, please, consider that the specific folder naming could be defined as
> configurable items. We still benefit from
> the existing directory the structure and the jelly scripts behavior is preserved.
>
> "target/" becomes "${target-dir-nm}/" in build.xml and jelly.
>
> with
> # --
> # build.properties
> # --
> bin-dir-nm=bin
> target-dir-nm=target
> conf-dir-nm=conf
> dist-dir-nm=dist
> lib-dir-nm=lib
> sql-dir-nm=sql
> src-dir-nm=src
> tst-dir-nm=test
> web-dir-nm=web
> xdoc-dir-nm=xdoc
>
> Thanks for your consideration.
>
Ok, in your opinion what would be the advantage of making these things
above configurable? Do you really care that much if all classes are
output to target/ ?
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How set maven.build.dest in project.xml ?
Jason,
Please, I beseech you to reconsider the "make target/ your only choice" limitation.
We acknowledge that a standard directory structure facilitates maintenance.
However, please, consider that the specific folder naming could be defined as
configurable items. We still benefit from
the existing directory the structure and the jelly scripts behavior is preserved.
"target/" becomes "${target-dir-nm}/" in build.xml and jelly.
with
# --
# build.properties
# --
bin-dir-nm=bin
target-dir-nm=target
conf-dir-nm=conf
dist-dir-nm=dist
lib-dir-nm=lib
sql-dir-nm=sql
src-dir-nm=src
tst-dir-nm=test
web-dir-nm=web
xdoc-dir-nm=xdoc
Thanks for your consideration.
Sean
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 5:35 AM
To: Maven Users List
Subject: Re: How set maven.build.dest in project.xml ?
On Thu, 2003-12-11 at 04:41, Stéphane Philippart wrote:
> Hello,
>
> I want to set the maven.build.dest to the 'build' value, when i do
> that in a project.properties of each sun projects with :
> maven.build.dest=${basedir}/build/ everything is find !
I'll ask why you really want to do this and second that in coming versions I would
like to make target/ your only
choice.
> But i don't want to do that for all my sub-projects so i want to put
> this property in the project.xml of my projects main project and
> inherite it in my sub projects.
>
> I put the lines :
>
> build
>
> in the root projetc.xml.
>
> The other parameters (like dependencies, build for example) are well
> inherited the properties seems not inherited. In the archive thread i
> read it will be having problems for inheritance of properties in the
> project.xml.
>
> Does it work ? If yes what i have did wrong ?
Why do you even want to do this?
> Thanks
> -
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational and technical order to
justify his work and to be
justified in it.
-- Jacques Ellul, The Technological Society
-
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 stall
On Thu, 2003-12-11 at 12:28, Nathan Mcminn wrote: > Wow, that's venomous. Forget I asked. Oh c'mon, you have a have a thicker skin than that. If you give us some information we can help you but if you just blame Maven and give us a stack trace there isn't much we can do or will do. Just poke around a bit more, give us something to work with and we can probably help. Look at the message you sent us which seems to involve some odd behaviour for a build. If you answer the questions I asked you I'll be able to help. Just because I have a sharp tongue doesn't mean I won't help you, I'm just asking for some information. > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 11, 2003 10:19 AM > > To: Maven Users List > > Subject: Re: Maven stall > > > > > > On Thu, 2003-12-11 at 11:04, Nathan Mcminn wrote: > > > We are currently using Maven to build our project. Yesterday, it > > > started acting up. We have not made any changes to our > > configuration > > > files, or upgraded Maven. Out of the blue, when we build > > the project, > > > Maven freezes at the following portion of the build: > > > > If it worked before and now it doesn't it's probably not > > Maven's fault. I find it very unlikely that Maven just > > stopped working. Maven is quirky but I'm willing to bet the > > problem is on your end as it is most of time when people > > blame the tools they use. If I got a nickel for every time > > someone said "we didn't touch anything!" when they actually > > did I would be a very rich man. > > > > > 0 [main] INFO services.BaseServiceBroker - Added Mapping > > for Service: > > > XmlRpcSer vice > > > 10 [main] INFO services.BaseServiceBroker - Start > > Initializing service > > > (early): > > > XmlRpcService > > > 140 [main] INFO services.BaseServiceBroker - Finish Initializing > > > service (early > > > ): XmlRpcService > > > 140 [main] INFO services.BaseServiceBroker - Finished > > initializing all > > > services > > > ! > > > > This looks like Turbine, yes? So I'm not sure why services or > > Fulcrum is firing up while you're building or is this part of > > a runtime test? > > > > > And it will not complete the build. There are no errors > > displayed in > > > the console. Has anybody else had this happen? > > > > Honestly, what kind of help do you really expect with "It > > doesn't work anymore, we didn't do anything" and a bit of a > > log. I know you just want a little help and guidance but help > > us out here. > > > > > > > > Nathan McMinn > > > Application Developer > > > NequalsOne - HealthCare marketing tools > > mailto:[EMAIL PROTECTED] > > > http://www.NequalsOne.com > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://tambora.zenplex.org > > > > In short, man creates for himself a new religion of a > > rational and technical order to justify his work and to be > > justified in it. > > > > -- Jacques Ellul, The Technological Society > > > > > > - > > 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven stall
Wow, that's venomous. Forget I asked. > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 11, 2003 10:19 AM > To: Maven Users List > Subject: Re: Maven stall > > > On Thu, 2003-12-11 at 11:04, Nathan Mcminn wrote: > > We are currently using Maven to build our project. Yesterday, it > > started acting up. We have not made any changes to our > configuration > > files, or upgraded Maven. Out of the blue, when we build > the project, > > Maven freezes at the following portion of the build: > > If it worked before and now it doesn't it's probably not > Maven's fault. I find it very unlikely that Maven just > stopped working. Maven is quirky but I'm willing to bet the > problem is on your end as it is most of time when people > blame the tools they use. If I got a nickel for every time > someone said "we didn't touch anything!" when they actually > did I would be a very rich man. > > > 0 [main] INFO services.BaseServiceBroker - Added Mapping > for Service: > > XmlRpcSer vice > > 10 [main] INFO services.BaseServiceBroker - Start > Initializing service > > (early): > > XmlRpcService > > 140 [main] INFO services.BaseServiceBroker - Finish Initializing > > service (early > > ): XmlRpcService > > 140 [main] INFO services.BaseServiceBroker - Finished > initializing all > > services > > ! > > This looks like Turbine, yes? So I'm not sure why services or > Fulcrum is firing up while you're building or is this part of > a runtime test? > > > And it will not complete the build. There are no errors > displayed in > > the console. Has anybody else had this happen? > > Honestly, what kind of help do you really expect with "It > doesn't work anymore, we didn't do anything" and a bit of a > log. I know you just want a little help and guidance but help > us out here. > > > > > Nathan McMinn > > Application Developer > > NequalsOne - HealthCare marketing tools > mailto:[EMAIL PROTECTED] > > http://www.NequalsOne.com > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a > rational and technical order to justify his work and to be > justified in it. > > -- Jacques Ellul, The Technological Society > > > - > 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 stall
If it worked before and now it doesn't it's probably not Maven's fault. I find it very unlikely that Maven just stopped working. Maven is quirky but I'm willing to bet the problem is on your end as it is most of time when people blame the tools they use. If I got a nickel for every time someone said "we didn't touch anything!" when they actually did I would be a very rich man. We have the following "quote" on our white board: "I didn't change anything... Besides, I changed it all back!" It's something that one of our team members actually said. :-) --Leif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven stall
On Thu, 2003-12-11 at 11:04, Nathan Mcminn wrote: > We are currently using Maven to build our project. Yesterday, it > started acting up. We have not made any changes to our configuration > files, or upgraded Maven. Out of the blue, when we build the project, > Maven freezes at the following portion of the build: If it worked before and now it doesn't it's probably not Maven's fault. I find it very unlikely that Maven just stopped working. Maven is quirky but I'm willing to bet the problem is on your end as it is most of time when people blame the tools they use. If I got a nickel for every time someone said "we didn't touch anything!" when they actually did I would be a very rich man. > 0 [main] INFO services.BaseServiceBroker - Added Mapping for Service: > XmlRpcSer > vice > 10 [main] INFO services.BaseServiceBroker - Start Initializing service > (early): > XmlRpcService > 140 [main] INFO services.BaseServiceBroker - Finish Initializing > service (early > ): XmlRpcService > 140 [main] INFO services.BaseServiceBroker - Finished initializing all > services > ! This looks like Turbine, yes? So I'm not sure why services or Fulcrum is firing up while you're building or is this part of a runtime test? > And it will not complete the build. There are no errors displayed in > the console. Has anybody else had this happen? Honestly, what kind of help do you really expect with "It doesn't work anymore, we didn't do anything" and a bit of a log. I know you just want a little help and guidance but help us out here. > > Nathan McMinn > Application Developer > NequalsOne - HealthCare marketing tools > mailto:[EMAIL PROTECTED] > http://www.NequalsOne.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven stall
We are currently using Maven to build our project. Yesterday, it started acting up. We have not made any changes to our configuration files, or upgraded Maven. Out of the blue, when we build the project, Maven freezes at the following portion of the build: 0 [main] INFO services.BaseServiceBroker - Added Mapping for Service: XmlRpcSer vice 10 [main] INFO services.BaseServiceBroker - Start Initializing service (early): XmlRpcService 140 [main] INFO services.BaseServiceBroker - Finish Initializing service (early ): XmlRpcService 140 [main] INFO services.BaseServiceBroker - Finished initializing all services ! And it will not complete the build. There are no errors displayed in the console. Has anybody else had this happen? Nathan McMinn Application Developer NequalsOne - HealthCare marketing tools mailto:[EMAIL PROTECTED] http://www.NequalsOne.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi Mmaczka,
I totally agree. I had forgotten that you could provide a comma separated
list of repositories. Jörg was also right.
The thing is now to check Nicolas' suggestion on using "file://" protocol
to specify a local repository.
Anyway, I would appreciate if you could please point me where I can find
further information about jar override. I don't know this feature.
As you says, I need to change the current structure of my lib folder to
be maven compliant.
Regards
Marcial
[EMAIL PROTECTED]
11/12/2003 15:24
Please respond to
"Maven Users List" <[EMAIL PROTECTED]>
To
Maven Users List <[EMAIL PROTECTED]>
cc
Subject
Re: RE: Réf. : The Dependencies are stored in CVS : Preparing Maven
Repository Beforehand ???
> Hi Jörg,
> I know what you mean, but for me it wouldn't work. I hope you understand
> the expression "I am against the wall" :-). I need that
maven.repo.remote
>
> points to our maven central repository (a web site set up with all the
> dependencies that maven requires by itself). Of course, all the
developers
>
> would only need to use this repository the first time they run maven on
> their machines to get everything to run maven.
>
> Regards
> Marcial
>
maven.repo.remote supports lists of repositories
So you can do (I am not sure if syntax is really correct, but I hope that
the idea will be clear)
maven.repo.remote=${basedir}/repo/,http://www.ibiblio.org,http://your_intranet
then either you have to organize your lib folder as maven repo is
organized
lib/foo
jars
foo-1.0.jar
baa
jars
baa-1.0.jar
or to look closer at maven jar overriding mechanism.
I will try to look at the possiblity of supporting CVS repositories (not
necesserly linked with single project as in above example).
But this will have to wait as botr Wagon & SCM subproject matures.
Michal
-
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: RE: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
> Hi Jörg,
> I know what you mean, but for me it wouldn't work. I hope you understand
> the expression "I am against the wall" :-). I need that maven.repo.remote
>
> points to our maven central repository (a web site set up with all the
> dependencies that maven requires by itself). Of course, all the developers
>
> would only need to use this repository the first time they run maven on
> their machines to get everything to run maven.
>
> Regards
> Marcial
>
maven.repo.remote supports lists of repositories
So you can do (I am not sure if syntax is really correct, but I hope that the idea
will be clear)
maven.repo.remote=${basedir}/repo/,http://www.ibiblio.org,http://your_intranet
then either you have to organize your lib folder as maven repo is organized
lib/foo
jars
foo-1.0.jar
baa
jars
baa-1.0.jar
or to look closer at maven jar overriding mechanism.
I will try to look at the possiblity of supporting CVS repositories (not necesserly
linked with single project as in above example).
But this will have to wait as botr Wagon & SCM subproject matures.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi Jörg, I know what you mean, but for me it wouldn't work. I hope you understand the expression "I am against the wall" :-). I need that maven.repo.remote points to our maven central repository (a web site set up with all the dependencies that maven requires by itself). Of course, all the developers would only need to use this repository the first time they run maven on their machines to get everything to run maven. Regards Marcial Jörg Schaible <[EMAIL PROTECTED]> 11/12/2003 14:10 Please respond to "Maven Users List" <[EMAIL PROTECTED]> To "Maven Users List" <[EMAIL PROTECTED]> cc Subject RE: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ??? [EMAIL PROTECTED] wrote on Thursday, December 11, 2003 2:42 PM: > Hi Nicolas, as I said in the mail, in previous projects that > was the way > we worked. But now, this project mandates that the libraries > should be in > cvs. I can't get away from that. > > I definitely like the way Maven suggests to handle the dependencies. Just an idea, but I do not know if the "file" protocol is supported: maven.repo.remote=file://cvs-repo Regards, Jörg - 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: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
[EMAIL PROTECTED] wrote on Thursday, December 11, 2003 2:42 PM: > Hi Nicolas, as I said in the mail, in previous projects that > was the way > we worked. But now, this project mandates that the libraries > should be in > cvs. I can't get away from that. > > I definitely like the way Maven suggests to handle the dependencies. Just an idea, but I do not know if the "file" protocol is supported: maven.repo.remote=file://cvs-repo Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi Dion, I haven't use this feature "jar overrides" so I don't how it works. Does "jar override" means that you specify in the dependency's field "jar" your location instead of the default one made up by Maven? [EMAIL PROTECTED] 11/12/2003 14:00 Please respond to "Maven Users List" <[EMAIL PROTECTED]> To "Maven Users List" <[EMAIL PROTECTED]> cc Subject Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ??? Why not use jar overrides, and point the jar override at ./lib? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ [EMAIL PROTECTED] wrote on 12/12/2003 12:41:58 AM: > Hi Nicolas, as I said in the mail, in previous projects that was the way > we worked. But now, this project mandates that the libraries should be in > cvs. I can't get away from that. > > I definitely like the way Maven suggests to handle the dependencies. > > Thank you, Nicolas. > > > > > > [EMAIL PROTECTED] > 11/12/2003 12:42 > Please respond to > "Maven Users List" <[EMAIL PROTECTED]> > > > To > "Maven Users List" <[EMAIL PROTECTED]> > cc > > Subject > Réf. : The Dependencies are stored in CVS : Preparing Maven Repository > Beforehand ??? > > > > > > > Why don't use SNAPSHOT version for your dependency and on a local server > store the jar who can't be in ibiblio. It seem to be the way method to > have latest version than storing them in CVS. With maven i think that lib > don't have to be in CVS because it have a mechanism to find them > automaticly. > > Nicolas > > > > > > [EMAIL PROTECTED] > 11/12/2003 12:33 > Veuillez répondre à "Maven Users List" > > > Pour : Maven Users List <[EMAIL PROTECTED]> > cc : > Objet : The Dependencies are stored in CVS : Preparing Maven Repository > Beforehand > ??? > > > Hi all, I barely remember that somebody mentioned this subject but I can > > find the thread anymore. > > The subject is about how do we handle our dependencies, if they are > stored in the CVS and every build gets a clean version of the whole > project from CVS. (I use explicitly CVS to avoid the word repository that > use later to refer to MAven repository). > > Let's say that any project contains a folder called: \lib where all the > > dependencies are stored and refered from project.xml. Any developer is > asked to keep uptodate the libraries they are using. > > In my case, I have to kick off an external script to move all the > libraries refered in the project.xml to the corresponding location in the > Maven repository. This script is kicked off before I can run maven on the > project. Maven will expect to find all the dependencies in project.xml in > the maven repository. > > In previous projects, we used Maven central repository to store and > provide all the dependencies and it was updated by a single person > (project manager). If you wanted to get the latest version, you only > needed to clean your local repository and maven retrieved them again from > the central repository (remote repository). Now, the current project > mandates to store the dependencies in CVS. > > > I wonder whether the way I am currently handling the dependencies is the > > most appropiate way or whether there is other ones. > > Thank you > > Marcial Rosales > > > - > 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]
Re: returning var value to initial value
I don't know if there is a builtin way, but would this work? I couldn't tell from your question if you were trying to avoid the j:set altogether, or just avoid hardcoding the original value. Jeff On Thu, 11 Dec 2003, at 07:15:22 [GMT -0600] Marc Dugger wrote: > If I define 'foo=something' in a build.properties or project.properties and > I in maven.xml, is there a way I can return > 'foo' to the original value (i.e. re-initialize?) defined in > build.properties or project.properties without having to >? > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Why not use jar overrides, and point the jar override at ./lib? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ [EMAIL PROTECTED] wrote on 12/12/2003 12:41:58 AM: > Hi Nicolas, as I said in the mail, in previous projects that was the way > we worked. But now, this project mandates that the libraries should be in > cvs. I can't get away from that. > > I definitely like the way Maven suggests to handle the dependencies. > > Thank you, Nicolas. > > > > > > [EMAIL PROTECTED] > 11/12/2003 12:42 > Please respond to > "Maven Users List" <[EMAIL PROTECTED]> > > > To > "Maven Users List" <[EMAIL PROTECTED]> > cc > > Subject > Réf. : The Dependencies are stored in CVS : Preparing Maven Repository > Beforehand ??? > > > > > > > Why don't use SNAPSHOT version for your dependency and on a local server > store the jar who can't be in ibiblio. It seem to be the way method to > have latest version than storing them in CVS. With maven i think that lib > don't have to be in CVS because it have a mechanism to find them > automaticly. > > Nicolas > > > > > > [EMAIL PROTECTED] > 11/12/2003 12:33 > Veuillez répondre à "Maven Users List" > > > Pour : Maven Users List <[EMAIL PROTECTED]> > cc : > Objet : The Dependencies are stored in CVS : Preparing Maven Repository > Beforehand > ??? > > > Hi all, I barely remember that somebody mentioned this subject but I can > > find the thread anymore. > > The subject is about how do we handle our dependencies, if they are > stored in the CVS and every build gets a clean version of the whole > project from CVS. (I use explicitly CVS to avoid the word repository that > use later to refer to MAven repository). > > Let's say that any project contains a folder called: \lib where all the > > dependencies are stored and refered from project.xml. Any developer is > asked to keep uptodate the libraries they are using. > > In my case, I have to kick off an external script to move all the > libraries refered in the project.xml to the corresponding location in the > Maven repository. This script is kicked off before I can run maven on the > project. Maven will expect to find all the dependencies in project.xml in > the maven repository. > > In previous projects, we used Maven central repository to store and > provide all the dependencies and it was updated by a single person > (project manager). If you wanted to get the latest version, you only > needed to clean your local repository and maven retrieved them again from > the central repository (remote repository). Now, the current project > mandates to store the dependencies in CVS. > > > I wonder whether the way I am currently handling the dependencies is the > > most appropiate way or whether there is other ones. > > Thank you > > Marcial Rosales > > > - > 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]
Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi, [EMAIL PROTECTED] wrote: Hi Nicolas, as I said in the mail, in previous projects that was the way we worked. But now, this project mandates that the libraries should be in cvs. I can't get away from that. Can't you make a CVS module out of your maven repository ? Even if it's a separate repository where you just keep the direct dependencies (and leave all the maven plugins and build dependencies in your maven home repos) Just a thought, I'm new to this :) Brice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi Nicolas, as I said in the mail, in previous projects that was the way we worked. But now, this project mandates that the libraries should be in cvs. I can't get away from that. I definitely like the way Maven suggests to handle the dependencies. Thank you, Nicolas. [EMAIL PROTECTED] 11/12/2003 12:42 Please respond to "Maven Users List" <[EMAIL PROTECTED]> To "Maven Users List" <[EMAIL PROTECTED]> cc Subject Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ??? Why don't use SNAPSHOT version for your dependency and on a local server store the jar who can't be in ibiblio. It seem to be the way method to have latest version than storing them in CVS. With maven i think that lib don't have to be in CVS because it have a mechanism to find them automaticly. Nicolas [EMAIL PROTECTED] 11/12/2003 12:33 Veuillez répondre à "Maven Users List" Pour : Maven Users List <[EMAIL PROTECTED]> cc : Objet : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ??? Hi all, I barely remember that somebody mentioned this subject but I can find the thread anymore. The subject is about how do we handle our dependencies, if they are stored in the CVS and every build gets a clean version of the whole project from CVS. (I use explicitly CVS to avoid the word repository that use later to refer to MAven repository). Let's say that any project contains a folder called: \lib where all the dependencies are stored and refered from project.xml. Any developer is asked to keep uptodate the libraries they are using. In my case, I have to kick off an external script to move all the libraries refered in the project.xml to the corresponding location in the Maven repository. This script is kicked off before I can run maven on the project. Maven will expect to find all the dependencies in project.xml in the maven repository. In previous projects, we used Maven central repository to store and provide all the dependencies and it was updated by a single person (project manager). If you wanted to get the latest version, you only needed to clean your local repository and maven retrieved them again from the central repository (remote repository). Now, the current project mandates to store the dependencies in CVS. I wonder whether the way I am currently handling the dependencies is the most appropiate way or whether there is other ones. Thank you Marcial Rosales - 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]
RE: How set maven.build.dest in project.xml ?
The default compile dir is ${basedir}/target/classes I want
${basedir}/build for all my projects.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: jeudi 11 décembre 2003 14:35
To: Maven Users List
Subject: Re: How set maven.build.dest in project.xml ?
On Thu, 2003-12-11 at 04:41, Stéphane Philippart wrote:
> Hello,
>
> I want to set the maven.build.dest to the 'build' value, when i do
that
> in a project.properties of each sun projects with :
> maven.build.dest=${basedir}/build/ everything is find !
I'll ask why you really want to do this and second that in coming
versions I would like to make target/ your only choice.
> But i don't want to do that for all my sub-projects so i want to put
> this property in the project.xml of my projects main project and
> inherite it in my sub projects.
>
> I put the lines :
>
> build
>
> in the root projetc.xml.
>
> The other parameters (like dependencies, build for example) are well
> inherited the properties seems not inherited. In the archive thread i
> read it will be having problems for inheritance of properties in the
> project.xml.
>
> Does it work ? If yes what i have did wrong ?
Why do you even want to do this?
> Thanks
> -
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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: How set maven.build.dest in project.xml ?
On Thu, 2003-12-11 at 04:41, Stéphane Philippart wrote:
> Hello,
>
> I want to set the maven.build.dest to the 'build' value, when i do that
> in a project.properties of each sun projects with :
> maven.build.dest=${basedir}/build/ everything is find !
I'll ask why you really want to do this and second that in coming
versions I would like to make target/ your only choice.
> But i don't want to do that for all my sub-projects so i want to put
> this property in the project.xml of my projects main project and
> inherite it in my sub projects.
>
> I put the lines :
>
> build
>
> in the root projetc.xml.
>
> The other parameters (like dependencies, build for example) are well
> inherited the properties seems not inherited. In the archive thread i
> read it will be having problems for inheritance of properties in the
> project.xml.
>
> Does it work ? If yes what i have did wrong ?
Why do you even want to do this?
> Thanks
> -
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
returning var value to initial value
If I define 'foo=something' in a build.properties or project.properties and I in maven.xml, is there a way I can return 'foo' to the original value (i.e. re-initialize?) defined in build.properties or project.properties without having to ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in multiproject:site
I already have in project.properties
maven.multiproject.basedir=${basedir}/modules
Beside only multiproject:site doesn't work, multiproject:jar and
multiproject:install are ok.
Mikael Lundgren writes:
> Hi!
>
> Did you define
> maven.multiproject.includes
> in your project.properties/build.properties in your root project?
>
> It should looks something like
> maven.multiproject.includes=modules/moduleA/project.xml,modules/moduleB/project.xml,modules/moduleC/project.xml
>
> or if you want to save some characters:
> maven.multiproject.includes=modules/*/project.xml
>
> /Mikael
>
> Dan Pomohaci wrote:
>
> > Hello,
> >
> > My project have the following structure:
> > project - modules - moduleA
> > - moduleB
> > - moduleC
> > If I run "maven site" from every module the result is OK but if I run
> > from project "maven multiproject:site" the result is:
> >
> > --
> > maven-junit-report-plugin:register:
> >
> >
> > xdoc:generate-from-pom:
> > Generating xdocs from POM ...
> >
> > BUILD FAILED
> > File.. file:/local/share/maven/plugins/maven-multiproject-plugin-1.1/
> > Element... maven:reactor
> > Line.. 69
> > Column 7
> > Unable to obtain goal [site] --
> > file:/local/share/maven/plugins/maven-xdoc-plugin-1.4/:399:9:
> > null:-1:-1: It appears that no class was specified as the Uberspect.
> > Please ensure that all configuration information is correct.
> > --
> >
> > Any clue?
> >
> > Thanks,
> > Dan
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Mikael Lundgren, LeanOn AB, www.LeanOn.se
> Phone: +46 18 146405, Mobile: +46 703 400105
> Kontroll på projekt och tid: www.teamplanet.net
>
> -
> 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]
Réf. : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Why don't use SNAPSHOT version for your dependency and on a local server store the jar who can't be in ibiblio. It seem to be the way method to have latest version than storing them in CVS. With maven i think that lib don't have to be in CVS because it have a mechanism to find them automaticly. Nicolas [EMAIL PROTECTED] 11/12/2003 12:33 Veuillez répondre à "Maven Users List" Pour : Maven Users List <[EMAIL PROTECTED]> cc : Objet : The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ??? Hi all, I barely remember that somebody mentioned this subject but I can find the thread anymore. The subject is about how do we handle our dependencies, if they are stored in the CVS and every build gets a clean version of the whole project from CVS. (I use explicitly CVS to avoid the word repository that use later to refer to MAven repository). Let's say that any project contains a folder called: \lib where all the dependencies are stored and refered from project.xml. Any developer is asked to keep uptodate the libraries they are using. In my case, I have to kick off an external script to move all the libraries refered in the project.xml to the corresponding location in the Maven repository. This script is kicked off before I can run maven on the project. Maven will expect to find all the dependencies in project.xml in the maven repository. In previous projects, we used Maven central repository to store and provide all the dependencies and it was updated by a single person (project manager). If you wanted to get the latest version, you only needed to clean your local repository and maven retrieved them again from the central repository (remote repository). Now, the current project mandates to store the dependencies in CVS. I wonder whether the way I am currently handling the dependencies is the most appropiate way or whether there is other ones. Thank you Marcial Rosales - 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]
The Dependencies are stored in CVS : Preparing Maven Repository Beforehand ???
Hi all, I barely remember that somebody mentioned this subject but I can find the thread anymore. The subject is about how do we handle our dependencies, if they are stored in the CVS and every build gets a clean version of the whole project from CVS. (I use explicitly CVS to avoid the word repository that use later to refer to MAven repository). Let's say that any project contains a folder called: \lib where all the dependencies are stored and refered from project.xml. Any developer is asked to keep uptodate the libraries they are using. In my case, I have to kick off an external script to move all the libraries refered in the project.xml to the corresponding location in the Maven repository. This script is kicked off before I can run maven on the project. Maven will expect to find all the dependencies in project.xml in the maven repository. In previous projects, we used Maven central repository to store and provide all the dependencies and it was updated by a single person (project manager). If you wanted to get the latest version, you only needed to clean your local repository and maven retrieved them again from the central repository (remote repository). Now, the current project mandates to store the dependencies in CVS. I wonder whether the way I am currently handling the dependencies is the most appropiate way or whether there is other ones. Thank you Marcial Rosales - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How set maven.build.dest in project.xml ?
Hello,
I want to set the maven.build.dest to the 'build' value, when i do that
in a project.properties of each sun projects with :
maven.build.dest=${basedir}/build/ everything is find !
But i don't want to do that for all my sub-projects so i want to put
this property in the project.xml of my projects main project and
inherite it in my sub projects.
I put the lines :
build
in the root projetc.xml.
The other parameters (like dependencies, build for example) are well
inherited the properties seems not inherited. In the archive thread i
read it will be having problems for inheritance of properties in the
project.xml.
Does it work ? If yes what i have did wrong ?
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MAVEN_HOME and MAVEN_HOME_LOCAL
Glenn, Paul wrote:
Hi,
From what I understand, the location of the user's
repository no longer has anything to do with the
value of MAVEN_HOME (it's where the 'binaries'
are installed).
Yep - makes sense.
The repository is (by default) relative to the
new MAVEN_HOME_LOCAL (${MAVEN_HOME_LOCAL}/repository).
I think this can be overridden with the user's
build.properties (or other overrides), by setting
maven.repo.local to a value.
If MAVEN_HOME_LOCAL isn't set, it defaults
to '${HOME}/.maven'.
So putting it all together, if you don't set
anything, you get ${HOME}/.maven/repository
as the location of the repo.
I think what you really want to do is use
the value of maven.repo.local, rather than
derive it yourself. Is this outside of a plugin?
Yes. Can't assume the system property - but that's ok - based on what
your saying and my own digging the following logic should work fine:
private static String getMavenRoot()
{
String local =
System.getProperty(
"maven.home.local",
Env.getEnvVariable( "MAVEN_HOME_LOCAL" ) );
if( null != local ) return local;
return System.getProperty( "user.home" )
+ File.separator + ".maven";
}
Thanks for the feedback!
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/ |
||
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MavenTagLibrary class not found
Tim Chen wrote: I just did the same thing and didnt receive any errors. Are you sure you're using a clean copy of Maven? (Make sure to blow out the .maven directory as well in your user.home directory Thanks, I remove the .maven directory from my user home and it works ! Brice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MAVEN_HOME and MAVEN_HOME_LOCAL
Hi,
>From what I understand, the location of the user's
repository no longer has anything to do with the
value of MAVEN_HOME (it's where the 'binaries'
are installed).
The repository is (by default) relative to the
new MAVEN_HOME_LOCAL (${MAVEN_HOME_LOCAL}/repository).
I think this can be overridden with the user's
build.properties (or other overrides), by setting
maven.repo.local to a value.
If MAVEN_HOME_LOCAL isn't set, it defaults
to '${HOME}/.maven'.
So putting it all together, if you don't set
anything, you get ${HOME}/.maven/repository
as the location of the repo.
I think what you really want to do is use
the value of maven.repo.local, rather than
derive it yourself. Is this outside of a plugin?
Paul
-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 10:24 PM
To: Maven Users List
Subject: Re: MAVEN_HOME and MAVEN_HOME_LOCAL
Jason van Zyl wrote:
>On Wed, 2003-12-10 at 10:34, Stephen McConnell wrote:
>
>
>>Product: Maven 1.0-rc1
>>
>>MAVEN_HOME = /java/maven
>>MAVEN_HOME_LOCAL =
>>
>>During a build, it seems that Maven will ignore MAVEN_HOME when it copies
the
>>result to the repository cache. Instead it copies to ${user.home}/.maven
>>
>>
>
>First off, what are you trying to do exactly. I don't understand the
>sentence above.
>
When Nicols' invokes jar:install the resulting artifact is placed by
maven in the repository under ${user.home}/.maven. A unit test
associated with the build is pulling in resources from that repository -
but the code pulling is the resoruces is assuming that the repository is
a %MAVEN_HOME%/repository. What we need to confirm is the logic
resolution of the user's local repository based only on the availability
of the MAVEN_HOME and MAVEN_HOME_LOCAL environment variables.
Current assumptions are something like the following;
private static String getMavenHome()
{
String local =
System.getProperty(
"maven.home.local",
Env.getEnvVariable( "MAVEN_HOME_LOCAL" ) );
if( null != local ) return local;
String maven =
System.getProperty(
"maven.home",
Env.getEnvVariable( "MAVEN_HOME" ) );
if( null != maven ) return maven;
return System.getProperty( "user.home" ) + File.separator +
".maven";
}
However, Nocols' case suggests either the above assumptions are
incorrect or something strage is happening in maven.
>Are you talking about a jar:install type operation here?
>
Yes.
Stephen.
>
>
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/ |
||
-
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]
