I've been working on and off on a few different archiva related tools /
tasks / libs.
Brett and Wendy convinced me to upload what I got and outline what I've
got in mind to let the creative juices flow. (besides, I'm running out
of time to commit to archiva, so this work will be slow to
Whoops.
Forgot to mention that you can find this code at ...
https://svn.apache.org/repos/asf/maven/sandbox/trunk/archiva/archiva-jarinfo
- Joakim
Joakim Erdfelt wrote:
I've been working on and off on a few different archiva related tools
/ tasks / libs.
Brett and Wendy convinced me to
IMHO, we can remove.
2008/3/10, Rahul Thakur [EMAIL PROTECTED]:
There are some other branches residing in Continuum SVN. Should we
remove any (or all) of the following if they are not in active
development? I know (id-refactor and key-based-refactor can go)
# continuum-acegi
#
On 11/03/2008, at 9:05 AM, [EMAIL PROTECTED] wrote:
- value${JAVA_HOME}/value
+ value${java.homr}/value
java.home?
- value${M2_HOME}/value
+ value${m2.home}/value
maven.home?
:)
- Brett
--
Brett Porter
[EMAIL
The branches have been removed except for 'continuum-site_1.1' which had
some updates a few months ago. If this is not required please feel free
to remove.
Rahul
Olivier Lamy wrote:
IMHO, we can remove.
2008/3/10, Rahul Thakur[EMAIL PROTECTED]:
There are some other branches residing
2008/3/9, Dennis Lundberg [EMAIL PROTECTED]:
Brett Porter wrote:
On 10/03/2008, at 6:07 AM, Dennis Lundberg wrote:
I have tested this on four different plugins. There were a couple of
typos in the generated report, which I fixed in r635325.
I'm assuming that can wait for the
2008/3/9, Dennis Lundberg [EMAIL PROTECTED]:
The scm urls are broken for all modules, except the parent. This comes
from the parent pom, which is missing a / at the end of the scm urls.
For the log, parent pom (r635514) already has a / at the end of the scm urls.
Calling release:prepare in
Hi
2008/3/9, Brett Porter [EMAIL PROTECTED]:
Since the POMs included in the artifacts and the stage repository,
does this mean the release needs to be started again?
Don't know. Do we have rules on it?
BTW I filled MRELEASE-331
Cheers,
Vincent
On 10/03/2008, at 1:41 AM, Vincent Siveton
Hi,
It s again me :) I would like to release (again) the Maven Plugin
Tools projects:
* maven-plugin-plugin-2.4
* maven-plugin-tools-beanshell-2.4
* maven-plugin-tools-java-2.4
* maven-plugin-tools-2.4
* maven-plugin-tools-javadoc-2.4
* maven-plugin-tools-ant-2.4
* maven-plugin-tools-model-2.4
*
Hi,
FYI I think it is important to respect our release process.
Cheers,
Vincent
-- Forwarded message --
From: Julien Graglia [EMAIL PROTECTED]
Date: 10 mars 2008 06:56
Subject: maven-javadoc-plugin 2.4 missing
To: [EMAIL PROTECTED]
The project summary (1) announce version
I'll give it a try. So the IT test just has to show the failure, right? Is
that enough for somebody on Maven to write the patch?
Paul
On Sun, Mar 9, 2008 at 10:22 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:
Can you make an IT for it?
Yes, the easiest way is to produce a build that fails when the bug is
expressed. Having this gives us a huge leg up in fixing the issue.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Monday, March 10, 2008 12:35 PM
To: Maven
+1
Vincent Siveton wrote:
Hi,
It s again me :) I would like to release (again) the Maven Plugin
Tools projects:
* maven-plugin-plugin-2.4
* maven-plugin-tools-beanshell-2.4
* maven-plugin-tools-java-2.4
* maven-plugin-tools-2.4
* maven-plugin-tools-javadoc-2.4
* maven-plugin-tools-ant-2.4
*
I'm debugging mng-2861 and I see some issues we need to consider for
3.0. This particular issue works like this:
a-b-d[1.2,)
a-c-e[2.0,3.0]
d1.2 is relocated to e1.2
During the processing of this, we select d1.2 and then transform this to
e1.2. (this bug happens to be that we don't
IIUC we've previously agreed that the only LICENSE and NOTICE files
that actually need to be in svn are at the root of expected checkouts
such as trunk, branches/xxx, and tags/xxx; all other LICENSE and
NOTICE files in distributable artifacts can be generated by some
process. Projects
This sounds good to me. I recently tried to release a first version of
Apache NMaven in the incubator and got blocked on this very issue of having
the dependency info in the Notice file. Any solution would be appreciated.
Shane
On Mon, Mar 10, 2008 at 11:44 AM, David Jencks [EMAIL PROTECTED]
On 11/03/2008, at 5:31 AM, Brian E. Fox wrote:
It seems to me that we need to process all the relocations and
normalize
an artifact across the spectrum BEFORE we start selecting versions
from
those ranges. This would need to happen across the graph in case there
are conflicts somewhere
You weren't blocked - the vote passed on 26 Feb. The notice file
should have less information - but it was not a blocker.
FWIW, I like David's solution - it does put the onus back on the
developer to understand the licenses of all your dependencies, but I
feel that is necessary in this
+1
Le samedi 8 mars 2008, Brian E. Fox a écrit :
It's time to release the next Javadoc plugin. Besides the fixes listed
below, the most important change is the reverting of javadoc acting as
an aggregator. This caused most users tons of grief during releases. The
issue for this is
Hi all,
In order to prevent the issues we've had in 2.0.x, I've refactored
the extension mechanism in 2.1 to be much more careful about
separating extensions from the core of maven. All extensions are
loaded into their own ClassRealm that inherits from the maven core
ClassRealm, and each
On 11/03/2008, at 6:52 AM, John Casey wrote:
I'd propose to resolve this using a mechanism borrowed from OSGi: we
should create some sort of manifest of classes to be exported from
the extension for use by the rest of Maven. This file could be
optional, and the existing behavior would
On Mon, Mar 10, 2008 at 11:44 AM, David Jencks [EMAIL PROTECTED] wrote:
Here's what it does:
By default, the LICENSE file is the standard apache license. The NOTICE
file is generated from a velocity template; here's an example of the output
(between - lines which are not included)
On Mar 10, 2008, at 12:43 PM, Henri Yandell wrote:
On Mon, Mar 10, 2008 at 11:44 AM, David Jencks
[EMAIL PROTECTED] wrote:
Here's what it does:
By default, the LICENSE file is the standard apache license. The
NOTICE
file is generated from a velocity template; here's an example of
the
On Mon, Mar 10, 2008 at 1:09 PM, David Jencks [EMAIL PROTECTED] wrote:
On Mar 10, 2008, at 12:43 PM, Henri Yandell wrote:
Two thoughts:
1) How is the end-year of the copyright done? AIUI, that should be the
year of last edit and not the year in which it is built. So if I build
I'm not entirely sure how to generalize it into plexus just yet,
since I'm jumping through some pretty complex ClassRealm-management
hoops in Maven right now. I'm not sure how I'd even start telling
Plexus to do that atm. The place in the current trunk implementation
to add this stuff is
On 10.03.2008, at 20:10, Shane Isbell wrote:
...
--
Geronimo :: Directory Plugin
Copyright 2003-2008 Apache Software Foundation
This product includes software developed at
Apache Software Foundation (http://www.apache.org/).
On Mar 10, 2008, at 2:55 PM, Erik Abele wrote:
On 10.03.2008, at 20:10, Shane Isbell wrote:
...
--
Geronimo :: Directory Plugin
Copyright 2003-2008 Apache Software Foundation
This product includes software developed at
Apache Software
Hi
To get the latest version of maven-source-plugin into our toolchain, I'd
like to release the shared components parent r635758 as version 9. A
site.xml has been added in this release.
Source:
https://svn.apache.org/viewvc/maven/shared/trunk/pom.xml?r1=587316r2=632477diff_format=h
You could also use Eclipse's ASTParser to scan sources for annotations.
Rahul
Jason van Zyl wrote:
On 25-Feb-08, at 2:21 AM, Bengali Bengali wrote:
I need to find annotated classes and generate an XML file.
Since i haven't found any good library to scan source files for
annotations.
I've been trying to make a multi-module archetype today using Archetype NG
(2.2-alpha 2) and I noticed that the relativePath of the parent is always
overridden with ../pom.xml. (This appears to be the result of some code in
org.apache.maven.archetype.common.MavenJDOMWriter#updateParent()).
30 matches
Mail list logo
