Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Creating archetypes and disabling velocity
I wanted to add to my last message. I found some instructions on using
archetype:create-from-project to create a new archetype. I followed them to
create a new archetype project. This had a slightly different file layout
than the webapp archetype I was trying to customize before. However, I'm
still having the same problem I did before. Specifically, archetype:create
seems to be trying to send every file through the velocity system.
The archetype:create-from-project did create an archetype-metadata.xml file
which I've modified as such in an attempt to completely remove all filtering
from my archetype.
?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=ColdFusion-archetype
fileSets
fileSet filtered=false packaged=true
directorysrc/main/directory
includes
include**/*.cfm/include
/includes
/fileSet
/fileSets
/archetype-descriptor
Unfortuantly, when I run archetype:create I'm still getting the same errors
from velocity. Am I going about this the right way? Is there any good
documentation on this stuff? Or maybe a useful book I could buy?
Thanks,
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Sat, May 9, 2009 at 11:06 PM, Doug Hughes dhug...@alagad.com wrote:
Hi,
I'm in the process of creating my first archetype. I've based it on the
simple-webapp archetype, but I've added the entire ColdFusion application.
This is 4114 files total. I can build and install the archetype just fine
using mvn install just fine. However, when I use mvn archetype:create to
create a new project based on my archetype I get this in the resulting
output:
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 20] : $coldfusion is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 31] : $tagext is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 38] : $lang is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 43] : $RegistryTag is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 62,column 244] : $Lcoldfusion is not a valid reference.
[ERROR] ResourceManager.getResource() parse exception:
org.apache.velocity.exception.ParseErrorException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 206,
column 35. Encountered: EOF after :
I think that what's going on is that the Velosity templating system is
seeing $ or ${ or something like that in the ColdFusion files. I'm trying
to find a way to tell velosity to ignore these files. Any tips on this?
I've read every line of documentation on the archetype plugin I can find,
but there's no clear answer.
I did find one page which discussed a file called archetype-metadata.xml.
The simple-webapp archetype I based this on didn't have one of these files.
I added it under src/main/resources/META-INF/maven, with the following XML,
but it didn't seem to have any effect at all the next time I tried to create
my archetype:
?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=basic
fileSets
fileSet filtered=false packaged=true
directorysrc/main/directory
includes
include**/*.*/include
/includes
/fileSet
/fileSets
/archetype-descriptor
I get the impression that there are two versions of the archetype plugin
and that the I might be building my archetype based on documentation on the
archetype 1 plugin and that the archetype-metadata.xml file is specific to
version 2?
Thanks for your help,
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
Download report
Hi, Is it possible to generate a download report with maven 2 as with xdoc plugin in maven 1? I cannot find any information about this. How do you create your download pages? Or is this not an intention of maven? Thanks Daniel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Creating archetypes and disabling velocity
Sorry to keep harping on this topic. I'm hoping someone can offer some
advice. :)
As a last test, I intentionally put invalid XML in the
archetype-metadata.xml file. I was able to run archetype:create without it
reporting an XML error. This tells me it's ignoring my metadata file
anyhow any ideas on what I can do to work around this?
Thanks,
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Sun, May 10, 2009 at 8:58 AM, Doug Hughes dhug...@alagad.com wrote:
I wanted to add to my last message. I found some instructions on using
archetype:create-from-project to create a new archetype. I followed them to
create a new archetype project. This had a slightly different file layout
than the webapp archetype I was trying to customize before. However, I'm
still having the same problem I did before. Specifically, archetype:create
seems to be trying to send every file through the velocity system.
The archetype:create-from-project did create an archetype-metadata.xml file
which I've modified as such in an attempt to completely remove all filtering
from my archetype.
?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=ColdFusion-archetype
fileSets
fileSet filtered=false packaged=true
directorysrc/main/directory
includes
include**/*.cfm/include
/includes
/fileSet
/fileSets
/archetype-descriptor
Unfortuantly, when I run archetype:create I'm still getting the same errors
from velocity. Am I going about this the right way? Is there any good
documentation on this stuff? Or maybe a useful book I could buy?
Thanks,
Doug Hughes, President
Alagad Inc.
dhug...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Sat, May 9, 2009 at 11:06 PM, Doug Hughes dhug...@alagad.com wrote:
Hi,
I'm in the process of creating my first archetype. I've based it on the
simple-webapp archetype, but I've added the entire ColdFusion application.
This is 4114 files total. I can build and install the archetype just fine
using mvn install just fine. However, when I use mvn archetype:create to
create a new project based on my archetype I get this in the resulting
output:
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 20] : $coldfusion is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 31] : $tagext is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 38] : $lang is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 17,column 43] : $RegistryTag is not a valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm
[line 62,column 244] : $Lcoldfusion is not a valid reference.
[ERROR] ResourceManager.getResource() parse exception:
org.apache.velocity.exception.ParseErrorException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 206,
column 35. Encountered: EOF after :
I think that what's going on is that the Velosity templating system is
seeing $ or ${ or something like that in the ColdFusion files. I'm trying
to find a way to tell velosity to ignore these files. Any tips on this?
I've read every line of documentation on the archetype plugin I can find,
but there's no clear answer.
I did find one page which discussed a file called archetype-metadata.xml.
The simple-webapp archetype I based this on didn't have one of these files.
I added it under src/main/resources/META-INF/maven, with the following XML,
but it didn't seem to have any effect at all the next time I tried to create
my archetype:
?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=basic
fileSets
fileSet filtered=false packaged=true
directorysrc/main/directory
includes
include**/*.*/include
/includes
/fileSet
/fileSets
/archetype-descriptor
I get the impression that there are two versions of the archetype plugin
and that the I might be building my archetype based on documentation on the
archetype 1 plugin and that the archetype-metadata.xml file is specific to
version 2?
Thanks for your help,
Doug Hughes, President
Alagad Inc.
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Message that artifact is already unpacked
I have an unpack execution which opens up a zip file in my deployment directory. However, even when the target files are NOT in place, Maven usually says that the zip is already unpacked as follows [INFO] runtimelib-1.0.1.zip already unpacked. If I change overWritefalse/overWrite to true, and re-run, then the zip gets correctly unpacked, but I do want to be able to set overWrite to false and let Maven detect whether the target files are there already. The relevant parts of the pom are below. (Using Maven Integration for Eclipse 0.9.7.) Thanks, MG plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idunpack/id phaseinitialize/phase goals goalunpack/goal /goals /execution /executions configuration artifactItems artifactItem artifactIdruntimelib/artifactId groupIdcom.foo.libs/groupId version1.0.1/version typezip/type overWritefalse/overWrite includes**/*/includes /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration ...
RE: Creating archetypes and disabling velocity
can you display the maven-metadata.xml (and your project's pom.xml) and display the command you are using which *should* reproduce this error? thanks, Martin __ Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: dhug...@alagad.com Date: Sun, 10 May 2009 09:13:14 -0400 Subject: Re: Creating archetypes and disabling velocity To: users@maven.apache.org Sorry to keep harping on this topic. I'm hoping someone can offer some advice. :) As a last test, I intentionally put invalid XML in the archetype-metadata.xml file. I was able to run archetype:create without it reporting an XML error. This tells me it's ignoring my metadata file anyhow any ideas on what I can do to work around this? Thanks, Doug Hughes, President Alagad Inc. dhug...@alagad.com 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Sun, May 10, 2009 at 8:58 AM, Doug Hughes dhug...@alagad.com wrote: I wanted to add to my last message. I found some instructions on using archetype:create-from-project to create a new archetype. I followed them to create a new archetype project. This had a slightly different file layout than the webapp archetype I was trying to customize before. However, I'm still having the same problem I did before. Specifically, archetype:create seems to be trying to send every file through the velocity system. The archetype:create-from-project did create an archetype-metadata.xml file which I've modified as such in an attempt to completely remove all filtering from my archetype. ?xml version=1.0 encoding=UTF-8? archetype-descriptor name=ColdFusion-archetype fileSets fileSet filtered=false packaged=true directorysrc/main/directory includes include**/*.cfm/include /includes /fileSet /fileSets /archetype-descriptor Unfortuantly, when I run archetype:create I'm still getting the same errors from velocity. Am I going about this the right way? Is there any good documentation on this stuff? Or maybe a useful book I could buy? Thanks, Doug Hughes, President Alagad Inc. dhug...@alagad.com 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Sat, May 9, 2009 at 11:06 PM, Doug Hughes dhug...@alagad.com wrote: Hi, I'm in the process of creating my first archetype. I've based it on the simple-webapp archetype, but I've added the entire ColdFusion application. This is 4114 files total. I can build and install the archetype just fine using mvn install just fine. However, when I use mvn archetype:create to create a new project based on my archetype I get this in the resulting output: [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template = archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm [line 17,column 20] : $coldfusion is not a valid reference. [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template = archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm [line 17,column 31] : $tagext is not a valid reference. [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template = archetype-resources/src/main/webapp/CFIDE/adminapi/_datasource/getaccessdefaultsfromregistry.cfm [line 17,column 38] : $lang is not a valid reference. [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template =
Re: Creating archetypes and disabling velocity
On Sun, May 10, 2009 at 3:13 PM, Doug Hughes dhug...@alagad.com wrote:
As a last test, I intentionally put invalid XML in the
archetype-metadata.xml file. I was able to run archetype:create without it
reporting an XML error. This tells me it's ignoring my metadata file
anyhow any ideas on what I can do to work around this?
I think, this file is only used, if you use the archetype:generate goal.
[line 17,column 31] : $tagext is not a valid reference.
For the references that should go unchanged into the generated sources
I usually do
#set ($d = $)
... ${d}{target} ...
This will expand to ${target} and will not raise a warning.
- Henry
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Creating archetypes and disabling velocity
Rather than editing my source files, is there not a way to disable
velocity for spcific files or folders? I ask because some of the
problem files in my archetype are binary. I'm not too comfortable
editing those by hand as you suggest. And I think they may be related
to the problems I'm seeing.
Thanks,
Doug
On May 10, 2009, at 12:41 PM, Heinrich Nirschl heinrich.nirs...@gmail.com
wrote:
On Sun, May 10, 2009 at 3:13 PM, Doug Hughes dhug...@alagad.com
wrote:
As a last test, I intentionally put invalid XML in the
archetype-metadata.xml file. I was able to run archetype:create
without it
reporting an XML error. This tells me it's ignoring my metadata file
anyhow any ideas on what I can do to work around this?
I think, this file is only used, if you use the archetype:generate
goal.
[line 17,column 31] : $tagext is not a valid reference.
For the references that should go unchanged into the generated sources
I usually do
#set ($d = $)
... ${d}{target} ...
This will expand to ${target} and will not raise a warning.
- Henry
-
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: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Sent from my [rhymes with myPod] ;-) On 10 May 2009, at 18:01, Stevo Slavić ssla...@gmail.com wrote: Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/ provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
IIRC maven warns you that you have changed a dependency from compile scope to test scope. you may have a valid reason for so doing, but maven is no medium and cannot ask a higher plain what you wanted to do. if a warning is not good enough, tough Sent from my [rhymes with myPod] ;-) On 10 May 2009, at 18:01, Stevo Slavić ssla...@gmail.com wrote: Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/ provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
One can package, install and deploy such a war, no warning related to this issue will get printed. Regards, Stevo. On Sun, May 10, 2009 at 8:57 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: IIRC maven warns you that you have changed a dependency from compile scope to test scope. you may have a valid reason for so doing, but maven is no medium and cannot ask a higher plain what you wanted to do. if a warning is not good enough, tough Sent from my [rhymes with myPod] ;-) On 10 May 2009, at 18:01, Stevo Slavić ssla...@gmail.com wrote: Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Creating archetypes and disabling velocity
On Sun, May 10, 2009 at 7:37 PM, Doug Hughes dhug...@alagad.com wrote: Rather than editing my source files, is there not a way to disable velocity for spcific files or folders? I ask because some of the problem files in my archetype are binary. I'm not too comfortable editing those by hand as you suggest. And I think they may be related to the problems I'm seeing. Did you try the filtered=false attribute in the archetype-metadata.xml file when you used the archetype:generate goal? - Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Creating archetypes and disabling velocity
how about adding includes for wanted extensions and excludes for files to be excluded such as this FileSet declaration for archetype-metadata.xml file? archetype-descriptor !-- usual declaration statements -- fileSets fileSet filtered=true packaged=false directorysrc/site/directory includes include**/*.ftl/include /includes excludes exclude**/*.vm/exclude /excludes? /fileSet /fileSets /archetype-descriptor http://ant.apache.org/manual/CoreTypes/fileset.html ? Martin Gainty __ Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 10 May 2009 21:39:31 +0200 Subject: Re: Creating archetypes and disabling velocity From: heinrich.nirs...@gmail.com To: users@maven.apache.org On Sun, May 10, 2009 at 7:37 PM, Doug Hughes dhug...@alagad.com wrote: Rather than editing my source files, is there not a way to disable velocity for spcific files or folders? I ask because some of the problem files in my archetype are binary. I'm not too comfortable editing those by hand as you suggest. And I think they may be related to the problems I'm seeing. Did you try the filtered=false attribute in the archetype-metadata.xml file when you used the archetype:generate goal? - Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Hotmail® goes with you. http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009
Re: Creating archetypes and disabling velocity
Martin, Thanks for the suggestion the thing is, that's what this tread started about. I have an archetype-metadata.xml file and followed the documentation (not at the link you provided which, fyi, doesn't document the filtered or packaged attributes). Anyhow, it seems that the archetype-metadata.xml file is being ignored. No mater what I put in that file (including invalid xml), it makes no difference. It's like the file doesn't even exist. I'll send more information on the structure of the archetype project and my various files and the commands I'm running later. Thanks, Doug Hughes, President Alagad Inc. dhug...@alagad.com 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Sun, May 10, 2009 at 4:26 PM, Martin Gainty mgai...@hotmail.com wrote: how about adding includes for wanted extensions and excludes for files to be excluded such as this FileSet declaration for archetype-metadata.xml file? archetype-descriptor !-- usual declaration statements -- fileSets fileSet filtered=true packaged=false directorysrc/site/directory includes include**/*.ftl/include /includes excludes exclude**/*.vm/exclude /excludes? /fileSet /fileSets /archetype-descriptor http://ant.apache.org/manual/CoreTypes/fileset.html ? Martin Gainty __ Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 10 May 2009 21:39:31 +0200 Subject: Re: Creating archetypes and disabling velocity From: heinrich.nirs...@gmail.com To: users@maven.apache.org On Sun, May 10, 2009 at 7:37 PM, Doug Hughes dhug...@alagad.com wrote: Rather than editing my source files, is there not a way to disable velocity for spcific files or folders? I ask because some of the problem files in my archetype are binary. I'm not too comfortable editing those by hand as you suggest. And I think they may be related to the problems I'm seeing. Did you try the filtered=false attribute in the archetype-metadata.xml file when you used the archetype:generate goal? - Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Hotmail® goes with you. http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009
Re: Message that artifact is already unpacked
The dependency plugin uses the existence of some marker files to detect if a given artifact has been unpacked. By default these markers are stored in /target/dependency. On Sun, May 10, 2009 at 11:33 AM, Melissa Tolliver mgtolli...@gmail.comwrote: I have an unpack execution which opens up a zip file in my deployment directory. However, even when the target files are NOT in place, Maven usually says that the zip is already unpacked as follows [INFO] runtimelib-1.0.1.zip already unpacked. If I change overWritefalse/overWrite to true, and re-run, then the zip gets correctly unpacked, but I do want to be able to set overWrite to false and let Maven detect whether the target files are there already. The relevant parts of the pom are below. (Using Maven Integration for Eclipse 0.9.7.) Thanks, MG plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idunpack/id phaseinitialize/phase goals goalunpack/goal /goals /execution /executions configuration artifactItems artifactItem artifactIdruntimelib/artifactId groupIdcom.foo.libs/groupId version1.0.1/version typezip/type overWritefalse/overWrite includes**/*/includes /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration ...
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/10 Stevo Slavić ssla...@gmail.com Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. I dig that. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). At face value the logic seems to make sense, but I haven't thought through all the ramifications. I thought Mark Hobson mentioned some cases where the opposite was desired. At this point your best bet is to prepare a proposal on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an associated Jira and then start building some consensus around the changes. Work in this area for 3.x is nearing so now's a good time to create the proposal. Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
