Re: continuous integration server
i know that spring uses bamboo for it's builds and i can't remember the last time that i've actually seen it work... http://build.springframework.org:8085/ On Tue, Apr 15, 2008 at 10:44 AM, Matthew Tordoff [EMAIL PROTECTED] wrote: Has anyone looked at Bamboo? -Original Message- From: Tom Huybrechts [mailto:[EMAIL PROTECTED] Sent: 13 April 2008 13:21 To: Maven Users List Subject: Re: continuous integration server Hudson, without a doubt. See https://hudson.dev.java.net/ or a live instance at http://hudson.jboss.org/hudson/ On Sun, Apr 13, 2008 at 1:36 PM, Peter Horlock [EMAIL PROTECTED] wrote: Hi, Which continuous integration server would you recommend me? Continuum? Or is there also a version by sonatype in the making?! :-) Thanks in advance, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The content of this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient and may not be disclosed, copied or distributed. If you received this email in error, please contact the sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete it and do not disclose its contents to any person. You should take full responsibility for checking this email for viruses. Markit reserves the right to monitor all e-mail communications through its network. Markit and its affiliated companies make no warranty as to the accuracy or completeness of any information contained in this message and hereby exclude any liability of any kind for the information contained herein. Any opinions expressed in this message are those of the author and do not necessarily reflect the opinions of Markit. For full details about Markit, its offerings and legal terms and conditions, please see Markit's website at http://www.markit.com http://www.markit.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ i kno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuous integration server
@Liz Just out of curiosity, why would you want to be running multiple instances? On Tue, Apr 15, 2008 at 12:13 PM, Sommers, Elizabeth [EMAIL PROTECTED] wrote: I use Vulcan. I like the fact that I can run multiple instances of it in the same tomcat. It also does everything I need in a CI server. http://code.google.com/p/vulcan/ Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Super POM location
actually, it does exist. if you look in the maven uber jar it's under org.apache.maven.project On Fri, Feb 15, 2008 at 10:30 AM, [EMAIL PROTECTED] wrote: I think the super-pom is the name for the concept of default settings and there is no actual super pom. The normal solution for your problem would be to create a corporate/company pom and let all projects add it as their parent. Hth, Nick S. -Original Message- From: Marcelo Alcantara [mailto:[EMAIL PROTECTED] Sent: Fri 2/15/2008 17:26 To: users@maven.apache.org Subject: Super POM location Hi, I searched a lot in the Internet but could not find this answer. Where is the super pom located? I have configurations that are for all projects that I wanted to setup in it. Thanks in advance. -- Marcelo Alcantara Senior Developer/Architect [EMAIL PROTECTED] +55 11 81968823 -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing files for site generation
between one build and the next, maven is suddenly failing to copy maven-base.css, print.css, site.css, and maven-feather.png. does anyone have any idea why this might be? there's nothing in the output with or without -X. i'm at a loss. -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype structure?
I'd previously gotten this sort of thing to work by setting up the archetype to look like: .../archetype-resources/src/main/java/sub In your case sub would be dao, model, etc. I'd had some problems with early versions of the archetype plugin, but as long as you're using 1.0-alpha-4 or later, it should work. Finally, I've heard great things about how the new version of the archetype plugin is shaping up. So, it might be worth investigating because the setup effort is supposed to be greatly reduced. On 9/5/07, Michael Griffith [EMAIL PROTECTED] wrote: I wish to create my own archetype for Maven2, admittedly I am a nOOb, and this seems way more difficult than it should be. I want my directory structure to be: src-- com.mycompany.project.dao com.mycompany.project.dao.hibernate com.mycompany.project.model com.mycompany.project.service com.mycompany.project.service.impl com.mycompany.project.util com.mycompany.project.web test-- com.mycompany.project.dao com.mycompany.project.dao.hibernate com.mycompany.project.model com.mycompany.project.service com.mycompany.project.service.impl com.mycompany.project.util com.mycompany.project.web I've read the web examples on the Maven2 site, and downloaded the Maven 2 book, but it still is not clear to me how to set this up. I can't seem to get my archetype template correct. Any shove in the right direction would be much appreciated! Thanks in advance... Best Regards, MG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hudson
I've used hudson and have been very happy with it. In my opinion, the biggest advantage over other CI servers is the ridiculously quick turn-around on bug fixes and requested enhancements. Kohsuke pushes out releases faster than anyone I've ever seen... On 7/6/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/6/07, Milos Kleint [EMAIL PROTECTED] wrote: Like define a unique local repo for the project, to prevent local repository cross-pollination by other maven projects built on the same machine. FWIW, I haven't tried it yet, but you should be able to do that fairly easily with Continuum by adding -Dmaven.repo.local=/path/to/separate/repo to the arguments. Or even -s /path/to/alt-settings.xml if you want completely different settings. (I went through an exercise recently trying to figure out how to make sure official builds don't use anything in the 'sandbox' repository, but only the approved third-party artifacts.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tools.jar dependency and MacOSX
The deal is that tools.jar is in classes.jar (i think) and is always on the classpath. If you just exclude the dependency it should work. On 6/11/07, Nathan Maves [EMAIL PROTECTED] wrote: What causes your project to have a dependency on tools.jar? I have been using maven on a mac for a while now and have never had to deal with the tools.jar. Nathan On 6/11/07, Jerome Thibaud [EMAIL PROTECTED] wrote: Hi All, Discovering the joy of coding Java in a Mac environment I learned that there is no tools.jar in the Mac version of the JDK. Consequence is, my projects having dependencies on tools.jar fail to build. So for the project with a direct dependency, I used Profile successfully. I created one profile triggered by the OS family and everything went smooth. Now I got 2 problems: - it seems that, when inherited through transitive dependency, the profile trigger is not taken into account and tools.jar is added to the dependencies list anyway. - I got an ant plugin setup in the build section with tools.jar in the dependencies section of the plugin. What do I use to make the dependency conditional there? thanks in advance Jerome -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tools.jar dependency and MacOSX
put it in a profile with os activation On 6/11/07, Jerome Thibaud [EMAIL PROTECTED] wrote: The symbolic link sounds like a nice trick, I'll try that. In the meantime, I was expecting something more mainstream. Also you guys realize that If i remove the dependency to tools.jar, my build will work on Mac but will stop working on Windows and Linux. rgds JT On 6/11/07, Nathan Maves [EMAIL PROTECTED] wrote: I agree with Gregory, I would remove the dependency all-together. Everything should just work. On 6/11/07, Gregory Kick [EMAIL PROTECTED] wrote: The deal is that tools.jar is in classes.jar (i think) and is always on the classpath. If you just exclude the dependency it should work. On 6/11/07, Nathan Maves [EMAIL PROTECTED] wrote: What causes your project to have a dependency on tools.jar? I have been using maven on a mac for a while now and have never had to deal with the tools.jar. Nathan On 6/11/07, Jerome Thibaud [EMAIL PROTECTED] wrote: Hi All, Discovering the joy of coding Java in a Mac environment I learned that there is no tools.jar in the Mac version of the JDK. Consequence is, my projects having dependencies on tools.jar fail to build. So for the project with a direct dependency, I used Profile successfully. I created one profile triggered by the OS family and everything went smooth. Now I got 2 problems: - it seems that, when inherited through transitive dependency, the profile trigger is not taken into account and tools.jar is added to the dependencies list anyway. - I got an ant plugin setup in the build section with tools.jarin the dependencies section of the plugin. What do I use to make the dependency conditional there? thanks in advance Jerome -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need testSourceDirectory to come before dependencies on classpath during surefire run
if it looks like a hack, sounds like a hack, smells like a hack... what's your specific use case for this? it seems like you'd probably be better off with a design change than relying on classpath ordering. On 5/23/07, Steven Cummings [EMAIL PROTECTED] wrote: Hello, I looked in the archives before posting and the closest thing I could find to my particular situation is all of the messages surrounding http://jira.codehaus.org/browse/MNG-1412 (the ordering of the dependencies on the classpath). I need a specific class to hide another that is in a needed dependency and control this ordering. Unlike with the previous discussion, my preferred version lives in the testSourceDirectory. When I run mvn test surefire seems to have all of the dependencies loaded on the classpath *before* testSourceDirectory. I know that one possibility would be to move this class to a new artifact or another existing artifact and make it a dependency, but that isn't a viable solution right now as I'm doing a bulk conversion of projects to Maven 2. So right now, I'm just wanting to know, is this possible? Is there a way to tell surefire to order the testSourceDirectory before any dependencies on the classpath when it runs? Thanks. -- Steven Cummings -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum dead?
If you're not happy with the turnaround on continuum, take a look at Hudson. The maven integration is great and releases/bug fixes come incredibly quickly. https://hudson.dev.java.net/ (I didn't write it... just a user :-) On 5/8/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/8/07, Crossley, Jim [EMAIL PROTECTED] wrote: Is Continuum dead? It hasn't been released in over a year. I need for it to build multi-module project snapshots correctly. Continuum has its own user and dev lists, for which you can find subscription info here: http://maven.apache.org/continuum/mail-lists.html Or you can follow the discusson on Nabble: http://www.nabble.com/Continuum---Users-f13868.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBUnit and table list
On 5/4/07, Pete [EMAIL PROTECTED] wrote: Hi there, 1) Firstly I've noticed there appears to be two DBUnit plugins, not sure which is best : http://mojo.codehaus.org/dbunit-maven-plugin maven 2.x http://maven-plugins.sourceforge.net maven 1.x 2) I'm trying to use the codehaus DBUnit plugin to export some data, but one table is giving me an error so I thought I'd provide a list of tables to export to the plugin configuration but not sure how to :- The docs says there is a configurable :- tables Table[] List of DbUnit's Table. See DbUnit's JavaDoc for details I have tried :- tables tabletable1/table tabletable2/table /tables and tablestable1,table2tables all inside the plugin's configuration. The plugin requires org.dbunit.ant.Table but looks like the Strings don't get converted to this. Cannot assign configuration entry 'table' to 'class org.dbunit.ant.Table' from 'acl_object_identity', which is of type class java.lang.String Help ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin: making optional optinal ?
On 4/28/07, Dan Tran [EMAIL PROTECTED] wrote: is it a bug? nah, i think that the behavior for optional is correct, but since it was the only option for slimming down wars with the desired manifest, it was being used in situations that probably didn't make sense. the only way that you could argue that this is a problem with the war plugin is if you thought that there should be a way to differentiate provided by the ear and provided by the container. the feature for the ear plugin would definitely be a rfe. it certainly works now, but it'd be nice if it cleaned up your libs. On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote: On 4/27/07, Gregory Kick [EMAIL PROTECTED] wrote: On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote: On 4/27/07, Gregory Kick [EMAIL PROTECTED] wrote: I think that instead of using optional, you have been meaning to use scopeprovided/scope. This would indicate that the jars are necessary, but won't include them in your war because it is assumed that it will be provided by the container, or in your case, the ear. Nope. Cf last part of http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html Ouch, that's a little disconcerting. Here's what the pom reference has to say about optional: optional: Marks optional a dependency when this project itself is a dependency. Confused? For example, imagine a project A that depends upon project B to compile a portion of code that may not be used at runtime, then we may have no need for project B for all project. Since it sounds like none of your dependencies are optional in either the english or maven senses of the word, I don't see the justification for the way the war manifests are configured.What you've done makes sense in terms of getting the desired effect, but not so much in terms of the meaning of the metadata. agreed What I'd rather see is an option in the ear plugin for removing artifacts from dependencies that are already present in APP-INF/lib. That way, you can remove the optional tag completely, still have your manifests the way you want, be able to test and still have your lean ears. That would be better as I would have to make a single change to my project (the optimization could almost be on by default in a next major release of the plugin). The solution should also update the wars MANIFEST files. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar with dependencies in a folder
When I read this thread it bothered me that people were recommending the dependency plugin because it seemed like something that the assembly plugin should be able to do on its own. I think that the following ought to get you what you wanted without that plugin. assembly xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/assembly-1.0.0.xsd; idmydist/id formats formatzip/format /formats fileSets fileSet directorytarget/directory outputDirectory/outputDirectory includes include*.jar/include /includes /fileSet /fileSets dependencySets dependencySet outputDirectorylib/outputDirectory unpackfalse/unpack scoperuntime/scope /dependencySet /dependencySets /assembly On 4/26/07, JavierL [EMAIL PROTECTED] wrote: Finally, it worked...thanks a lot ! Wayne Fay wrote: I could be wrong about that. Check the other examples. You might actually want copy-dependencies. Wayne On 4/25/07, Wayne Fay [EMAIL PROTECTED] wrote: You probably want dependency:unpack-dependencies. Wayne On 4/25/07, JavierL [EMAIL PROTECTED] wrote: Wayne Fay wrote: Ah! In that case, you want to use the maven-dependency-plugin: http://maven.apache.org/plugins/maven-dependency-plugin/ I've read docs and see this: -- artifactItems artifactItem groupId[ groupId ]/groupId artifactId[ artifactId ]/artifactId version[ version ]/version type[ packaging ]/type overWrite[ true or false ]/overWrite outputDirectory[ output directory ]/outputDirectory destFileName[ filename ]/destFileName /artifactItem --- I wonder if it means every dependency to be copied should be write by hand in such way. I hope to be wrong because I found this totally ilogical. I want something to do the job automatically and not complicate the verbose maven pom configuration. Thanks in advance J J -- View this message in context: http://www.nabble.com/jar-with-dependencies-in-a-folder-tf3644333s177.html#a10188383 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/jar-with-dependencies-in-a-folder-tf3644333s177.html#a10195552 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin: making optional optinal ?
I think that instead of using optional, you have been meaning to use scopeprovided/scope. This would indicate that the jars are necessary, but won't include them in your war because it is assumed that it will be provided by the container, or in your case, the ear. As far as your testing, you could setup a container that has those artifacts as part of the common libraries and deploy to that. For example, if you're using the jetty plugin, http://ramblingabout.wordpress.com/2007/01/12/jsf-on-jetty-and-maven/ says that you can just add them as dependencies for the plugin. I haven't tried it, but it seems reasonable. On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote: Hi, our project has several wars all bundled in an ear. In order to reduce the size, we moved most of the dependencies to the ear using optionaltrue/optional. Now we would like the developers to be able to test deploy the wars independently and it is not possible due to the now 'missing' dependencies. I can see 2 options: * use profiles. Not very flexible and project specific * add an option to ignore the optional recommendations in the war plugin. Later on perhaps create a new fullwar mojo that ignores the optional recommendation by default and store the results in a different war file. Attach the artifact. mvn war -DignoreOptional=true mvn war:fullwar // creates target/$warname-$version-fullwar.war ?? Maybe there's a third solution? Anyone doing similar today ? Comments ? Cheers, -- Jerome Lacoste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war plugin: making optional optinal ?
On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote: On 4/27/07, Gregory Kick [EMAIL PROTECTED] wrote: I think that instead of using optional, you have been meaning to use scopeprovided/scope. This would indicate that the jars are necessary, but won't include them in your war because it is assumed that it will be provided by the container, or in your case, the ear. Nope. Cf last part of http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html Ouch, that's a little disconcerting. Here's what the pom reference has to say about optional: optional: Marks optional a dependency when this project itself is a dependency. Confused? For example, imagine a project A that depends upon project B to compile a portion of code that may not be used at runtime, then we may have no need for project B for all project. Since it sounds like none of your dependencies are optional in either the english or maven senses of the word, I don't see the justification for the way the war manifests are configured.What you've done makes sense in terms of getting the desired effect, but not so much in terms of the meaning of the metadata. What I'd rather see is an option in the ear plugin for removing artifacts from dependencies that are already present in APP-INF/lib. That way, you can remove the optional tag completely, still have your manifests the way you want, be able to test and still have your lean ears. How's that sound? As far as your testing, you could setup a container that has those artifacts as part of the common libraries and deploy to that. For example, if you're using the jetty plugin, http://ramblingabout.wordpress.com/2007/01/12/jsf-on-jetty-and-maven/ says that you can just add them as dependencies for the plugin. I haven't tried it, but it seems reasonable. That's not satisfying. I will have to put this environment each time my dependencies are changed. That's just pushing the problem away. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any change in ${ reports} in site.xml recently?
use menu ref=reports/ instead. i'm pretty sure that ${reports}
was deprecated anyway.
On 4/25/07, Curt Arnold [EMAIL PROTECTED] wrote:
I've been working on several log4j related projects with Maven
recently and I've started having errors during site generation start
occurring on projects that had been working. The symptom is:
[WARNING] Error loading report org.apache.maven.plugin.jxr.JxrReport
- AbstractMethodError: canGenerateReport()
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position:
TEXT seen ...g.apache.org/log4j/companions/\r/links\r{$
reports}\r /... @1:1352)
And will disappear if the ${ reports} is removed from src/site/site.xml.
I've been experiencing the problem with Maven 2.0.6 or Maven 2.0.4 on
Mac OS/X
java version 1.5.0_07
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
and still had the problem after deleting my local repository.
To reproduce the problem, check out the following project:
svn co https://svn.apache.org/repos/asf/logging/sandbox/log4j/component
and then do mvn site
I had previously used {$reports} instead of ${ reports}, but it
seemed like both forms use to work and now neither form does.
p.s. I'm a maven newbie, so any comments on the project would be
appreciated. Cobertura has been very finicky, saw the note on 2.1
but even using 2.0, I have to manually blow the plugin from the
repository and the surefire* files from the project to get the site
to produce correctly.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Gregory Kick
http://kickstyle.net/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse and Processing Filtered Resources on Clean
Thomas, As I expected, I can't reproduce your problem. I put the buildCommand that you've included into the .project file for an eclipse project, run eclipse:eclipse and it stays put. Are you running eclipse:clean? That would completely remove and regenerate the .project file. Otherwise, I'm pretty sure that eclipse:eclipse only modifies the .classpath file. By the way, I'm using v2.3 of the eclipse plugin. Do you have a different one? On 4/26/07, Thomas Van de Velde [EMAIL PROTECTED] wrote: I am using the Eclipse plugin for Maven to add a builder so that upon every clean the resources:resources goal gets invoked. This avoids the tedious process of keep filtered resources up to date after a clean in Eclipse. The output for this in the .project file looks as follows: buildCommand nameorg.eclipse.ui.externaltools.ExternalToolBuilder/name triggersfull,incremental,/triggers arguments dictionary keyLaunchConfigHandle/key valuelt;projectgt;/.externalToolBuilders/Repository Resources [Builder].launch/value /dictionary /arguments /buildCommand Whenever I regenerate the project with eclipse:eclipse, this section gets wiped out and I need to add it again manually. I haven't found a way to add these more complicated buildCommand to the maven-eclipse plugin. The maven-plugin only seems to support simple buildcommands. Any solutions for this? I have trouble understanding that both the m2 eclipse plugin and the maven-eclipse plugin have not solved this issue. I would assume this is a common requirement for anybody using filters. -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven repository metadata
I've got a quick question about repository metadata. If you take a look at http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml it has all of the versioning information, which makes sense, but it also has a version tag with a version that's neither the oldest nor the most recent. How does this tag get populated and what is it used for? It seems like this tag shouldn't even be there... Are there metadata files that are only associated with a particular version? -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype : $ a predefined character
I think that you want to take a look at
http://velocity.apache.org/engine/releases/velocity-1.5/user-guide.html#escapingvalidvtlreferences
On 4/16/07, Marouane Amraoui [EMAIL PROTECTED] wrote:
Good news :
I do the test on this line :
property name=myproject.name value=${artifactId}/
property name=myproject value=${root}\${artifactId}/
Two good news :
1. ${root} maven try to parse it but only show a wrning message , so don't exit
with error :)
2. what you assumed don't work (\$) work very fine :). Because it generate me
this line :
property name=myproject.name value=myproject/
property name=myproject value=${root}${artifactId}/.
You look in the second line maven delete only the character \ without
interpreting ${artifactId} :)
Thx
-Message d'origine-
De: Marouane Amraoui [mailto:[EMAIL PROTECTED]
Envoyé: lundi 16 avril 2007 15:42
À: Maven Users List
Objet: RE: Archetype : $ a predefined character
If you can explain me more your solution ?
What I need is :
property name=myproject value=${root}\${artifactId}/
${root} to be ignored. (is ant variable)
And ${artifactId} to be parsed.
Thx
-Message d'origine-
De: Kathryn Huxtable [mailto:[EMAIL PROTECTED]
Envoyé: lundi 16 avril 2007 15:37
À: Maven Users List
Objet: Re: Archetype : $ a predefined character
I defined a symbol called dollar equal to a dollar sign and used ${dollar}
throughout. It worked. I think you're supposed to be able to use \$, but I
couldn't get it to work.
-K
On 4/16/07 10:19 AM, Marouane Amraoui [EMAIL PROTECTED] wrote:
Hi,
I create my own archetype :
This archetype generate me a project that contain some file that contain in
there body the character $. This character
Is normaly interpreted by velocity.
There is some solution for that ?
---
Merouane AMRAOUI
Consultant Expert
Division Développement
Email.: [EMAIL PROTECTED]
Gsm .: 065 19 60 99
Tél. | Tel.: 022 98 70 70Téléc | Fax: 022 98 70 70
OMNIDATA , 74 Bv AbdelMoumen
-
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]
--
Gregory Kick
http://kickstyle.net/
Re: How to get the active profiles in a maven plugin
you could take a look at the source for the 'active-profiles' goal in the 'help' plugin... On 4/14/07, Lewandowski, Eric [EMAIL PROTECTED] wrote: Hi ! I have to write a Maven plugin and I need to access to the active profiles list. For example, if I execute the command line : mvn groupId:artifactId:goal -P profile-1,profile-2 ... I need to get in my java classes the list of active profiles (here profile-1 and profile-2) Does somebody know to do this or where I can found documentation about that ? Thanks ! Eric Lewandowski -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ERROR The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist
try running with -X to see what the problem is specifically On 4/12/07, Mekonium [EMAIL PROTECTED] wrote: Hello everyone, Im a newbie in Maven, i must use this tool in my proiect. Unfortunately im bloked by a problem, i use a proxy that i have already configured, and i think that this configuration works because the command mvn archetype:create ... has terminated correctly. But when i execute mvn compile i meet this message error The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist. Plz if you have anyidea dont hesitate to answear me. Thanks a lot. By Mekonium -- View this message in context: http://www.nabble.com/ERROR-%22The-plugin-%27org.apache.maven.plugins%3Amaven-resources-plugin%27-does-not-exist%22-tf3564721s177.html#a9956871 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ERROR The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist
sometimes when the proxy freaks out in the initial trials, it puts some metadata in my repository that makes it permanently fail. check to see if ~/.m2/repository contains anything for that plugin and delete it. On 4/12/07, Mekonium [EMAIL PROTECTED] wrote: I use a proxy that we have in the company.For tha i configured the following file: maven-2.0.6\conf\settings.xml any idea ??? thanks a lot By mekonium -- View this message in context: http://www.nabble.com/ERROR-%22The-plugin-%27org.apache.maven.plugins%3Amaven-resources-plugin%27-does-not-exist%22-tf3564721s177.html#a9964243 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wagon providers and proxyInfo
I'm having some trouble getting proxies setup with the http-lightweight-wagon and the webdav-wagon. I've got one proxy that serves both http and https from the same port. If I specify a proxy in settings.xml with the protocol http, the lightweight wagon can pull files from the central repository, but I can't get anything from another repository that uses https. If I specify two proxies with different protocols, it still doesn't work. However, if only put https as my protocol i can pull from either repository (how does that make sense???). Finally, no matter what i do, i can't get the webdav wagon to pick up a proxy. Just for clarification, every time it does find a proxy, it works and every time it doesn't i get Caused by: java.net.SocketException: Network is unreachable: connect in my stack trace. Does anyone have any idea about how to make both wagons pick up the proxy information for both http and https? -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apt - annotation processing tool
there's always maven-antrun-plugin + the java task On 3/26/07, leonid_ilyevsky [EMAIL PROTECTED] wrote: Is there any progress in using apt with maven2? I saw one message suggesting org.apache.myfaces.tobago. I couldn't figure out how to make it to do anything at all. Are there any examples anywhere? Without maven, apt works fine for me, but I want it as a part of the maven build. Another question: in general, is there a way (maybe some generic plugin) to just call any unix command during the build? This also could solve my problem. -- View this message in context: http://www.nabble.com/apt---annotation-processing-tool-tf3468198s177.html#a9676982 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
create an assembly only for a release
Does anyone know of a good way to have a particular assembly generated and deployed iff I'm cutting a release? It'd be nice if I could get it to happen automatically (without having to specify a profile or something). Greg Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] PVCS SCM
Yeah, I've been watching that bug and appreciate the effort. Thanks for all of your work. On 3/14/07, JC Walmetz [EMAIL PROTECTED] wrote: I have added the plugin in JIRA. If you try it, just keep me inform. Gregory Kick-2 wrote: That would be very great. I think the bug you're talking about is at http://jira.codehaus.org/browse/SCM-34 On 3/7/07, JC Walmetz [EMAIL PROTECTED] wrote: I'm afraid the donation of a plugin by serena is in a bad way. Few month ago we ask to Serena if it was planned. Their answer was NO. It looks it somewhere in a wish list. Maybe if you are a Serena Customer you can contact their support. In JIRA there is a startup for a PVCS plugin (just the checkout from what I remember). I have implement some more task but that's not tested. I'll try to find the bug in JIRA and to add my plugins. I use it to release my projects with the release plugin. Gregory Kick-2 wrote: A while back there was some talk of a PVCS integration being donated. Did anything ever come of that? Has anyone successfully used maven with pvcs? Thanks, -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/PVCS-SCM-tf3353835s177.html#a9339363 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/PVCS-SCM-tf3353835s177.html#a9462735 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: use mvn install inside POM.xml
It doesn't look like it because you can't override artifactId, groupId, file, etc. On 3/12/07, sirji [EMAIL PROTECTED] wrote: Hi all, I have project requirement where we need to install custom jar file (generated using another project) into the maven local repository using mvn install command. My question is: How can we run mvn install command from POM.xml? Kindly let me know if this is not possible. Thanks regards, -- View this message in context: http://www.nabble.com/use-mvn-install-inside-POM.xml-tf3388796s177.html#a9432558 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] PVCS SCM
That would be very great. I think the bug you're talking about is at http://jira.codehaus.org/browse/SCM-34 On 3/7/07, JC Walmetz [EMAIL PROTECTED] wrote: I'm afraid the donation of a plugin by serena is in a bad way. Few month ago we ask to Serena if it was planned. Their answer was NO. It looks it somewhere in a wish list. Maybe if you are a Serena Customer you can contact their support. In JIRA there is a startup for a PVCS plugin (just the checkout from what I remember). I have implement some more task but that's not tested. I'll try to find the bug in JIRA and to add my plugins. I use it to release my projects with the release plugin. Gregory Kick-2 wrote: A while back there was some talk of a PVCS integration being donated. Did anything ever come of that? Has anyone successfully used maven with pvcs? Thanks, -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/PVCS-SCM-tf3353835s177.html#a9339363 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tools.jar Apple
Since classes.jar is always on the classpath, you could probably just
use an exclusion to disregard the dependency. Otherwise, you
actually end up with classes.jar on your classpath twice.
On 3/7/07, Wayne Fay [EMAIL PROTECTED] wrote:
There is no tools.jar on Mac. Instead, the classes from tools.jar are
included in a larger classes.jar file. Don't ask me...
Wayne
On 3/6/07, Dan Tran [EMAIL PROTECTED] wrote:
Apple renames tools.jar to classes.jar?
-D
On 3/6/07, Ryan Cuprak [EMAIL PROTECTED] wrote:
Managed to get around the problem. I edited the pom file under .m2
to point directly at the classes.jar file on MacOS X. A bit of a hack
but it worked.
-Ryan
On Mar 6, 2007, at 2:37 PM, Ryan Cuprak wrote:
The error message is:
Missing:
--
1) sun.jdk:tools:jar:1.5.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=sun.jdk -DartifactId=tools \
-Dversion=1.5.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.codehaus.mojo:jaxws-maven-plugin:maven-plugin:1.0-
beta-1-20070203.171044-8
2) sun.jdk:tools:jar:1.5.0
On the mac, the classes that comprise the tools are located in:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Classes/
classes.jar
Googling I come across postings where it is recommend that I alter
the systempath to point to classes.jar.
-Ryan
On Mar 6, 2007, at 2:30 PM, Dan Tran wrote:
jaxws is capable of automatically pickup tools.jar from
${java.home}/lib/tools.jar
( MacOS specific)
What is the error?
you may need to get the latest source and build your self.
-D
On 3/6/07, Ryan Cuprak [EMAIL PROTECTED] wrote:
Hello,
I am trying to get the jaxws-maven-plugin up and running on my
box. Evidently Apple has been kind enough to stick tools.jar
elsewhere.
Any reason why the snippet below wouldn't work?
-Ryan
Snippet:
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjaxws-maven-plugin/artifactId
version1.0-beta-1-SNAPSHOT/version
executions
execution
goals
goalwsgen/goal
/goals
/execution
/executions
configuration
seinet.cuprak.ryanportal/sei
genWsdltrue/genWsdl
/configuration
dependencies
dependency
groupIdsun.jdk/groupId
artifactIdtools/artifactId
version1.5.0/version
systemPath/System/Library/Frameworks/
JavaVM.framework/Versions/1.5/Classes/classes.jar/systemPath
scopesystem/scope
/dependency
/dependencies
/plugin
/plugins
-
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]
--
Gregory Kick
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tools.jar Apple
Actually, I take that back... you can define exclusions for
dependencies within a plugin, but it doesn't look like you can define
them for a plugin itself.
Anybody know of a good way to do that?
On 3/7/07, Gregory Kick [EMAIL PROTECTED] wrote:
Since classes.jar is always on the classpath, you could probably just
use an exclusion to disregard the dependency. Otherwise, you
actually end up with classes.jar on your classpath twice.
On 3/7/07, Wayne Fay [EMAIL PROTECTED] wrote:
There is no tools.jar on Mac. Instead, the classes from tools.jar are
included in a larger classes.jar file. Don't ask me...
Wayne
On 3/6/07, Dan Tran [EMAIL PROTECTED] wrote:
Apple renames tools.jar to classes.jar?
-D
On 3/6/07, Ryan Cuprak [EMAIL PROTECTED] wrote:
Managed to get around the problem. I edited the pom file under .m2
to point directly at the classes.jar file on MacOS X. A bit of a hack
but it worked.
-Ryan
On Mar 6, 2007, at 2:37 PM, Ryan Cuprak wrote:
The error message is:
Missing:
--
1) sun.jdk:tools:jar:1.5.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=sun.jdk -DartifactId=tools \
-Dversion=1.5.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.codehaus.mojo:jaxws-maven-plugin:maven-plugin:1.0-
beta-1-20070203.171044-8
2) sun.jdk:tools:jar:1.5.0
On the mac, the classes that comprise the tools are located in:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Classes/
classes.jar
Googling I come across postings where it is recommend that I alter
the systempath to point to classes.jar.
-Ryan
On Mar 6, 2007, at 2:30 PM, Dan Tran wrote:
jaxws is capable of automatically pickup tools.jar from
${java.home}/lib/tools.jar
( MacOS specific)
What is the error?
you may need to get the latest source and build your self.
-D
On 3/6/07, Ryan Cuprak [EMAIL PROTECTED] wrote:
Hello,
I am trying to get the jaxws-maven-plugin up and running on my
box. Evidently Apple has been kind enough to stick tools.jar
elsewhere.
Any reason why the snippet below wouldn't work?
-Ryan
Snippet:
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjaxws-maven-plugin/artifactId
version1.0-beta-1-SNAPSHOT/version
executions
execution
goals
goalwsgen/goal
/goals
/execution
/executions
configuration
seinet.cuprak.ryanportal/sei
genWsdltrue/genWsdl
/configuration
dependencies
dependency
groupIdsun.jdk/groupId
artifactIdtools/artifactId
version1.5.0/version
systemPath/System/Library/Frameworks/
JavaVM.framework/Versions/1.5/Classes/classes.jar/systemPath
scopesystem/scope
/dependency
/dependencies
/plugin
/plugins
-
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]
--
Gregory Kick
[EMAIL PROTECTED]
--
Gregory Kick
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
PVCS SCM
A while back there was some talk of a PVCS integration being donated. Did anything ever come of that? Has anyone successfully used maven with pvcs? Thanks, -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Username and password for deploy plugin
I think that you might be talking about what was reported in http://jira.codehaus.org/browse/MNG-553 . This issue was reported a long time ago and doesn't seem to be getting much attention anymore... Maybe a few more votes for it? On 3/3/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/28/07, Paul Gier [EMAIL PROTECTED] wrote: Is there a way to supply a username and password for a remote repository on the command line instead of in the settings.xml? It would be helpful if the deploy plugin could prompt the user as needed for this information. The password could be hidden from view this way, and developers would not have to worry about configuring settings.xml. Specifically, I would like to have this feature for the wagon-webdav plugin, but I think it could apply to all the deploy related plugins. No idea if it takes userid/password on the command line, but there is some work in the gpg plugin to prompt for a passphrase (and mask it). Perhaps that could be borrowed. (wagon-webdav isn't a plugin, is it? I only know it as an artifact that needs to be configured as a build extension or otherwise added to Maven since it doesn't support dav by default.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating APT-files
The page that I usually go to for lifecycles is: http://docs.codehaus.org/display/MAVENUSER/introduction-to-the-lifecycle It's a bit of a pain to switch back and forth between the maven site and the wiki, but there's some good stuff there. On 2/26/07, Roland Asmann [EMAIL PROTECTED] wrote: Got it running now, thanks! One question though, how come I can't find anything about the site's lifecycle on the maven-pages? Might be a good idea to post the life-cycles there (like the standard lifecycle for building packages). On Monday 26 February 2007 21:10, Wendy Smoak wrote: On 2/26/07, Roland Asmann [EMAIL PROTECTED] wrote: So, what does goals does the 'mvn site' run compared to 'mvn site:site'? The site lifecycle is: pre-site, site, post-site, site-deploy Maven will run any plugin goals bound to those phases, up to and including the phase you specify. So, anything you've bound to the phases, plus anything bound by default. I don't know offhand what the site plugin does in each phase, I'd have to look. When you execute 'mvn site:site' you are only running a single goal on a single plugin. -- Roland Asmann CFC Informationssysteme Entwicklungsgesellschaft m.b.H Bäckerstrasse 1/2/7 A-1010 Wien FN 266155f, Handelsgericht Wien Tel.: +43/1/513 88 77 - 27 Fax.: +43/1/513 88 62 Email: [EMAIL PROTECTED] Web: www.cfc.at - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED]
Maven/Codehaus JIRA NullPointerException
I was trying to create a new issue in JIRA and repeatedly get a 500 error caused by a NullPointerException. Can somebody look into this? I'd create an issue about it, but... ---stack trace--- java.lang.NullPointerException at com.atlassian.jira.plugin.webresource.JiraWebResourceIntegration.getBaseUrl(JiraWebResourceIntegration.java:42) at com.atlassian.plugin.webresource.WebResourceManagerImpl.getStaticResourcePrefix(WebResourceManagerImpl.java:182) at _jsp._500page__jsp._jspService(includes/decorators/stylesheettag.jsp:12) at com.caucho.jsp.JavaPage.service(JavaPage.java:60) at com.caucho.jsp.Page.pageservice(Page.java:570) at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:159) at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:115) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:208) at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:268) at com.caucho.server.webapp.RequestDispatcherImpl.error(RequestDispatcherImpl.java:113) at com.caucho.server.webapp.ErrorPageManager.sendServletError(ErrorPageManager.java:354) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:165) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:208) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:396) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:363) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490) at com.caucho.util.ThreadPool.run(ThreadPool.java:423) at java.lang.Thread.run()V(Unknown Source) -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing the value of the pom name
Ole,
Take a look at http://jira.codehaus.org/browse/ARCHETYPE-55
If you apply the patch it will work.
On 2/21/07, Ole Ersoy [EMAIL PROTECTED] wrote:
Hi,
I'm trying to pass the pom name element value
to the archetype:create command.
I tried -Dname=TheName
but the pom still gets created with ${name}
instead of TheName
Thoughts?
Thanks,
- Ole
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food Drink QA.
http://answers.yahoo.com/dir/?link=listsid=396545367
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Gregory Kick
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bizarre behaviour modules in site generation
I'm finding some strange behavior with generating sites. I have a project with pom packaging and two modules. One module has ear packaging and another has pom packaging also. I was running 'mvn site' from the top level without a problem, but I hadn't given the projects names via the name tag. After I'd given all three names, suddenly, the modules section on the top-level was no longer being populated. The really bizarre thing is that if i run 'mvn -N site', the modules show up again. Summary: 'mvn site' and no names - modules 'mvn site' and names - no modules 'mvn -N site' and names - modules Anybody have any idea what could be causing that? Nothing shows up with -X... -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Q: Weblogic Plugin
Using maven-antrun-plugin with the wldeploy ant task works with wl 8.1. You might give that a try... On 2/1/07, lemon dumpling [EMAIL PROTECTED] wrote: Hi Everyone, Is there a way to deploy and redeploy exploded war file into weblogic 9.2using maven2? Thanks. Cheers -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: codehaus xmlbeans and eclipse
John, I know exactly what you're talking about and there isn't really a great solution. On 1/17/07, flyboy [EMAIL PROTECTED] wrote: I have some issues with xmlbeans and eclipse. Is anyone successful? 1) I have a maven project with xml beans generated code. The xmlbeans maven plugin creates a directory 'target/classes/schemaorg_apache_xmlbeans. Eclipse removes this directory on a 'project clean' or build classpath configuration. The reason this happens is that xmlbeans generates two sets of files. The first is the typical java files that you'd expect. In the xmlbeans ant task, these are the ones that you'd get in the target of the srcgendir directory. The second set is the bizarre one. When srconly is true, there are still some files generated in the classgendir directory. These files are the compiled schema files (.xsb) and TypeSystemHolder.class. These are only generated by the plugin and since clean will wipe everything from the target directory and there are no correspond sources/resources, you'll have to rerun the plugin. 2) After losing target/classes/schemaorg_apache_xmlbeans, the xmlbeans maven plugin will not recreate it, because the other directory it creates, target/xmlbeans-source is still present. Removing target/xmlbeans-source from command line causes eclipse to automatically remove xmlbeans-source from the source path. So, after regenerating both subdirectories, restoring xmlbeans-source as a source directory causes the first problem above to occur. Not so sure about this one because I built my own plugin to better handle the first issue. :-) 3) Eclipse is not 'seeing' target/classes/schemaorg_apache_xmlbeans and so the generated source code in xmlbeans-source cannot be built. Specifically, schemaorg_apache_xmlbeans/system/big honkin' dir name/TypeSystemHolder is NOT getting resolved. This is probably the result of eclipse compilation and the problem that I talked about in #1. My guess is that eclipse compiles the sources, notices that there is no TypeSystemHolder and removes the .class file. This is pretty unavoidable because there __is no .java file__. Xmlbeans does some weird thing where it actually manipulates a template class file. The only thing I can recommend is to run the plugin, don't touch anything, and run whatever you want to from eclipse. That usually works for me. I am using eclipse 3.2.1, xmlbeans-maven-plugin 2.0, maven 2.0.4, eclipse maven plugin 2.3. Is anyone using xmlbeans, maven and eclipse with success? Are you struggling with this? Is there workaround? Thanks, John -- View this message in context: http://www.nabble.com/codehaus-xmlbeans-and-eclipse-tf3029668s177.html#a8418392 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Archives: Source Plugin vs. Assembly Plugin
Franz, On 1/14/07, franz see [EMAIL PROTECTED] wrote: Good day to you, Gregory, Actually, the plugin does not define the lifecycle. Rather, it's the packaging type which defines the default goal bindings to the lifecycle phases. That's what I meant. Sorry for misspeaking. Regarding consolidating the functionality in order to minimize the effort across pugins - if you're referring to implementation-wise, I think they are using a common component for the assembly. I hadn't really looked into it in the source, but like I said in the my message to Dennis, we end up with multiple goals with the same parameters. Not a huge deal, but it seems a bit silly... Also, IMHO, eventhough source and javadoc are both auxiliary artifacts, they're both common functionalities just like the jars, wars, etc. Thus, I don't find any fault with the existence of source:jar and javadoc:jar. The assembly plugin is usually used for the uncommon use cases. Yes, I think that that is what Dennis was saying as well. My thought was that now that the assembly plugin seems to have matured into something more stable, it might be worth using it in the common cases as well. As for knowing all the artifacts being generated by a build, maybe creating a report would be better ( though I am not sure how though :) ). Actually, I made one. It was a pain to get it to work correctly and it's pretty hackish. I'd much rather just be able to manage the assembly plugin and be done with it. But if you want, you can take this up in the maven dev list to get more inputs :) Alright, lets see what they have to say. Just my 2 cents worth. Franz Gregory Kick-2 wrote: Franz, The difference that I see between the sources and javadoc plugins and jar, war, etc. is that plugins like the jar plugin actually define the lifecycle for that particular packaging. Since source and javadoc jars are auxiliary artifacts, it seems as though it would make more sense to consolidate that functionality in order to minimize effort across the plugins. Also, it seems like it would be much more convenient to look look at the descriptorRefs tag and see __every__ artifact that was being generated (aside from the default, main artifact). Aside from it already being implemented, was there a specific reason for sources and javadoc to create their own jars? On 1/12/07, franz see [EMAIL PROTECTED] wrote: Good day to you, Gregory, I think it is simply for ease of use. Intead of configuring the assembly plugin, you can simply do mvn sources:jar. Same goes for the other packaing goals ( jar:jar, javadoc:jar, ejb:ejb, ejb3:ejb3, war:war, ear:ear, etc ). Usually, you don't have to use the assembly plugin because the other packaging goals are much easier to use. But if those goals are not enough for your needs, then go for the assembly plugin. As for the difference between -sources and -src, I am not sure myself :-) Cheers, Franz Gregory Kick-2 wrote: After looking through the documentation for each of these plugins, I am left with a few questions: - Isn't the functionality of the source plugin just a subset of the assembly plugin (i.e. couldn't I just use the assembly plugin to do the same thing and only have to worry about one plugin)? - Is there a reason that the assembly plugin uses -src for its archives while the sources plugin uses -sources? - Should the Source Plugin be deprecated for a pre-defined assembly descriptor with the same behavior? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8292765 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8350410 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Archives: Source Plugin vs. Assembly Plugin
Dennis, I definitely agree. The sources plugin has been successfully used as the mechanism for creating and deploying source jars to the the repository. The reason that I brought it up was that any number of artifacts can be deployed to a repository ( http://maven.apache.org/plugins/maven-assembly-plugin/faq.html#deploy ) and it seems to be unnecessary to have to manage multiple plugins. I would understand if there was some added functionality that was provided by the source plugin, but the goals and parameters both seem to be a subset. As far as it being write protected, wouldn't a predefined descriptor standardize the process to the same degree? In the end, I certainly have nothing against the source plugin and the jar goal of the javadoc plugin because I use them both frequently. It would just simplify my POMs and probably promote source and jar publishing if adding these artifacts was an additional line in the assembly plugin configuration instead of running each plugin manually or individually attaching them to the lifecycle. Now obviously, I could just go ahead and do it, but I brought it up because assembly's faq refers users to the javadoc plugin for that artifact and has a different suffix and packaging for sources. So, again I'll ask if there is a particular reason that this hasn't been consolidated or is it just because the assembly plugin seems to have matured a bit later? On 1/13/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Gregory Although I haven't spent a lot of time using either of these plugins, it is my understanding that the source-plugin is there to enable you to publish the sources for your product in the repository. Look at it as a write-protected assembly which is tailored to match the exact needs of sources jars that are to be published in the repository. Gregory Kick wrote: Franz, The difference that I see between the sources and javadoc plugins and jar, war, etc. is that plugins like the jar plugin actually define the lifecycle for that particular packaging. Since source and javadoc jars are auxiliary artifacts, it seems as though it would make more sense to consolidate that functionality in order to minimize effort across the plugins. Also, it seems like it would be much more convenient to look look at the descriptorRefs tag and see __every__ artifact that was being generated (aside from the default, main artifact). Aside from it already being implemented, was there a specific reason for sources and javadoc to create their own jars? On 1/12/07, franz see [EMAIL PROTECTED] wrote: Good day to you, Gregory, I think it is simply for ease of use. Intead of configuring the assembly plugin, you can simply do mvn sources:jar. Same goes for the other packaing goals ( jar:jar, javadoc:jar, ejb:ejb, ejb3:ejb3, war:war, ear:ear, etc ). Usually, you don't have to use the assembly plugin because the other packaging goals are much easier to use. But if those goals are not enough for your needs, then go for the assembly plugin. As for the difference between -sources and -src, I am not sure myself :-) Cheers, Franz Gregory Kick-2 wrote: After looking through the documentation for each of these plugins, I am left with a few questions: - Isn't the functionality of the source plugin just a subset of the assembly plugin (i.e. couldn't I just use the assembly plugin to do the same thing and only have to worry about one plugin)? - Is there a reason that the assembly plugin uses -src for its archives while the sources plugin uses -sources? - Should the Source Plugin be deprecated for a pre-defined assembly descriptor with the same behavior? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8292765 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Archives: Source Plugin vs. Assembly Plugin
Franz, The difference that I see between the sources and javadoc plugins and jar, war, etc. is that plugins like the jar plugin actually define the lifecycle for that particular packaging. Since source and javadoc jars are auxiliary artifacts, it seems as though it would make more sense to consolidate that functionality in order to minimize effort across the plugins. Also, it seems like it would be much more convenient to look look at the descriptorRefs tag and see __every__ artifact that was being generated (aside from the default, main artifact). Aside from it already being implemented, was there a specific reason for sources and javadoc to create their own jars? On 1/12/07, franz see [EMAIL PROTECTED] wrote: Good day to you, Gregory, I think it is simply for ease of use. Intead of configuring the assembly plugin, you can simply do mvn sources:jar. Same goes for the other packaing goals ( jar:jar, javadoc:jar, ejb:ejb, ejb3:ejb3, war:war, ear:ear, etc ). Usually, you don't have to use the assembly plugin because the other packaging goals are much easier to use. But if those goals are not enough for your needs, then go for the assembly plugin. As for the difference between -sources and -src, I am not sure myself :-) Cheers, Franz Gregory Kick-2 wrote: After looking through the documentation for each of these plugins, I am left with a few questions: - Isn't the functionality of the source plugin just a subset of the assembly plugin (i.e. couldn't I just use the assembly plugin to do the same thing and only have to worry about one plugin)? - Is there a reason that the assembly plugin uses -src for its archives while the sources plugin uses -sources? - Should the Source Plugin be deprecated for a pre-defined assembly descriptor with the same behavior? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8292765 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Source Archives: Source Plugin vs. Assembly Plugin
After looking through the documentation for each of these plugins, I am left with a few questions: - Isn't the functionality of the source plugin just a subset of the assembly plugin (i.e. couldn't I just use the assembly plugin to do the same thing and only have to worry about one plugin)? - Is there a reason that the assembly plugin uses -src for its archives while the sources plugin uses -sources? - Should the Source Plugin be deprecated for a pre-defined assembly descriptor with the same behavior? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
applying filters to a site
after looking through the thread at
http://www.nabble.com/-M2--Insert-variables-in-xdoc-apt-files-tf1956665.html
i've gotten filters applied to a site using:
resources
resource
directorysrc/site/directory
targetPath../filtered-site/targetPath
filteringtrue/filtering
/resource
/resources
filters
filtersite-filter.properties/filter
/filters
and
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
configuration
siteDirectory${project.build.directory}/filtered-site/siteDirectory
/configuration
/plugin
Is there a better way to get this done? It seems like there are way
too many steps involved...
--
Gregory Kick
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: dependency management within plugin dependencies
Federico, I'm aware of what it does... The question was regarding dependencies listed relative to a plugin. Wayne, The problem with pluginManagement is that I don't necessarily want a dependency for every invocation of the pluign. For example, say that have a plugin that uses the jaxb api and I want to use jaxb in some situations and jaxme in others. They have the same api so it might be reasonable to want a plugin to execute using one implementation in some instances and the other implementation in another. Additionally, I'd like to standardize the versions in the same way as I would with a typical dependency, so that I always use jaxb whatever-jaxb-version and jaxme whatever-jaxme-version. My first thought is that a dependency that is listed under a plugin should also utilize dependencyManagement, but that seems to not be the case. And, since there's no dependencyManagement under pluginManagement I wondered whether this was intentional or an oversight. Thoughts? On 12/7/06, Federico Yankelevich [EMAIL PROTECTED] wrote: Hi, dependencyManagement is inherited by children POMs. It is useful to define a dependency within dependencyManagement tag expliciting the version there. Then in the children POMs you can just declare your dependecy without having the version tag have a look here: http://maven.apache.org/pom.html#Dependency%20Management bye, Federico Gregory Kick-2 wrote: I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dependency-management-within-plugin-dependencies-tf2772190s177.html#a7735149 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency management within plugin dependencies
I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a custom archetype
Anthony, I definitely understand the feeling of being lost while trying to create archetypes. I wrote up a small thing about dealing with packages that might be of some use. On 11/19/06, franz see [EMAIL PROTECTED] wrote: Good day to you, Anthony Ryan, A Maven Project needs to have a POM. Also, the diretory structure must follow the standard set by maven (either that, or you tell maven that you're using a different directory structure). When you create archetype, you would have to create its POM and follow the directory structure just like any other maven project. Secondly, you would have to create your prototype POM and prototype files. These prototypes are what gets created when you do archetype:create. Also, you would have to create an archetype descriptor (which describes the archetype to be created). Lastly, you install (or deploy) it so that you can use it in your archetype:create. In summary, you have a POM and files for the maven project of your archetype. And some of these files are your achetype files (prototype POM, prototype files, archetype descriptor). Cheers, Franz Anthony Ryan wrote: Hi, I'm new to using maven and want to set up a custom project template archetype that will create a specific file structure and put a few key documents in specific places at the start of each new project. The trouble I'm having is in setting up this archetype. I have read the guide at http://maven.apache.org/guides/mini/guide-creating-archetypes.html but it does not say if I already need to have this file structure created to install this archetype or if having the file paths written in the sources tags in the archetype file is enough. It also gives little information on why there are two pom.xml files in the example and what is the difference between them What are the steps in creating a custom archetype? Is it: 1.. Create archtype.xml with accompanying sources tags etc 2.. 'install' this archetype using mvn install 3.. Use archetype create to use this new archetype I apologise if this seems like a basic problem but there are few clear web pages written on the subject, Many thanks for any help, Anthony Ryan -- View this message in context: http://www.nabble.com/Creating-a-custom-archetype-tf2654228s177.html#a7430064 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a custom archetype
Ah, sorry... Accidental send... The link I meant to include is: http://kickstyle.net/pebble/2006/07/19/115335810.html I hope this helps. Also, if you create an archetype that might be useful to others and has to do with javaee, consider submitting it to https://maven-archetypes.dev.java.net/ On 11/19/06, Gregory Kick [EMAIL PROTECTED] wrote: Anthony, I definitely understand the feeling of being lost while trying to create archetypes. I wrote up a small thing about dealing with packages that might be of some use. On 11/19/06, franz see [EMAIL PROTECTED] wrote: Good day to you, Anthony Ryan, A Maven Project needs to have a POM. Also, the diretory structure must follow the standard set by maven (either that, or you tell maven that you're using a different directory structure). When you create archetype, you would have to create its POM and follow the directory structure just like any other maven project. Secondly, you would have to create your prototype POM and prototype files. These prototypes are what gets created when you do archetype:create. Also, you would have to create an archetype descriptor (which describes the archetype to be created). Lastly, you install (or deploy) it so that you can use it in your archetype:create. In summary, you have a POM and files for the maven project of your archetype. And some of these files are your achetype files (prototype POM, prototype files, archetype descriptor). Cheers, Franz Anthony Ryan wrote: Hi, I'm new to using maven and want to set up a custom project template archetype that will create a specific file structure and put a few key documents in specific places at the start of each new project. The trouble I'm having is in setting up this archetype. I have read the guide at http://maven.apache.org/guides/mini/guide-creating-archetypes.html but it does not say if I already need to have this file structure created to install this archetype or if having the file paths written in the sources tags in the archetype file is enough. It also gives little information on why there are two pom.xml files in the example and what is the difference between them What are the steps in creating a custom archetype? Is it: 1.. Create archtype.xml with accompanying sources tags etc 2.. 'install' this archetype using mvn install 3.. Use archetype create to use this new archetype I apologise if this seems like a basic problem but there are few clear web pages written on the subject, Many thanks for any help, Anthony Ryan -- View this message in context: http://www.nabble.com/Creating-a-custom-archetype-tf2654228s177.html#a7430064 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: naming groupId and artifactId?
I know that this doesn't directly address the question, but I had been working with the JAXB/Codemodel group on some decent naming standards for artifactId/groupId combinations as they relate to projects and sub-projects. Since the whole naming thing came up, I though that I'd post my little writeup and see if I could get some feedback on what everybody thinks in terms of the conventions. http://kickstyle.net/pebble/2006/10/27/116201538.html Thanks. On 11/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/7/06, jiangshachina [EMAIL PROTECTED] wrote: But at Maven central repository, http://www.ibiblio.org/maven2/ I don't find any accurate regular. For example, Apache Commons projects aren't grouped as org.apache, or org.apache.commons, or apache.commons, even not commons. Each Commons project is individual groupId. That (individual group ids) was the convention for Maven 1. Changing to org.apache.commons is under discussion on the Commons development list. Because the Commons libraries are so widely used, it needs to be done very carefully. Why Maven central repo classifies jars as the regular? And how do I name goupId for 3rd-part files not hosted by Maven central repo? There are some suggestions for Sun's jars, here: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html If it's not one of those, I usually use the package name or the company's domain name (reversed) for the groupId. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven rant
site on the website too, at least for the releases. regards Adam [1] http://dev.mysql.com/doc/refman/5.0/en/linux-rpm.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick http://kickstyle.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
