On 13/11/2007, at 4:37 AM, Richard van Nieuwenhoven wrote:
I see different solutions, but witch one to take
- copy the sources and leaf them as untouched as possible (may be even
in a own source folder to separate them and exclude them from code
reformating)
yes, they will need to be sep
Hi Jason,
This sounds like a really great idea.
Is there an issue or wiki page I can refer people to with regard to this
change? Seems like it should be an improvement noted on the deploy plugin
JIRA.
Cheers,
Matt
On 10/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> I've been working on so
Hi Dennis,
Is it a known limitation of release plugin? I am not aware about this.
Cheers,
Vincent
2007/11/13, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
> Date: Tue Nov 13 11:49:14 2007
> New Revision: 594621
>
> URL: http://svn.apache.org/viewvc?rev=594621&view=rev
> Log:
> o Kee
Thanks for that.
I ended up by patching the cargo uberwar behaviour and adding
a true
option, which makes the lib directory contain the 'correct, calculated'
dependencies.
I resorted to a hideous hack to do it (generating "shadow" pom files in the
repository with "war" types converted to be "pom"
I agree with Brett. Any organization that is "seriously" using Maven
is probably running a proxy/repo manager.
Also, I know how other people "manage" their repos, and it is a bit
scary. I don't trust most of them to never change artifacts etc. "Oh
this jar has a bug, but its only been out for 2 we
On 13 Nov 07, at 9:15 AM 13 Nov 07, Paul Gier wrote:
Jason van Zyl wrote:
On 12 Nov 07, at 4:21 PM 12 Nov 07, Mark Struberg wrote:
--- Johan Kindgren <[EMAIL PROTECTED]> schrieb:
Maybe it's better to make things easier for the
committers? I've been following this list for a couple of months,
On 13/11/2007, at 9:46 AM, Paul Gier wrote:
Brett Porter wrote:
Hi all,
This has been the state of play in surefire for some time due to
lack of volunteers: http://docs.codehaus.org/display/MAVEN/
Surefire+TestNG+refactoring
I'm still only finding occasional time for it and usually some
r
That would be a better description of my issue :
There is no way to access from maven1 some artifacts that use the
m2-specific "classifier" concept. Using classifier would create
valid m1 requests but requires to configure some custom type -> extensions
mappings in archiva.
Nico.
2007/11/13, Bre
Brett Porter wrote:
Hi all,
This has been the state of play in surefire for some time due to lack of
volunteers:
http://docs.codehaus.org/display/MAVEN/Surefire+TestNG+refactoring
I'm still only finding occasional time for it and usually some
regression in 2.3 takes my attention first - I st
Good point - in fact Joakim had mentioned this already and I gave the
same explanation. Coffee helps me remember :)
So you're really looking for a feature request to make the m1 type
mappings extensible?
- Brett
On 13/11/2007, at 9:44 AM, nicolas de loof wrote:
That's right, I just forgo
That's right, I just forgot those ones :-/
Requesting org.apache.commons/jars/commons-io-1.3.2-sources.jar also fails
and is translated to
org/apache/commons/commons-io/1.3.2-sources/commons-io-1.3.2-sources.jar
But maybe this is NOT an issue : in maven1 world there is no classifier, and
my back
Anything with source or javadoc :)
- Brett
On 13/11/2007, at 9:33 AM, nicolas de loof wrote:
MRM-593
Do you know any artifact in central that uses a classifier ? I'd
like to
make the test on a non-SNAPSHOT artifact. Struts does not publish
it's "j4"
backported artifacts.
Nico.
2007/11/
MRM-593
Do you know any artifact in central that uses a classifier ? I'd like to
make the test on a non-SNAPSHOT artifact. Struts does not publish it's "j4"
backported artifacts.
Nico.
2007/11/13, Brett Porter <[EMAIL PROTECTED]>:
>
> Thanks again Nicolas - I'm sure this is easily fixed, so it w
Thanks again Nicolas - I'm sure this is easily fixed, so it would be
worth dropping in JIRA.
- Brett
On 13/11/2007, at 9:20 AM, nicolas de loof wrote:
I have a lib that is built by maven2. It also has a retrotranslator
version,
with classifier "-backport", as part of the build process.
Wh
You can also use the plexus command line utils:
http://plexus.codehaus.org/plexus-utils/
http://plexus.codehaus.org/plexus-utils/apidocs/index.html
I think that's what the release plugin is using.
Daniel Kulp wrote:
On Monday 12 November 2007, Jens Rapp wrote:
well, i use a self-written plugi
I have a lib that is built by maven2. It also has a retrotranslator version,
with classifier "-backport", as part of the build process.
When I deploy a SNAPSHOT of this lib, I get :
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from platina
Uploading: /jmonit-1.0-alpha-1-SNAP
Jason van Zyl wrote:
On 12 Nov 07, at 4:21 PM 12 Nov 07, Mark Struberg wrote:
--- Johan Kindgren <[EMAIL PROTECTED]> schrieb:
Maybe it's better to make things easier for the
committers? I've been following this list for a couple of months, and
it seems to be a reoccuring issue that patches ar
On 13/11/2007, at 4:45 AM, Dimitris Kapanidis wrote:
P.S. duplicate declarations of the same plugin isn't a good idea.
I run to a similar problem also the other day, maybe duplicate
declarations should be warned-out by maven in the future (a check
during parsing for duplicates and a messag
Actually, it's 19Gb
Emmanuel
Jens Rapp a écrit :
hi again,
i'm trying to get a new copy of the mvn plugin central for about a week. Until now, i got about 15GB. maven homepage says that there are about 10 GB..
So, how much data is it really?
All,
with a very small code change and 2 small sources from a eclipse-plugin
the maven-eclipse-plugin will be able to connect projects to the
projects in the workspace instead of the jars for the repository. This
is a very important feature for the maven-eclipse-plugin.
Now to my question:
To do
Marat Radchenko (JIRA) wrote:
[ http://jira.codehaus.org/browse/SUREFIRE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113289 ]
Marat Radchenko commented on SUREFIRE-351:
--
This is not a bug. Instead, use the follo
I think the whole central repo is >30gb.
-Original Message-
From: Jens Rapp [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 13, 2007 10:53 AM
To: dev@maven.apache.org
Subject: how big is the plugin central?
hi again,
i'm trying to get a new copy of the mvn plugin central for about a w
hi again,
i'm trying to get a new copy of the mvn plugin central for about a week. Until
now, i got about 15GB. maven homepage says that there are about 10 GB..
So, how much data is it really?
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung
I agree with what Brian has said. FWIW, any organisation can
implement this internally in minutes by configuring any one of the
available repository managers [1].
The only thing I'd add is that in my opinion Maven needs better
support for true mirrors (of central, but also any other repo),
This sounds good on paper, but in practicality it could be troublesome.
First of all, there are many more moving parts and we can't be sure of
or control the reliability of all these remote repos. Recall the trouble
we had with Ibiblio a few years ago and the instability there. Since
central move
All,
It's time to move forward with 2.0.8. I stopped to evaluate MNG-3259 but
I think this is an edge case and the fix has a greater chance of
breaking more stuff. I'd rather fix this early in 2.0.9 so there is
plenty of time for any issues to surface. I've placed a new build on
http://people.apac
26 matches
Mail list logo
