Re: a newbie question
after few retry, I still can't get my sample project
to work. So I try to download another version of the
maven from apache.org (its version:maven-1.0-rc1).
beside, I found out it seemly has different setting
from maven-1.0-beta-7 (previously installed),
resulting in another error, in which it states
"NoClassDefFoundError:com/werken/forehead/Forehead".
What can I do, because I try to find werkz released
from http://werkz.codehaus.org/, yet none binary can
be found?
Or is there any missing part I may ingore, which
causes such problem? because I think it takes too long
to build werkz from home grown (e.g., what else if I
found another dependencies missed when building
werkz??) I simply new to maven and want to test an
sample. Would anyone have better idea or would like to
tell me where there's resources?
I appreciate it,
sincerely.
--- [EMAIL PROTECTED] 的訊息：> Hi -
>
> You need to have a local repository (created by
> setting $MAVEN_HOME and running
> $MAVEN_HOME/bin/install_repo.sh
> $HOME/.maven/repository, or something similar).
>
> I have a dial-up connection, and I encountered
> exactly the same "java.net.ConnectException"
> that you did. I solved the problem by connecting to
> my ISP and re-running the build. All
> of the necessary .jar files were copied to my local
> repository, and the build completed
> successfully. Moreover, I was able to do all
> subsequent builds completely off-line.
>
> Another option that might be of use to you is the
> "maven -o" (for "offline") command parameter.
>
> Hope that helps .. PSM
>
>
> -Original Message-
> From: <[EMAIL PROTECTED]>
> Sent: Jan 28, 2004 7:42 PM
> To: [EMAIL PROTECTED]
> Subject: a newbie question
>
> hi mavens,
> i'm new to maven project and after reviewing several
> tutorial, i found out it's a great tool for
> developer
> to weave into a project.
> however, when i learn to see how it gets to work
> (from
> example theserverside.com provides -
>
http://www.theserverside.com/articles/article.jsp?l=MavenMagic).
> i found out seemly it always try to get repository
> from remote through network with exception <[ERROR]
> java.net.ConnectException: Connection timed out:
> connect>.
>
> how to avoid that? or what command i need to type in
> order to compile code correctly (i type the command
> with "maven build-all"). for after review its
> source,
> it only contains some simple java file that needed
> to
> be compiled.
> the maven version is 1.0-beta-7
> i appreciate any suggestions.
> below is the maven.xml and project.xml
>
>
> xmlns:j="jelly:core"
> xmlns:maven="jelly:maven">
>
>
> includes="*/project.xml"
> goals="foobar-dist"
> banner="Building Foobar"
> ignoreFailures="false"/>
>
>
>
> --
>
>
>
> 3
> foobar-online
> Foobar-Travels
> 2.0
> Foobar Online Project
>
>
>
>
>
>
> Foobar Travels Inc.
> http://www.foobartravels.com
>
>
http://foobartravels.com/images/logo.gif
>
>
> 2003
> foobar.*
>
>
http://foobartravels.com/images/projectlogo.gif
> Foobar Online is Project to webify
> Foobar Travels
> Foobar Online is Project to
> webify Foobar Travels
>
>
>
>
>
http://bugzilla.foobartravels.com
> www.foobaronline.com
>
>
>
/foobar/dist/${pom.artifactId}/
>
>
>
>
>
>
>
>
>
> Srikanth Shenoy
> shenoy
> [EMAIL PROTECTED]
> Objectseek
>
> Java Developer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
[EMAIL PROTECTED]
>
>
${basedir}/src/java
>
>
${basedir}/src/test
>
>
>
> **/Test*.java
>
>
> **/*Test*All.java
>
>
>
>
>
>
>
>
> maven-checkstyle-plugin
>
>
>
> maven-changes-plugin
> maven-jdepend-plugin
> maven-checkstyle-plugin
> maven-pmd-plugin
> maven-junit-report-plugin
> maven-clover-plugin
> maven-changelog-plugin
> maven-file-activity-plugin
>
> maven-developer-activity-plugin
> maven-file-activity-plugin
> maven-license-plugin
>
=== message truncated ===
-
每天都 Yahoo!奇摩
海的顏色、風的氣息、愛你的溫度，盡在信紙底圖
http://tw.promo.yahoo.com/mail_premium/stationery.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Maven is a perfectly suited package management tool for its native language: Java. If you find some project which _happens_to_be_ built in a non-portable way, why not just throw up your own maven repository, and add a piece to the default build.properties, placing your repository first in the list to check for dependencies? You can then distribute this file with the distro in question, and everyone will be happy. I don't understand why it has to turn into such a ground-shifting change. While it's definitely not perfect, a very simple patch to maven (to remove the Base64 encoder dependency) will accommodate everything you've mentioned in your emails, Dalibor. -john On Wed, 2004-02-04 at 16:42, Jason van Zyl wrote: > On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote: > > > I fully understand that you have to prioritize your schedule to fix the > > bugs that affect the most users, like any other OSS project with limited > > ressources. > > > > But that clearly shows why Maven wouldn't make for a good software > > packaging mechanism to me: you'd have to settle for what works for most > > people. Now, what works for most people will not work for a minority. > > When they come to you to fix their problems you may not be able to, due > > to more pressing bugs on more popular platforms. I foresee a lot of > > 'Just use Sun - but Sun doesn't shine on my platform' flamewars down > > that road. > > I honestly don't get that riled up about it. I fight the fights I can > but I'm not going to spend my life battling Sun. I fight them by > choosing not to use their APIs where I can. As far as Maven goes you can > send us patches and we will apply them to make Maven work with Kaffe. I > personally don't care whether anyone uses Maven or not. Obviously I > would like it if they did but it's no skin off my back. You'll see from > any history of discussions that involve me that I'm not very dogmatic. > If Maven doesn't suit your needs, use whatever you like. > > > It's not very clear to me why you'd want to do the work of system > > integrators and distributors instead of spending that time improving > > Maven. > > I don't think you really understand what Maven is about. It's about > development in Java for Java developers. Platform OS packaging > mechanisms are irrelavent essentially. > > What you are asking of us is to relinquish control over the repository > that Maven users are accustomed to and hand that over to people making > packages for a specific OS. That simply isn't reasonable because that > immediately requires us to know about specific OS in order for Maven to > work the way it does now. That is just not going to happen. > > > Maybe you don't see a difference between software development, > > software distribution, and software management. I do, so let me try to > > explain it ;) > > > > When you look around at UNIX programs as they are shipped in Linux > > distributions, or BSDs, or commercial UNIX implementations, most of them > > are customized by the distributors in order to make them fit in better > > into the platform. Of course there is POSIX, but in the real world, > > still everyone feels the need to be able to make (often necessary) > > changes to produce a better package than the original developers did (or > > can do, in case of small platforms) and they often succeed. > > > > If I understood your arguments correctly, you seem to think that such > > platforms-specific adaptations are unnecessary with java applications > > and libraries. In my experience, that is not true, as soon as you move > > away from the setup the original developers used for developement and > > testing, even for java applications. The hidden, unwarrented assumptions > > only start to show where the code is used in an environment that breaks > > them. > > After many years of writing Java applications I have not found many > great difficulties running Java applications on different platforms. > Most problems have been with platform specific startup scripts. > > Maven having to deal with the innumerable inconsistencies of all the > existing package managers would make Maven nearly impossible to use in > my estimation and would lose all of what makes it attractive to use. > > I have honestly never used a JDK that comes in a package. I download the > JDK and use it in the same way on the different platforms I deploy the > application on. > > > >>Usually OS repositories can be rebuilt from source (if the license > > >>permits so). There is also the need to be rebuildable from source in > > >>order to apply bug fixes to the source code, or other patches. > > > > > > > > > Ok, I still don't see what stops you from using Maven to do this. Which > > > is what it's for and then use the packaging tool after Maven has done > > > its job. > > > > Nothing, if I understand your explanation about how Maven works correctly. > > > > The thing is, I'd like to (have Maven) pick up the platform specif
Re: new idea on maven usage?
I think the easiest solution to this problem is to make a better effort to test Maven (and all other Java programs) on a many JDKs as possible: Sun, IBM, Kaffe, etc. This effort would most likely come from users who have a vested interest in having the programs work on a specific platform, like BSD users. Trying to involve Maven in anything native just sounds like a disaster, and a basic misinterpretation of what Java is supposed to be about. If certain Java programs don't work on all platforms, then let's improve those programs -- instead of converting Maven into something else, letting some bad apples spoil the whole scene. I worked at a place where the admins kept telling us to put our jar files in /usr/local/lib. Most of the time we ignored them, but occasionally we couldn't and were forced to have our jars alongside billions of *.so files. My point is that Java is platform-less, and any attempt to make it different just seems sideways. While I'm sure that all Java code is not platform independent, I'd bet the farm that the vast majority of it is. And isn't that the reason that we're using Java in the first place? I'm confused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Checkstyle ClassCastException
It's caused by the execution of java:compile. So something like jar:install site probably won't work no matter where the report is. - Brett > -Original Message- > From: Sean Timm [mailto:[EMAIL PROTECTED] > Sent: Thursday, 5 February 2004 9:09 AM > To: Maven Users List > Subject: RE: Checkstyle ClassCastException > > > I got rid of this by placing my checkstyle report first in > the list...prior to this, jdepend was in front of it, and I > was seeing this issue. > > > -Original Message- > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 04, 2004 3:04 PM > > To: 'Maven Users List' > > Subject: RE: Checkstyle ClassCastException > > > > http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPCHECKSTYLE-16 > > > > I hope there is a better way to fix it, but I do remember > > these being taken out some time ago. > > > > - Brett > > > > > -Original Message- > > > From: Marcel Graber [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, 5 February 2004 8:53 AM > > > To: Maven Users List > > > Subject: Checkstyle ClassCastException > > > > > > > > > Hi , > > > > > > I did a new CVS checkout of the maven / maven_plugins > > stuff, and had > > > the problem, that Checkstyle only did ClassCastException > in "maven > > > site:generate" (with "maven checkstyle:report" it was ok) > > > > > > I have now added the following lines in all dependency in the > > > /maven-checkstyle-plugin-2.3-SNAPSHOT/project.xml and it seems to > > > work. > > > > > > > > > root > > > > > > perhaps a member of the checkstyle plugin can fix this? > > > > > > tnx, > > > marcel > > > > > > > > > > > > - > > > 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: Checkstyle ClassCastException
I got rid of this by placing my checkstyle report first in the list...prior to this, jdepend was in front of it, and I was seeing this issue. > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 04, 2004 3:04 PM > To: 'Maven Users List' > Subject: RE: Checkstyle ClassCastException > > http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPCHECKSTYLE-16 > > I hope there is a better way to fix it, but I do remember > these being taken out some time ago. > > - Brett > > > -Original Message- > > From: Marcel Graber [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 5 February 2004 8:53 AM > > To: Maven Users List > > Subject: Checkstyle ClassCastException > > > > > > Hi , > > > > I did a new CVS checkout of the maven / maven_plugins > stuff, and had > > the problem, that Checkstyle only did ClassCastException in "maven > > site:generate" (with "maven checkstyle:report" it was ok) > > > > I have now added the following lines in all dependency in the > > /maven-checkstyle-plugin-2.3-SNAPSHOT/project.xml and it seems to > > work. > > > > > > root > > > > perhaps a member of the checkstyle plugin can fix this? > > > > tnx, > > marcel > > > > > > > - > > 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: Checkstyle ClassCastException
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPCHECKSTYLE-16 I hope there is a better way to fix it, but I do remember these being taken out some time ago. - Brett > -Original Message- > From: Marcel Graber [mailto:[EMAIL PROTECTED] > Sent: Thursday, 5 February 2004 8:53 AM > To: Maven Users List > Subject: Checkstyle ClassCastException > > > Hi , > > I did a new CVS checkout of the maven / maven_plugins stuff, > and had the > problem, that Checkstyle only did ClassCastException in "maven > site:generate" (with "maven checkstyle:report" it was ok) > > I have now added the following lines in all dependency in the > /maven-checkstyle-plugin-2.3-SNAPSHOT/project.xml and it > seems to work. > > > root > > > perhaps a member of the checkstyle plugin can fix this? > > tnx, > marcel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Checkstyle ClassCastException
Hi , I did a new CVS checkout of the maven / maven_plugins stuff, and had the problem, that Checkstyle only did ClassCastException in "maven site:generate" (with "maven checkstyle:report" it was ok) I have now added the following lines in all dependency in the /maven-checkstyle-plugin-2.3-SNAPSHOT/project.xml and it seems to work. root perhaps a member of the checkstyle plugin can fix this? tnx, marcel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin For Nightly Builds?
No to SCM - for now. I don't know about cruise control. - Brett > -Original Message- > From: ami mehta [mailto:[EMAIL PROTECTED] > Sent: Thursday, 5 February 2004 2:31 AM > To: [EMAIL PROTECTED] > Subject: Plugin For Nightly Builds? > > > Hi, > > I went through the mailing list but i am yet not clear if scm plugin > supports subversion. Will the cruise-control work with subversion > > Thanks > -Ami > > _ > Scope out the new MSN Plus Internet Software - optimizes > dial-up to the max! >http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: new idea on maven usage?
On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote: > I fully understand that you have to prioritize your schedule to fix the > bugs that affect the most users, like any other OSS project with limited > ressources. > > But that clearly shows why Maven wouldn't make for a good software > packaging mechanism to me: you'd have to settle for what works for most > people. Now, what works for most people will not work for a minority. > When they come to you to fix their problems you may not be able to, due > to more pressing bugs on more popular platforms. I foresee a lot of > 'Just use Sun - but Sun doesn't shine on my platform' flamewars down > that road. I honestly don't get that riled up about it. I fight the fights I can but I'm not going to spend my life battling Sun. I fight them by choosing not to use their APIs where I can. As far as Maven goes you can send us patches and we will apply them to make Maven work with Kaffe. I personally don't care whether anyone uses Maven or not. Obviously I would like it if they did but it's no skin off my back. You'll see from any history of discussions that involve me that I'm not very dogmatic. If Maven doesn't suit your needs, use whatever you like. > It's not very clear to me why you'd want to do the work of system > integrators and distributors instead of spending that time improving > Maven. I don't think you really understand what Maven is about. It's about development in Java for Java developers. Platform OS packaging mechanisms are irrelavent essentially. What you are asking of us is to relinquish control over the repository that Maven users are accustomed to and hand that over to people making packages for a specific OS. That simply isn't reasonable because that immediately requires us to know about specific OS in order for Maven to work the way it does now. That is just not going to happen. > Maybe you don't see a difference between software development, > software distribution, and software management. I do, so let me try to > explain it ;) > > When you look around at UNIX programs as they are shipped in Linux > distributions, or BSDs, or commercial UNIX implementations, most of them > are customized by the distributors in order to make them fit in better > into the platform. Of course there is POSIX, but in the real world, > still everyone feels the need to be able to make (often necessary) > changes to produce a better package than the original developers did (or > can do, in case of small platforms) and they often succeed. > > If I understood your arguments correctly, you seem to think that such > platforms-specific adaptations are unnecessary with java applications > and libraries. In my experience, that is not true, as soon as you move > away from the setup the original developers used for developement and > testing, even for java applications. The hidden, unwarrented assumptions > only start to show where the code is used in an environment that breaks > them. After many years of writing Java applications I have not found many great difficulties running Java applications on different platforms. Most problems have been with platform specific startup scripts. Maven having to deal with the innumerable inconsistencies of all the existing package managers would make Maven nearly impossible to use in my estimation and would lose all of what makes it attractive to use. I have honestly never used a JDK that comes in a package. I download the JDK and use it in the same way on the different platforms I deploy the application on. > >>Usually OS repositories can be rebuilt from source (if the license > >>permits so). There is also the need to be rebuildable from source in > >>order to apply bug fixes to the source code, or other patches. > > > > > > Ok, I still don't see what stops you from using Maven to do this. Which > > is what it's for and then use the packaging tool after Maven has done > > its job. > > Nothing, if I understand your explanation about how Maven works correctly. > > The thing is, I'd like to (have Maven) pick up the platform specific > adaptations and fixes, instead of the generic binary/sources from the > upstream. I'd also like versioning of dependencies, integration with > native package management, etc. See for example > http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html > for a description of what a package management tool can do, and what the > design principles behind it are. I see Maven (or actually the POMs) as a > tool that might be useful in the package management of Java > applications, but not as replacement for native package management. We don't want native package management, that's the whole point I think you're missing here. We do not want to have to deal with the platform at all. There would be widespread, immediate and problems if Maven had to deal with platform specifics. How would you propose that we deal with the variances of every platform sp
Re: new idea on maven usage?
Hi John, John Casey wrote: being the BSD's and Debians of the world. The problem with BSD is that they don't even port the JVM quickly enough to be considered relevant. The BSDs are not supported by Sun. Sun's JDK code is not open source, so they are not allowed to just take it, port it and distribute it. Read the fine license of Sun's source code releases ;) I'll skip the flame-fest invitation of how relevant BSDs are. It doesn't matter if they are relevant to you, it matters if they are relevant to their users ;) If you don't consider them to be relevant, Maven can hardly claim to be truely 'cross-platform and just works out of the box'. More like 'cross-platform and just works out of the box (on a few selected platforms)' ;) Which is what I've been saying all along ;) If we tried to program strictly for BSD, we'd all still be stuck on JDK 1.3. As for Debian, from what I've heard it's a nice system, but you can't make sweeping, generalized statements about package managers when this is nearly the only relevant example. In short, the result of my experience with dependency management in most package management software has been increased blood pressure and (I'm sure) a shortened life span. Obviously, I'm no expert, but I believe I can take a fair crack at representing the masses. ;) Package management is not meant as a passtime for the masses, but to make the work easier for system administrators. ;) Debian is not the only nice system out there. I've heard very nice things about gentoo's 'source only' package management, for example. But this is not the proper forum to discuss package management systems. The thread is about using maven for package management, and I'm arguing that it's not suited for it. Is maven the right thing to use for managing native code? Probably not, at least by itself. Definitely not. It may be O.K. for whatever environment Maven developers decide to use, but it would fail horribly on others. Fetch GNU libtool, read the sources, and weep ;) Even building dynamic libraries in C and C++ is very painful and platform specific, don't get me started about managing different versions of dynamic native libraries on the same system. People are building Linux distributions for embedded systems that use uClibc insted of GNU libc. Maven would need to host all possible combinations of native-library * compiler-version * libc-type * libc-version and that's just for starters. I haven't even mentioned the different configuration flags available for native libraries at compile time. Down that centralized path lies insanity. ;) Does it have an appreciable advantage for most users over 99% of the dependency management field? OH, Hell yes. When 99% of the field has no dependency management at all (i.e. Windows), that's hardly that surprising, isn't it ? ;) I'd be interested in what Maven can offer that a native package manager (say dpkg) can not. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Jason, Jason van Zyl wrote: On Mon, 2004-02-02 at 10:39, Dalibor Topic wrote: Hi Jason, thanks a lot for taking the time to reply so quickly. Compliancy to JDK APIs is a seal of approval given out by Sun for passing the TCK. Since the TCK is not available under a free software or open source license, it's hard for free implementations to claim compatibility with JDK APIs, without risking to get sued anyway. ;) They are available to OSS projects, we have licenses for many of them here at Apache. The folks working on it here have worked long and hard to get them for us but I'm sure you too can gain access to them. As far as I can see it as an outsider, Apache is in a somewhat special love-hate relationship with Sun. Neverthless, Apache members have done a lot to open the process up, and that's great. But its still impossible for an OSS project to get a copy of the JDK 1.4.2 TCK, under non-discriminating terms, for example. If you have information to the contrary, I'd be glad to hear about it. I don't think many people use sun.* packages. What's in Maven is vestigal and can certainly be fixed. I actually fixed it in the component based version of Maven last night when you mentioned it in your post. Great! Thank you very much! I don't see any comments from you on http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129 though, so maybe we should discuss the fix there. Dion explained that my fix broke the bootstrap, so I assume yours doesn't ;) Send me an e-mail when it's in the CVS so that I can give it a go on kaffe. Unfortunately, in my experience, I see a lot of code using sun.* packages. For example, taking the freshly released ant 1.6.1 beta 1: bash-2.05a$ grep -r import . | grep sun ./src/main/org/apache/tools/ant/taskdefs/email/UUMailer.java:import sun.misc.UUEncoder; ./src/main/org/apache/tools/ant/taskdefs/optional/image/Image.java:import com.sun.media.jai.codec.FileSeekableStream; I can't say how many projects have this sort of problems, but from my experience in getting software to run on kaffe, there is a lot of unportable java code written by programmers not aware of their assumptions out there. I'm currently involved with an effort to clean up OpenOffice, and it's no fun. In fact, some Linux distributions ship OpenOffice with Java code disabled or ripped out, since it's so heavily tied to Sun's JVM. My most interesting problem with Maven and Kaffe combo so far was the tools.jar reference in the forehead.conf file, as maven-1.0rc1 wouldn't start up with it. Since Sun's tools.jar is distributed under a very restrictive license, Kaffe (and other free runtimes) can't ship it, so that any code which wants to mess with tools.jar is bound to fail. This is certainly something we can fix, but you have to keep in mind that 99% of folks are going to download a Sun or IBM JDK and consequently won't have that problem. There aren't many people more into OSS then I am but you have to pragmatic about these things. You have a simple patch I believe for the tools.jar problem so no biggie but ultimately we only have so much time and will more than likely focus on general usage patterns which unfortunately rarely includes Kaffe. I fully understand that you have to prioritize your schedule to fix the bugs that affect the most users, like any other OSS project with limited ressources. But that clearly shows why Maven wouldn't make for a good software packaging mechanism to me: you'd have to settle for what works for most people. Now, what works for most people will not work for a minority. When they come to you to fix their problems you may not be able to, due to more pressing bugs on more popular platforms. I foresee a lot of 'Just use Sun - but Sun doesn't shine on my platform' flamewars down that road. It's not very clear to me why you'd want to do the work of system integrators and distributors instead of spending that time improving Maven. Maybe you don't see a difference between software development, software distribution, and software management. I do, so let me try to explain it ;) When you look around at UNIX programs as they are shipped in Linux distributions, or BSDs, or commercial UNIX implementations, most of them are customized by the distributors in order to make them fit in better into the platform. Of course there is POSIX, but in the real world, still everyone feels the need to be able to make (often necessary) changes to produce a better package than the original developers did (or can do, in case of small platforms) and they often succeed. If I understood your arguments correctly, you seem to think that such platforms-specific adaptations are unnecessary with java applications and libraries. In my experience, that is not true, as soon as you move away from the setup the original developers used for developement and testing, even for java applications. The hidden, unwarrented assumptions only start to show where the code is us
Question about scm:checkout-project goal
I'm interested in extending this to support Perforce but before I go down that road I have a question... If I do 'maven scm:checkout-project build-my-project' and the result of scm:checkout-project is to checkout a new project.xml and/or maven.xml and/or project.properties will the subsequent build-my-project goal see the new values of those files? Obviously I can do 'maven scm:checkout-project && maven build-my-project' and see the changes but that's not quite as elegant. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS NT Repo
Thanks to everyone that offered a solution :) This one works with my default cvs checkout as well so I used it instead of using the pipe | approach which worked just as well for the reports. Thanks again :) -Tim Cuong Tran wrote: Try this: /d//CVSREPO --- Tim Chen <[EMAIL PROTECTED]> wrote: Stupid CVS NT Repos have connection strings such as: [EMAIL PROTECTED]:d:/CVSREPO This causes report errors: BUILD FAILED File.. file:/C:/Documents and Settings/chengt/.maven/plugins/maven-multiproject-plugin-1.1/ Element... maven:reactor Line.. 69 Column 7 Unable to obtain goal [site] -- file:/C:/Documents and Settings/chengt/.maven/plugins/maven-xdoc-plugin-1.4/:399:9: Invocation of method 'getCvsRoot' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains more than six tokens Total time: 23 seconds Finished at: Tue Feb 03 14:55:30 EST 2004 Anyone have a way around this? Anyone using cvs nt? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - 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: aspectj includes
I've been trying. Its tricky stuff. I'll try looking into the jar plugin to see how it reads the and try to copy that to the aspectj plugin. Oh yeah, with MavenNG, will it still use maven.xml - since maven.xml is jelly based and MavenNG does not seem to be using jelly? Just wondering where I should invest my efforts. :) Charlie Vincent Massol wrote: Hi Charles, The current version of the aspectj plugin does not support copying resource files. If you have time, please submit a patch :-) Thanks -Vincent -Original Message- From: Charles N. Harvey III [mailto:[EMAIL PROTECTED] Sent: 02 February 2004 17:20 To: Maven Users List Subject: aspectj includes Hello. 'Nother aspectj question that probably can't be answered, but I will ask anyway. How can I include *.properties or *.xml files in my aspected jar? No matter what I seem to do my static files are never copied over into the jar. Which, of course, makes my app fail. It even strips them out when I do . The original jar has properties files but the new aspected one does not. Pretty frustrating. Any tips would be much appreciated. Thanks. Charlie - 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: cvs checkout of multiple subprojects [newbie]
OK, I took a look, thanks for the pointer. Yes, I also decided to use an external script for initial checkout of the other Maven build files grouped in a module in CVSROOT/modules. But to retain platform independence, it is also a maven subproject (albeit very simple). So one needs to checkout this "bootstrapping" project first (or copy it from somewhere), and then run checkout to get all Maven build files (including the latest copy of itself). This is how our Ant build also works, BTW. Rgs, -- Svetlin Jeffrey Bonevich wrote: For mevenide we are using a simple shell/batch script that does all the checkout and then runs maven to build; not using maven per se to do this initial stuff. I believe there is also a bootstrap concept for maven install that you might be able to adapt, but have not dealt with this. For the script way, check out http://mevenide.sourceforge.net jeff Svetlin Stanchev wrote: Hi, I am trying to enhance/replace our Ant build with Maven. But I am unable to find the answer or a good practice for a seemingly basic activity: How can I perform a cvs checkout from scratch of multiple (>20) projects, including their project.xmls starting from the upper/top level project.xml? I can't use the reactor as the subordinate directories are not created and populated at the very beginning. It is my understanding per project only one module could be checked out with (i.e. I can't specify multiple modules to be checked out). Moreover, after inspection plugin.jelly for scm:checkout-project seems to first delete the directory with the checked-out module (if any), so any kind of "bootstrapping" (creating the directories and then somehow generating or checking-out and copying the individual project.xmls) would not work either. Is the only way to go to write a pre/postGoal ant task in the top-level maven.xml or there is something better? Why am I not able to find an example how to do this, is this considered such a rare task or I am missing something? I am really confused here. Thanks for any help, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugin For Nightly Builds?
Hi, I went through the mailing list but i am yet not clear if scm plugin supports subversion. Will the cruise-control work with subversion Thanks -Ami _ Scope out the new MSN Plus Internet Software optimizes dial-up to the max! http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/ /OREF:CPT2D44A method getScmType threw exception class java.lang.StringIndexOutOfBoundsException: Any idea why?
Hi All, I ran "maven site:generate" for my project and got the below exception. Could anyone give me a clue as to what might be wrong. Thanks, --Alen ... ... ... xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. file:/root/.maven/plugins/maven-xdoc-plugin-1.4/ Element... velocity:merge Line.. 399 Column 9 Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.StringIndexOutOfBoundsException : String index out of range: -5 com.werken.werkz.UnattainableGoalException: Unable to obtain goal [site] -- file:/root/.maven/plugins/maven-xdoc-plugin-1.4/:399:9: Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.StringIndexOutOfBoundsException : String index out of range: -5 at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:348) at org.apache.maven.cli.App.doMain(App.java:543) at org.apache.maven.cli.App.main(App.java:1109) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: file:/root/.maven/plugins/maven-xdoc-plugin-1.4/:399:9: Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.StringIndexOutOfBoundsException : String index out of range: -5 at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:239) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java(Compiled Code)) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java(Compiled Code)) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java(Compiled Code)) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java(Compiled Code)) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java(Compiled Code)) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:448) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:348) at org.apache.maven.cli.App.doMain(App.java:543) at org.apache.maven.cli.App.main(App.java:1109) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Root cause org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getScmType' in class org.apache.maven.project.Repository threw exception class java.lang.StringIndexOutOfBoundsException : String index out of range: -5 at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:309) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java(Compiled Code)) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:357) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:135) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java(Compiled Code)) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:109)
Problems with https maven remote repo
Hi, We have recently moved our in-house maven remote repo to sit behind https and a server-side certificate. Since then I've been trying to get artifact downloading to work again. I've added our server-side SSL certificate to the truststore of the relevant JVM but maven (rc1 on windows, jdk 1.4.2_03) keeps failing with a "java.net.ConnectException: Connection refused" message. I've written a quick unit test that does exactly the same thing as the Maven HttpUtils class. This test runs fine and the artifact gets downloaded. Then I changed the unit test to explicitly call the maven HttpUtils.getFile() method. This also went fine. If I turn on SSL tracing, I can see that the local truststore is found and that it contains the correct certificate. But when running maven from the command line, instead of initiating the SSL handshake process, it stops after veryfying the truststore and throws the "java.net.ConnectException: Connection refused" exception. Does anyone know what could influence the behaviour of HttpUtils when called from withing maven ? Has anyone seen this behaviour before ? Regards, Age - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling cyclic dependencies
> On Tue, 03 Feb 2004 20:09:25 -0500, "Parsons, David" <[EMAIL PROTECTED]> said: >> Parsons, David wrote: >Using these dependencies, I have succeeded >> in getting the maven reactor >to build the jars in the correct >> order, i.e. B-interface; A; B-impl. >In order to do so, however, I >> had to suppress the unit tests for >component A from running. This >> is because they require that the B-impl >classes be on the >> classpath, which is not described in the dependencies >(and cannot >> be, since that would reintroduce a cycle). >> >> David, >> >> since you're testing A, B-impl shouldnot be required for those >> tests. so cannot you use some dummy implementations of your >> interfaces or some kind of simple mocks ? >> >> -- gd > You're right. In this example I was really misusing the unit > testing feature of maven to do a cross-component functional test. > Instead, we've decided to write custom goals for our functional > tests, and restrict unit tests to single components by using mocks > or whatnot. Yes, this is what I attempt to do also. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
checkstyle for test sources
I want my unit test sources to look as nice as my actual source files. Is it possible to run checkstyle to check the test sources as well? I haven't found a property for the checkstyle-plugin to configure the path to look for source files (just the includes/excludes properties). Thanks, Holger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/ /OREF:CPT838AD Re: Checkout project
Hi Martin, Thanks for your reply. However, I still have a problem and that is, where do I define the CVS host, username, etc.? In my project.xml file I have repository connection settings to connect to NT CVS: scm|cvs|pserver|[EMAIL PROTECTED]|/d//cvs|RBookings Now I suppose I would use "scm:checkout-project" to perform the checkout but that complains about CVSROOT var not being set. What do I set the CVSROOT var to when the cvs root is on another server? Any help pls... thx, --Alen [EMAIL PROTECTED] 02/04/2004 02:58 PM To [EMAIL PROTECTED] cc Please respond to [EMAIL PROTECTED] Subject g Re: / /OREF:CPT63B20 Checkout project Hi Alex Take a look at the SCM Plugin: http://maven.apache.org/reference/plugins/scm/ It's used for Sourcecontrol access. >>---> Martin On Wed, 4 Feb 2004 [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: / /OREF:CPT63B20 Checkout project > Date: Wed, 4 Feb 2004 14:49:09 +0200 > X-mailer: Lotus Notes Release 6.0.1CF3 July 29, 2003 > > > > > > How do I issue a checkout command for CVS in Maven? (wish do checkout > project from CVS to some local dir.) > > Thx, > --Alen > > > > - > 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: Using CVS via Maven
Do you search this : http://maven.apache.org/reference/plugins/scm/goals.html ?? Arnaud -Message d'origine- De : Arnaud Heritier [mailto:[EMAIL PROTECTED] Envoyé : mercredi 4 février 2004 00:57 À : 'Maven Users List'; [EMAIL PROTECTED] Objet : RE: Using CVS via Maven You must configure the repository element. http://maven.apache.org/reference/project-descriptor.html#repository Arnaud > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 4 février 2004 00:24 > À : [EMAIL PROTECTED] > Objet : Using CVS via Maven > > Hi, could someone point me to reference docs on how to use CVS via Maven? > I would like to setup the project.xml with the required information. > > Thanks in advance, > > -Conrad > > > > > - > 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: / /OREF:CPT63B20 Checkout project
Hi Alex Take a look at the SCM Plugin: http://maven.apache.org/reference/plugins/scm/ It's used for Sourcecontrol access. >>---> Martin On Wed, 4 Feb 2004 [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: / /OREF:CPT63B20 Checkout project > Date: Wed, 4 Feb 2004 14:49:09 +0200 > X-mailer: Lotus Notes Release 6.0.1CF3 July 29, 2003 > > > > > > How do I issue a checkout command for CVS in Maven? (wish do checkout > project from CVS to some local dir.) > > Thx, > --Alen > > > > - > 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: User input for Continuum
On Thu, Jan 15, 2004 at 09:56:49PM -0500, Jason van Zyl wrote: > Howdy, > > I have Continuum up and running using the new maven-scm stuff and the > new maven components so I wanted to get some input on how people would > like to use it. All the information required for checking out and > building are contained within the POM so how would you like to be able > to use Continuum? By this I mean how would you like to be able to > register projects to be built? > > Some ideas might be: > > o little server component which listens and just takes an url or a path > to a POM. > > o xmlrpc to hand off an url or path, this would be handy for non-java > clients. We have Pete Kazmiers nice little Pythong xml-rpc utils that we > could distribute. > > o web interface to register an url or path > > I figure Continuum would come up raw and await instructions for a build. > > I am also using the nagEmailAddress to send notification messages right > now. Anything is possible as there are Java libraries for Jabber, IRC or > whatever but for now the notification goes to the nag address. > > Figured I would take a little input, incorporate the ideas and then I'll > throw it out as a little alpha for people to try. Howdy, I've been using Maven till beta4 and I'm anxious to finally see Continuum. We currently use a recent Maven with a very tiny patch which reports in a variable the success or failure of build, test build and test results. Then, we use the reactor along with a small velocity page to display the result. The complete build/test is run every few hours. That is far from ideal, and it would be way better to recompile only the needed modules only when a commit occur (I believe that's what continuum does). Anyway, my 2 cents regarding your question would be: there should probably be a CLI for registering/unregistrering projects to build. For a million+ LOC project with hundreds of artefacts, each with several versions, you don't want to have only a WEB interface unless maybe it is sophisticated enough to be configured once for all at the beginning. By the way, is there any place where I can find the features that the first version of continuum will have (or should I just wait for the alpha?). -- Julien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/ /OREF:CPT63B20 Checkout project
How do I issue a checkout command for CVS in Maven? (wish do checkout project from CVS to some local dir.) Thx, --Alen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Local Repository synchronization problem
Dear community, I am using maven since some time and though I was ant supporter I should say that you managed to convince me to use it. Since some time, I am having a problem of synchronization between my remote (privately defined repository and the local one. here is an extract of the property file: maven.home=D:\Temp\maven-1.0-rc1 maven.repo.remote.enabled=true maven.repo.remote= http://myprivate:8080/maven/ix/ , http://www.ibiblio.org/maven now in that private remote repository I have published my service in a form of a jar -->test jars myservice-1.0.jar it was all working fine till when I erased the file from my local repository . the consequent build realized that the jar was no longer there, and started downloading it again , but this time instead of the real one I get something strange in my local repository : -->test jars myservice-1.0.jar myservice-1.0.jar.md5 where those files are nothing else than the xml catalog of the ibiblio/maven repository . here is (See attached file: myservice-1.0.jar) I find all that a bit strange has any of the community faced something similiar .. Any help is welcome Regards Michele Forte This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: / /OREF:CPT95AB9 Project>Dependecies Newbie question
I don't see why removing this restriction compromises project guidelines, it just allows for more flexibility when setting those guidelines. Stan -Original Message- From: Rafal Krzewski [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 11:00 AM To: Maven Users List Subject: Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question [EMAIL PROTECTED] wrote: > I actually consider this an unnecessary restriction. You should be > able to specify dependencies without forcing a naming convention > where version numbers are applied. You can use the .properties files > to get round this but you lose the inheritance benefits , I believe > (is this changing in later versions) Flexibility is important. Maven project is about setting guidelines for project development. A project that conforms to those guidelines is easy to comprehend and maintain. The Maven build tool is an important secondary pupropse. It helps to develop projects that conform to the guidelines. If you don't want to use the guidelines, but still use the build tool - you are on your own. R. - 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]
/ /OREF:CPT7CF94 Check project out of repository
Hi All,
I'm not 100% sure if this is even possible to do...
In short...
I would like Maven to checkout a project for me from another server
and then run the instructions in my project.xml file against the
checked out code.
More...
I would like Maven to checkout my project from CVS repository into
directory /blabla/projects/rbookings/.
Directory /blabla/projects/rbookings/ contains my project.xml file
that I wish to run.Repository is on another server running NT CVS.
I'm not to sure about the syntax for the connection to NT CVS.
We use pserver as CVS protocol.
All I have defined so far is the in my project.xml file
that looks something like this:
scm|cvs|pserver|[EMAIL PROTECTED]|d:
\cvs\Projects\ReeferBookings
scm|cvs|pserver|${maven.username}
@myserver|d:\cvs\Projects\ReeferBookings
Response I got was:
"repository connection string contains less than six tokens"
Any ideas?
Regards,
--Alen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question
[EMAIL PROTECTED] wrote: > I actually consider this an unnecessary restriction. You should be > able to specify dependencies without forcing a naming convention > where version numbers are applied. You can use the .properties files > to get round this but you lose the inheritance benefits , I believe > (is this changing in later versions) Flexibility is important. Maven project is about setting guidelines for project development. A project that conforms to those guidelines is easy to comprehend and maintain. The Maven build tool is an important secondary pupropse. It helps to develop projects that conform to the guidelines. If you don't want to use the guidelines, but still use the build tool - you are on your own. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question
> In Maven, every artifact in the repository has a > version. Trying to > circumvert that will give you more headache that it > is worth. > Certain artifact are have their versions removed > when they are copied > out of the repository, but this is really an > uncommon case. > OTOH project dependencies always specify a version. > Your options where > are: just give your artifact an arbitrary version > tag (1.0 seems a nice > choice), or use the special tag SNAPSHOT. You still can use jar override feature to include jar from some obscure location or even withouot version number ( like something coming from sun :) regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: / /OREF:CPT95AB9 Project>Dependecies Newbie question
I actually consider this an unnecessary restriction. You should be able to specify dependencies without forcing a naming convention where version numbers are applied. You can use the .properties files to get round this but you lose the inheritance benefits , I believe (is this changing in later versions) Flexibility is important. Regards Stan -Original Message- From: Rafal Krzewski [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 10:04 AM To: Maven Users List Subject: Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question [EMAIL PROTECTED] wrote: > Is the following snippet a valid dependency? > > > sailing-schedules > SailingSchedulesUtils > > > For this dependency, I will not be providing an artifact version. > So I wish to define the jar file name that resides in > $MAVEN_REP/sailing-schedules/jars/ named SailingSchedulesUtils.jar > as apose to something like this: In Maven, every artifact in the repository has a version. Trying to circumvert that will give you more headache that it is worth. Certain artifact are have their versions removed when they are copied out of the repository, but this is really an uncommon case. OTOH project dependencies always specify a version. Your options where are: just give your artifact an arbitrary version tag (1.0 seems a nice choice), or use the special tag SNAPSHOT. R. - 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: / /OREF:CPT95AB9 Project>Dependecies Newbie question
[EMAIL PROTECTED] wrote: > Is the following snippet a valid dependency? > > > sailing-schedules > SailingSchedulesUtils > > > For this dependency, I will not be providing an artifact version. > So I wish to define the jar file name that resides in > $MAVEN_REP/sailing-schedules/jars/ named SailingSchedulesUtils.jar > as apose to something like this: In Maven, every artifact in the repository has a version. Trying to circumvert that will give you more headache that it is worth. Certain artifact are have their versions removed when they are copied out of the repository, but this is really an uncommon case. OTOH project dependencies always specify a version. Your options where are: just give your artifact an arbitrary version tag (1.0 seems a nice choice), or use the special tag SNAPSHOT. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2nd edition] MAVEN dependencies' mechanism
>> But if you consider the URL provided in project.properties
>> (maven.repo.remote) in place of "The url of the dependency's homepage",
the
>> mechanism works as described bellow and my questions remain the same.
> Which questions?
Initially, my questions were :
1. To be a quite more generic (not only java/binary oriented), is there a
way to define other formats available for automatic download+expand with
the
attribute. I mean Is there a way to define dependency as a
DEPEND-1.0.tar or, mostly appreciated, as a PLUGIN-1.0.[tar|bz2|tgz|...].
I tried something which works (download in
$MAVEN_HOME_LOCAL/repository/something/jars/DEPEND-1.0.jar) but I lost the
"precious" automatic expand functionnality of the plugin...
2. Should the dependencies be specific of a particular goal in maven.xml.
With these pre-requisites, it should become coarse to distribute specific
data and made its available (question 1.) on demand (question 2.)
And it's related to :
>> I think that :
>> - "The url of the dependency's homepage" is a bit confusing (but I
didn't
> Got a suggestion for a better description? We'll use it.
This kind of output is confusing (not the description itself) :
| Attempting to download .
| WARNING: Failed to download .
| The build cannot continue because of the following unsatisfied
dependency:
| ()
An URL appears but it's inaccurate with the error.
A "maven -X " should at least output the full url (done with a
java.net.ConnectException) :
| Attempting to download .
| Error retrieving artifact from []: java.net.ConnectException:
| Connection refused
| WARNING: Failed to download .
| The build cannot continue because of the following unsatisfied
dependency:
...
>> - an extended download mechanism should be very usefull because the
>> existing one is spread accross tags as - or
and
>> , confusing in the file-type/extension and the download
>> mechanism (just *download* for or foo and
>> *download+expand* for plugin) in different locations (local
>> directories like $MAVEN_HOME_LOCAL/plugins or
>> $MAVEN_HOME_LOCAL/repository). An additionnal tag (and probably
optionnal
>> like ) could allow to clarify the expected extension.
> There already is a ???
Yes but it's not precise enough to give a generic way to automatically
download _and_ expand artifacts with different file types than .jar.
An additionnal tag could clarify this file type.
Olivier Champagne
(\(\ "Regular Expression
( ~.) are to strings what
o((")(") math is to numbers"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: aspectj includes
Hi Charles, The current version of the aspectj plugin does not support copying resource files. If you have time, please submit a patch :-) Thanks -Vincent > -Original Message- > From: Charles N. Harvey III [mailto:[EMAIL PROTECTED] > Sent: 02 February 2004 17:20 > To: Maven Users List > Subject: aspectj includes > > Hello. > 'Nother aspectj question that probably can't be answered, but I will > ask anyway. How can I include *.properties or *.xml files in my > aspected jar? No matter what I seem to do my static files are never > copied over into the jar. Which, of course, makes my app fail. > > It even strips them out when I do . The original jar has > properties files but the new aspected one does not. Pretty frustrating. > > Any tips would be much appreciated. > > Thanks. > > > Charlie > > > - > 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: Using mutliple testSourceDirs
Hi Jason, > For my projects I put each of those things in a separate project. I > leave unit tests with their component and the other various kinds of > testing in other projects that depend on the component. Don't try and > circumvent the one test source directory. Take the time and partition > your code and you'll be glad you did in the long run. I want to avoid it to outwit maven. :) How do you handle it with database tests e.g I have a facade for persitence described with interfaces. So would you create seperate the interfaces into a own JAR, then a Mock-Impl-JAR and a Real-Impl JAR? Bye Toby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
