On 6/13/11 9:52 PM, Ralph Goers wrote:
On Jun 13, 2011, at 9:02 PM, Brett Porter wrote:
On 14/06/2011, at 1:05 PM, Ralph Goers wrote:
On Jun 13, 2011, at 7:23 AM, Nigel Magnay wrote:
There is a fork under the old license here:
https://bitbucket.org/ivertex/java-service-wrapper/overview
+1 (non-binding)
everything by the book!
On 10/4/10 5:16 AM, Benjamin Bentmann wrote:
Hi,
feedback on the RCs seems to be decreasing and I am currently not
aware of any major regression so let's try and cross the finishing
line of this marathon.
We solved 31 issues since 3.0-beta-3:
http
I am getting:
java.lang.ClassNotFoundException: javax.persistence.Entity
from spring context initialization. Class not found varies depending on
the order of spring dependencies, could be a Logger, etc.
Same build works fine under 2.2.1. and 3.0-beta-2
I will create an issue if manage to lo
+1
20-some modules with AspectJ, built, deploy.
Terracotta plugin 1.4.0 failed to execute tests with NPE in aether code
[MNG-4785], worked fine in beta-2. But imho - one plugin is not a reason
to stop this version, could be fixed in beta-4
On 8/30/10 6:09 AM, Benjamin Bentmann wrote:
Hi,
+1
20-some module project with AspectJ & Terracotta - no issues.
On 8/25/10 4:36 PM, Benjamin Bentmann wrote:
Hi,
apart from another few regression fixes, this release includes Guice
and Aether [0] and shall help to get some more community testing on
these new components. Overall, we solved
Jason van Zyl wrote:
Yes, about 5 people will do that. No one tries anything until we
release it the vast majority of the time, unfortunately. We just have
to be proactive about it. If we tried new plugins on the grid we'll
likely find most of the problems.
Thanks,
Jason
An external look
+1
Tested, works fine in my build
Arnaud HERITIER wrote:
Hi,
We solved 2 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147&styleName=Html&version=15244
Those one are very important for many projects because the plugin failed in
a project without sources which is really a
+1
Igor rocks!
Jason van Zyl wrote:
Hi,
Igor has been submitting patches for over a year now and in the last
12 weeks he's been submitting some very substantive changes to 3.x.
Igor has done things like create a performance framework for Maven 3.x
to make sure it doesn't regress, has creat
Brian Fox wrote:
Once John gets the assembly plugin sorted out, then we can apply the source
bundle changes and pile on the release.
In the meantime I checked the outstanding issues, closed one, and looks
like what's left are "old wishes", pushed to this version.
MCOMPILER-16 ability to s
Brian,
Would you like some help releasing it? I have some time to do that :)
Thanks,
Oleg
Daniel Le Berre wrote:
Hi Brian,
That would be fantastic!
Cheers,
Daniel
Brian Fox a �crit :
We can try a release maybe next week. We first have to get some assembly and
parent pom things
+1
worked fine for me ..
Paul Gier wrote:
Hi,
We solved 14 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=Html&version=14199
There are still several issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11533&status=1
Jason van Zyl wrote:
If you want Maven specific use the RepositorySystem in that branch
(will go to trunk in a few days), and use Mercury directly if you want
something Maven independent.
In case you decided to try out Mercury - look at IT
https://svn.apache.org/repos/asf/maven/mercury/tr
Brian Fox wrote:
Oleg Gusakov wrote:
fyi:
- maven password encryption uses SHA-256 and switching to SHA-512
could be done using optional encrypted string attributes to ensure
decryption of the existing passwords. SHA-256 is already SHA2 family
and has not been cracked yet, so we can
fyi:
- maven password encryption uses SHA-256 and switching to SHA-512 could
be done using optional encrypted string attributes to ensure decryption
of the existing passwords. SHA-256 is already SHA2 family and has not
been cracked yet, so we can wait. Main question was availability of
SHA-51
+1
Brian Fox wrote:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/apache/apache/6/apache-6.pom
https://repository.apache.org/content/repositories/maven-staging-012/org/apache/maven/maven-parent/12/maven-parent-12.pom
T
The vote has passed with the following result :
+3 (binding): Jason, Brian, John
+3 (non binding): Benjamen, Paul, Oleg
I will promote the artifacts to the central repo.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.o
rations are now parametrized.
Which is not too cool - I agree on that. I miss a container big time :(
Maybe later, but it need to be generic to meet design goals
Thanks,
Oleg
Oleg Gusakov wrote:
Paul Gier wrote:
I have a few questions and then I will give my +1.
It looks like the ant tasks
neric, of cause :)
Thanks,
Oleg
Thanks!
[1]https://svn.apache.org/repos/asf/maven/mercury/tags/mercury-1.0-alpha-6/mercury-ant-tasks/
[2]http://jira.codehaus.org/browse/MERCURY-111
Oleg Gusakov wrote:
Hi,
Iterative alpha release. Major fixes:
- # of dependencies - less'n 64 were ordered cor
Hi,
Iterative alpha release. Major fixes:
- # of dependencies - less'n 64 were ordered correctly the rest used to
be random ordering
- bad/missing repository metadata is worked around in most cases
Mercury-ant is now successfully used to bootstrap build Maven3 trunk.
Working towards implement
+1
Jason van Zyl wrote:
Hi,
I just want to release this to fix the coupling of the exception to
the maven-reporting-api which happened by mistake.
Staging repo:
https://repository.apache.org/content/repositories/maven-staging-002
Guide to testing staged releases:
http://maven.apache.org/gui
� wrote:
Timothy Reilly wrote:
Hi Oleg,
I just worked with a company converting 130+ projects from Ant to Maven.
LATEST and RELEASE were invaluable.
I do think there needs to be more thought around when they're allowed. No
artifact's "release" pom should contain SNAPSHOT, LATEST or REL
I posted a short blog on the subject [http://tinyurl.com/c7m8qv], and in
addition to that - I argue that LATEST and RELEASE are bad. What do you
think?
Extract:
Let me first be clear about virtual versions as a whole: they are an
excellent source of hard-to-find build erro
I would like to release maven-compiler-2.1-SNAPSHOT plugin - need to
release a project, requiring changes
http://jira.codehaus.org/browse/MCOMPILER-83
If there are no objections/show stoppers, I will proceed tomorrow.
Thanks,
Oleg
--
Arnaud HERITIER wrote:
Hi guys,
In a multi-project, is it possible to resolve its dependencies without
having to build it ?
I'm trying to find a clean solution for
http://jira.codehaus.org/browse/MECLIPSE-472
Any idea ?
How are you doing in IDE plugins ? I have to use something not availa
bring up the GUI .
I will post a note as soon as I test it all the long option names and
publish the new component.
Thanks,
Oleg
Brian E. Fox wrote:
A gui is overkill here.
-Original Message-
From: Oleg Gusakov [mailto:oleg.subscripti...@gmail.com] Sent:
Thursday, February 26, 20
Jason van Zyl wrote:
This doesn't need to go into the core, I think a plugin is better.
I was thinking about GUI in the plugin - that way we either go by
-Dsettings-master-password and -Dsettings-server-password or have the
same options available via swing GUI
Thanks,
Oleg
On 26-Feb-09, a
+1
Brian E. Fox wrote:
Time to release a beta with a few bug fixes:
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14948&styleName
=Html&projectId=11530&Create=Create
Staged site:
http://people.apache.org/~brianf/staging/people.apache.org/www/maven.apa
che.o
+1
Mark Struberg wrote:
looks good
+1
--- John Casey schrieb am Mo, 23.2.2009:
Von: John Casey
Betreff: Re: [vote] Release maven-plugin-tools version 2.5
An: "Maven Developers List"
Datum: Montag, 23. Februar 2009, 21:23
Here's the updated URL:
https://repository.apache.org/content/r
Brett Porter wrote:
I don't view this as a temporary measure - as my second comment said,
you may need a password to get the plugin in the first place. How
would you address this case?
I have never seen an environment where read-only access to central or
central replica is authenticated.
Jason van Zyl wrote:
If you create a set of binaries that have checksums and are signed it
doesn't much matter how you produced the release. I mentioned the Ant
tasks or using Maven itself as that's generally a good way to make a
release. We'll probably make something with Mercury to provid
Brett Porter wrote:
On 20/02/2009, at 10:19 PM, Brett Porter wrote:
Hi,
To make it a bit easier to remember, I added two options to the CLI
for 2.1: --enc-master-passwd and --enc-passwd; which are equivalent
to -m and -p on DefaultSecDispatcher.
For consistency with other options, it ta
I am modifying the bootstrap and am hitting a problem:
Generating sources for maven-model/src/main/mdo/maven.mdo
[java] Usage: modello
[]
Has modello CLI been changed recently? The bootstrap ant macro calls it
like:
+1
Brian E. Fox wrote:
New parents need to be released with the new distributionManagement
sections pointed at repository.apache.org:
Apache Pom Diffs:
http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584&r
2=745325&diff_format=h
Staged at:
https://repository.apache.org/conte
Additional clarifications:
Oleg Gusakov wrote:
pi song wrote:
I just had a look at Mercury artifact resolver. It currently returns a list
of artifacts.
Mercury has the following resolution APIs - see DependencyBuilder
interface:
I became so addicted to m2eclipse that completely forgot
pi song wrote:
I just had a look at Mercury artifact resolver. It currently returns a list
of artifacts.
Mercury has the following resolution APIs - see DependencyBuilder interface:
- buildTree - creates a full metadata tree
- resolveConflicts has two flavors
-- List resolveConflicts( Meta
The vote has passed with the following result :
+6 (binding): Jason, Brian, Jesse, Olivier, Arnaud, Herve
+1 (non binding): Oleg
I will promote the artifacts to the central repo.
-
To unsubscribe, e-mail: dev-unsubscr...@mav
Benjamin,
I might have messed up: promotion refused to cooperate and I remember
manually supplying password for each single artifact. PGP sigs were OK,
so I did not look at other checksums. I cannot pinpoint the exact
reason, and - given the new Nexus-based process, I doubt it will happen
aga
eactor): do you intend to release it separately?
Regards,
Hervé
Le mercredi 11 février 2009, Oleg Gusakov a écrit :
Hi,
Main reason for this release - bug fixes. A lot of testing done on the
repository side, IT coverage on repository components is 60-70 %
We solved 11 issues:
http://jira.code
Guys,
Need one more vote!
I understand that nobody is using Mercury yet, so it's hard to yay or
nay when project is still in alpha stage..
Thanks,
Oleg
Brian E. Fox wrote:
+1
-Original Message-
From: Oleg Gusakov [mailto:oleg.subscripti...@gmail.com]
Sent: Wednesday, Februa
Dennis Lundberg wrote:
If it's possible I'd like to continue this release with the artifacts
that were already built. I've been through hell and back already trying
to get this release out the door.
This is an interesting remark. I felt exactly the same until I tried
Nexus process. Before -
I have a tool that compares resolved dependency lists between Mercury
and Maven2, not binaries. Will not be hard to modify to add binary
comparison.
Paul Benedict wrote:
Does any tool exist that can build a project in Maven 2 and Maven 3
and then compare the binaries to see if they are equal?
Hi,
Main reason for this release - bug fixes. A lot of testing done on the
repository side, IT coverage on repository components is 60-70 %
We solved 11 issues:
http://jira.codehaus.org/browse/MERCURY/fixforversion/14955
Staging repo:
https://repository.apache.org/content/repositories/maven-s
+1
Brian E. Fox wrote:
It's finally time after 8 Release Candidates:
Issues fixed:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName
=Html&projectId=10500&Create=Create
NOTE: The urls below are using a self-signed certificate.
There is an issue requesting an o
Brian E. Fox wrote:
Once multiple resolution strategies start appearing, life will be
infinitely more complicated.
yes :( I think Mercury has a pretty decent potential to cover majority
of the reasons to change version comparisons. For example - there is a
notion of version quality and reposit
+1
Brian E. Fox wrote:
As proposed in separate threads[1][2] and Infra jira[3], we have setup a
new zone and repository manager for hosting Apache artifacts at
https://repository.zones.apache.org. The service is now setup and
several releases of Maven are already staged there.
The initial
Thanks Benjamin !
I put [MERCURY-69] off till I fix more urgent issues, that's why this
workaround. Will get to it as soon as I can :)
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Thu Feb 5 16:56:40 2009
New Revision: 741180
URL: http://svn.apache.org/viewvc?rev=741180&view=re
+1
This is awesome news - real repository manager at last !! When can we
start using it?
Jason van Zyl wrote:
Hi,
This release worked out better and the release profile is working now
and everything is signed. This release is being staged with Nexus that
we've installed in a new zone. So B
Georgy Bolyuba wrote:
Hi,
I am new here, so, might be missing something. I am trying to build
maven from trunk and:
I guess, I phrased my question incorrectly: maven trunk depends on
mercury 1.0.0-alpha-2, where did you get that error? Building what?
Thanks,
Oleg
Missing:
--
1)
something. I am trying to build
maven from trunk and:
Missing:
--
1) org.apache.maven.mercury:mercury-event:jar:1.0.0-alpha-4-SNAPSHOT
So, I am kinda confused. Is it or is it not available (mercury-1.0.0-alpha-4)?
Georgy
On Mon, Feb 2, 2009 at 6:44 PM, Oleg Gusakov
wrote:
+3 binding votes
+3 binding votes, I proceed moving mercury-1.0.0-alpha-4 to production
Thanks,
Oleg
Oleg Gusakov wrote:
This is iterative improvements release of Mercury.
The major change:
- timestamped artifacts can now have dependencies - a bug was fixed
1 issue fixed:
http://jira.codehaus.org/browse
This is iterative improvements release of Mercury.
The major change:
- timestamped artifacts can now have dependencies - a bug was fixed
1 issue fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14889
Staged release in repository at
http://people.apache.org/~ogusakov/repos/staging/
Looks like the name sec.xml is too short and may be confusing. Changing
for encryption-settings.xml
Oleg Gusakov wrote:
After a long and interesting discussion last August
(http://docs.codehaus.org/display/MAVEN/Secured+Passwords) and several
meetings with users, I felt it's overdue to d
After a long and interesting discussion last August
(http://docs.codehaus.org/display/MAVEN/Secured+Passwords) and several
meetings with users, I felt it's overdue to do the actual implementation.
I massaged my old, vintage 2007 code and put it into 2.1.x trunk.
How it all works - more detaile
I feel I owe an explanation about what was going with the release. As we
tried to refactor out jetty server code out of the transport provider,
we hit a few bumps on the road. But with the help from Jetty community,
who were kind enough to fix it and release jetty 6.1.15.rc2 today -
everything
Hate to do this, but logistics are not there yet. Will have to wait for
another jetty release. I will re-issue the vote as soon as it's out and
I do all the moves again.
Thanks,
Oleg
Oleg Gusakov wrote:
Logistics were sorted out, here we go:
This is iterative improvements relea
Logistics were sorted out, here we go:
This is iterative improvements release of Mercury.
Most important are:
- repository exception handling adjusted for clearer client
notifications. For example - absence of metadata did produce NPE result,
now it throws a checked exception
- plexus componen
Vote canceled.
I have to sort out some logistics issues. Will re-post the vote as soon
as that's done
Oleg Gusakov wrote:
This is an iterative improvements release of Mercury.
7 issues fixed:
http://jira.codehaus.org/browse/MERCURY/fixforversion/14748
Most important are:
- repos
This is an iterative improvements release of Mercury.
7 issues fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14748
Most important are:
- repository exception handling adjusted for clearer client
notifications. For example - absence of metadata did produce NPE result,
now it thro
+1
John Casey wrote:
Hi everyone,
I've had the pleasure of working with Petar since sometime around
August or a bit earlier. He's been instrumental in getting this latest
release of the Assembly Plugin tested, patched, and ready to go. His
continued focus on the release cycle for this plugin
Shane Isbell wrote:
I've run into an issue where the current behavior of building a project
model in Maven 2.0.x seems wrong. In the case of inheritance of dependency
scope, there is a default value of "compile". This default will override the
parent scope. This part is correct. But if the depen
+1
Jason van Zyl wrote:
Hi,
This is really to get the ball rolling for Maven 3.x. While I have
some gracious guinea pigs who are arduously pummeling this code base I
wouldn't recommend anyone use this in production. If you want to try
it and give feedback that's great, but we have a lot of w
I remember that wagon, at least 1.0-beta-4, strips everything after " *"
in the signature file including, so it should already be implemented on
the reading side. Wagon team - please correct me if I am wrong - I did
not check out the wagon source.
So we'll have to add it to the writing side of
Hervé BOUTEMY wrote:
I didn't have time to really look at it, but I like this deps directly into
classpath!
really kewl ;)
I know man, I was really excited when it all worked! The coolest part is
that can also be used inside filesets, so you don't need to do
anything special to access fi
FYI - a new dev. snapshot.
After the first round of testing and discussions mercury-ant has had a
face lift:
* added simplified syntax and a system of defaults - examples in
http://people.apache.org/~ogusakov/sites/mercury-ant/mercury-ant-tasks/howto.html
In the simplest form it could be use
Ralph Goers wrote:
I understand what you are suggesting, although the example above
doesn't seem to match since the asm and platform tags are used outside
the scope.
Maybe because we understand the scope a little differently? For me scope
is just a name - it does not have any attributes. So
Ralph,
If we start walking this road - let's generalize starting from existing
model, so that it could still be a subset of the the solution.
So what we have now:
* each artifact "supplies"/"provides"/"has" a set of attributes: groupId
(G), artifactId (A), version (V), classifier (C), type (
Vincent Siveton wrote:
Hi,
2008/12/24, Oleg Gusakov :
[SNIP]
Can you name one single reason why moving this file away and creating 6
additional folders on the way that would not exist otherwise is beneficial?
Without using the argument "it's a convention"? :)
A
Benjamin,
Benjamin Bentmann wrote:
Oleg Gusakov wrote:
If this file sits in the src/main/java/... package - it's one mouse
click in Eclipse to open it. If I move it to src/main/resources/.. -
it becomes a multi-click - one has to click as many times as there
are members in the package
Ralph,
Ralph Goers wrote:
This whole thread makes my head hurt.
Frankly, and at the risk of being repetitious, I think all this work
into making this resolution based on versioning is pretty much a waste
of time. Now if your picture incorporated artifact metadata, such as
"provides" and "re
Brian E. Fox wrote:
Let me respectfully disagree: I used to work for a company where I was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of 1 -
I would be out of job the next day.
Btw, eclipse has
Brian E. Fox wrote:
I also respect the conventions, but in this particular case the
convention became counter-productive: I externalized all the messages
into Messages.properties file per package and have to modify this file
all the time.
If this file sits in the src/main/java/... p
Vincent,
Vincent Siveton wrote:
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I
Benjamin,
It slipped in - fixing. Yes - I remember MERCURY-58 :)
Thanks for catching,
Oleg
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Tue Dec 23 19:55:25 2008
New Revision: 729211
URL: http://svn.apache.org/viewvc?rev=729211&view=rev
Log:
[MERCURY-65] adding mapped repo implem
Vincent Siveton wrote:
Hi,
2008/11/7, ogusa...@apache.org :
Author: ogusakov
Date: Fri Nov 7 18:47:29 2008
New Revision: 712345
URL: http://svn.apache.org/viewvc?rev=712345&view=rev
Log:
added more helper types
Added:
maven/mercury/trunk/mercury-artifact/src/main/java/org/apa
e and
result is so called "repository update policy" which in it's default
implementation, defines cached metadata TTL per remote repository.
Thanks,
Oleg
Gilles Scokart
2008/12/22 Oleg Gusakov :
Gilles Scokart wrote:
I have no doubt that SAT can resolve huge system
Gilles Scokart wrote:
I have no doubt that SAT can resolve huge system of constraints, but I
fear that building the dirty tree migh be very heavy. You may have to
download and parse plenty of pom (or other meta-data files).
BTW, when you download a pom, did you also download the jar, or did
Daniel Le Berre wrote:
Gilles Scokart a �crit :
An Ivy like function might be nice as well.;-) But there is a piece
that I miss. How did you handle conlicts? I means not multiple
possible solution, but real conflicts. This seems to be incompatible
with a strtict system of constraints.
I
Daniel Le Berre wrote:
Oleg Gusakov a écrit :
The tree could be walked in two directions, and these approaches are
equivalent, except for b and c optionality:
Representation #1: P2
a1 -> b1 or b2 or b3
a1 -> c1 or c2
b1 + b2 + b3 <= 1 # this one implicates that b is optiona
uot;, but it's all configurable with a set of comparators, passed to
the solver. And if the need comes - we can cover a lot of exotic
variations, the first one coming to mind - "maven2 compatibility mode"
comparator. Maven2 selects the first version on the same level, Mercury
- the ne
Fixed. Thank you!
Tomasz Pik wrote:
On Fri, Dec 19, 2008 at 7:29 PM, Oleg Gusakov
wrote:
a diagram of mercury inner workflow is here:
http://blogs.sonatype.com/people/?p=1016
One minor change - there should be a1 = 1 instead of a = 1.
Regards,
Tomek
a diagram of mercury inner workflow is here:
http://blogs.sonatype.com/people/?p=1016
fyi - I am also working on re-introducing the "old" maven-ant syntax to
mercury-ant-tasks. Herve - as you wished!
-
To unsubscribe, e-mail:
is posted at http://blogs.sonatype.com/people/?p=1065
Thanks,
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
mercury-ant-tasks is an ant wrapper for Mercury project. I will draft
some documentation tomorrow.
If somebody is interested to try it:
* grab the uber jar from
http://people.apache.org/~ogusakov/repos/test/org/apache/maven/mercury/mercury-ant-tasks/1.0-alpha-1-SNAPSHOT/mercury-ant-tasks-1.0-a
Herve,
Hervé BOUTEMY wrote:
Le mercredi 17 décembre 2008, Benjamin Bentmann a écrit :
Oleg Gusakov wrote:
Unit tests were using those jars to compile test code.
Just a technical question: Is it actually required/desirable to really
compile code during the tests?
Over in the
Benjamin Bentmann wrote:
Oleg Gusakov wrote:
Unit tests were using those jars to compile test code.
Just a technical question: Is it actually required/desirable to really
compile code during the tests?
Over in the Maven core ITs, running the Compiler (or Surefire) Plugin
was the
Jason van Zyl wrote:
On 17-Dec-08, at 9:57 AM, Arnaud HERITIER wrote:
Hi,
In this thread you are talking about several teams. I'm considering
there
is only one maven team. If this not the case is there someone who can
explain to me which teams we have and who is working in which ?
Obv
Brett,
Trust me, I don't enjoy this discussion no more that you, but I have to
respond.
Brett Porter wrote:
I'm sorry you lost some time investigating it, but I made every
attempt to do this properly.
At the time I made the change, I cleaned out the checkout and did a
build without getting
Brett,
Please don't change the code you don't understand without, at least,
consulting people who work on it.
I lost entire day between yesterday and today, trying to understand why
my unit tests suddenly stopped working. They traced to your commit
r725533 which emptied jar files in mercury-
Recorded in http://jira.codehaus.org/browse/MERCURY-59, will comply asahp
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880
URL: http://svn.apache.org/viewvc?rev=726880&view=rev
Log:
[MERCURY-56] verification configuration for mercury ant t
Ben,
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880
URL: http://svn.apache.org/viewvc?rev=726880&view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done,
PGP unit test works on osx. Need test keyrings for other
Hey Ben,
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880
URL: http://svn.apache.org/viewvc?rev=726880&view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done,
PGP unit test works on osx. Need test keyrings for ot
2008, at 1:02 PM, Oleg Gusakov wrote:
6 votes casted
[+1] 6: 4 binding, 2 non-binding
[-1]
[0]
I released Mercury 1.0.0-alpha-2, site at
http://maven.apache.org/mercury
Thanks,
Oleg
Oleg Gusakov wrote:
Dear All,
This is the first release of Mercury with all major [mercury]
functionali
I made a first working snapshot of the Mercury ant tasks available at
http://people.apache.org/~ogusakov/repos/test/org/apache/maven/mercury/mercury-ant-tasks/1.0-alpha-1-SNAPSHOT/mercury-ant-tasks-1.0-alpha-1-20081211-all.jar
Just put this jar into ~/.ant/lib and use
http://people.apache.org/~
6 votes casted
[+1] 6: 4 binding, 2 non-binding
[-1]
[0]
I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury
Thanks,
Oleg
Oleg Gusakov wrote:
Dear All,
This is the first release of Mercury with all major [mercury]
functionality enabled: repository access + dependency
Vincent Siveton wrote:
Hi,
2008/12/11 <[EMAIL PROTECTED]>:
Author: ogusakov
Date: Wed Dec 10 23:23:19 2008
New Revision: 725604
URL: http://svn.apache.org/viewvc?rev=725604&view=rev
Log:
Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about com
Le mercredi 10 décembre 2008, Oleg Gusakov a écrit :
Herve,
Hervé BOUTEMY wrote:
Hi Oleg,
In fact, I have only one question: why create a completely new codebase?
Of course, the new code with less features is simpler *for the moment*:
less features is less code.
At first I honestl
Herve,
Hervé BOUTEMY wrote:
Hi Oleg,
In fact, I have only one question: why create a completely new codebase?
Of course, the new code with less features is simpler *for the moment*: less
features is less code.
At first I honestly tried to plug in Mercury into existing code, but:
* as the c
If I may cast my opinion here as a direct recipient.
When I saw "Oleg, I have to -1 this" to me it sounded like a death
sentence, an honorable PMC member vetoed my changes! And for what - test
repo is too big ??
Right after this - I see that I can no longer connect to
people.apache.org nor c
Whoever might be interested, and especially Herve:
I am putting together a simplified ant wrapper for Mercury. Can you
please critique http://jira.codehaus.org/browse/MERCURY-48 ?
Main idea - create a simple to use syntax, yet being able to extend it
to full power of Mercury. The game plan is
Dear All,
This is the first release of Mercury with all major [mercury] functionality enabled: repository access + dependency resolution. You can try using it for resolving artifacts and then writing them into a local repo in a standalone application, event system helps to understand what is goin
1 - 100 of 228 matches
Mail list logo
