Thanks Dennis for the initiative. Unfortunately it comes at a bad time for me, I'm
afraid I won't be able to help much in the next weeks (new job, new country, new
home...) but I fully endorse your plan of action. See my comments below.
Dennis Lundberg wrote:
Hi all
I think it's about
Hi!
Just make a step back and look at the repository problematic from a bit
different perspective.
I'm working for a few companies and even different projects in those companies
use different repositories sections in their poms.
But in my local repo, all the artifacts from those repositories
This was a proposal about a year or two back IIRC there were other
more pressing issues and nothing much happened since.
The proposal was part of the make repository access thread-safe for
people using maven on CI systems, or running builds in parallel from
the CLI
-Stephen
2009/10/30 Mark
Thanks Stephen!
Wasn't aware that Brett had the same idea a long time ago.
Found it now:
http://markmail.org/thread/wqi43wiwbj43vwq6
It would be a good amount of work, but since this seems to pop up regulary, we
may think about it for m3.
LieGrue,
strub
- Ursprüngliche Mail
Von:
Reading the original proposal again, I've an idea:
The structure of the local repository should become:
~/.m2/repository
|-- cache
|-- remote
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
`-- workspace
|-- default
|-- workspace1
`-- ...
The purposes of
+1
Arnaud
On Fri, Oct 30, 2009 at 12:29 AM, Olivier Lamy ol...@apache.org wrote:
+1
--
Olivier
2009/10/30 Benjamin Bentmann benjamin.bentm...@udo.edu:
Hi,
if some of you have a déjà vu while regarding the mail title, that's
fine...
my previous attempt at making our release
Le Tue, 13 Oct 2009 10:09:34 -0400,
John Casey jdca...@commonjava.org a écrit :
Hi guys,
I'd like to know if I can vote with you ? or is it reserved to people with
credentials on svn ?
+1
Arnaud HERITIER wrote:
Hi,
We solved 2 issues:
Mark Struberg wrote:
But in my local repo, all the artifacts from those repositories gets merged to
a single big landfill.
That seems to be a completely independent issue, isn't it? The question
I originally raised was about what repositories ought to be considered
during dependency
Everybody can vote, and you are encouraged to do so if you have tested the
release. Even though officially only PMC votes count to determine the result,
every other vote is appreciated as additional feedback. See
http://www.apache.org/foundation/voting.html.
Cheers,
-Lukas
Tony Chemit
In general I think this could be handy, but I'm mostly thinking from
the angle of separating things needed BY the build from things needed
FOR the build. Ie separating Maven and plugin dependencies from the
project being built's dependencies. Specifically to handle things like
blocking GPL
If I understand your comments om MSHARED-120 correctly, the Changes
Plugin should not be affected by this, because the previous 2.1 version
of the plugin uses Doxia 1.0-alpha-11.
Vincent Siveton wrote:
Hi Dennis,
For the changes plugin, we probably need to release before
maven-reporting-impl
Hi,
I have a multimodule project and it fails during release:perform with new
javadoc plugin.
I'm working on a simple project to open an issue, but let me explain the issue
in case someone can tell me if there is something wrong in my configuration.
Say my project is composed of:
Parent
-
It's a great new. Thanks Dennis for the initiative.
2. Which issues do we include?
Here's a list of the issues currently scheduled for the above releases:
http://jira.codehaus.org/browse/MSHARED-102
http://jira.codehaus.org/browse/DOXIA-354
http://jira.codehaus.org/browse/DOXIA-355
Yes, these things tend to degrade. Please stay on topic.
This can be another discussion but I separated and layered the local
repository implementation some time ago to allow for:
1) snapshot only local repositories
2) per project local repositories
And there are still fundamental issues
Txs Benjamin!
I don't think it is that different, because my real problem is that I cannot
distinguish between those artifacts because of that.
So the problem of _retrieving_ those artifacts (and detecting problems within
them) maybe can be solved by storing them in a different way?
In other
There are three primary variants of how the artifact resolution can
work with respect to repositories where RS is the set of remote
repositories that will be used for artifact resolution:
1) RS is what's available in the effective POM. Easy.
2) RS is collect from inspecting metadata
I was reading the Introduction to the POM page. It says:
These variables are all referenced by the prefix project..
You may also see references with pom. as the prefix, or the
prefix omitted entirely - these forms are now deprecated and
should not be used.
Will these old-style uses finally
On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
I was reading the Introduction to the POM page. It says:
These variables are all referenced by the prefix project..
You may also see references with pom. as the prefix, or the
prefix omitted entirely - these forms are now deprecated and
should
Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit :
On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
I was reading the Introduction to the POM page. It says:
These variables are all referenced by the prefix project..
You may also see references with pom. as the prefix, or the
Yes, I agree. Providing warnings is a simple incentive to push people
away from their use.
Paul
On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN p...@nosphere.org wrote:
Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit :
On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
I was reading
I think 2) and 3) require a lot of discussion. So really I think it boils
down to are we going to really make 1) the way it works? Otherwise I think
we are also obliged to look at the models in P2 and OBR because it probably
doesn't make sense to re-invent another mediation and reconciliation
Yeah deprecated in 3.x. However we'll always have to support them when
resolving things from the repo since that's cast in stone for projects
already released. We should not support them for projects being built
with 3.x though.
On Fri, Oct 30, 2009 at 1:34 PM, Paul Benedict pbened...@apache.org
I created MNG-4421 to track this issue:
http://jira.codehaus.org/browse/MNG-4421
Paul
On Fri, Oct 30, 2009 at 5:15 PM, Brian Fox bri...@infinity.nu wrote:
Yeah deprecated in 3.x. However we'll always have to support them when
resolving things from the repo since that's cast in stone for
Brian Fox wrote:
I think we have to also consider that 2) is what Maven does now.
(Benjamin thinks it might be 3 but I seem to recall repos added along
the way stick around forever)
I was trying to check what Maven 2.x actually does and came up with this
POM snippet:
dependencies
It is going interesting to see lots/logs of warnings when we starting
using 3.0 :-)
-Dan
On Fri, Oct 30, 2009 at 4:12 PM, Paul Benedict pbened...@apache.org wrote:
I created MNG-4421 to track this issue:
http://jira.codehaus.org/browse/MNG-4421
Paul
On Fri, Oct 30, 2009 at 5:15 PM, Brian
On 2009-10-30, at 3:13 PM, Brian Fox wrote:
I think 2) and 3) require a lot of discussion. So really I think it
boils
down to are we going to really make 1) the way it works? Otherwise
I think
we are also obliged to look at the models in P2 and OBR because it
probably
doesn't make sense
26 matches
Mail list logo
