Hi SCM team!
I am involved in grounding a maven release management. So I have to keep
some backward functionality.
I have to generate a textfile containing exactly what provide the svn
status -uv command.
Looking at the SvnStatusCommand and SvnStatusConsumer implementation, it
seems that
You may want to take a look at svn provider source to see if it can be
extended to
accept additional arguments via svn-settings.xml for scm:status command
see
http://maven.apache.org/scm/subversion.html
-D
On Thu, Aug 28, 2008 at 2:57 AM, Kiss Tibor [EMAIL PROTECTED] wrote:
Hi SCM team!
I
James,
I am not exactly sure what is the problem for Archiva or any other project
to use nexus indexer API. For instance, Archiva is already using number of
dependencies from outside of Maven project and even from outside Apache
umbrella and it doesn't seem to be an issue.
As Jason already
On Thu, Aug 28, 2008 at 8:02 AM, Eugene Kuleshov [EMAIL PROTECTED] wrote:
James,
I am not exactly sure what is the problem for Archiva or any other project
to use nexus indexer API. For instance, Archiva is already using number of
dependencies from outside of Maven project and even from
On 27-Aug-08, at 11:22 PM, Milos Kleint wrote:
On Thu, Aug 28, 2008 at 8:02 AM, Eugene Kuleshov [EMAIL PROTECTED] wrote:
James,
I am not exactly sure what is the problem for Archiva or any other
project
to use nexus indexer API. For instance, Archiva is already using
number of
Hi Benjamin,
Thanks to update these files!
Also, WDYT to do the same for faq.fml?
Cheers,
Vincent
2008/8/26 [EMAIL PROTECTED]:
Author: bentmann
Date: Tue Aug 26 06:36:10 2008
New Revision: 689071
URL: http://svn.apache.org/viewvc?rev=689071view=rev
Log:
o Changed encoding of site
Milos Kleint wrote:
as a user of the nexus indexer (in netbeans integration), I'm hoping
this kind of statements only mean compatible changes in the index that
will not break users of the old APIs.
Can you confirm?
Absolutely. But I still recommend to update to the latest when you can
On Thu, Aug 28, 2008 at 3:03 PM, Eugene Kuleshov [EMAIL PROTECTED] wrote:
Milos Kleint wrote:
as a user of the nexus indexer (in netbeans integration), I'm hoping
this kind of statements only mean compatible changes in the index that
will not break users of the old APIs.
Can you confirm?
Hi Vincent,
Also, WDYT to do the same for faq.fml?
+1, life should be easier if our source files are consistently encoded.
Maybe I find some time this evening, feel free to join forces ;-)
Benjamin
-
To unsubscribe,
2008/8/28 Benjamin Bentmann [EMAIL PROTECTED]:
Hi Vincent,
Also, WDYT to do the same for faq.fml?
+1, life should be easier if our source files are consistently encoded.
Maybe I find some time this evening, feel free to join forces ;-)
It's great that you guys are sorting this all out,
I did a quick scan in jira, but couldn't sort out the proper project. I
figured someone would correct me. ;-)
Brett Porter wrote:
Should this be moved to MPLUGIN, or was it a core fix? It's currently
set as fixed in 2.0.11 :)
- Brett
On 28/08/2008, at 12:10 PM, John Casey (JIRA) wrote:
See MPLUGIN-136
John Casey wrote:
I think I've found the issue. Once I've tested this theory out a little
more, I'll file a JIRA issue, and get this fixed with an integration
test in place.
Henrique Prange wrote:
Hi John,
I compared the contents of the artifacts generated by 2.0.9 and
On 27-Aug-08, at 5:59 PM, James William Dumay wrote:
Jason,
I'm cool sticking with the Nexus index format - it works and there
has been a successful uptake with different tool vendors - so it
seems to be the defacto standard. We will certainly be using it in a
future version of Archiva.
I'll clean up the tags today, thanks for the reminder. However, I'm not
sure I know enough about JIRA permissions to give you access to clean up
the Fix-For versions out there...probably better to leave this to Brett
or Jason, or someone who's more familiar with JIRA's admin.
Paul Benedict
Hi Mark,
2008/8/28 Mark Hobson [EMAIL PROTECTED]:
2008/8/28 Benjamin Bentmann [EMAIL PROTECTED]:
Hi Vincent,
Also, WDYT to do the same for faq.fml?
+1, life should be easier if our source files are consistently encoded.
Maybe I find some time this evening, feel free to join forces ;-)
Anyone?
--jason
On Thu, Aug 21, 2008 at 3:52 PM, Jason Dillon [EMAIL PROTECTED] wrote:
Seems that with svn 1.4.4 the maven-release-plugin works just fine... whats
going on with SVN 1.5.x?
--jason
On Aug 21, 2008, at 2:15 PM, Jason Dillon wrote:
I'm having lots of problems using the
cross posting to maven dev list
oh and in case anyone has any doubts, I'm +1 ;-)
Sent from my iPod
On 28 Aug 2008, at 12:03, Stephen Connolly [EMAIL PROTECTED]
wrote:
Hi Everyone,
The versions-maven-plugin is currently in the *sandbox*.
This is the first step for a future 1.0.0-alpha-1
On Mon, Aug 25, 2008 at 4:15 PM, John Casey [EMAIL PROTECTED] wrote:
Hi again,
One bug was identified in 2.0.10-RC10 last Friday night. This release
candidate addresses that issue. You can find it here:
Can you run with -X and attach the output? This isn't enough to diagnose
the error, but I suspect it's a permissions (or, open files) problem on
windows. I'm not sure this is specific to any maven version, TBH.
-john
Geoffrey Wiseman wrote:
On Mon, Aug 25, 2008 at 4:15 PM, John Casey [EMAIL
I've had a look at that code, and I think it is doing something other than
what is required here!
As I see it, the display-plugin-updates goal should tell you of an update
that is relevant to the *current pom only*.
So if my parent pom specifies a version... then even if there is a newer
version
I've renamed the current RC to 2.1.0-M1-RC12-SNAPSHOT, for this reason.
If we can put together a plan for the GA release of 2.1.0, I'd prefer to
have that in place before we do a final release from this RC branch.
Preferably something we can achieve in the next 2 months given current
resource
Hi,
Some thoughts...
I think you need to update your license header template to the new
format :)
Also, I think type is a more familiar name than packaging, and you
might want to add classifiers.
Finally, I think it's more correct to throw a MojoFailureException if
you get an
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC
to make this the first milestone toward some as-yet-undetermined feature
list for 2.1.0.
So, let's talk about that feature list. From
Hi,
2008/8/28 Brett Porter [EMAIL PROTECTED]:
...
Finally, I think it's more correct to throw a MojoFailureException if you
get an ArtifactNotFoundException, and keep the MojoExecEx for the ArtResEx
Brett proposed a very good question here. The Javadoc [1] and [2]
explain the differences but
Hi,
We solved less than 20 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11141styleName=Htmlversion=12300
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11141status=1
Staging repo:
I am OK with this.
You may or may not have noticed but I created branch maven-2.1.x-MNG-624
last night. It contains the fix for MNG-624. I have created integration
tests but haven't committed them yet. I will soon. Before committing
these to the 2.1.x branch I'd really like folks to try it
I left some initial questions and comments in JIRA. I don't care where
you answer them but I would like a little more background before
delving into code. Primarily sample projects to see what you intend.
It's hard to grok entirely from your description.
On 28-Aug-08, at 4:11 PM, Ralph
We've come this far, why not make 2.1.0 right now as we were doing
2.0.10? I don't see any benefit to waiting longer. Just do it and then
we can start adding more things to 2.1.1 or 2.2
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 6:29 PM
Sure. I updated the issue. I'll try to get some sample tests checked in
as soon as I can.
Jason van Zyl wrote:
I left some initial questions and comments in JIRA. I don't care where
you answer them but I would like a little more background before
delving into code. Primarily sample projects
The question is at what point do you say no new stuff on 2.1? IMO,
there needs to be a fair amount of time for unstable things to be
introduced in 2.1 before a formal release is made. In other words, I'd
like to see a process where we have a branch that is stable and a branch
in development
+0.5 We should release that code that we did all that RC testing on, right
away, and I don't care what we call it; I thought that was what John was
proposing in his earlier [PROPOSAL].
-Dan
Brian E. Fox wrote:
We've come this far, why not make 2.1.0 right now as we were doing
2.0.10? I
Exactly. I don't think we need to reopen this up to a bunch more
changes, we can make more releases later. If I thought we would be
opening a can of worms for this originally, I probably wouldn't have
been in favor of it. My understanding was that 2.0.10 became 2.1.0 and
more changes would follow
Issue Subscription
Filter: Design Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
Not using it, but I think it is useful in the future
+1 to graduate and release it
-D
On Thu, Aug 28, 2008 at 11:10 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
cross posting to maven dev list
oh and in case anyone has any doubts, I'm +1 ;-)
Sent from my iPod
On 28 Aug 2008, at 12:03,
-1, though I could be convinced to change my mind if we felt like we were
in a rush for some reason.
I found a number of documentation-level bugs that I think should be
straightforward to fix... I'm checking in a few fixes now.
-Dan
Vincent Siveton wrote:
Hi,
We solved less than 20
35 matches
Mail list logo
