Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
Hi Hervé, Hervé BOUTEMY wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom Just an idea: Use a separate pom file with the proper site settings in the same directory and declare the ASF pom as parent. Deploy the site docs separately then with: mvn -f site-pom.xml site site:deploy 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Woes of site:stage-deploy
Hervé, FYI things are not perfect yet
The woes of getting site:stage-deploy to work...
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: The site does not exist,
please run site:site first - [Help 1]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 2.2.1
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO]
[INFO] Building Maven Release
[INFO]task-segment: [site:stage-deploy]
[INFO]
[INFO] [site:stage-deploy {execution: default-cli}]
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The site does not exist, please run site:site first
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Jun 27 10:03:27 IST 2011
[INFO] Final Memory: 16M/81M
[INFO]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:site site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO]
[INFO]
[INFO] Building Maven Release 2.2
[INFO]
[INFO]
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x instead!
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site_en.xml
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
(3 KB at 3.2 KB/sec)
[INFO] Relativizing decoration links with respect to project URL:
http://maven.apache.org/maven-release/
[INFO] Rendering site with
org.apache.maven.skins:maven-stylus-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-site-plugin:2.3:stage-deploy (default-cli) @ maven-release ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Release . FAILURE [3.804s]
[INFO] Maven Release Manager . SKIPPED
[INFO] Maven Release Plugin .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.146s
[INFO] Finished at: Mon Jun 27 10:04:07 IST 2011
[INFO] Final Memory: 8M/81M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: Unsupported protocol: 'scp':
Cannot find wagon which supports the requested protocol: scp:
com.google.inject.ProvisionException: Guice provision errors:
[ERROR]
[ERROR] 1) No implementation for org.apache.maven.wagon.Wagon
annotated with @Named(value=scp) was bound.
[ERROR]
[ERROR] 1 error
[ERROR] role: org.apache.maven.wagon.Wagon
[ERROR] roleHint: scp
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the
Re: Woes of site:stage-deploy
The first failure is expected since site-plugin-2.3:
http://maven.apache.org/plugins/maven-site-plugin/migrate.html
The other one, I don't know...
-Lukas
Stephen Connolly wrote:
Hervé, FYI things are not perfect yet
The woes of getting site:stage-deploy to work...
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: The site does not exist,
please run site:site first - [Help 1]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 2.2.1
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO]
[INFO] Building Maven Release
[INFO]task-segment: [site:stage-deploy]
[INFO]
[INFO] [site:stage-deploy {execution: default-cli}]
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The site does not exist, please run site:site first
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Jun 27 10:03:27 IST 2011
[INFO] Final Memory: 16M/81M
[INFO]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:site site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO]
[INFO]
[INFO] Building Maven Release 2.2
[INFO]
[INFO]
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x instead!
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site_en.xml
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
(3 KB at 3.2 KB/sec)
[INFO] Relativizing decoration links with respect to project URL:
http://maven.apache.org/maven-release/
[INFO] Rendering site with
org.apache.maven.skins:maven-stylus-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-site-plugin:2.3:stage-deploy (default-cli) @ maven-release ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Release . FAILURE [3.804s]
[INFO] Maven Release Manager . SKIPPED
[INFO] Maven Release Plugin .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.146s
[INFO] Finished at: Mon Jun 27 10:04:07 IST 2011
[INFO] Final Memory: 8M/81M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: Unsupported protocol: 'scp':
Cannot find wagon which supports the requested protocol: scp:
com.google.inject.ProvisionException: Guice provision errors:
[ERROR]
[ERROR] 1) No implementation for
Re: Woes of site:stage-deploy
On 27 June 2011 10:12, Lukas Theussl ltheu...@apache.org wrote:
The first failure is expected since site-plugin-2.3:
http://maven.apache.org/plugins/maven-site-plugin/migrate.html
well http://maven.apache.org/developers/release/maven-shared-release.html
could do with some love then ;-)
The other one, I don't know...
-Lukas
Stephen Connolly wrote:
Hervé, FYI things are not perfect yet
The woes of getting site:stage-deploy to work...
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: The site does not exist,
please run site:site first - [Help 1]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 2.2.1
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO]
[INFO] Building Maven Release
[INFO] task-segment: [site:stage-deploy]
[INFO]
[INFO] [site:stage-deploy {execution: default-cli}]
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The site does not exist, please run site:site first
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Jun 27 10:03:27 IST 2011
[INFO] Final Memory: 16M/81M
[INFO]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:site site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO]
[INFO]
[INFO] Building Maven Release 2.2
[INFO]
[INFO]
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x
instead!
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site_en.xml
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
(3 KB at 3.2 KB/sec)
[INFO] Relativizing decoration links with respect to project URL:
http://maven.apache.org/maven-release/
[INFO] Rendering site with
org.apache.maven.skins:maven-stylus-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-site-plugin:2.3:stage-deploy (default-cli) @
maven-release ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Release . FAILURE
[3.804s]
[INFO] Maven Release Manager . SKIPPED
[INFO] Maven Release Plugin .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.146s
[INFO] Finished at: Mon Jun 27 10:04:07 IST 2011
[INFO] Final Memory: 8M/81M
[INFO]
[ERROR] Failed to execute goal
[VOTE] ReleaseMaven Release plugin version 2.2
Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=16778 Staging repo: https://repository.apache.org/content/repositories/maven-061/ Source distribution: https://repository.apache.org/content/repositories/maven-061/org/apache/maven/release/maven-release/2.2/maven-release-2.2-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
OK, call that '2(c)' from my list. On Mon, Jun 27, 2011 at 3:07 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Hervé, Hervé BOUTEMY wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom Just an idea: Use a separate pom file with the proper site settings in the same directory and declare the ASF pom as parent. Deploy the site docs separately then with: mvn -f site-pom.xml site site:deploy 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Mocking a repository, sort of
There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
I have been working on the mock-repository-maven-plugin over at mojo... but it's a side-project of one of my side-projects' side-projects... I shall be getting back at some time in the near future. I would do something like a file:/// based repo for now until I can get you the mock-repo plugin -Stephen On 27 June 2011 13:24, Benson Margulies bimargul...@gmail.com wrote: There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
I'm checking into whether archiva can be launched embeddedly. On Mon, Jun 27, 2011 at 8:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have been working on the mock-repository-maven-plugin over at mojo... but it's a side-project of one of my side-projects' side-projects... I shall be getting back at some time in the near future. I would do something like a file:/// based repo for now until I can get you the mock-repo plugin -Stephen On 27 June 2011 13:24, Benson Margulies bimargul...@gmail.com wrote: There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
Ugh! very heavyweight file:/// is usually sufficient On 27 June 2011 13:55, Benson Margulies bimargul...@gmail.com wrote: I'm checking into whether archiva can be launched embeddedly. On Mon, Jun 27, 2011 at 8:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have been working on the mock-repository-maven-plugin over at mojo... but it's a side-project of one of my side-projects' side-projects... I shall be getting back at some time in the near future. I would do something like a file:/// based repo for now until I can get you the mock-repo plugin -Stephen On 27 June 2011 13:24, Benson Margulies bimargul...@gmail.com wrote: There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
On Mon, Jun 27, 2011 at 8:55 AM, Benson Margulies bimargul...@gmail.com wrote: I'm checking into whether archiva can be launched embeddedly. Seems like overkill. Deploying to file:// using -Dmaven.repo.local=/tmp/repo (to keep from updating the local repo of the project you are testing with) should do it. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
If the dates are all in the .xml files, that would 'serve' for this purpose. How heavy depends on how cleverly they've provided maven plugins, after all, on the other hand. On Mon, Jun 27, 2011 at 9:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ugh! very heavyweight file:/// is usually sufficient On 27 June 2011 13:55, Benson Margulies bimargul...@gmail.com wrote: I'm checking into whether archiva can be launched embeddedly. On Mon, Jun 27, 2011 at 8:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have been working on the mock-repository-maven-plugin over at mojo... but it's a side-project of one of my side-projects' side-projects... I shall be getting back at some time in the near future. I would do something like a file:/// based repo for now until I can get you the mock-repo plugin -Stephen On 27 June 2011 13:24, Benson Margulies bimargul...@gmail.com wrote: There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
OK, bear of little brain time here. If I use install:install-file on a file URL, I can turn around after that and use the resulting thing as a repository? On Mon, Jun 27, 2011 at 9:08 AM, Wendy Smoak wsm...@gmail.com wrote: On Mon, Jun 27, 2011 at 8:55 AM, Benson Margulies bimargul...@gmail.com wrote: I'm checking into whether archiva can be launched embeddedly. Seems like overkill. Deploying to file:// using -Dmaven.repo.local=/tmp/repo (to keep from updating the local repo of the project you are testing with) should do it. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
On Mon, Jun 27, 2011 at 9:44 AM, Benson Margulies bimargul...@gmail.com wrote: OK, bear of little brain time here. If I use install:install-file on a file URL, I can turn around after that and use the resulting thing as a repository? No, you'd want deploy:deploy-file, however I wouldn't try that with a snapshot, I'm not sure it would get the timestamped snapshot filename and metadata quite right, and in any case it isn't going to test what a user would be reporting. I would set up project A that uses dependency B. In B, configure distributionManagement to file://path/to/remote/repo . When you deploy that snapshot, use a separate local repository so you don't step on the one you're using with A to test the snapshot download. Now build A normally, and it should retrieve the snapshot. Then deploy a new snapshot of B (again using the separate local repo.) Build A using whatever setting is supposed to NOT retrieve snapshots, and see if it does. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question about maven archetype: how to convert ${artifactId} into a file system path?
Hi
I don't know this helps you are not but if you want to create a file system
path with a parameter.
You can set packaged=true in fileset tag , then all the defined files in
filetag will be created in a file system path as given to ${package}.
example:
${package}=my.nice.little.project
//archetype-metadata.xml/
fileSets
fileSet filtered=true *packaged=true* encoding=UTF-8
directoryapi/directory
includes
includeTest.java/include
/includes
/fileSet
/fileSets
then your Test.java file will be created in
api/my/nice/little/project/Test.java
-Goutham
On Sun, Jun 26, 2011 at 2:40 PM, Unico Homme un...@apache.org wrote:
As far as I know this is not possible. Velocity is not powerful enough to
do
string manipulation, it's only a templating language.
Actually I am running into the same limitation.
For this to work you would need to put a custom object into the Velocity
context that parses the artifactId property and exposes the data to the
template. Currently this is not possible.
I've found several mails on the user list that mentioned similar
requirements: a mechanism in the archetype plugin to hook in custom
velocity
context objects.
Additionally I've found [1], where the same is mentioned and from which I
conclude that such an addition to the archetype plugin would be welcome and
possible.
This mail describes the possibility of user defined hooks that get called
while preparing the velocity context to enhance the velocity context.
However I don't readily see how such a hook could be loaded. I assume such
a
hook would be packaged together with the archetype template archive. This
archetype template archive is not a dependency on the maven classpath as
far
as I know.
Of course, usually you can add extra dependencies when you configure a
plugin in the pom. However, the archetype plugin is special in that
normally
when you use archetype:generate you will not have any pom yet.
So it puzzles me how in [1] JvZ imagined this was going to work.
Anyone have suggestions?
1.
http://maven.40175.n5.nabble.com/Archetype-capabilities-limitations-td216158.html#a216159
On Thu, Jun 23, 2011 at 8:20 PM, Christian Schuhegger
christian.schuheg...@gmx.de wrote:
Hello list,
I am writing a maven archetype and it would be useful to convert an
${artifactId} (e.g. my.nice.little.project) into a path:
my/nice/little/project.
If this is possible, could somebody please point me to the relevant
documentation? I did not find it via google.
Many thanks,
--
Christian Schuhegger
http://www.el-chef.de/
--**--**-
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org
dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
On Mon, Jun 27, 2011 at 10:08 AM, Wendy Smoak wsm...@gmail.com wrote: Build A using whatever setting is supposed to NOT retrieve snapshots, and see if it does. Then again, it only retrieves snapshots once a day by default, so you'd either have to wait until tomorrow for that part of the test, or perhaps configure that repository to 'always'. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mocking a repository, sort of
The assembly-plugin can create a repository structure [1] which can then be used as a file:/// based repo. [1] http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository Am 27.06.2011 14:55, schrieb Benson Margulies: I'm checking into whether archiva can be launched embeddedly. On Mon, Jun 27, 2011 at 8:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have been working on the mock-repository-maven-plugin over at mojo... but it's a side-project of one of my side-projects' side-projects... I shall be getting back at some time in the near future. I would do something like a file:/// based repo for now until I can get you the mock-repo plugin -Stephen On 27 June 2011 13:24, Benson Marguliesbimargul...@gmail.com wrote: There's a jira claiming that the 'don't update snapshots' flag isn't working. I thought to build a real test case; I wondered if we have anything in the way of a precedent. I need to construct a repo that claims to have a very new snapshot so that Maven will be tempted to download it. I can think of a way to set this up, but i didn't want to repeat history. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Where do the integration tests live?
Where do overall maven integration tests live? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Where do the integration tests live?
http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-it-suite/ http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-it-suite/src/test/resources/ Is it what you are looking for ?? On Mon, Jun 27, 2011 at 4:27 PM, Benson Margulies bimargul...@gmail.comwrote: Where do overall maven integration tests live? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
scopeperi/scope
In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Woes of site:stage-deploy
for the second issue:
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x
instead!
Regards,
Hervé
Le lundi 27 juin 2011, Stephen Connolly a écrit :
On 27 June 2011 10:12, Lukas Theussl ltheu...@apache.org wrote:
The first failure is expected since site-plugin-2.3:
http://maven.apache.org/plugins/maven-site-plugin/migrate.html
well http://maven.apache.org/developers/release/maven-shared-release.html
could do with some love then ;-)
The other one, I don't know...
-Lukas
Stephen Connolly wrote:
Hervé, FYI things are not perfect yet
The woes of getting site:stage-deploy to work...
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: The site does not exist,
please run site:site first - [Help 1]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 2.2.1
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO]
[INFO] Building Maven Release
[INFO]task-segment: [site:stage-deploy]
[INFO]
[INFO] [site:stage-deploy {execution: default-cli}]
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The site does not exist, please run site:site first
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Jun 27 10:03:27 IST 2011
[INFO] Final Memory: 16M/81M
[INFO]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:site site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO]
[INFO]
[INFO] Building Maven Release 2.2
[INFO]
[INFO]
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x
instead!
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-par
ent-20-site_en.xml Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-par
ent-20-site.xml Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-par
ent-20-site.xml (3 KB at 3.2 KB/sec)
[INFO] Relativizing decoration links with respect to project URL:
http://maven.apache.org/maven-release/
[INFO] Rendering site with
org.apache.maven.skins:maven-stylus-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-site-plugin:2.3:stage-deploy (default-cli) @
maven-release ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Release . FAILURE
[3.804s]
[INFO] Maven Release Manager . SKIPPED
[INFO] Maven Release Plugin .. SKIPPED
[INFO]
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
None here. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Multiple invocations of invoker plugin don't pick up new parameters?
Folks, I tried to set up a scheme for testing -nsu by using the invoker plugin to build the same project twice with two different local repositories -- using two executions. Unfortunately for me, it used the value of localRepository from the first execution for the second. Is this some sort of old news, or could I possibly be missing something? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multiple invocations of invoker plugin don't pick up new parameters?
Please ignore this. Pilot error. On Mon, Jun 27, 2011 at 5:42 PM, Benson Margulies bimargul...@gmail.com wrote: Folks, I tried to set up a scheme for testing -nsu by using the invoker plugin to build the same project twice with two different local repositories -- using two executions. Unfortunately for me, it used the value of localRepository from the first execution for the second. Is this some sort of old news, or could I possibly be missing something? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
ETA for the release of maven-deploy-plugin:2.7 and maven-gpg-plugin:1.4?
Hi is there any ETA on the release of maven-deploy-plugin:2.7 and maven-gpg-plugin:1.4? I am particulary interested in the fixes of http://jira.codehaus.org/browse/MDEPLOY-137 http://jira.codehaus.org/browse/MGPG-38 my use case is in trying to help get some libraries to deploy into maven central, and it would be helpful to be able to provide them this solution instead of the current one that has problems with snapshots, and a fix at a later time. The main reason is that these libraries are not using maven for their builds, so trying to explain all of this and getting them to accept patches is some work, and the less patches I can provide the better. thanks for any info. Rubén Garat - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: ETA for the release of maven-deploy-plugin:2.7 and maven-gpg-plugin:1.4?
There really is just the one issue in both cases, and the issue is not burning yet for me... I will want to get them soonish, but I have bigger fish to fry. Ping me in 2 weeks if I have not pushed a release On 27 June 2011 22:45, Ruben Garat ruben01@gmail.com wrote: Hi is there any ETA on the release of maven-deploy-plugin:2.7 and maven-gpg-plugin:1.4? I am particulary interested in the fixes of http://jira.codehaus.org/browse/MDEPLOY-137 http://jira.codehaus.org/browse/MGPG-38 my use case is in trying to help get some libraries to deploy into maven central, and it would be helpful to be able to provide them this solution instead of the current one that has problems with snapshots, and a fix at a later time. The main reason is that these libraries are not using maven for their builds, so trying to explain all of this and getting them to accept patches is some work, and the less patches I can provide the better. thanks for any info. Rubén Garat - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
core integration tests trunk
I just added an IT for MNG-5062. When I run the whole set, I get: Tests run: 697, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,520.853 sec FAILURE! Results : Failed tests: testitMNG3951(org.apache.maven.it.MavenITmng3951AbsolutePathsTest): expected:/private/tmp but was:/tmp Tests run: 697, Failures: 1, Errors: 0, Skipped: 0 This looks like a macosx incompatibity to me. Anyone else with a view? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation But that right that in maven 2 we just ignored unknown scopes while maven 3 throws a warning Arnaud On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies bimargul...@gmail.comwrote: In looking at the tomcat plugin, I noticed that it depends on using a custom scope, and there was commentary complaining that maven 3 complains. Is there a thread or a JIRA about this? I'm contemplating creating something like this of my own, and I'd like to know what trouble I'm getting myself into. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place for the definition. 2011/6/27 Arnaud Héritier aherit...@gmail.com: I don't have any pointer in mind except this page which doesn't say much than a stricter validation of POM :
Re: scopeperi/scope
surefire not surfer... stupid phone - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 01:32, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head: 1) Eliminate the warning. 2) Allow some means for officially defining scopes -- the problem being that the consumer is the logical place
Re: scopeperi/scope
I found the tomato reference funnier. On 28/06/2011, at 8:33 AM, Stephen Connolly wrote: surefire not surfer... stupid phone - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 01:32, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId version.../version scopes scope namecompile/name transitivetrue/transitive /scope scope nameruntime/name transitivefalse/transitive /scope scope nametest/name transitivetrue/transitive /scope /scopes /dependency Man that's ugly On 27 June 2011 23:27, Benson Margulies bimargul...@gmail.com wrote: Two options in my head:
Re: scopeperi/scope
On 28/06/2011, at 7:46 AM, Benson Margulies wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Right - you should be declaring a new type in a plugin that can turn off addedToClasspath/ - or use a packaging type like zip which wasn't already. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. The currently recommended approach to this is to filter the list of dependencies with includes/excludes configuration in the plugin, like the dependency plugin does. This doesn't require duplicating as much information since you can use some short hand. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
