Sorry about an email that was sent from my email
Hi Everyone, There was some automated mail that went out to all contacts in my address book. I was unaware of it, till I got a bunch of undelivered emails. I am so sorry for any inconvenience this has caused you. Thank you. Savitha - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[SORRY FOR SPAMMING] hibernate 3 maven plugin
Sorry for spamming you all - I ran this on the top level artifact and should of course only have done that on the plugin. Sorry - here's my 4th mail to you on the subject today. :-I -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [SORRY FOR SPAMMING] hibernate 3 maven plugin
Shows that your release process is properly set up ... ;-) Siegfried Goeschl da...@davidkarlsen.com wrote: Sorry for spamming you all - I ran this on the top level artifact and should of course only have done that on the plugin. Sorry - here's my 4th mail to you on the subject today. :-I -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [SORRY FOR SPAMMING] hibernate 3 maven plugin
+1 for the display of a good release process. On Wed, Jan 21, 2009 at 3:07 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Shows that your release process is properly set up ... ;-) Siegfried Goeschl da...@davidkarlsen.com wrote: Sorry for spamming you all - I ran this on the top level artifact and should of course only have done that on the plugin. Sorry - here's my 4th mail to you on the subject today. :-I - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Sorry to ask the questions again
I hope some one can give me some options, if the Maven dont support this issues, just tell me, That dont works. Thanks for help. 1 Can maven import some properties files outside the project? Maven can define some resource properties in the head section using the properties Tag just like this: properties tc-refund-all.version1.0.2/tc-refund-all.version tc-refund-domain.aidtc-refund-domain/tc-refund-domain.aid properties I have define the configs in a my.properties file, how can I import this config file and use it in the build process? 2 How to copy the resource files into my packaged folder in the build time? I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. I should copy that resources to that, in ant, i just use copy tag it works. but in maven, how can i copy the file to the folder? Is the antrun plugin can do this kind of things?
Re: Sorry to ask the questions again
On Wed, Oct 22, 2008 at 10:53 AM, sean.chen(陈思淼) [EMAIL PROTECTED] wrote: I hope some one can give me some options, if the Maven dont support this issues, just tell me, That dont works. Thanks for help. It's better to start a separate thread for each question, with a descriptive subject line. 1 Can maven import some properties files outside the project? Maven can define some resource properties in the head section using the properties Tag just like this: ... I have define the configs in a my.properties file, how can I import this config file and use it in the build process? Depending on how you want to use it, resource filtering might help. 2 How to copy the resource files into my packaged folder in the build time? Usually the resources plugin does this for you... anything in src/main/resources gets copied and packaged in the artifact. I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. The convention is to share things through the repository. If they are *outside* the project, then consider packaging them up into a jar or zip, and using the dependency plugin to retrieve them from the repository and place them where you need them. -- Wendy
Re: Sorry to ask the questions again
Iam sorry to ask question in this way, because Ive post these question five days ago and got no anwsers, so I post them again. I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. why we put the resource file outside the project because the resource file is different in different environment, I think maybe the antrun plugin can be our choice. 2008/10/23 Wendy Smoak [EMAIL PROTECTED] On Wed, Oct 22, 2008 at 10:53 AM, sean.chen(陈思淼) [EMAIL PROTECTED] wrote: I hope some one can give me some options, if the Maven dont support this issues, just tell me, That dont works. Thanks for help. It's better to start a separate thread for each question, with a descriptive subject line. 1 Can maven import some properties files outside the project? Maven can define some resource properties in the head section using the properties Tag just like this: ... I have define the configs in a my.properties file, how can I import this config file and use it in the build process? Depending on how you want to use it, resource filtering might help. 2 How to copy the resource files into my packaged folder in the build time? Usually the resources plugin does this for you... anything in src/main/resources gets copied and packaged in the artifact. I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. The convention is to share things through the repository. If they are *outside* the project, then consider packaging them up into a jar or zip, and using the dependency plugin to retrieve them from the repository and place them where you need them. -- Wendy
Re: Sorry to ask the questions again
If your different environments are known to you, it sounds to me like you should set up modules that produce jars containing the specifics for each environment. These jars can be distributed with your main jar to provide the resources needed by the environment. Then, either build all the various jars and have them available, or use profiles to specify which modules to build. If, on the other hand, you're talking about runtime properties that are changed on a site by site basis, that's really not a Maven issue. Dave sean.chen(陈思淼) wrote: Iam sorry to ask question in this way, because Ive post these question five days ago and got no anwsers, so I post them again. I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. why we put the resource file outside the project because the resource file is different in different environment, I think maybe the antrun plugin can be our choice. 2008/10/23 Wendy Smoak [EMAIL PROTECTED] On Wed, Oct 22, 2008 at 10:53 AM, sean.chen(陈思淼) [EMAIL PROTECTED] wrote: I hope some one can give me some options, if the Maven dont support this issues, just tell me, That dont works. Thanks for help. It's better to start a separate thread for each question, with a descriptive subject line. 1 Can maven import some properties files outside the project? Maven can define some resource properties in the head section using the properties Tag just like this: ... I have define the configs in a my.properties file, how can I import this config file and use it in the build process? Depending on how you want to use it, resource filtering might help. 2 How to copy the resource files into my packaged folder in the build time? Usually the resources plugin does this for you... anything in src/main/resources gets copied and packaged in the artifact. I define my own pakcaging type just like ear but have some customer file type process. but sometimes, the project have some resources outside the project. The convention is to share things through the repository. If they are *outside* the project, then consider packaging them up into a jar or zip, and using the dependency plugin to retrieve them from the repository and place them where you need them. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry for my last mail,i can view other files after refresh the work directory!
but still got 404 NOT_FOUND error!_ oliver.lee 2008-06-30
Re: Sorry and problem description
2008/6/23 Martin Höller [EMAIL PROTECTED]: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.6/target /configuration /plugin Why is this not present in the release-pom? First, the configuration needs not to be in the release-pom, as it's (probably) inherited from the parent which is specified in the release-pom and therefore available via a repository. I do not really understand what you mean by that. The parent pom is in a different directory and included via a relative path, which works w/o any problem for the dependencies so far. Do I have to change that to a released pom in our company maven repo? Second, where exactly do you specify this section? Within a pluginManagement section? I'm not sure wheter it is inherited if it is in pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-8859-1/encoding /configuration /plugin /plugins /pluginManagement /build /project I tried exactly this, and it's not inherited into the release-pom. I mixed things up a little bit in my first mail: dependencyManagement is for defining version of dependencies and pluginManagement is for defining versions of plugins. What I wanted to write was: | Just define the version of all plugins you are using (best in a | pluginyManagement section),... Hmm, why are the docs/FAQ's not always mention that? Are these tags kind of implicit or why do so many examples simply omit them? In any case, adding them did not really solve my problem. Thanks again! Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
Hi Andre! On Tuesday 24 June 2008 André Kelpe wrote: 2008/6/23 Martin Höller [EMAIL PROTECTED]: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.6/target /configuration /plugin Why is this not present in the release-pom? First, the configuration needs not to be in the release-pom, as it's (probably) inherited from the parent which is specified in the release-pom and therefore available via a repository. I do not really understand what you mean by that. Ok, let me explain it in more detail. What you have is a parent project P and a child project C. The child specifies its parent via parent groupIdyourGroupId/groupId artifactIdtheParentId/artifactId versionsomeVersion/version relativePath../wherever/parent/lives/relativePath /parent in the pom.xml file. Is this correct? The parent project P configures the compiler plugin via pluginManagement as described in my previous mail. Also correct? If the above is true, C should inherit the configuration from P when building. AFIAK maven does not insert the configuration from P into C's pom.xml, as the configuration can always be retreived from P's pom.xml. That's the reason why maven inserts a version tag for your parent when releasing the child. The parent pom is in a different directory and included via a relative path, which works w/o any problem for the dependencies so far. Ok, I wouldn't expect any problem here. Do I have to change that to a released pom in our company maven repo? You don't have to change that. What you have to do is, to also release your parent's project to your repo. Otherwise the build of the child couldn't complete because of missing depedencies. Unfortunately I'm not 100% sure if all details are completely correct, but the basics are. Second, where exactly do you specify this section? Within a pluginManagement section? I'm not sure wheter it is inherited if it is in pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-8859-1/encoding /configuration /plugin /plugins /pluginManagement /build /project I tried exactly this, and it's not inherited into the release-pom. What do you mean by inherited? Copyied into C's pom.xml? That's not the intention. It should be inserted into the reactor at runtime from the parent. I mixed things up a little bit in my first mail: dependencyManagement is for defining version of dependencies and pluginManagement is for defining versions of plugins. What I wanted to write was: | Just define the version of all plugins you are using (best in a | pluginyManagement section),... Hmm, why are the docs/FAQ's not always mention that? Are these tags kind of implicit or why do so many examples simply omit them? Probably because most examples want to stay simple and small. Using a pluginManagement in a parent is like specifying a default plugin version to use, if not explicitly specivied via the version tag in a subproject. See the books Better Builds with Maven and Maven - The Definitve Guide for more explanations. hth, - martin signature.asc Description: This is a digitally signed message part.
Re: Sorry and problem description
Hi Martin! 2008/6/24 Martin Höller [EMAIL PROTECTED]: [...] Ok, let me explain it in more detail. What you have is a parent project P and a child project C. The child specifies its parent via parent groupIdyourGroupId/groupId artifactIdtheParentId/artifactId versionsomeVersion/version relativePath../wherever/parent/lives/relativePath /parent in the pom.xml file. Is this correct? Yes. The parent project P configures the compiler plugin via pluginManagement as described in my previous mail. Also correct? If the above is true, C should inherit the configuration from P when building. AFIAK maven does not insert the configuration from P into C's pom.xml, as the configuration can always be retreived from P's pom.xml. That's the reason why maven inserts a version tag for your parent when releasing the child. Okay, maybe I wasn't explicit enough I am not talking about the normal use case I am talking about the usage of the release plugin, where you specify in the config to generate a release pom, like so: build plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version configuration tagBasesvn://foo/bar/baz/tagBase generateReleasePomstrue/generateReleasePoms /configuration /plugin build This is what I have in the child projects pom and this also ends up in the release-pom.xml which the release plugin generates. But what I found out is that all other plugins defined in the build tag of the _parents_ pom are completely ignored and do not end up in the release-pom.xml, which is, what I would expect as that works for all other stuff coming from the parent pom like reporting, dependencies or repositories. To make it more clear: I try to create a pom that is completely frozen (no version ranges etc.) to be checked in to be able to rebuild any release in the future w/ the ability to use version ranges during development. That is what the release plugin promises and does except for the configuration for plugins in the build section of the parent pom, from what I can see so far. I tried exactly this, and it's not inherited into the release-pom. What do you mean by inherited? Copyied into C's pom.xml? That's not the intention. It should be inserted into the reactor at runtime from the parent. As I said, the generated release-pom.xml does not contain any of the settings defined in the build tag of the parent pom. Bug? Feature? Wrong understanding? Probably because most examples want to stay simple and small. Using a pluginManagement in a parent is like specifying a default plugin version to use, if not explicitly specivied via the version tag in a subproject. See the books Better Builds with Maven and Maven - The Definitve Guide for more explanations. Will digg into those once again, but I have tried to find answers there, maybe I just overlook something obvious. Thanks again! Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
Hi again: Replying to myself: After googling and searching JIRA I found this http://jira.codehaus.org/browse/MRELEASE-294 and since it's still open. The way I intended to use the plugin does not work right now. Is there any way I can help out to get that problem fixed and a new release out? Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry and problem description
Hello again, big apologies for the premature email. Seems like I did not have enough caffeine today :-) I hope someone can help me, so here is now my problem: In the company I work for we have a somewhat big maven2 setup which is working quite good so far. We now wanted to organize our release process in a more structured way (esp. release-poms) to avoid problems with version ranges and I found the maven release plugin, which looks like it can solve all our problems. Currently I am trying to set it correctly up, but I always encounter a problem, which is that the release pom is not correctly created. For all plugins that we use the version number in the release-pom is set to RELEASE instead of the actual version number. Here is an example: This is in the master pom: [...] plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution idattach-javadocs/id goals goaljar/goal /goals /execution /executions /plugin [...] and this is what will end up in the release-pom plugin artifactIdmaven-javadoc-plugin/artifactId versionRELEASE/version -- this is the problem configuration links linkhttp://java.sun.com/javase/6/docs/api//link /links aggregatetrue/aggregate /configuration /plugin Because of these broken version numbers the verify phase will fail and I cannot use the release plugin at all. What am I doing wrong? Thanks a lot for your help and apologies for my first email. André - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
On Monday 23 June 2008 André Kelpe wrote: In the company I work for we have a somewhat big maven2 setup which is working quite good so far. We now wanted to organize our release process in a more structured way (esp. release-poms) to avoid problems with version ranges and I found the maven release plugin, which looks like it can solve all our problems. Currently I am trying to set it correctly up, but I always encounter a problem, which is that the release pom is not correctly created. For all plugins that we use the version number in the release-pom is set to RELEASE instead of the actual version number. Here is an example: This is in the master pom: [...] plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution idattach-javadocs/id goals goaljar/goal /goals /execution /executions /plugin [...] and this is what will end up in the release-pom plugin artifactIdmaven-javadoc-plugin/artifactId versionRELEASE/version -- this is the problem configuration links linkhttp://java.sun.com/javase/6/docs/api//link /links aggregatetrue/aggregate /configuration /plugin You probably didn't define a version for the maven-javadoc-plugin in this projects pom or a parent pom, so maven (prior to 2.0.9) defaults to RELEASE. Just define the version of all plugins you are using (best in a dependencyManagement section), which is a best practice anyway. This should solve your problem. hth, - martin signature.asc Description: This is a digitally signed message part.
Re: Sorry and problem description
Hi Martin! 2008/6/23 Martin Höller [EMAIL PROTECTED]: You probably didn't define a version for the maven-javadoc-plugin in this projects pom or a parent pom, so maven (prior to 2.0.9) defaults to RELEASE. You were right, I didn't do that. I updated the parent pom and now I can enter the validation phase but there I encounter the next problem: The forked validate tries to compile all sources with compliance level 1.3 which will fail b/c we use generics etc. The strange thing is that the parent pom sets the compiler plugin to compliance level 1.6, which was never a problem, but somehow this setting is not carried over into the release-pom.xml. Here is how the compiler plugin is configured in the parent pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.6/target /configuration /plugin Why is this not present in the release-pom? Just define the version of all plugins you are using (best in a dependencyManagement section), which is a best practice anyway. This should solve your problem. Never heard of the dependencyManagement before, will take a look. Thanks! Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
On Monday 23 June 2008 André Kelpe wrote: Hi Martin! 2008/6/23 Martin Höller [EMAIL PROTECTED]: You probably didn't define a version for the maven-javadoc-plugin in this projects pom or a parent pom, so maven (prior to 2.0.9) defaults to RELEASE. You were right, I didn't do that. I updated the parent pom and now I can enter the validation phase but there I encounter the next problem: The forked validate tries to compile all sources with compliance level 1.3 which will fail b/c we use generics etc. The strange thing is that the parent pom sets the compiler plugin to compliance level 1.6, which was never a problem, but somehow this setting is not carried over into the release-pom.xml. Here is how the compiler plugin is configured in the parent pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.6/target /configuration /plugin Why is this not present in the release-pom? First, the configuration needs not to be in the release-pom, as it's (probably) inherited from the parent which is specified in the release-pom and therefore available via a repository. Second, where exactly do you specify this section? Within a pluginManagement section? I'm not sure wheter it is inherited if it is in pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-8859-1/encoding /configuration /plugin /plugins /pluginManagement /build /project Just define the version of all plugins you are using (best in a dependencyManagement section), which is a best practice anyway. This should solve your problem. Never heard of the dependencyManagement before, will take a look. I mixed things up a little bit in my first mail: dependencyManagement is for defining version of dependencies and pluginManagement is for defining versions of plugins. What I wanted to write was: | Just define the version of all plugins you are using (best in a | pluginyManagement section),... hth, - martin signature.asc Description: This is a digitally signed message part.
Sorry
I feel so sorry about my insistence. But I have a little problem that still
can't resolve. I want to put a section at the menisfest using this code:
build
!--defaultGoalpackage/defaultGoal--
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
!--modedevelopment/mode
url${pom.url}/url--
Java-Version${java.version}/Java-Version
Build-Platform${os.name} ${os.arch}
${os.version}/Build-Platform
Built-By${user.name}/Built-By
Class-Path${manifest.classpath}
SaiphST-ejbClient.jar/Class-Path
section
Namebr/com/saiph/st/ejb/Name
Specification-TitleSaiphST-ejb API/Specification-Title
Specification-Version${saiph.rel}_${saiph.ver}/Specification-Version
Specification-VendorExtend.Net Ltda./Specification-Vendor
Implementation-Titlebr.com.saiph.st.ejb/Implementation-Title
Implementation-Version${saiph.rel}_${saiph.ver}
${TODAY}/Implementation-Version
Implementation-VendorExtend.Net Ltda./Implementation-Vendor
/section
/manifestEntries
/archive
/configuration
/plugin
/plugins
/build
Informations above section are shown, but inside not. I just want to put a
section in the file. How can I do it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry
I haven't used this functionality, so I can't confirm this will work but try
using manifestSection as described here
http://maven.apache.org/shared/maven-archiver/index.html (the jar plugin
references this plugin for details about manifest generation).
On Jan 22, 2008 11:20 AM, Arthur Rodrigues Stilben
[EMAIL PROTECTED] wrote:
I feel so sorry about my insistence. But I have a little problem that
still can't resolve. I want to put a section at the menisfest using this
code:
build
!--defaultGoalpackage/defaultGoal--
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
!--modedevelopment/mode
url${pom.url}/url--
Java-Version${java.version}/Java-Version
Build-Platform${os.name} ${os.arch} ${os.version
}/Build-Platform
Built-By${user.name}/Built-By
Class-Path${manifest.classpath} SaiphST-ejbClient.jar
/Class-Path
section
Namebr/com/saiph/st/ejb/Name
Specification-TitleSaiphST-ejb API/Specification-Title
Specification-Version${saiph.rel}_${saiph.ver
}/Specification-Version
Specification-VendorExtend.NetLtda./Specification-Vendor
Implementation-Titlebr.com.saiph.st.ejb
/Implementation-Title
Implementation-Version${saiph.rel}_${saiph.ver}
${TODAY}/Implementation-Version
Implementation-VendorExtend.NetLtda./Implementation-Vendor
/section
/manifestEntries
/archive
/configuration
/plugin
/plugins
/build
Informations above section are shown, but inside not. I just want to put
a section in the file. How can I do it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry
This works:
manifestSections
manifestSection
namecom/company/mine/name
manifestEntries
Currently using it.
Kalle
On 1/22/08, Arthur Rodrigues Stilben [EMAIL PROTECTED]
wrote:
I feel so sorry about my insistence. But I have a little problem that
still can't resolve. I want to put a section at the menisfest using this
code:
build
!--defaultGoalpackage/defaultGoal--
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
!--modedevelopment/mode
url${pom.url}/url--
Java-Version${java.version}/Java-Version
Build-Platform${os.name} ${os.arch} ${os.version
}/Build-Platform
Built-By${user.name}/Built-By
Class-Path${manifest.classpath} SaiphST-ejbClient.jar
/Class-Path
section
Namebr/com/saiph/st/ejb/Name
Specification-TitleSaiphST-ejb API/Specification-Title
Specification-Version${saiph.rel}_${saiph.ver
}/Specification-Version
Specification-VendorExtend.NetLtda./Specification-Vendor
Implementation-Titlebr.com.saiph.st.ejb
/Implementation-Title
Implementation-Version${saiph.rel}_${saiph.ver}
${TODAY}/Implementation-Version
Implementation-VendorExtend.NetLtda./Implementation-Vendor
/section
/manifestEntries
/archive
/configuration
/plugin
/plugins
/build
Informations above section are shown, but inside not. I just want to put
a section in the file. How can I do it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RES: Sorry
Thank you for help!
Arthur Rodrigues Stilben
De: Kalle Korhonen [EMAIL PROTECTED]
Enviado: terça-feira, 22 de janeiro de 2008 15:36
Para: Maven Users List
Assunto: Re: Sorry
This works:
manifestSections
manifestSection
namecom/company/mine/name
manifestEntries
Currently using it.
Kalle
On 1/22/08, Arthur Rodrigues Stilben [EMAIL PROTECTED]
wrote:
I feel so sorry about my insistence. But I have a little problem that
still can't resolve. I want to put a section at the menisfest using this
code:
build
!--defaultGoalpackage/defaultGoal--
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
!--modedevelopment/mode
url${pom.url}/url--
Java-Version${java.version}/Java-Version
Build-Platform${os.name} ${os.arch} ${os.version
}/Build-Platform
Built-By${user.name}/Built-By
Class-Path${manifest.classpath} SaiphST-ejbClient.jar
/Class-Path
section
Namebr/com/saiph/st/ejb/Name
Specification-TitleSaiphST-ejb API/Specification-Title
Specification-Version${saiph.rel}_${saiph.ver
}/Specification-Version
Specification-VendorExtend.NetLtda./Specification-Vendor
Implementation-Titlebr.com.saiph.st.ejb
/Implementation-Title
Implementation-Version${saiph.rel}_${saiph.ver}
${TODAY}/Implementation-Version
Implementation-VendorExtend.NetLtda./Implementation-Vendor
/section
/manifestEntries
/archive
/configuration
/plugin
/plugins
/build
Informations above section are shown, but inside not. I just want to put
a section in the file. How can I do it?
-
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]
Sorry email test
Sorry email test
Re: server certificate verification failed (sorry, offtopic)
I wonder if we are talking at cross purposes. Our subversion repository is actually hosted with a thirdparty (collabnet) and I believe they have changed their certificate and to one that isn't trusted by a root certificate. Therefore unless I am missing yet another point, I don't believe we can have any influence over this. If our repository was inhouse, then what you are are saying would make sense to me. Graham Leggett [EMAIL PROTECTED] wrote on 15/10/2007 14:26:02: On Mon, October 15, 2007 3:08 pm, Ashley Williams wrote: Although I would have thought the issue of whether or not I trust a particular site is different from whether my continuum installation is connecting me to the site I think it should be. SSL performs two functions - one to obscure the data in transit to protect from eavesdropping, the second to ensure that you are talking to the right party so that you don't end up giving away secrets to imposters. So can you give guidance as to what my action should be? Each developer has just been hitting the 'accept permanently' button in subclipse in their own workspaces. Ideally you need to deploy a certificate onto your server that is trusted by a root certificate. The root certificate gets installed on all your clients in some kind of trusted fashion. When the svn client connects to the svn server, it says Oh, you gave me a cert, is this cert signed by one of the root certs I have locally trusted? Yes? Come on right in. When your developers are trained to just hit p, what they are effectively doing is saying trust anybody, even disgruntled employee's fake server three cubicles down. The quickest way to get a certificate that's trusted by a root certificate is to buy one from a certificate authority. You don't need to buy a certificate with onerous identity checking, because you trust yourself already. A cheaper alternative is to create a root certificate yourself using a toolkit like openssl. Don't create a self signed cert, as it doesn't offer you the same protection. So should we be thoroughly investigating the proposed certificate before doing this, since a glance at the certificate hostname field looks fine to me ( *.ibitdev.com). Continuum is in a dmz and has not been reconfigured since the last build, so I am fairly certain it is connecting to the correct url. The only way continuum can be sure the correct URL is being used is if the certificate presented is trusted by a CA certificate on svn (via continuum)'s list of trusted CA certificates. If continuum breaks expecting a p, it means something weird or dogy is going on on your network, which warrants investigation. Regards, Graham -- --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: server certificate verification failed (sorry, offtopic)
On Mon, October 15, 2007 3:54 pm, Ashley Williams wrote: I wonder if we are talking at cross purposes. Our subversion repository is actually hosted with a thirdparty (collabnet) and I believe they have changed their certificate and to one that isn't trusted by a root certificate. Therefore unless I am missing yet another point, I don't believe we can have any influence over this. I would seriously doubt that a company that offers commercial svn hosting would expect customers to accept a self signed certificate. It would pay to query them and check, they may only supply you with the root certificate if you ask for it. Regards, Graham --
sorry!
Hi all, just to appologies for the last email, I accidently sent gmail invitation on the mailing list... sorry again and have a nice day! Jeremy
SORRY!!!
Sorry everybody - this is so emberrasing!!! I just realized that I sent the last mails to [EMAIL PROTECTED] ... instead of [EMAIL PROTECTED] Sorry, I promise it won't happen again. Andreas Ebbert-Karroum Senior Software Design Engineer - Nokia Networks Services / Middleware phone: +49-211-94123928, fax: +49-211-94123838 Heltorfer Straße 1, 40472 Düsseldorf, Germany This message is confidential. If you have received this message in error, please delete it from your system. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and therefore Nokia GmbH does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. Thank you. Nokia GmbH, Nokia Networks is a German Company. Further information about the Company is available from its principal offices at Heltorferstrasse 1, D-40472, Düsseldorf, Germany and from the website at http://www.nokia.com/
Re: NullPointerEXception , Sorry to insist guys
Other people are reporting similar problems. I don't use site right now, so I don't get it, but this is a pretty common complaint just recently. Search the Maven Users archive -- perhaps there's a fix? Otherwise try to find your bug (with a fix?) on JIRA... http://jira.codehaus.org/browse/MSITE Wayne On 3/1/06, Gianfranco Oldani [EMAIL PROTECTED] wrote: I cannot go out of my problem (and now its becoming urgent) of NullPointerEXception while invoking the site plugin via : mvn site I use maven 2.02. Thanks for help. _ Sélectionnez les meilleurs albums pour votre discothèque MP3 en ligne! http://sib1.od2.com/common/Framework.aspx?shid=0045002E - 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: NullPointerEXception , Sorry to insist guys
On 3/1/06, Gianfranco Oldani [EMAIL PROTECTED] wrote: I cannot go out of my problem (and now its becoming urgent) of NullPointerEXception while invoking the site plugin via : mvn site I use maven 2.02. If you aren't going to read the posting guildelines when discussing a bug, how do you expect people to help you? You at least need to run mvn -X and attach the NPE stacktrace. I've been happily using site fine. I had some initial NPEs because some resources did not exist, say LICENSE.txt or something, but the stack trace error messages told me exactly what needed fixing. Not the most user friendly way to show errors, but enough for a decent developer to work out what to do to solve the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerEXception , Sorry to insist guys
Thanks for your answer and the various advises. In the meantime I have found the problem and it was only a wrong reference in a plugin section. Cheers Gianfranco PS: I will read all guidelines from now on...;o)) Original Message Follows From: Barrie Treloar [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: Maven Users List users@maven.apache.org Subject: Re: NullPointerEXception , Sorry to insist guys Date: Thu, 2 Mar 2006 06:46:58 +1030 On 3/1/06, Gianfranco Oldani [EMAIL PROTECTED] wrote: I cannot go out of my problem (and now its becoming urgent) of NullPointerEXception while invoking the site plugin via : mvn site I use maven 2.02. If you aren't going to read the posting guildelines when discussing a bug, how do you expect people to help you? You at least need to run mvn -X and attach the NPE stacktrace. I've been happily using site fine. I had some initial NPEs because some resources did not exist, say LICENSE.txt or something, but the stack trace error messages told me exactly what needed fixing. Not the most user friendly way to show errors, but enough for a decent developer to work out what to do to solve the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sélectionnez les meilleurs albums pour votre discothèque MP3 en ligne! http://sib1.od2.com/common/Framework.aspx?shid=0045002E - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NullPointerEXception , Sorry to insist guys
I cannot go out of my problem (and now its becoming urgent) of NullPointerEXception while invoking the site plugin via : mvn site I use maven 2.02. Thanks for help. _ Sélectionnez les meilleurs albums pour votre discothèque MP3 en ligne! http://sib1.od2.com/common/Framework.aspx?shid=0045002E - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry for the double posting (n.T.)
Re: [m2] eclipse plugin broken (sorry,still in the same way)
Actually forget my last comment I've just seen that eclipse:eclipse
fails in the same way in the following method:
private static String toRelative( File basedir, String
absolutePath )
{
String relative;
if ( absolutePath.startsWith( basedir.getAbsolutePath() ) )
{
JUST HERErelative = absolutePath.substring
( basedir.getAbsolutePath().length() + 1 );
}
else
{
relative = absolutePath;
}
relative = StringUtils.replace( relative, \\, / );
return relative;
}
exception is java.lang.StringIndexOutOfBoundsException: String index
out of range: -1
Also if I wanted to do a local fix, how easy is it to build the
eclipse plugin on its own and get it into my repository??
Thanks
- AW
On 2 Sep 2005, at 17:17, Ashley Williams wrote:
Ok the latest maven seems to work despite the build exception and
happily I was able to run the eclipse:eclipse goal successfully.
However when I open the project in eclipse the files appear under
the (default package) node which means eclipse red crosses
everywhere. This despite the fact that the source code was created
under com.blah and installed okay.
On 2 Sep 2005, at 16:27, Ashley Williams wrote:
Oh happy day - not!
Just had a glance at my console only to see the pasted text below
- is this going to be a build breaker? I'm using Java 5 by
default, is this a mistake?? Also Mac OS X doesn't appear to have
a tools.jar file.
COPY AND PASTE...
Running maven-core integration tests ...
Using default local repository: /Users/developer/.m2/repository
it0063... FAILED
- Standard Out -
Command: /Applications/maven-latest/bin/m2 -e --no-plugin-registry
--batch-mode -Dmaven.repo.local=/Users/developer/.m2/repository
clean:clean package
- Standard Error -
Exit code: 1
Error Stacktrace:
org.apache.maven.it.VerificationException
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:
574)
at org.apache.maven.it.Verifier.main(Verifier.java:677)
Error Stacktrace
Log file contents:
+ Error stacktraces are turned on.
[INFO] Searching repository for plugin with prefix: 'clean'.
[INFO]
-
---
[INFO] Building org.apache.maven.it:maven-core-it0063:jar:1.0
[INFO]task-segment: [clean:clean, package]
[INFO]
-
---
[INFO] [clean:clean]
[INFO] [resources:resources]
[INFO]
-
---
[INFO] BUILD FAILURE
[INFO]
-
---
[INFO] Main Error:
System artifact: jdk-tools:jdk-tools:jar:1.4.2 not found in
path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
Home/../lib/tools.jar
jdk-tools:jdk-tools:1.4.2:jar
Path to dependency:
1) org.apache.maven.it:maven-core-it0063:jar:1.0
2) jdk-tools:jdk-tools:jar:1.4.2
Root error:
System artifact: jdk-tools:jdk-tools:jar:1.4.2 not found in
path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
Home/../lib/tools.jar
jdk-tools:jdk-tools:1.4.2:jar
Path to dependency:
1) org.apache.maven.it:maven-core-it0063:jar:1.0
2) jdk-tools:jdk-tools:jar:1.4.2
On 2 Sep 2005, at 15:52, Trygve Laugstøl wrote:
On Fri, Sep 02, 2005 at 03:34:59PM +0100, Ashley Williams wrote:
Don't understand what you're saying the problem is, but will the
fix
be quick, i.e. 10 minutes?? If so then I don't mind waiting...
Try now.
--
Trygve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Clover: getting error Sorry, you are not licensed to use the requested feature
Hi We just purchased a workstation license for clover. Previously we were using the 30 evaluation license which is downloaded via the maven environment. I intially tried to simply add the license to the existing clover-ant-1.3_01.jar but that didn't work. We then downloaded the Clover Version 1.3.4 from the Cenqua web site and attempted load the new clover.jar using different methods. attempt #1 - copying the new clover.jar over the existing clover-ant-1.3_01.jar attempt #2 - updated my build.properties to explicately point to the correct goodies. maven.clover.license.path=/home/saba/license/clover.license maven.clover.jar=/home/saba/clover-1.3.4/lib/clover.jar It looks like it's picking up the correct clover jar file however I'm still getting Sorry, you are not licensed to use the requested feature. with all my attempts. I can recall others on this list having Clover license issues. Was this one of the problems that's easily resolved? Do the clover licenses from Cenqua use current username or hostname in the license key. My manager gave me this license and I'm not sure what information was provided to create it. I'll forward this to Cenqua if I don't get a response however they are on the other side of the planet. I'd like to finish this today so I thought I'd start with the global Maven Experts. Thanks Tim __ __ clover:test: clover:init: clover:on: [echo] Setting Clover compiler [clover-setup] Clover Version 1.3.4, built on January 14 2005 [clover-setup] loaded from: /home/saba/.maven/repository/clover/jars/clover-ant-1.3_01.jar [clover-setup] Workstation License registered to [EMAIL PROTECTED], Sendmail, Inc. [clover-setup] Clover is enabled with initstring '/home/saba/saba/work/appliance-gui-1-0/1108667231/work/mmc-appl-mgmt/target/clover/database/clover_coverage.db' [echo] Now using primary build.compiler : org.apache.tools.ant.taskdefs.CloverCompilerAdapter java:prepare-filesystem: java:compile: [echo] Compiling to /home/saba/saba/work/appliance-gui-1-0/1108667231/work/mmc-appl-mgmt/target/clover/classes java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: test:test: [junit] Running com.sendmail.jsf.sitemap.SiteMapTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.673 sec clover:off: clover:init: Overriding previous definition of reference to clover.classpath clover:report: clover:html-report-internal: [clover-report] Clover Version 1.3.4, built on January 14 2005 [clover-report] loaded from: /home/saba/.maven/repository/clover/jars/clover-ant-1.3_01.jar [clover-report] Workstation License registered to [EMAIL PROTECTED], Sendmail, Inc. BUILD FAILED File.. /home/saba/.maven/cache/maven-clover-plugin-1.6/plugin.jelly Element... ant:clover-report Line.. 289 Column 24 Sorry, you are not licensed to use the requested feature. Total time: 6 seconds Finished at: Thu Feb 17 13:31:01 PST 2005 ## maven debug output at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: /home/saba/.maven/cache/maven-clover-plugin-1.6/plugin.jelly:289:24: ant:clover-report Sorry, you are not licensed to use the requested feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clover: getting error Sorry, you are not licensed to use the requested feature
I guess I didn't read the fine print. :( You cannot create reports with a Workstation license. That's where it's failing b) Workstation Edition A Workstation Edition license entitles the licensee to use Clover Workstation Edition on one (1) machine by one (1) individual end user. Workstation Edition does not permit the generation of reports for distribution. Thanks anyway Tim Tim Brazil wrote: Hi We just purchased a workstation license for clover. Previously we were using the 30 evaluation license which is downloaded via the maven environment. I intially tried to simply add the license to the existing clover-ant-1.3_01.jar but that didn't work. We then downloaded the Clover Version 1.3.4 from the Cenqua web site and attempted load the new clover.jar using different methods. attempt #1 - copying the new clover.jar over the existing clover-ant-1.3_01.jar attempt #2 - updated my build.properties to explicately point to the correct goodies. maven.clover.license.path=/home/saba/license/clover.license maven.clover.jar=/home/saba/clover-1.3.4/lib/clover.jar It looks like it's picking up the correct clover jar file however I'm still getting Sorry, you are not licensed to use the requested feature. with all my attempts. I can recall others on this list having Clover license issues. Was this one of the problems that's easily resolved? Do the clover licenses from Cenqua use current username or hostname in the license key. My manager gave me this license and I'm not sure what information was provided to create it. I'll forward this to Cenqua if I don't get a response however they are on the other side of the planet. I'd like to finish this today so I thought I'd start with the global Maven Experts. Thanks Tim __ __ clover:test: clover:init: clover:on: [echo] Setting Clover compiler [clover-setup] Clover Version 1.3.4, built on January 14 2005 [clover-setup] loaded from: /home/saba/.maven/repository/clover/jars/clover-ant-1.3_01.jar [clover-setup] Workstation License registered to [EMAIL PROTECTED], Sendmail, Inc. [clover-setup] Clover is enabled with initstring '/home/saba/saba/work/appliance-gui-1-0/1108667231/work/mmc-appl-mgmt/target/clover/database/clover_coverage.db' [echo] Now using primary build.compiler : org.apache.tools.ant.taskdefs.CloverCompilerAdapter java:prepare-filesystem: java:compile: [echo] Compiling to /home/saba/saba/work/appliance-gui-1-0/1108667231/work/mmc-appl-mgmt/target/clover/classes java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: test:test: [junit] Running com.sendmail.jsf.sitemap.SiteMapTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.673 sec clover:off: clover:init: Overriding previous definition of reference to clover.classpath clover:report: clover:html-report-internal: [clover-report] Clover Version 1.3.4, built on January 14 2005 [clover-report] loaded from: /home/saba/.maven/repository/clover/jars/clover-ant-1.3_01.jar [clover-report] Workstation License registered to [EMAIL PROTECTED], Sendmail, Inc. BUILD FAILED File.. /home/saba/.maven/cache/maven-clover-plugin-1.6/plugin.jelly Element... ant:clover-report Line.. 289 Column 24 Sorry, you are not licensed to use the requested feature. Total time: 6 seconds Finished at: Thu Feb 17 13:31:01 PST 2005 ## maven debug output at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: /home/saba/.maven/cache/maven-clover-plugin-1.6/plugin.jelly:289:24: ant:clover-report Sorry, you are not licensed to use the requested feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry for the confusion Was: howto: request committer status
No, sorry Brett for the confusion, there is no patch and I wasn't trying to get anything through at least not yet... it was nothing you did. The thread is born out of pure frustration on my part for trying to not have the RFE dismissed out of hand because someone can't be bothered to RTFM. What I was asking for was a simple property switch so that when a war was built, I could have the project classes bundled into a jar and added to the WEB-INF/lib dir instead of unpacked in the WEB-INF/classes dir. I'm doing this because I'm using the package versioning spec, see: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html Now, this thread has grown because I keep getting some kind of garbage about war files and the servlet spec, witch has nothing to do with what I'm talking about and from my perspective the antagonist in question can't be bother to understand how 1) a servlet container works. 2) how the package versioning spec. works. Now, I appear to not be eloquent enough for some people around here. Maybe this can all be put to rest if someone can explain the difference between a war and a jar and that the servlet spec and the versioning spec. have little to do with one another. Am I talking out my rear here or does anyone at all understand what I'm talking about? - Brill Pappin Brett Porter wrote: No idea what patch, but it was probably me that rejected it. Sorry if it caused an offence, but I always try to give a reason that something is not suitable. If I didn't, or you don't think it's correct, you're welcome to continue to debate it in the relevant JIRA issue, or take it up on the -dev list if you want the opinion of other committers. The user list is the wrong place for this discussion. Let's keep it to the user's questions. But if after all that the -dev list has also not supported the patch or there have been no additional response, you might have to accept that we've been doing this longer and probably know better :) It's not a unique situation - even when I commit stuff I get rebuked for it sometimes because other developers don't agree - and when they've been doing it longer than I have I accept that they probably know better :) Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry for the confusion Was: howto: request committer status
On Wed, 30 Jun 2004 10:18:04 -0400, Brill Pappin [EMAIL PROTECTED] wrote: [snip] Am I talking out my rear here or does anyone at all understand what I'm talking about? Brill, since the war plugin already compiles java code (indirectly by running the tests), it would seem a reasonable alternative to either allow the compiled code to be placed in WEB-INF/classes (as it is at the moment), or jar'ed up and placed in WEB-INF/lib as if it was an ordinary jar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sorry about gmail request going into list!
... was in a hurry, and forgot to remove default reply! Sorry! :( regards, Bent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sorry
sorry about the double post there, mozilla is playing up at the moment. -- I am taking part in Flora London Marathon 2003 on behalf of Breakthrough Breast Cancer Please click on a link below to support me! http://www.bmycharity.com/breakthrough/event.asp?eventid=BE3CD43A-0243-44BB-A564-40A0B38C075C or http://www.geocities.com/neilblue/index.html or http://www.geocities.com/neilblue/marathon.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
