Run the following:
mvn source:jar javadoc:jar repository:bundle-create
The bundle doesn't contain the javadoc jar.
Anyone (who knows about said code) aware of this bug?
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Hi,
Repost of the vote after fixing the issues with the uber JAR that was
produced. Hervé and I have tried them and they appear to work fine.
The staging repository is here:
http://people.apache.org/~jvanzyl/maven-ant-tasks-2.0.7-staging-
repository/
The uber jar that people will want to
Hi,
Just a little note on this release.
There are a lot of bugfixes (SNAPSHOT downloading, for example), new features
(VersionMapper, remoteRepository support for pom and install-provider tasks)
documented on http://maven.apache.org/ant-tasks.html.
But there are 2 incompatible changes that you
Brian E. Fox wrote:
Sorry, I didn't mean to start the conversation, then bail. I was hoping
I could stage and call a vote before I went travelling and working off a
slow cell connection.
I'm still having failures on XP. Is this just a windows problem, or is
stuff really broken, or is it
I laways have a lot of unable to delete dir on windows.
seems to be related to http://jira.codehaus.org/browse/PLXUTILS-35
the fix in plexus could not be enough
I'm trying to upgrade my jdk
Can't we delete those directories at the jvm shutdown ?
Is there a risk of reuse of these directories
Max Bowsher wrote:
I've also found some sort of regression, I believe related to
dependencies with classifiers.
Filed MECLIPSE-287.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Thanks Herve, I forgot about adding that even though you reminded me
last night. Think you might make a site patch for the release notes
regarding these issues?
On 27 Jun 07, at 11:29 PM 27 Jun 07, Hervé BOUTEMY wrote:
Hi,
Just a little note on this release.
There are a lot of bugfixes
On Jun 28, 2007, at 2:29 AM, Hervé BOUTEMY wrote:
2. MANTTASKS-65: central is not automatically added any more if a
remoteRepository is set: the code has been changed to work as the
documentation said
This seems inconsistent with the way Maven as a whole works.
Are you saying that the
+1, as long as the release notes include the notes mentioned.
Also, for future releases, the POM and one source file have an
outdated license:
pom.xml: ~ Copyright 2005-2006 The Apache Software Foundation.
src/main/java/org/apache/maven/artifact/ant/VersionMapper.java: *
Copyright
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
The gross thing the wagon manager does for the proxy, etc is to push
the settings in from the core to the wagon manager itself so there's
passing it through the api.
Otherwise, I guess you'll need to pass the conflict resolver property
through
On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
The gross thing the wagon manager does for the proxy, etc is to push
the settings in from the core to the wagon manager itself so there's
passing it through the api.
Otherwise, I guess you'll
On 28 Jun 07, at 9:35 AM 28 Jun 07, Mark Hobson wrote:
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
The gross thing the wagon manager does for the proxy, etc is to push
the settings in from the core to the wagon manager itself so there's
passing it through the api.
Otherwise, I guess
One nitpick is that I think we should stick to property names that
follow Java variable name conventions like mavenConflictResolvers,
and this also prevents any screw ups with any ELs or expression
resolvers that might potentially get confused by dots in the expression.
On 28 Jun 07, at
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
The other sticking point was how to propagate
ConflictResolverNotFoundException. I'd rather not wrap it up in a
misleading checked exception, and I'm not sure how people feel about
adding it as
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I thought we agreed that this was not to surface in a POM? If you put
that in there now people will start using it. I thought you were
going to be able to do this strictly by changes to your installation?
The initial way I got this working
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
One nitpick is that I think we should stick to property names that
follow Java variable name conventions like mavenConflictResolvers,
and this also prevents any screw ups with any ELs or expression
resolvers that might potentially get confused
My understanding was that it was all experimental at this point to
see what actually worked, then need to decide where it lands.
Requiring a change in the install is no good - it ruins the install
for general use and is more hassle than it's worth. I think the
(undocumented, unsupported)
On 28 Jun 07, at 11:48 AM 28 Jun 07, Mark Hobson wrote:
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I thought we agreed that this was not to surface in a POM? If you put
that in there now people will start using it. I thought you were
going to be able to do this strictly by changes to
Howdy,
Is there anything special that needs to happen for the dependencies
section to get written out when using generateReleasePoms and version
ranges? I'm getting everything *but* the dependencies section written
out. Simple hello world project; one dep on commons-logging.
Are there some of you who can test/review the most popular issues :
http://jira.codehaus.org/browse/MECLIPSE-78
Some of them have a patch
It could be important to see if we can apply them before the next release.
Arnaud
On 28/06/07, Max Bowsher [EMAIL PROTECTED] wrote:
Max Bowsher wrote:
I've
The link I wanted to paste is :
http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:popularissues-panel
Arnaud
On 28/06/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:
Are there some of you who can test/review the most popular issues :
Le jeudi 28 juin 2007, John Casey a écrit :
On Jun 28, 2007, at 2:29 AM, Hervé BOUTEMY wrote:
2. MANTTASKS-65: central is not automatically added any more if a
remoteRepository is set: the code has been changed to work as the
documentation said
This seems inconsistent with the way Maven
On 28 Jun 07, at 1:33 PM 28 Jun 07, Hervé BOUTEMY wrote:
Le jeudi 28 juin 2007, John Casey a écrit :
On Jun 28, 2007, at 2:29 AM, Hervé BOUTEMY wrote:
2. MANTTASKS-65: central is not automatically added any more if a
remoteRepository is set: the code has been changed to work as the
Le jeudi 28 juin 2007, Jason van Zyl a écrit :
Thanks Herve, I forgot about adding that even though you reminded me
last night. Think you might make a site patch for the release notes
regarding these issues?
Do you mean adding release notes for Maven Ant Tasks like for Maven Core
Anyone remember why there is a snapshot of the verifier in the ITs.
I've got the Archetype stuff working well now thanks to Raphael and
so I want to lock down all the versions of dependencies in the first
version of the IT archetype.
Thanks,
Jason
Le jeudi 28 juin 2007, Jason van Zyl a écrit :
On 28 Jun 07, at 1:33 PM 28 Jun 07, Hervé BOUTEMY wrote:
Le jeudi 28 juin 2007, John Casey a écrit :
On Jun 28, 2007, at 2:29 AM, Hervé BOUTEMY wrote:
2. MANTTASKS-65: central is not automatically added any more if a
remoteRepository is set:
On 28 Jun 07, at 1:54 PM 28 Jun 07, Hervé BOUTEMY wrote:
Le jeudi 28 juin 2007, Jason van Zyl a écrit :
Thanks Herve, I forgot about adding that even though you reminded me
last night. Think you might make a site patch for the release notes
regarding these issues?
Do you mean adding release
I figured out why some tests where failing for me. I have
downloadSourcestrue/downloadSources set in my settings and this was
causing the correct behavior in the plugin, but it didn't match the
expected classpath. I'll write a jira for this to be resolved later
since it's not critical.
Issue Subscription
Filter: Design Best Practices (32 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
29 matches
Mail list logo
