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
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]
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
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
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:
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
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
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
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...
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
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)
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
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
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
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
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,
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
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
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
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
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
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?
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
40 matches
Mail list logo
