I searched on the asf repository [1], [2] but I didn't found it :
[1]
https://repository.apache.org/index.html#nexus-search;quick~org.apache.mavenhttps://repository.apache.org/index.html#nexus-search;quick%7Eorg.apache.maven
[2]
This use case currently isn't covered, you're right and it's really
the only reason anymore to use non unique snapshots. Bringing this
over to @dev to figure out what to do.
On Mon, Nov 16, 2009 at 3:41 PM, Paul Benedict pbened...@apache.org wrote:
I did read the link. I thought Jason was saying
Personally I didn't even know you could put a version into the
lifecycle, I've never seen that done.
Second, I always subscribe to the theory that closest wins. In the
inheritance case, it means things in my pom override my parent pom,
which overrides the grandparent etc. I think in this case,
Vote results: +14 : Jason, Jesse, Oliver, Brett, John, Herve, Oleg,
Benjamin, Mark, Arnaud, Lucas, Ralph, Nicolas, Brian
Igor, congratulations, sorry for the delay.
On Tue, Aug 18, 2009 at 10:51 PM, Brett Porter br...@apache.org wrote:
time to close this vote? :)
On 28/07/2009, at 6:52 PM,
This is more a plan to implement the existing multi-threading patch
than an actual proposal. Imo a proposal should describe the
solution...ie how will this multi-threading work, how will it decide
what to build and in what order, etc. I think essentially the details
you Ralph and I briefly
The stable versions are 2.0.10 and 2.2.1, 2.1.0 is not considered stable.
On Fri, Nov 13, 2009 at 1:59 AM, Stevo Slavić ssla...@gmail.com wrote:
IMO 2.1.0 should stay as it is, if I'm not mistaken, most recent stable
release of maven which is compatible with Java 1.4. When maven 2.2.1 is
In snapshots that used to be a problem but was fixed ~2.0.6ish. The
properties aren't interpolated on deploy so it works ok.
On Fri, Nov 13, 2009 at 1:23 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
A while back this would not have been a safe thing to do. Will this now
work correctly?
That sounds like the one that is supposed to be fixed in alpha-4
On Thu, Nov 12, 2009 at 8:20 AM, Brett Porter br...@apache.org wrote:
Doesn't affect my vote, but I noted that this IT fails on 3.0-alpha-3, even
though it is marked as fixed in JIRA:
- mng4361ForceDependencySnapshotUpdate
There should be a start and end range for the tests. These new ones
start in alpha-4-snapshot and end ]
On Thu, Nov 12, 2009 at 8:20 AM, Brett Porter br...@apache.org wrote:
Hi,
I ran the ITs against 3.0-alpha-3 and got a number of failures.
Several of those are because they are fixed in
You should use the inherited element of the execution for that.
On Wed, Nov 11, 2009 at 4:43 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Just thought of a use-case for listing the same plugin twice in the
one plugins section namely inheritedtrue/inherited and
+1
On Tue, Nov 10, 2009 at 6:35 PM, Paul Gier pg...@redhat.com wrote:
+1
I tested it on a few projects and in general it seems to be working well.
I ran into a problem resolving local snapshots with classifiers after I had
just installed them which appears to be related to an existing
+1
On Wed, Nov 11, 2009 at 10:25 AM, Olivier Lamy ol...@apache.org wrote:
+1
2009/11/8 Benjamin Bentmann benjamin.bentm...@udo.edu:
Hi,
This is a maintenance release for the assembly descriptor that we use to
create ASF-compliant source distros. This release fixes a bug in version
1.0.1
1) Where did you get the artifacts? 2) It's pretty out of date:
http://maven.sensate.se/maven2/last_updated.txt
On Wed, Nov 11, 2009 at 10:02 AM, Rickard Lundin
rickard.lun...@sensate.se wrote:
Hi !
is it possible to add my freshly setup maven2 repo as an official
scandinavian mirror/Repo ?
I think you have the wrong dev list
On Wed, Nov 11, 2009 at 7:53 PM, Garvin LeClaire
garvin.lecla...@gmail.com wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11701version=15548
There are still a couple of issues left in JIRA:
On Tue, Nov 10, 2009 at 3:21 PM, Dan Fabulich d...@fabulich.com wrote:
Jason van Zyl wrote:
The trunk is now critical for M2Eclipse and anyone else who is embedding
and new features just aren't going in without adequate ITs.
m2eclipse depends on the Maven 3.0-SNAPSHOT trunk?
Kinda
Does
I haven't tested alpha-3 yet, but I don't want to see anything derail that,
since it's been a long time coming. I think it would be better for issues
found after the last 11 months of changes to be separate from anything
introduced by a multi-threaded build.
Agreed. Unless you can attach the
It's not done yet.
On Sat, Nov 7, 2009 at 5:38 AM, Gilles Scokart gscok...@gmail.com wrote:
2009/11/6 Stephen Connolly stephen.alan.conno...@gmail.com
I suspect that the plug-ability being introduced in 3.0 will mean that
we are able to provide a hook for m3 to discover how to handle newer
-1 lets get the new descriptor benjamin staged included
On Thu, Nov 5, 2009 at 4:52 PM, Brian Fox bri...@infinity.nu wrote:
+1
On Thu, Nov 5, 2009 at 1:00 PM, Olivier Lamy ol...@apache.org wrote:
+1
--
Olivier
2009/11/5 John Casey jdca...@commonjava.org:
Hi,
I've included the source
+1
On Thu, Nov 5, 2009 at 1:00 PM, Olivier Lamy ol...@apache.org wrote:
+1
--
Olivier
2009/11/5 John Casey jdca...@commonjava.org:
Hi,
I've included the source-release assembly configuration in the Apache parent
POM since it's working pretty well here in Maven. This will allow other
Yes, we now have the source bundle issue resolved, just upgrade to the
latest maven parents...and we are still using Nexus where you staged
it last time ;-)
2009/11/3 Raphaël Piéroni raphaelpier...@gmail.com:
Hello Benjamin,
I am really sorry for not having concluded the release process (yet).
+1, a few people here at the hackathon have asked it to be promoted so
they can benefit on other ASF projects.
On Tue, Nov 3, 2009 at 4:05 PM, John Casey jdca...@commonjava.org wrote:
Hi,
Seems like the source-release assembly is working pretty well, particularly
now that Benjamin refined it.
of the
chain. We should think about collision detection, but this should be
detectable at least.
There are most probably also things to consider for repository managers.
I'm not sure if it is worth the effort though.
LieGrue,
strub
- Ursprüngliche Mail
Von: Brian Fox bri
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
+1
On Sun, Oct 25, 2009 at 11:25 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
these releases are primarily meant to incorporate the fixed source release
assembly descriptor into our projects, thereby addressing the issue outlined
in
+1
On Sun, Oct 25, 2009 at 11:18 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
This is a maintenance release for the assembly descriptor that we use to
create ASF-compliant source distros. This release fixes a bug in version 1.0
that erroneously includes paths like
It's amazing how google's thread compression of a discussion can cause
me to overlook a huge thread so near and dear to my heart.
To start, Benjamin has hit the nail on the head of a discussion point
Jason and I have had going for quite some time. In fact, we even wrote
up a proposal for it
and agenda ideas. I have some content to talk
about Maven 3.x changes if desired, but the community can drive the
final agenda.
[1]https://docs.sonatype.org/display/COMM/Maven+Meetup+at+US+Apache+Con+09
Thanks,
Brian Fox
Apache Maven PMC Chair
The only way to do this reliably would be to go get the metadata from
the repository and use that...it's inside the deploy plugin that this
transformation occurs and it happens based on the metadata that it
just retrieved.
Alternatively you could do this with a repo manager. Nexus provides
rss
Just summing up a conversation I had with Jason and Benjamin: After
Benjamin finishes up the current issue MNG-4221
(http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500fixfor=14719resolution=-1sorter/field=issuekeysorter/order=DESC)
then we think it's time to prepare the next
this will need a release of some stuff. [1].
This need some jobs to be really complete (sorry not enough spare atm)
--
Olivier
[1] http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin
2009/10/22 Brian Fox bri...@infinity.nu:
Just summing up a conversation I had with Jason
What was wrong with the RuntimeInformation that was present in M2?
There should be one canonical interface to get the version of Maven
that everyone uses. The implementation behind that may implement some
of these suggestions, but I wouldn't want to see this in every plugin
that cares.
On Wed,
On Wed, Oct 21, 2009 at 7:08 PM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Brian Fox wrote:
What was wrong with the RuntimeInformation that was present in M2?
It was put in maven-compat and deprecated in M3 so we were looking for
alternatives.
Yeah, but why?
Benjamin
On Wed, Oct 21, 2009 at 7:15 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
2009/10/22 Brian Fox bri...@infinity.nu
On Wed, Oct 21, 2009 at 7:08 PM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Brian Fox wrote:
What was wrong with the RuntimeInformation
On Tue, Oct 13, 2009 at 3:05 AM, Jason van Zyl ja...@sonatype.com wrote:
Nope, I had that in my copy from a new days ago and then I asked the
question.
I'll make a profile to publish all formats.
Huh? At least 4 more lines in the pom to save 2 in the assembly? I say
drop the bz2 and leave
On Mon, Oct 12, 2009 at 12:00 PM, Daniel Kulp dk...@apache.org wrote:
I personally think that not having a tar.gz will be very unnatural for unix
folks and will cause a barrage of where's the unix build? emails to users@
and such.
To me, there is no downside of having it. It takes an extra
This should be posted to the user list, along with an example of your
pom and perhaps some mvn -x output to go with it.
On Sat, Oct 3, 2009 at 10:50 AM, Franco Ehrat franco.eh...@giniality.ch wrote:
Hi developers,
I send you this mail because I'm totally irritated. I tried a few times
to
I'll get them updated, the steps are substantially the same but
screens slightly different.
On Sun, Oct 11, 2009 at 7:52 PM, Arnaud HERITIER
arnaud.herit...@exoplatform.com wrote:
Hi,
I'm doing a release and noticed that many screenshots of Nexus are
outdated in the current version we are
On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz albert.kur...@gmail.com wrote:
Tamas, I cannot predict when, but once it will be done in a machine
way or a mathematical/logical proof will be discovered that it is
impossible. Agreed, it will not be easy.
This is why in suggestion 1) I said lets
,
Albert
On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox bri...@infinity.nu wrote:
Albert,
Clearly you seem to have plenty of enthusiasm for helping to provide
better metadata, and I don't want to discourage that.
Providing and hosting a repository containing 90 thousand files that
serves greater
On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Brian,
Ok then, I assert they are all fine. Now you can provide a list and
refute me ;-).
In this case (if they were all fine) here is your list:
http://repo2.maven.org/maven2/.index/
(But unfortunately they are
On Mon, Oct 5, 2009 at 4:36 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Brian,
If you start maintaining a list of violators I have zero motivation to
contribute to your list, because this kind of list is useless for me.
If you start maintaining a list of compliant artifacts (what many
I think it would be more legible if the fetch and push urls were
separated with something not part of the url normally, ie a | instead
of : would stand out visually. Otherwise, this seems like the only
workable solution in the current pom model.
On Sat, Oct 3, 2009 at 2:52 AM, Mark Struberg
On Fri, Oct 2, 2009 at 5:57 AM, Paul Gier pg...@redhat.com wrote:
Why would everyone need to use both repos? If the legacy repository is done
correctly, the vast majority of users would never need to hit it, or even
know about it at all.
Note that this idea is different than creating a new
personally think attempting to fork an
entire repository is not going to help the users as much as even
items #1,2,3 above.
Brian Fox
Apache Maven PMC Chair-Elect
On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz albert.kur...@gmail.com wrote:
I would like to see some votes:
1. Big Rotten Onion
2
On Thu, Oct 1, 2009 at 2:24 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
If somebody can create a Maven repo crawler as a hobby project, then
somebody will.
The Nexus Indexer already runs on Central, directly on the machine.
Brian, do you want expand on this for the rest of us? What are the rules,
how will it work, and how can we use it?
The details belong in another thread, but we'll be able to implement
these rules for projects using repository.apache.org and
oss.sonatype.org. This isn't really new information,
Yes it counts. Hopefully you'll see your account tomorrow. Please
confirm or deny when it does or doesn't show up ;-)
On Thu, Oct 1, 2009 at 1:51 AM, Arnaud HERITIER aherit...@gmail.com wrote:
I think your vote count but for infra I don't know what to do.
On Thu, Oct 1, 2009 at 9:33 AM,
+1
On Wed, Sep 30, 2009 at 1:54 PM, Paul Benedict pbened...@apache.org wrote:
+1 here
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I think having it even if over time it rots, is better than having
nothing to start with. Bottom line is that we will want this in
central and will look to automate enforcement, so the bundle plugin
should line up with that process to simplify life for everyone.
On Tue, Sep 29, 2009 at 2:14 PM,
If we don't require it then people simply won't populate it even when
it could be done.
There will always be a manual way to get artifacts through a process
into central if they don't meet the requirements that would have to be
judged on a case by case basis. I think that a significant majority
unmanageable, you can bet we'll act to solve it.
On Tue, Sep 29, 2009 at 3:42 PM, Brian Fox bri...@infinity.nu wrote:
If we don't require it then people simply won't populate it even when
it could be done.
There will always be a manual way to get artifacts through a process
into central if they don't
The managing of Child A doesn't necessarily mean that Child A's
dependencies are weighed higher than other direct dependencies. Also,
given the same depth in the tree, the first version processed for a
given group:artifact wins...ie the order in the pom can have subtle
impacts.
On Mon, Sep 28,
+1
On Sat, Sep 26, 2009 at 8:54 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
We solved 2 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=15698styleName=HtmlprojectId=11990
There are still a couple of issues left in JIRA:
The server hosting the zone for repository.apache.org is having some
maintenance issues at the moment so the repository is offline. You can
follow the apache infra twitter for updates on the status:
http://twitter.com/infrabot
-
It can't hurt.
On Wed, Sep 23, 2009 at 6:03 PM, Brett Porter br...@apache.org wrote:
On 24/09/2009, at 7:22 AM, Hervé BOUTEMY wrote:
I also think we should move all the MARTIFACT JIRAs back into MNG.
I don't know how to do the move to MNG Artufact and Repositories
component,
then disable
Central
regarding size or the number of artifacts, but some OSS developers
might prefer to use from and supply to this one instead of the big and
ugly.
On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox bri...@infinity.nu wrote:
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com
wrote
Making resolution of things from a repository dependent on an
environment is definitely dangerous. The only way I would consider it
valid is if there's some default provided in the pom itself, but
that's going to be difficult to enforce reliably I think.
On Mon, Sep 21, 2009 at 6:09 AM, Jason van
to find
the first jar I uploaded.
Jira issue: MDEPLOY-48
Brian Fox wrote:
I was recently working with a customer to move them off of using
non-unique snapshots for various reasons. In the process we discovered
a problem with snapshots, classifiers and multi-platform builds.
In this scenario
This list is for development of maven only. AND i already answered
your question on the user list the last time you asked.
On Tue, Sep 8, 2009 at 7:54 AM, Praveenkumar Kasupraveenkum...@hcl.in wrote:
Hi All,
I am having a property named test.version in pom.xml
properties
+1
On Sun, Sep 6, 2009 at 7:24 PM, Arnaud
HERITIERarnaud.herit...@exoplatform.com wrote:
Hi all,
I'd like to propose giving commit access to Stephen Connolly.
He is already a committer @ Mojo for many monthes and did a great work on
several plugins.
He is the author of the very useful
I agree, but I got the feeling Brian would like the same version on these
parallel builds which will need extra to make sure they are in sync.
I'm just exploring the concepts and options. I think most cases could
be solved by being able to resolve the latest snapshot of a particular
. And I also like to look in my repo or my
package and know exactly which snapshot i have in case there's a
discrepancy.
-Stephen
2009/9/4 Brian Fox bri...@infinity.nu
I was recently working with a customer to move them off of using
non-unique snapshots for various reasons. In the process we
These questions belong on the user list. If you asked there, I'll answer it ;-)
On Wed, Sep 2, 2009 at 4:26 PM, Arul Anand S Parulanan...@gmail.com wrote:
hi all,
I am having a property named test.version in parent pom.xml
properties
test.version8/test.version
/properties
and I have
I saw this on Benjamin's compat page yesterday and thought I'd throw
it up for discussion:
Non-unique Snapshot Deployments
The setting uniqueVersionfalse/uniqueVersion for a distribution
repository has no effect in version 3.x, snapshot artifacts will
always be deployed using a timestamped
I was recently working with a customer to move them off of using
non-unique snapshots for various reasons. In the process we discovered
a problem with snapshots, classifiers and multi-platform builds.
In this scenario, we have a project that is built on multiple
platforms, say windows, solaris
On Fri, Sep 4, 2009 at 4:06 PM, Jason van Zyljvan...@sonatype.com wrote:
I think it can be in the same vein as the no versions for plugins. Not a
very good idea and potentially harmful.
We put it in, deprecate it over 3.0 and it becomes taboo in 3.1. If it's a
bad practice in the majority of
Just my 2 cents as a Maven evangelist in a big private company. Even if
Maven is around for years now, basic endusers just start to get
accustomed to pom.xml and Maven philosophy (really! people are far slowest to
change than in OpenSource project team).
Please, please don't mess
On Fri, Sep 4, 2009 at 4:36 PM, Jason van Zyljvan...@sonatype.com wrote:
Why not just incorporate the full coordinate in the metadata. This is also a
problem for finding attached artifacts like javadocs and sources. There is
no record of them in the metadata. If we had a complete catalog of the
Ok here.
On Fri, Aug 28, 2009 at 7:40 AM, Benjamin
Bentmannbenjamin.bentm...@udo.edu wrote:
John Casey wrote:
I have a working implementation [...] but it currently depends on Java
1.5. [...] I'd really prefer to leave this requirement on 1.5 in place, to
help us gradually pull ourselves out
I've never seen make or ant scripts that effectively crawled up a disk
looking for other things to build. I don't see how maven is different.
On Tue, Aug 25, 2009 at 4:27 PM, Jochen
Wiedmannjochen.wiedm...@gmail.com wrote:
Arnaud HERITIER-3 wrote:
What do you think about this post and
We still have some fixes to make before we promote it apache wide.
Once it's working for all our stuff we can upgrade the apache pom.
On Fri, Aug 21, 2009 at 7:08 PM, Arnaud HERITIERaherit...@gmail.com wrote:
perhaps you could forward this to all PMCs ?
Cheers,
Arnaud
# Arnaud Héritier
#
+1
On Wed, Aug 12, 2009 at 4:43 PM, Benjamin
Bentmannbenjamin.bentm...@udo.edu wrote:
Hi,
for Maven 3.x, I would like to discuss the introduction of a new mojo
annotation
�...@requiresdependencycollection required-scope
As the name probably suggests, the intended effect is to resemble an
+1. This works as I had envisioned but I did uncover one small issue:
the DEPENDENCIES file for a multi-module project is not complete, and
in the case of the enforcer simply empty because that pom is serving
only aggregation purposes. I talked to John and he's preparing a
remote-resources
They fall under different profiles. Hopefully tonight i can give this
a test whirl on something like the enforcer.
On Tue, Aug 18, 2009 at 11:51 AM, John Caseyjdca...@commonjava.org wrote:
Thanks Benjamin. I made a dumb assumption that the only difference would be
the number. Clearly that's
You only have permissions to deploy artifacts based on the groupId for
configured projects. IOW you as a Maven committer can deploy
/org/apache/maven/.* but commons-monitoring is not configured in
repository.apache.org so you have no permissions for those artifacts.
You can get it migrated here:
Such a project would be built after its child modules. Basically, the
occurrence of parent in a POM should no longer establish any kind of
dependency between the parent project and the inheriting project, only
aggregation would do so.
So in essence we are relying on the resolution of this
On Wed, Aug 12, 2009 at 5:58 PM, Jason van Zyljvan...@sonatype.com wrote:
John,
What's the range of features across the two http Wagon's right now?
Currently the lightweight impl handles NTLMv2 and does a better job
caching the data when the repository asks for authentication (this one
uses
On Thu, Aug 13, 2009 at 4:50 PM, Stephen
Connollystephen.alan.conno...@gmail.com wrote:
2009/8/13 Wendy Smoak wsm...@gmail.com:
It would also be good to post the original document on the mailing
list, so it will be in the archives as a basis for the discussion.
Confluence may not be there
On Wed, Aug 12, 2009 at 5:57 PM, jdca...@apache.org wrote:
Author: jdcasey
Date: Wed Aug 12 21:57:19 2009
New Revision: 803723
URL: http://svn.apache.org/viewvc?rev=803723view=rev
Log:
Adding source-release assembly configuration.
Modified:
maven/pom/trunk/maven/pom.xml
Modified:
Tell him to email repo-maintain...@maven.apache.org. The ibiblio copy
seems to match what is in the central repository so this isn't an
ibiblio issue.
On Wed, Aug 12, 2009 at 9:45 AM, Don Sizemored...@ibiblio.org wrote:
Hello,
We received the following question in our help queue today:
Here's what I got from the Selenium team:
The user is simply confused:
http://nexus.openqa.org/content/repositories/releases/org/seleniumhq/selenium/server/selenium-server/1.0.1/
What he wants is the standalone jar which contains all the
dependencies rolled up in it:
Fine with me.
On Tue, Aug 11, 2009 at 11:09 AM, John Caseyjdca...@commonjava.org wrote:
Re-posting to get this out of the original message thread, so it doesn't
hide on some email clients:
---
This is something I wanted to bring up on the dev list, actually. I simply
went through all of
You may want to take a look at the enforcer plugin and the rules, many
of the release criteria checks are already implemented as enforcer
rules. If you build something that could consume the enforcer rule
api, that would be pretty handy at least for the validation parts of
the release process.
On
Before we push this, I'd like to add a requirement to include the scm
url and project url in the pom that is bundled. This information is
currently required in Jira, but it should be in the pom.
On Fri, Aug 7, 2009 at 10:10 AM, John Caseyjdca...@commonjava.org wrote:
Oops, forgot to record my
The cobertura one yes because it would be produced potentially by the
tests. The others probably have less harm.
On Mon, Aug 10, 2009 at 4:41 PM, Brett Porterbr...@apache.org wrote:
On 07/08/2009, at 4:11 PM, jdca...@apache.org wrote:
+ !-- misc --
I tested it briefly by deploying some enforcer snapshots. Nothing
unusual detected, but I definitely didn't look at the detailed issues
we had earlier.
On Mon, Aug 3, 2009 at 7:49 PM, John Caseyjdca...@commonjava.org wrote:
Hi again,
After Brett sorted out some issues that got lost in the
I think the disconnect here is that the resolution scope != specified scope
That is to say if you ask for the runtime scope in a plugin, you get
more than things declared runtime. We all know this intuitively but
it is confusing at times. Perhaps what is needed is the addition of a
few more
In the dependency and enforcer plugins where I potentially need
everything, I just ask for test to be resolved and then i pick the
elements i need.
On Sun, Aug 2, 2009 at 2:28 PM, Benjamin
Bentmannbenjamin.bentm...@udo.edu wrote:
Brian Fox wrote:
I think those bugs may be due to the plugin
2009/7/31 Jason van Zyl jvan...@sonatype.com:
Ok, we need to figure out how to do this generally. I really don't want to
see this in every POM we have. Brian, is there no way to share this?
Yes there is. The problem was getting the license and notice files
included. On the infra list it seems
I think those bugs may be due to the plugin using the runtime scope
not the runtime classpath? The runtime classpath should include the
compile scope artifacts.
2009/7/31 Benjamin Bentmann benjamin.bentm...@udo.edu:
Hi,
I would like to propose an extension of the mojo annotation
/dependency
Which I think we've seen suggested before.
Anything more than that is probably not going to be as feasible and prone to
confusion.
On 29/07/2009, at 7:27 PM, Brian Fox wrote:
First question, wouldn't ${project.version} solve the use case of
updating same versioned dependencies
dependency
groupId${project.groupId}/groupId
artifactIdother-artifactId/artifactId
version${project.version}/version
/dependency
would become:
dependency
artifactIdother-artifactId/artifactId
/dependency
Besides saving a few keystrokes I don't see how that helps much? It's
+1
2009/7/30 Brett Porter br...@apache.org:
Hi,
Mark has been contributing regularly to Maven SCM for quite some time (in
particular the git support recently, and I think has been wanting to help
with improving the API and release mechanism for git), as well as being more
broadly active.
On Thu, Jul 30, 2009 at 9:51 AM, Ralph Goersralph.go...@dslextreme.com wrote:
On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
Are those itemized anywhere? Eventually
Therefore I think that
the pluginManagement in Super-Pom caused some
trouble and confusion that you might not be aware of.
It should use the version even if you invoke directly from the command
line, if not, that's a separate bug.
First question, wouldn't ${project.version} solve the use case of
updating same versioned dependencies?
Also: A version that was omitted in a dependency section can only
be resolved if the referenced modules are resolved. So if it is NOT
part of the sub-tree where the build was invoked we have a
+1
On Tue, Jul 28, 2009 at 6:52 PM, Jason van Zyljvan...@sonatype.com 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
I used the same parent as the jarsigner plugin which does appear to have the
source archive. I just assumed the -source now contained the self-building
requirement. Using the same parent and not getting the same output I'll look
into tomorrow.
That's on me, I haven't finished it yet. My boss
Yep, it needs to be closed.
On Sat, Jul 25, 2009 at 7:53 AM, Benjamin
Bentmannbenjamin.bentm...@udo.edu wrote:
Jason van Zyl wrote:
It's there if you go to the UI, something appears to be wrong with the
redirects.
The repo isn't closed, that could explain why it doesn't show up in public
301 - 400 of 663 matches
Mail list logo
