On Wed, 2003-10-22 at 02:45, Brett Porter wrote:
> > These below should go as well. The coupling on the license
> > plugin needs to be removed, multiproject certainly isn't
> > core, and neither is plugin.
> >
> > > - license
> > > - multiproject
> > > - touchstone
> > > - touchstone-partner
> >
> These below should go as well. The coupling on the license
> plugin needs to be removed, multiproject certainly isn't
> core, and neither is plugin.
>
> > - license
> > - multiproject
> > - touchstone
> > - touchstone-partner
> > - plugin
Isn't touchstone needed to test the maven code though?
On Wed, 2003-10-22 at 00:57, [EMAIL PROTECTED] wrote:
> I'd like to move the following plugins out of the core cvs module:
>
> - artifact
> - caller
> - changelog
> - changes
> - checkstyle
> - deploy
> - developer-activity
> - dist
> - ear
> - ejb
> - faq
> - file-activity
> - javadoc
> - jdepend
dion2003/10/21 22:50:13
Modified:xdocs/reference/developers developer-guide.xml
Log:
Move how to create your first plugin to xdocs from wiki
Revision ChangesPath
1.4 +142 -0maven/xdocs/reference/developers/developer-guide.xml
Index: developer-guide.xml
dion2003/10/21 22:46:56
Modified:.project.properties
Log:
Allow html2xdoc docs
Revision ChangesPath
1.48 +25 -18maven/project.properties
Index: project.properties
===
RCS file: /
dion2003/10/21 22:44:52
Modified:aspectj .cvsignore
Log:
Ignore logs
Revision ChangesPath
1.2 +1 -0 maven-plugins/aspectj/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/maven-pl
> > I wonder if it is also worth putting all of the report only plugins
> > into
> a
> > separate subdirectory.
>
> What about plugins that are report and something else like
> the javadoc
> plugin?
Yeah, you are right. If we are going to go down the categorisation path,
best do it properly a
Brett Porter <[EMAIL PROTECTED]> wrote on 22/10/2003 03:14:52 PM:
> +0, although I'm not sure what makes multiproject core.
Cool. I missed that one somehow. It's not used in bootstrap, so it could
move too.
> I wonder if it is also worth putting all of the report only plugins into
a
> separat
+0
Why don't you also move the multiplugin project?
Thanks
-Vincent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 06:58
> To: [EMAIL PROTECTED]
> Subject: Moving plugins
>
> I'd like to move the following plugins out of the core cvs mod
dion2003/10/21 22:18:15
Removed: src/plugins-build/dist/xdocs properties.xml changes.xml
goals.xml .cvsignore navigation.xml index.xml
src/plugins-build/dist project.xml project.properties
plugin.jelly .cvsignore plugin.p
+0, although I'm not sure what makes multiproject core.
I wonder if it is also worth putting all of the report only plugins into a
separate subdirectory.
You'll need to be careful that there aren't any issues with dynatag
libraries too, I think a couple of core ones still specify xmlns:deploy,
ev
I'd like to move the following plugins out of the core cvs module:
- artifact
- caller
- changelog
- changes
- checkstyle
- deploy
- developer-activity
- dist
- ear
- ejb
- faq
- file-activity
- javadoc
- jdepend
- jellydoc
- junit-report
- jxr
- linkcheck
- scm
- site
- tasklist
- vdoclet
- war
-
Last 500 lines of a clean bootstrap build of maven at 20031021-2200
[exec] extra-failure
[exec] +
[exec] | Testing extra-failure
[exec] | Memory: 15M/17M
[exec] +
[exec] build:
[exec
The following comment has been added to this issue:
Author: dion gillard
Created: Tue, 21 Oct 2003 9:25 PM
Body:
Applied the patch for issue 1
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key
dion2003/10/21 18:58:51
Modified:src/java/org/apache/maven/cli App.java
Log:
Apply a patch for part 1) of Maven-109
Revision ChangesPath
1.37 +5 -1 maven/src/java/org/apache/maven/cli/App.java
Index: App.java
==
The following comment has been added to this issue:
Author: Ben Walding
Created: Tue, 21 Oct 2003 9:15 PM
Body:
The previous comment is correct for 1), I have not verified #2. This will be an issue
with build tools such as Continuum / DamageControl if they rely on exit codes.
eg
The following comment has been added to this issue:
Author: dion gillard
Created: Tue, 21 Oct 2003 9:13 PM
Body:
Can you provide a sample?
I'll happily reopen this issue if you do.
-
View the issue:
http://jira
The following comment has been added to this issue:
Author: dion gillard
Created: Tue, 21 Oct 2003 9:10 PM
Body:
It should copy it to
repo/${pom.groupId}/ears/${pom.artifactId}-${pom.currentVersion}.ear
-
View the
The following comment has been added to this issue:
Author: dion gillard
Created: Tue, 21 Oct 2003 8:20 PM
Body:
Is this for the checkstyle plugin only?
If so, what about using maven:addPath?
-
View the issue:
The following issue has been updated:
Updater: Brett Porter (mailto:[EMAIL PROTECTED])
Date: Tue, 21 Oct 2003 8:02 PM
Comment:
almost there.
I'd like to get this in before rc2 is released
Changes:
Fix Version changed to 1.0-rc2
Fix Version changed from
The following comment has been added to this issue:
Author: dion gillard
Created: Tue, 21 Oct 2003 7:30 PM
Body:
the current javadoc plugin already allows a maven.javadoc.maxmemory property to be
specified.
-
View
brett 2003/10/21 15:51:52
Modified:xdocs/start install.xml
Log:
update documentation to warn of bug on Win9x installations.
Revision ChangesPath
1.15 +7 -0 maven/xdocs/start/install.xml
Index: install.xml
The following issue has been updated:
Updater: Brett Porter (mailto:[EMAIL PROTECTED])
Date: Tue, 21 Oct 2003 6:10 PM
Comment:
known problem. Simply skip the step until a fix is made - this just saves a bit of
downloading.
I will update the install docs.
Changes:
Looks good Mauro. Thanks.
My only comment is about the "category" addition to a dependency. Can you
explain the usage of this with an example? My impression was that the form
of copying out of the "jars" directory should not be done, and instead use
${dependency.path}, to allow for jar overrides.
The following comment has been added to this issue:
Author: Brett Porter
Created: Tue, 21 Oct 2003 6:00 PM
Body:
Martin, please read previous comments before adding your own. Using $MAVEN_HOME_LOCAL
has already been suggested (isn't that the issue subject?), and the reasons not to
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-957
Here is an overview of the issue:
--
The following comment has been added to this issue:
Author: Martin Skopp
Created: Tue, 21 Oct 2003 12:18 PM
Body:
Please consider this alternative, posted by Konstantin Shaposhnikov <[EMAIL
PROTECTED]> on the maven-dev list:
What about placing this file in ${user.home}/.maven/
Jason van Zyl wrote:
Shall we adjust the release plugin as well to match the addition of this
to the dist? From within the release plugin we can use your new
additions the dist plugin.
yep - that's my plan. just taking it one step at a time.
wanted to gauge reactions to this change as it deviates
On Tue, 2003-10-21 at 17:34, Konstantin Shaposhnikov wrote:
> What about placing this file in ${user.home}/.maven/ directory by
> default and use ${user.home}/build.properties only if previous file
> (${user.home}/.maven/build.properties) not found?
+2
--
Martin Skopp
Riege Software Internation
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-956
Here is an overview of the issue:
--
Hi all.
What about placing this file in ${user.home}/.maven/ directory by
default and use ${user.home}/build.properties only if previous file
(${user.home}/.maven/build.properties) not found?
build.properties is only configuration file that is not hidden in my
linux home directory (i.e. doesn'
The following comment has been added to this issue:
Author: Joakim Erdfelt
Created: Tue, 21 Oct 2003 10:45 AM
Body:
I cannot include older ant script (due to corporate security policy), besides, after
neutering it would be useless to you, (I think).
Ok, some success with javadoc
evenisse2003/10/21 08:04:59
Modified:src/plugins-build/jellydoc plugin.jelly project.xml
src/plugins-build/jellydoc/src/main/org/apache/maven/jellydoc
TagXMLDoclet.java XMLDoclet.java
src/plugins-build/jellydoc/xdocs changes.xml
Log
On Tue, 2003-10-21 at 04:29, Mauro Talevi wrote:
> It would help to actually attach the patch :-)
>
> __
Shall we adjust the release plugin as well to match the addition of this
to the dist? From within the release plugin we can u
The following issue has been updated:
Updater: anita kulshreshtha (mailto:[EMAIL PROTECTED])
Date: Tue, 21 Oct 2003 8:32 AM
Comment:
Here is a patch to get around this problem. It may not be the best solution.
Changes:
Attachment changed to mavenbat.patch
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-955
Here is an overview of the issue:
--
On Tue, 2003-10-21 at 09:34, Brett Porter wrote:
> http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-605
Thanks, Brett. I will add some comments there...
The issue is unassigned / unscheduled - will one hold a voting for a new
filename or just change the source?
I am +1 anyway, including w
The following comment has been added to this issue:
Author: Julien Kirch
Created: Tue, 21 Oct 2003 4:36 AM
Body:
I successfully (ahem) reproduced the bug : the amp should be in the link part of the
navigation file and not in the menu part.
-
It would help to actually attach the patch :-)
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven/src/plugins-build/dist/plugin.jelly,v
retrieving revision 1.11
diff -u -r1.11 plugin.jelly
--- plugin.jelly16 Oct 2003 08:46
Brett Porter wrote:
This sounds about right. I'd had plans to do some such thing, as for our
workplace I created an installer plugin that basically does bits of dist and
a bit more to create a tarball. Also, the SCM plugin has release type stuff
in there that overlaps some with the release plugin.
The following comment has been added to this issue:
Author: Martin Skopp
Created: Tue, 21 Oct 2003 3:41 AM
Body:
So I identified 2 options for the directory:
(1) $HOME
(2) $MAVEN_HOME_LOCAL (=$HOME/.maven per default)
and 3 options for the filename:
(a) build.properties
(b) .maven
Message:
The following issue has been closed.
Resolver: Ben Walding
Date: Tue, 21 Oct 2003 3:27 AM
Patches applied. Thanks.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-915
Here is
There is already a JIRA issue.
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-605
> -Original Message-
> From: Martin Skopp [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 21 October 2003 5:10 PM
> To: Maven Developers
> Subject: Use another file instead of ${user.home}/build.prope
Hi gurus,
I like to use another file instead ${user.home}/build.properties.
I like to specify a alternative filename e.g. on the maven CLI or by a
system property (e.g. maven
-Duser.properties.file=C:\maven.build.properties/via $MAVEN_OPTS).
I have the problem here that build.properties as filen
44 matches
Mail list logo
