With the latest Archiva and Redback built from source, I can't access
the repositories.
When I give guest the global repo observer role, Archiva still prompts
for credentials.
http://jira.codehaus.org/browse/MRM-349
--
Wendy
Continuum Developers,
A new feature that would aid my project greatly would be a password
feature to deal with the CVSNT problem.
Since one has to run Continuum as a local user account, and then cmd:
cvs -d login, to fix this problem I think it is common enough of a
problem to add a fix. I
Ryan Daum a écrit :
I have a local version here which now passes all Tck tests by doing the
inventory of the repository after the tag.
Emmanuel, I can provide you with a patch, but can you give me advice on
how to get Subversion to produce a diff file (from svn diff) that will
do the right
You can't get the files list by parsing the tag command output only?
Ryan Daum a écrit :
No, it's not possible to do this -- and in any case the list of tagged
files would be the entire repository; not sure it makes sense that the
Tck test should require that a provider return a list like this
I'm restarting the release process to integrate SCM-319
For those of you that have already tested the release, it won't change the result becuase the patch added is only for the Mercurial (hg) provider with tag command, so it will be supported by the
release plugin too.
Emmanuel
Emmanuel
Thank you, Emmanuel
On 5/23/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
I'm restarting the release process to integrate SCM-319
For those of you that have already tested the release, it won't change the
result becuase the patch added is only for the Mercurial (hg) provider with
tag command,
Thanks John - good catch.
The proposal did intend to encompass that version problem (I took a
lead from other projects that have done that successfully, for
example httpd). But that covers previous releases and trunk only.
What we really need is for, in the proposal below, versioned to
+1
Stéphane
On 5/22/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I'd like to release the release manager and the release plugin.
These versions included some bug fixes, a new goal for the branch creation and
the latest Maven-SCM (1.0)
The Road Map:
On 22/05/2007, at 5:36 AM, Raphaël Piéroni wrote:
So i did not forked, but rewrited.
Some history :
I must admit have inspired myself on using the artifactDownloader
and use of
component in plexus and a bit of modello.
I first made some paper work during new year holydays. And started
On 22/05/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I'd like to release the release manager and the release plugin.
These versions included some bug fixes, a new goal for the branch creation and
the latest Maven-SCM (1.0)
The Road Map:
On 21/05/07, Brett Porter [EMAIL PROTECTED] wrote:
It seems more that you'd need to change the code that is relying on
the isSnapshot result from the wrong directory?
The code is fair enough given the limitation of a boolean return type:
ArtifactRepositoryPolicy policy =
+1
-Deng
Emmanuel Venisse wrote:
Hi,
I'd like to release the release manager and the release plugin.
These versions included some bug fixes, a new goal for the branch
creation and the latest Maven-SCM (1.0)
The Road Map:
On 21/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Using the manual resolution would only work if an earlier step in the
release:prepare process had definitely built all the dependencies.
However, there is an alternative: you can combine the reactor
projects (which you should have), with the
Hi
2007/5/23, Brett Porter [EMAIL PROTECTED]:
On 22/05/2007, at 5:36 AM, Raphaël Piéroni wrote:
It don't prompt when maven is called with -B
I understand - but this is not the previous behaviour.
Could that point should be marked as a non mandatory backward
incompatibility ?
Because i
On 23/05/2007, at 9:55 PM, Raphaël Piéroni wrote:
Could that point should be marked as a non mandatory backward
incompatibility ?
Because i dunno how to forbid prompting behaviour unless the usage
of this
option.
For the old goal names, we can use the default as false instead of
Hi,
We need to figure out where we go next with Archetype. Raphaël has
been doing a good job adding features and patiently listening to my
feedback/nagging. It appears to me that it is very close to being as
good as what we had before (though still a long list of things to do
before
+1 (But it don't really count :-))
Raphaël
2007/5/23, Brett Porter [EMAIL PROTECTED]:
Hi,
We need to figure out where we go next with Archetype. Raphaël has
been doing a good job adding features and patiently listening to my
feedback/nagging. It appears to me that it is very close to being
+1
Mark
On 23/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Hi,
We need to figure out where we go next with Archetype. Raphaël has
been doing a good job adding features and patiently listening to my
feedback/nagging. It appears to me that it is very close to being as
good as what we had before
+1
On 5/23/07, Mark Hobson [EMAIL PROTECTED] wrote:
+1
Mark
On 23/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Hi,
We need to figure out where we go next with Archetype. Raphaël has
been doing a good job adding features and patiently listening to my
feedback/nagging. It appears to me
+1
On 5/23/07, Maria Odea Ching [EMAIL PROTECTED] wrote:
+1
-Deng
Emmanuel Venisse wrote:
Hi,
I'd like to release the release manager and the release plugin.
These versions included some bug fixes, a new goal for the branch
creation and the latest Maven-SCM (1.0)
The Road Map:
On 23 May 07, at 8:28 AM 23 May 07, Raphaël Piéroni wrote:
+1 (But it don't really count :-))
You are the one that counts the most. I disagree with Brett about
moving this code over here right now because I don't think you're
ready, though I do see that you have the potential to be a
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi
Hi,
I'd like to revert my vote to -1 (non veto) because of the following issue:
http://jira.codehaus.org/browse/MRELEASE-128
It has a high number of votes and does not work on CVS.
Thanks,
Stéphane
On 5/22/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I'd like to release the release
Ok, probably needs a little clarity - I'll try and keep it brief as
it is a vote.
Firstly, we're not diametrically opposed on when to make people
committers, as I've tried to point out elsewhere, though we do
disagree. But that's not really the issue here, so I won't go into it
any
Short answers inlined
Raphaël
2007/5/23, Brett Porter [EMAIL PROTECTED]:
Ok, probably needs a little clarity - I'll try and keep it brief as
it is a vote.
Firstly, we're not diametrically opposed on when to make people
committers, as I've tried to point out elsewhere, though we do
disagree.
Hi Frank,
From the information you posted, I have a few questions.
1. Is XXX:AAA the parent of XXX:BBB? If not, I don't believe XXX:BBB would
not inherit the definition of the ${buildVersion} property.
2. Where do you set ${label}, in your settings.xml? If so can you post the
relevant
I have a local version here which now passes all Tck tests by doing the
inventory of the repository after the tag.
Emmanuel, I can provide you with a patch, but can you give me advice on how
to get Subversion to produce a diff file (from svn diff) that will do the
right thing with creating new
Good day,
Anybody would like to take a look at archetype-40? ..it's a simple
problem with a simple patch attached to it.
Thanks,
Franz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
+1
I've tried to create 2 archetypes for netbeans based apps (placed at
mojo.codehaus.org svn) and it works like a charm as opposed to the
current archetype in trunk.
Milos
On 5/23/07, John Casey [EMAIL PROTECTED] wrote:
+1
On 5/23/07, Mark Hobson [EMAIL PROTECTED] wrote:
+1
Mark
On
On 23 May 07, at 10:16 AM 23 May 07, Tim O'Brien wrote:
On 5/23/07, Brett Porter [EMAIL PROTECTED] wrote:
On 23/05/2007, at 2:10 PM, Jason van Zyl wrote:
Let's run with that below, now what do we do to organize the actual
information for each sub-project and what tools can we make to
On 5/23/07, Brett Porter [EMAIL PROTECTED] wrote:
On 23/05/2007, at 2:10 PM, Jason van Zyl wrote:
Let's run with that below, now what do we do to organize the actual
information for each sub-project and what tools can we make to make
the site making follow that structure below.
I think
On 4/21/07, Wendy Smoak [EMAIL PROTECTED] wrote:
New plan.
* Change nothing about the way 'mvn site-deploy' currently works-- it
will publish to, for example,
http://maven.apache.org/plugins/maven-site-plugin. This will be used
for the docs for the latest release, and avoids breaking
On 5/18/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I'd like to release a buildable source distribution to go along with
Archiva 0.9-alpha-2.
Please review the archiva-0.9-alpha-2-src.tar.gz file and its
companion checksums and signature, and then cast your vote.
*
Hi Evan,
XXX:AAA is not the parent of XXX:BBB. I've tried two scenarios, one
multi-module project, where 10 JARs are built, and some jars depending on
previous built ones (here I'm using dependencyManagement in the top most POM,
setting the version number for the jar/module dependencies to the
Maybe someone else can chime in here, but if XXX:AAA is not the parent of
XXX:BBB I don't think XXX:BBB will have the buildVersion property defined.
If that property isn't defined then XXX:BBB will not be able to resolve a
dependency to XXX:CCC because it doesn't know which version you want,
On 23 May 07, at 10:52 AM 23 May 07, Brett Porter wrote:
Ok, probably needs a little clarity - I'll try and keep it brief as
it is a vote.
Firstly, we're not diametrically opposed on when to make people
committers, as I've tried to point out elsewhere, though we do
disagree. But that's
I'm normally all for bringing the code over, however since Raphael isn't
currently a committer it seems to make sense to keep it at Mojo. I honestly
don't see any big benefit to bringing in. It's not like he's off in some place
random and most of the apache committers also watch/participate in
Team,
What do we do for this issue? Do we move it to the next version or do you want
to see it resolved in 2.0-beta-6?
Emmanuel
Stephane Nicoll a écrit :
Hi,
I'd like to revert my vote to -1 (non veto) because of the following issue:
http://jira.codehaus.org/browse/MRELEASE-128
It has a
On 5/21/07, Joakim Erdfelt [EMAIL PROTECTED] wrote:
What I'd like for any developer reading this, is to tell me what your top
10 list of concepts that illicit a huh? or wha? type response when you
read it in the list below.
I'm not sure how many people are here listening to the request. :)
Emmanuel Venisse ha scritto:
Team,
What do we do for this issue? Do we move it to the next version or do
you want to see it resolved in 2.0-beta-6?
My preference as *user* is to have 2.0-beta-6 out asap.
If I understood it correctly MRELEASE-128 is not a regression introduced
since
+1
Ultimately, I think site-deploy should do the latter, and the /maven-
site-plugin directory should point to different versions of the
documentation (probably an autogenerated page). This is totally
consistent with the layout you are stting up though, just a next
step. wdyt?
- Brett
On 5/23/07, Brett Porter [EMAIL PROTECTED] wrote:
+1
Ultimately, I think site-deploy should do the latter, and the /maven-
site-plugin directory should point to different versions of the
documentation (probably an autogenerated page). This is totally
consistent with the layout you are stting
I'm fine with either - though the latter does make a bit more sense
to me (thinking consistency with the repository).
I'm not sure I understand why it's a bigger change with more
maintenance, though - can you explain that in more detail?
Thanks!
- Brett
On 24/05/2007, at 7:40 AM, Wendy
On 5/23/07, Brett Porter [EMAIL PROTECTED] wrote:
I'm fine with either - though the latter does make a bit more sense
to me (thinking consistency with the repository).
I'm not sure I understand why it's a bigger change with more
maintenance, though - can you explain that in more detail?
I'm
Of course, thanks for the reminder. While the second can likely be
automated, the linking/bookmark issue is definitely a problem.
I can understand how that is a general issue and a reason to publish
to /. However, I'm not sure how that impacts the decision of using -
or / as the version
Separating this discussion from the vote.
On 24/05/2007, at 2:53 AM, Jason van Zyl wrote:
I don't consider working on Archetype at Mojo unacceptable.
Raphaël is welcome to work on it there, of course.
But this vote is about where the active development of the code will
continue. And I
On 24/05/2007, at 2:53 AM, Jason van Zyl wrote:
I've only ever vetoed code I as working on that someone interfered
with and didn't ask. I've not ever vetoed against the majority on
project decisions. It's Raphael's decision really, and my only
point is that people should accept when they
Applied, thanks!
On 24/05/2007, at 1:10 AM, Franz Allan Valencia See wrote:
Good day,
Anybody would like to take a look at archetype-40? ..it's a simple
problem with a simple patch attached to it.
Thanks,
Franz
-
To
On 23/05/2007, at 8:27 PM, Mark Hobson wrote:
On 21/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Using the manual resolution would only work if an earlier step in the
release:prepare process had definitely built all the dependencies.
However, there is an alternative: you can combine the
Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (42 issues)
Subscriber: mavendevlist
Key Summary
MEV-522 Invalid POM element project.organization.logo in
org.apache.poi:poi:3.0-FINAL
http://jira.codehaus.org/browse/MEV-522
MEV-520
Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (12 issues)
Subscriber: mavendevlist
Key Summary
MAVENUPLOAD-1565upload vraptor 2.3.3
http://jira.codehaus.org/browse/MAVENUPLOAD-1565
MAVENUPLOAD-1564JCaptcha 1.0-RC6 Release
I've attached a patch to the issue.
It essentially boils down to adding another prepare phase after scm-tag
(in the end I plumped for adding it after scm-commit-development).
Pretty simple patch really.
I need the extra phase so that I can update the subclipse:tags property
on the trunk with the
But this vote is about where the active development of the code will
continue. And I have to disagree on Mojo, even if it is temporary.
I'll agree it's temporary in my mind.
The Maven PMC has no oversight over the project, nor any authority.
The code at mojo is not covered under any of
I am reposting this question to dev list based on a (very) vague
understanding of how it working now:
I see the settings runs through
org.codehaus.plexus.util.interpolation.RegexBasedInterpolator so I think
the answer to my question is that only system properties are available
for variable
54 matches
Mail list logo
