The Apache Maven team would like to announce the availability of Maven
2.0.8. We closed out 32 issues and no major issues upgrading are
expected.
There is one slight change to be aware of, the test-classes folder is
now before the classes in the classpath to allow test resources to
override
Hi jim, it might be a typo below, buy you still need to specify the
goa in the poml, just not the phase.
--Brian
On May 12, 2008, at 5:14 PM, Jim Bethancourt
[EMAIL PROTECTED] wrote:
Hi all,
I'm trying to bind my mojo to the package phase using @phase
package, and
it's not working.
My guess is that one of your plugins isn't resolving the correct scope
of dependencies and having the enforcer masks this.
Sent from my iPhone
On Jun 4, 2008, at 11:33 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
Are you sure ?
I tested it all the day and it doesn't work for me without
If we don't include the new artifact code, the we need to fix several
issues related to reresolving artifacts multiple times.
On Jun 13, 2008, at 5:28 AM, Brett Porter [EMAIL PROTECTED] wrote:
I went through the unscheduled bunch of issues looking for
reported 2.1 regressions this
I agree that this is a big regression and most people will stay on
beta 5 untill it's fixed... Possibly making a release without it
pointless
--Brian (mobile)
On Jun 27, 2008, at 9:26 AM, Bouiaw [EMAIL PROTECTED] wrote:
Just a user advice :
I don't know if it is a blocker for you, but
You mean bootstrap first, then use that build to run release:prepare...?
--Brian
On Jul 7, 2008, at 6:13 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
Hi,
I'm working release planning, and I want to define how we actually
build Maven for a release.
For me it essentially boils down to:
Use
She takes a lot of vacation :-)
--Brian (mobile)
On Jul 11, 2008, at 5:18 PM, Vincent Siveton [EMAIL PROTECTED]
wrote:
Not again ;)
Vincent
2008/7/11, Julia Antonova [EMAIL PROTECTED]:
I will be out of the office starting 12.07.2008 and will not
return until
28.07.2008.
I will
What if we just turn off the repeated build failure emails?
Sent from my iPhone
On Jul 28, 2008, at 6:42 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi
I think that we need to change the setup in Hudson for Maven
Plugins. Currently there is a job [1] called Maven-Plugins which
has a
No, it's not required to redo it as freestyle just to add fae
On Jul 30, 2008, at 9:45 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
Just use a freestyle project and then you can do whatever you like.
On 30-Jul-08, at 6:36 AM, Arnaud HERITIER wrote:
Is it possible ?
I never saw this option in
Go for it
Sent from my iPhone
On Jul 30, 2008, at 9:13 AM, Benjamin Bentmann [EMAIL PROTECTED]
wrote:
Hi,
while having a look at the recent failure during build #181 of maven-
shared, I noticed that the modules after the failing one were not
build at all (Build failed before it gets to
Just add -fae to the goals line. Until I verify the use separate repo
works I prefer to use the maven switch directly
Sent from my iPhone
On Jul 30, 2008, at 9:36 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
Is it possible ?
I never saw this option in hudson.
Is it the option called
As I said before, this was done by infra with no notice to us. The new
policy of purging is theirs, not ours. See the infra archives if you
would like to read about it.
On Aug 5, 2008, at 10:45 PM, Patrick Moore [EMAIL PROTECTED]
wrote:
Of course this means that the maven team is
Shane has reworked maven project with an eye towards these use cases.
This stuff is in maven 3.0
Sent from my iPhone
On Aug 25, 2008, at 8:26 PM, Ralph Goers [EMAIL PROTECTED]
wrote:
I'm still confused. If I had thought that it could be done that way
I would have done it in the first
Sounds good to me
Sent from my iPhone
On Sep 3, 2008, at 5:35 PM, John Casey [EMAIL PROTECTED] wrote:
Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we have a concrete strategy for
implementation including a design doc, I don't feel
I don't but I don't know how not including it might affect the site
specifically. The parent isn't a magical thing and it's been 6 months.
Why not release it, do the enforcer and release it again? Release it 3
or 4 more times for good measure.
Sent from my iPhone
On Sep 8, 2008, at 4:47
Ok, I'll take another look and if it works correctly put it back for v10
Sent from my iPhone
On Sep 13, 2008, at 6:12 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brian E. Fox wrote:
No, it's available in the quality-checks profile as well.
I saw that but it didn't work. It tried to find
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient so there's no reason to
exclude it in the new wagon. Taking it away simply because someone
could be dumb doesn't sense, especially since we already have on valid
use case for it.
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Sent from my iPhone
On Sep 29, 2008, at 10:08 PM, Oleg Gusakov
[EMAIL PROTECTED] wrote:
I implemented this method to pass ITs, it's existence is off the
table.
Brian Fox wrote:
Oleg
Arnaud, the idea is to limit the scope to new regressions once we
start an RC. Otherwise we would spin in circles forever.
--Brian (mobile)
On Oct 29, 2008, at 2:04 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
ok brett,
I'll try to create a testcase without seam.
Even if we try to
You can't unset something like that because it appears null and the
merge will overwrite it. You could change it to something else though
--Brian (mobile)
On Oct 29, 2008, at 1:49 AM, Nick Pellow [EMAIL PROTECTED] wrote:
Hi,
If a plugin is defined in the normal build section of a pom and
=10500Create=Create
And I've staged RC-3 here:
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC3/
Please try it out and see if we have any remaining regressions over 2.0.9.
Thanks,
Brian
--
Brian Fox
Apache Maven PMC
http
There's nothing presumptive about the fact that it HAS been deprecated
in trunk for quite some time now. (since it was still called 2.1-snap)
The aggregator is full of problems and usually leads to recursive
builds when you bind it to the lifecycle. A complely new concept is
needed to
Only the rsync to central and then to the mirrors has changed.
--Brian (mobile)
On Dec 12, 2008, at 3:13 AM, Jason Dillon ja...@planet57.com wrote:
Oh, I thought it was the same sync'ing as with sites, every few
hours, or has that changed now too?
--jason
On Dec 12, 2008, at 3:05 PM,
It's not just about ignorig the ids. What about the distmgt info that
would be needed to deploy... Or filtering or processing of it? I think
it's just better to keep processing of the Nixon separate.
--Brian (mobile)
On Dec 18, 2008, at 10:15 AM, Ralph Goers ralph.go...@dslextreme.com
The solution outlined below is the recommended way to handle this.
Copy/unpack was meant to handle external artifacts.
--Brian (mobile)
On Dec 18, 2008, at 4:28 PM, Jamie Whitehouse basil.whiteho...@genesyslab.com
wrote:
I've run into a similar situation and I'll explain how I resolved
Pretty sure that's when he's targeting the stage/vote.
--Brian (mobile)
On Dec 22, 2008, at 2:00 PM, Jochen Wiedmann jochen.wiedm...@gmail.com
wrote:
On Mon, Dec 22, 2008 at 3:54 AM, Jason van Zyl
jvan...@sonatype.com wrote:
I plan to release it January 5th.
Beg your pardon, but
I'm -1 to making a new format, but ambivalent about changing it to
match openssl standards
--Brian (mobile)
On Jan 2, 2009, at 5:31 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
With regard to MINSTALL-47, I would like to discuss if we can/should
change the format used
The Maven team is pleased to announce the release of the Maven
Clean Plugin, version 2.3
This plugin is used to delete artifacts to provide a clean build.
http://maven.apache.org/plugins/maven-clean-plugin/
You should specify the version in your project's plugin configuration:
plugin
The Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.1
This plugin is used to copy and unpack artifacts and dependencies. It
also provides visualization and optimization tools for your project
dependencies.
Good point, I didn't consider things in a repo. We'll have to take the
last one in that case.
--Brian (mobile)
On Jan 26, 2009, at 6:21 PM, Brett Porter br...@apache.org wrote:
On 26/01/2009, at 12:17 PM, Brian E. Fox wrote:
It should be a validation error if we find duplicated entries.
The range should simply skip 3.0alpha1 and 2
--Brian (mobile)
On Jan 29, 2009, at 12:45 AM, Arnaud HERITIER aherit...@gmail.com
wrote:
What i understand in brett's email is that its patches are for 2.1
branch
but he would like to add ITs to check those fixes in 2.1. His
question seems
Thanks for reminding me. We'll implement a custom plugin to validate
the sigs and send a notification. If the sigs don't match, we can stop
the promotion.
--Brian (mobile)
On Feb 8, 2009, at 12:32 PM, Wendy Smoak wsm...@gmail.com wrote:
On Thu, Feb 5, 2009 at 10:19 PM, Brett Porter
Any thing fixed in 2.0.10/11 will be in 2.1+
--Brian (mobile)
On Feb 8, 2009, at 12:42 PM, Paul Benedict pbened...@apache.org wrote:
While I prefer 2.1 to be released soon, I am more interested in bug
fixes from 2.0.10 and 2.0.11 than the new features.
What do you guys think about moving
Is it released yet? The reason it didn't make the previous releases is
that it wasn't ready. I think it should be in 2.1 but not 2.0 at this
point
--Brian (mobile)
On Feb 8, 2009, at 1:03 PM, Lukas Theussl ltheu...@apache.org wrote:
Picking up the doxia thread:
I have the feeling Doxia
I have it on my todo to integrate mercury into the dependency plugin.
Most of the shared component will be superceded by mercury. It's too
early to say if the Interface will change or not
--Brian (mobile)
On Feb 16, 2009, at 5:54 PM, pi song pi.so...@gmail.com wrote:
I have just noticed
You will need to change the distmgt to match the new parent poms or
wait for those to be staged(I'm waiting for svn to be back up to
finish all the plugin updates)
--Brian (mobile)
On Feb 16, 2009, at 5:58 PM, Arnaud HERITIER aherit...@gmail.com
wrote:
Without any other comments, I'll
IMO it should continue, I merely copied the artifacts from one
location to another. Inspecting the signatures should validate the
artifacts.
--Brian (mobile)
On Feb 18, 2009, at 8:16 AM, Vincent Siveton
vincent.sive...@gmail.com wrote:
Hi Dennis/Brian,
Does the vote could continue
The Maven team is pleased to announce the release of the Maven 2.0.10
This is a stable bug fix release and you can see the full list of
issues fixed at
http://maven.apache.org/release-notes.html
Enjoy,
-The Maven team
-
To
No, 2.1 should be 1.5 so the job is wrong.
--Brian (mobile)
On Feb 25, 2009, at 2:32 AM, Brett Porter br...@apache.org wrote:
Sorry, I keep forgetting we're still 1.4 minimum on here. It's just
a test library - I can fix when I get back in a couple of hours.
- Brett
On 25/02/2009, at
The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0-beta-1
The Enforcer plugin is used to fail a build if certain constraints are
not met. There are too many standard rules to describe here, but check
out the site for more details:
Awesome, thanks Hervé
--Brian (mobile)
On Mar 6, 2009, at 6:12 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le vendredi 06 mars 2009, Hervé BOUTEMY a écrit :
I tried to deploy a new 2.3-SNAPSHOT, just with the actual trunk
code, but
got a 401 return code from
The assembly plugin can construct a repo and put it in a zip, but I
would be surprised if this case is covered. then you would have to
devise a way to unpack the zip to the users local repo.
--Brian (mobile)
On Mar 13, 2009, at 4:38 PM, Kaveh Goudarzi ka...@itkaa.com wrote:
Hi Brian,
.
Brian Fox wrote:
The assembly plugin can construct a repo and put it in a zip, but I
would be surprised if this case is covered. then you would have to
devise a way to unpack the zip to the users local repo.
--Brian (mobile)
On Mar 13, 2009, at 4:38 PM, Kaveh Goudarzi ka...@itkaa.com wrote
+1
Benjamin Bentmann wrote:
Hi,
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540styleName=Htmlversion=14831
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11540status=1
Staging repo:
We currently have some expectations about what artifacts are created for
apache builds, such as javadocs and source jars, and specifically
artifact signatures. Currently each project must configure the current
release profile in their own top level pom. This raises the bar of entry
for new
Martijn Dashorst wrote:
I think this is a great idea. You could even put the new apache wide
repository and staging area in the release profile. Would make doing a
release a snap IMO.
That part is already in Apache-5 ;-)
Raphaël Piéroni wrote:
Hi folks,
I try to prepare the release of the next version of the archetype plugin,
but i fail.
The release plugin tell me it can't create the tag.
I run mvn release:prepare -DdryRun=true without any problem,
but when i remove the dryRun, i got this exception :
[INFO]
This was a test. Emails will be sent out when new artifacts are staged
and again when things are promoted. This is to improve visability into
what is being deployed into the repo but the repo team and each dev team.
Nexus Repository Manager wrote:
The following artifacts have been staged to
.
2009/4/14 Arnaud HERITIER aherit...@gmail.com:
Or you have to use SVN 1.5.0 or 1.6.0 bianires. No 1.5.x.
Arnaud
On Tue, Apr 14, 2009 at 11:33 PM, Brian Fox bri...@infinity.nu
wrote:
Raphaël Piéroni wrote:
Hi folks,
I try to prepare the release of the next version of the
archetype
The original dependency plugin filtering syntax was intended for a
different purpose. It was meant that you might filter only on group id
and not a combination of all the fields.
Paul Gier wrote:
I like the syntax that you chose using includes and excludes
containing a comma separated list of
Each of those fields maps to a separate filter in the artifact filters.
The filters grew over time but they were meant to be used separately
most of the time. So you might say copy all com.sonatype or exclude
org.apache but rarely try to specify and individual artifact...that's
what the
.
2009/4/14 Arnaud HERITIER aherit...@gmail.com:
Or you have to use SVN 1.5.0 or 1.6.0 bianires. No 1.5.x.
Arnaud
On Tue, Apr 14, 2009 at 11:33 PM, Brian Fox bri...@infinity.nu
wrote:
Raphaël Piéroni wrote:
Hi
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
The changes were described
it explicitelytherefore if people have their own existing
release profiles, it's probably better that we don't stomp on them.
Jochen Wiedmann wrote:
On Tue, Apr 21, 2009 at 5:05 AM, Brian Fox bri...@infinity.nu wrote:
projects to produce proper releases. I think to do it and avoid conflicts
+1
Paul Gier wrote:
I still need on more vote on this before I can release it.
So far we have:
+1 (binding): John Casey, Benjamin Bentmann
Thanks!
Paul Gier wrote:
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147styleName=Htmlversion=13830
There
That was an error, I'll roll it back.
Dennis Lundberg wrote:
Brian, why are you modifying the pom.xml file under the apache-5 tag?
That has already been released and shouldn't be tampered with...
bri...@apache.org wrote:
Author: brianf
Date: Tue Apr 21 01:55:16 2009
New Revision: 766940
We previously already voted that 2.1.x would require 1.5.
Arnaud HERITIER wrote:
Bumping the Java requirement doesn't feel like a maintenance release IMHO.
Therefore, shouldn't we bump the Maven version to 2.2 as well and rename the
branch or create a new one?
+1 It's a too big change for
It definately sounds strange to me, but without debugging through that
code it's hard to say for sure.
Stephen Connolly wrote:
Bump!
Brett, Jason, Benjamin, Brian, anyone?
-Stephen
2009/4/21 Stephen Connolly stephen.alan.conno...@gmail.com
mailto:stephen.alan.conno...@gmail.com
Came
On the release plugin I believe John Smart has that working. And
having our release toolchain tested before switching is a completely
reasonable criterion.
That's my primary concern, that the tools support it, or we experiment
first to find out _how_ they work. It seems like from the
Mark Struberg wrote:
technically there is no git repo which is 'better' than the other.
This hierarchy is an orga one.
If you can pull from my repo and from Jasons, from whom will you pull your
master mainly? Bet you will pull from Jasons. And I also bet all contributors
will try to get
Agreed 100%, it applies across the board. We have two hurdles, one easy,
one not so easy:
1. fix the release plugin / scm provider.
2. convince infra to host a rw git repo.
Tim O'Brien wrote:
I think DVCS would benefit Maven doc. Someone (not a commiter) could clone
the site, fix it,
Isn't Nicolas around, maybe he'd like to offer a translation?
Jason van Zyl wrote:
Thanks if that seems like a reasonable translation I will respond.
On 23-Apr-09, at 4:00 PM, Christian Edward Gruber wrote:
My french isn't perfect, but the article basically...
summary
...argues against you
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix the
other stuff, great. But lets keep the scope very small and limited so we
can get the regressions in 2.1.0 out quickly. I'm afraid that relabeling
it 2.2 would mean a pile on the bandwagon effect occurs and we'd be
stuck
FWIW, here might have been a good place to discuss concerns to begin
with, instead of on a blog.
Brian Fox wrote:
Isn't Nicolas around, maybe he'd like to offer a translation?
Jason van Zyl wrote:
Thanks if that seems like a reasonable translation I will respond.
On 23-Apr-09, at 4:00 PM
2) On a more serious note: this is EXACTLY the issue. Jason is no more
special than I am or anyone else on the Maven PMC. That is why there is a
centralized storage for the repo. Anyone on the PMC (actually, any
committer) MUST have access to entire repo for the project and be able to do
On 4/23/2009 9:57 PM, Brett Porter wrote:
On 24/04/2009, at 9:55 AM, Brian Fox wrote:
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix the
other stuff, great. But lets keep the scope very small and limited so
we can get the regressions in 2.1.0 out quickly.
I don't think
or in settings.xml, it will just prompt you for
the passphrase. Thus, it's not needed in the config.
Dan
On Mon April 20 2009 11:05:50 pm Brian Fox wrote:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/a
pache/apache/6/apache-6.pom
Svn is up again it seems so you can login to Nexus if you want to look.
On 4/24/2009 1:40 AM, Brett Porter wrote:
Can't access these since Nexus is not responding because SVN is down.
My vote is on the ones in SVN, I'm going to trust they are the same.
+1
On 21/04/2009, at 1:05 PM, Brian Fox
because people _can_
rebase/resync their local repo clone doesn't mean they _have to_. Code
in different repo clones could diverge pretty wildly. In particular,
I'm thinking about Don Brown's maven builds, only magnified.
Just some thoughts.
-john
Brian Fox wrote:
2) On a more serious note
I'm talking with the jgit guys to see about adapting the git archive
functionality to implement an effective export that we can use from the
release plugin. Mark, it looks like the git provider is already setup to
easily integrate an alternate implementation so I think this won't be
hard once
If you like me to help then simply ping me, I'd be honoured to help.
I didn't dive into the testing structure in place there, but if it
doesn't exist already, some external ITs would be awesome. Something we
could run against the multiple implementations to guarantee compatibility.
Anyone else? We have just two votes so far.
On 4/20/2009 11:05 PM, 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
Brian Fox bri...@infinity.nu:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/ap
ache/apache/6/apache-6.pom
https://repository.apache.org/content/repositories/maven-staging-012/org/apa
che/maven/maven-parent/12
We already decided to move to 1.5 in 2.1 but never did. For me it's a
given in 2.2, why even bother debating it?
John Casey wrote:
Read MNG-4140. We had a solution much like you mention (it used string
searches, not DOM searches, but amounts to the same thine...the
version element is
Besides inertial friction to a change, is there a specific reason not to
consolidate on a single http provider? We already know that people may
use the dav wagon simply to handle larger artifacts and such, it seems
like reducing our surface area here would help
I wouldn't be opposed to
I've promoted these artifacts to the release repository.
Brian Fox wrote:
This vote now has sufficient votes to pass. However some concerns were
raised on legal-discuss (apparently a month ago and not mentioned
here) that may require some tweaks to the release profile. I'll hold
on promoting
I'm not sure if this is in scope of what John is trying to do wrt to 2.2.
Jason van Zyl wrote:
I don't believe anyone actually agreed to this yet. Are you sure this
is not going to cause problems for users?
On 1-May-09, at 1:04 AM, nico...@apache.org wrote:
Author: nicolas
Date: Fri May 1
ClassCastExceptions at
runtime or sue type-safe collections to help them create stronger
code ?Anyway,
few plugins allready use Java5. Java 1.4 based one will not be
broken as the
generics signature is only a compile-time check.
2009/5/1 Brian Fox bri...@infinity.nu
I'm not sure if this is in scope
Changes like this are pretty disastrous:
-private MapString, ArtifactVersion managedVersionMap;
+private MapString, Artifact managedVersionMap;
Does it even compile?
John Casey wrote:
Can you please take a look at any other code you might have
automatically fixed using Eclipse's
Maybe that code could be rolled into the indexer since it's the source
of the data.
Tamás Cservenák wrote:
We could create a CLI tool out of Nexus Archetype Plugin in similar manner
as Nexus Indexer CLI exists (or even make those two CLIs
one?) Naturally, the Archetype CLI would required
Why would you have a symlink in your target folder to someplace important?
On Mon, May 4, 2009 at 5:25 PM, Bouiaw bou...@gmail.com wrote:
Hi,
Sorry to write again about clean plugin, but there is currently 2 VERY big
bugs in Maven clean with no workaround.
Just so it's clear, I'm -1 on this commit. I see things like:
-private MapString, ArtifactVersion managedVersionMap;
+private MapString, Artifact managedVersionMap;
And that means it wasn't done properly and thus I have no faith in the rest
of the commit. Please revert this.
On Mon, May
.
There's no need to introduce additional risk for nearly no gain.
On Fri, May 1, 2009 at 11:05 AM, Brian Fox bri...@infinity.nu wrote:
I'm not sure if this is in scope of what John is trying to do wrt to 2.2.
Jason van Zyl wrote:
I don't believe anyone actually agreed to this yet. Are you sure
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
Brett Porter wrote:
Don't we already have the archetype:crawl mojo?
On 05/05/2009, at 3:52 AM, Brian Fox wrote:
Maybe that code could be rolled into the indexer since it's the
source
There have been a few threads spawned on various ASF lists lately about
the release process at the ASF and Maven projects and other Apache
projects that use Maven being compliant.
A documentation patch for the release page at
http://www.apache.org/dev/release.html is pending, but it's close
Yeah, that's what made me think about combining them.
Brett Porter wrote:
On 05/05/2009, at 10:16 AM, Brian Fox wrote:
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
True. Is there a way for the indexer to generate it during
: Brian Fox bri...@infinity.nu
An: dev@maven.apache.org
Gesendet: Dienstag, den 5. Mai 2009, 03:01:25 Uhr
Betreff: Update on ASF Release requirements
There have been a few threads spawned on various ASF lists lately about the
release process at the ASF and Maven projects and other Apache projects
05 mai 2009 00:12:55, Brian Fox a écrit :
Why would you have a symlink in your target folder to someplace
important?
Here is a quick example that came to my mind : Imagine you package a
tarball
containing such a symlink and that during the build you have to extract it
to
change
What options are being passed to the release invocation? It's using -f
which seems to be invalid.
Paul MERLIN wrote:
Hey,
I had no issue building my projects.
release:prepare is working but release:perform is not (see the trace below).
I switched to 2.1.0 right after that and the
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 wait. Main question was
On Thu, May 7, 2009 at 4:31 PM, Asgeir S. Nilsen asge...@gmail.com wrote:
I've set up a local Nexus repository mirroring some central
repositories. I'm using Maven 2.1.0.
In settings.xml I've set up the mirror as such, using the new mirrorOf
syntax:
mirror
idTwingine/id
On Sat, May 9, 2009 at 4:48 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I found that there is a little list of incompatibilities form m2.1 at:
http://maven.apache.org/release-notes.html
However there are a lot more.
E.g. with
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are you using the release plugin?
Additionally
Are you using the release plugin?
Nope! I tried it and came to the point that is no good for me.
I also had a discussion with the developers long time ago
and filed some feature request. Anyhow I still think this
is the wrong approach for me.
Can you give more details about what doesn't
I agree that this (lack of generics) can be a problem, but concur that it's
not the most pressing thing, particularly with 3.x looming ahead. Fixing
bugs in 2.x would serve the users far more and once 3.x stabilizes, then we
can add generics if they aren't there yet.
On Sun, May 10, 2009 at 3:48
It's time to start looking at the problems with the current 2.x resolution
scheme as it specifically relates to repository declaration and discovery.
I've created the start of a document at [1]. This should be the place to
gather feedback and use cases that will help drive towards a more complete
Can you give more details about what doesn't work or doesn't match your
process?
E.g. it tried to convince me to release all modules of my entire project
and complained if some module had a non SNAPSHOT version.
Since it's going to convert a module to a release version, you shouldn't
As I already said, I talked about release-plugin and my view of the world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and NOT by
the philosophy of some plugin.
I'm trying to understand your structure and
There's no source bundle.
On Thu, May 14, 2009 at 3:59 AM, Lukas Theussl ltheu...@apache.org wrote:
Hi,
We solved 27 (Doxia) and 3 (Sitetools) issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=15073
We can try a release maybe next week. We first have to get some assembly and
parent pom things fixed to get our releases back in compliance with asf
policy.
On Thu, May 14, 2009 at 8:42 AM, Nick Stolwijk nick.stolw...@gmail.comwrote:
I don't know when it will be released, but take a look at [1]
1 - 100 of 661 matches
Mail list logo
