cvs commit: maven-plugins/jdiff project.xml
evenisse2003/12/18 22:03:30 Modified:jdiffproject.xml Log: Upgrade to jdiff-1.0.9 Revision ChangesPath 1.18 +3 -2 maven-plugins/jdiff/project.xml Index: project.xml === RCS file: /home/cvs/maven-plugins/jdiff/project.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- project.xml 18 Dec 2003 22:54:54 - 1.17 +++ project.xml 19 Dec 2003 06:03:30 - 1.18 @@ -47,8 +47,9 @@ - jdiff - 1.0.7 + jdiff + jdiff + 1.0.9 root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1086) Maven (forehead.conf) should use ant 1.5.4+
The following comment has been added to this issue: Author: dion gillard Created: Thu, 18 Dec 2003 10:46 PM Body: 1.6.0 has just been released - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1086 Here is an overview of the issue: - Key: MAVEN-1086 Summary: Maven (forehead.conf) should use ant 1.5.4+ Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.0-rc2 Assignee: Reporter: Ramon Casha Created: Thu, 18 Dec 2003 10:28 PM Updated: Thu, 18 Dec 2003 10:46 PM Environment: JDK 1.4.2 Description: When using maven 1.0-rc2 with JDK1.4.2, the javah task doesn't work. I traced this to the version of ant which is specified in maven's forehead.conf - when I changed this from 1.5.3-1 to 1.5.4 it worked. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1086) Maven (forehead.conf) should use ant 1.5.4+
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1086 Here is an overview of the issue: - Key: MAVEN-1086 Summary: Maven (forehead.conf) should use ant 1.5.4+ Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Versions: 1.0-rc2 Assignee: Reporter: Ramon Casha Created: Thu, 18 Dec 2003 10:28 PM Updated: Thu, 18 Dec 2003 10:28 PM Environment: JDK 1.4.2 Description: When using maven 1.0-rc2 with JDK1.4.2, the javah task doesn't work. I traced this to the version of ant which is specified in maven's forehead.conf - when I changed this from 1.5.3-1 to 1.5.4 it worked. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new maven goal
On Thu, 2003-12-18 at 17:07, Sonnek, Ryan wrote: > I have nearly finished creating a small plugin that I think could be > integrated into the maven clean plugin. I would like to get feedback on it > and ask about if/how to submit it to the maven community. > > I created a plugin that goes through the user's local repository and deletes > out all timestamped artifacts EXCEPT the newest one (should be the same as > SNAPSHOT). I needed to create this plugin because after several weeks of > development, I'd have over 1 GB tied up in my local repo. It is not > possible to just "blow away" my local repo since we may or may not be online > to redownload the dependencies, so I created this plugin to do the grunt > work for me. > > I see this as being useful to organizations that develop using SNAPSHOT > dependencies (which kicks ass, and I thank maven for implementing this), and > don't want to weed through their local repo to clean up old files. > > Any suggestions on how to go about this would be greatly appreciated. > Thanks. This is something that you need to be careful about. It can't hurt to have the goal for those that want to use it. A local repository is obviously slightly different than ibiblio but one thing that we're strict about with ibiblio is that no removals occur. This is an important reason why ibiblio was chosen because it is a form of history and you could potentially really screw yourself, or someone else, in the future by removing stuff that doesn't seem important at the time. In an organization that has a shared repository for development you probably don't want to start nuking stuff, but this feature probably can't hurt for a user's local repository. Just some notions to keep in mind. > Ryan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new maven goal
It would be great to integrate this into the repository plugin (rather than clean). Could you post it to our bug reporting system? Thanks, -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ "Sonnek, Ryan" <[EMAIL PROTECTED]> wrote on 19/12/2003 09:07:51 AM: > I have nearly finished creating a small plugin that I think could be > integrated into the maven clean plugin. I would like to get feedback on it > and ask about if/how to submit it to the maven community. > > I created a plugin that goes through the user's local repository and deletes > out all timestamped artifacts EXCEPT the newest one (should be the same as > SNAPSHOT). I needed to create this plugin because after several weeks of > development, I'd have over 1 GB tied up in my local repo. It is not > possible to just "blow away" my local repo since we may or may not be online > to redownload the dependencies, so I created this plugin to do the grunt > work for me. > > I see this as being useful to organizations that develop using SNAPSHOT > dependencies (which kicks ass, and I thank maven for implementing this), and > don't want to weed through their local repo to clean up old files. > > Any suggestions on how to go about this would be greatly appreciated. > Thanks. > Ryan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPCHANGELOG-1) changelog-plugin does not work with svn
Message:
The following issue has been closed.
Resolver: Emmanuel Venisse
Date: Thu, 18 Dec 2003 5:26 PM
Already fixed
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPCHANGELOG-1
Here is an overview of the issue:
-
Key: MPCHANGELOG-1
Summary: changelog-plugin does not work with svn
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-changelog-plugin
Fix Fors:
1.4
Versions:
1.3
Assignee:
Reporter: Philipp Meier
Created: Tue, 12 Aug 2003 1:20 PM
Updated: Thu, 18 Dec 2003 5:26 PM
Environment: Debian GNU/Linux with subversion 0.26.0 (r6550)
Maven CVS from 20030811
Description:
The changelog-plugin calls svn as
svn "log" "-v" "-D start:end"
("" to symbolize array delimiters)
This would not work with svn 0.26.0 which expects the following format:
svn "log" "-v" "-D" "{start}:{end}"
Setting the range of the changelog report to the empty string will make changelog call
svn correctly but after the svn sub process exists maven hangs. (Will attach strace
log).
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/jdiff/xdocs changes.xml
evenisse2003/12/18 15:07:45 Modified:jdiff/xdocs changes.xml Log: Add reference to issue Revision ChangesPath 1.4 +1 -1 maven-plugins/jdiff/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/maven-plugins/jdiff/xdocs/changes.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- changes.xml 18 Dec 2003 22:44:11 - 1.3 +++ changes.xml 18 Dec 2003 23:07:45 - 1.4 @@ -8,7 +8,7 @@ - Fix error due to makeRelativePath. + MPJDIFF-1. Fix error due to makeRelativePath. update to use maven.docs.*/maven.gen.docs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJDIFF-1) jdiff-plugin does not work
Message: The following issue has been closed. Resolver: Emmanuel Venisse Date: Thu, 18 Dec 2003 5:07 PM Fixed in cvs - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPJDIFF-1 Here is an overview of the issue: - Key: MPJDIFF-1 Summary: jdiff-plugin does not work Type: Bug Status: Closed Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-jdiff-plugin Fix Fors: 1.2 Assignee: Reporter: Norbert Pabis Created: Fri, 10 Oct 2003 4:17 AM Updated: Thu, 18 Dec 2003 5:07 PM Environment: maven HAED, maven-plugins HEAD 2003-10-10 Description: >maven jdiff BUILD FAILED File.. file:/home/user/.maven/plugins/maven-jdiff-plugin-1.1/ Element... maven:makeRelativePath Line.. 44 Column 120 You must define an attribute called 'path' for this tag. Total time: 19 seconds Finished at: Fri Oct 10 10:52:26 CEST 2003 Properties have default values and there is only jdiff goal. At least according to jdiff docs. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/jdiff project.xml
evenisse2003/12/18 14:54:54 Modified:jdiffproject.xml Log: Fix IssueTracking Url Revision ChangesPath 1.17 +1 -0 maven-plugins/jdiff/project.xml Index: project.xml === RCS file: /home/cvs/maven-plugins/jdiff/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 18 Dec 2003 22:44:11 - 1.16 +++ project.xml 18 Dec 2003 22:54:54 - 1.17 @@ -14,6 +14,7 @@ scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:maven-plugins/jdiff/ http://cvs.apache.org/viewcvs/maven-plugins/jdiff/ + http://jira.codehaus.org/secure/BrowseProject.jspa?id=10374 dIon Gillard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1080) Maven download corrupted jar file into repository
The following comment has been added to this issue: Author: Charlie Dobbie Created: Thu, 18 Dec 2003 4:57 PM Body: I expect a fix for this should also fix the following: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCFETCH-1 - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1080 Here is an overview of the issue: - Key: MAVEN-1080 Summary: Maven download corrupted jar file into repository Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-final Versions: 1.0-rc1 Assignee: Reporter: Mesut Celik Created: Fri, 12 Dec 2003 3:27 PM Updated: Thu, 18 Dec 2003 4:57 PM Description: When you break up downloading the jar files into repository while executing some goal, Maven puts corrupted jar file into repository. Solution is to copy the same jar to the correct folder in the repository folder structure. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/jdiff/xdocs changes.xml
evenisse2003/12/18 14:44:11
Modified:jdiffplugin.jelly project.xml
jdiff/xdocs changes.xml
Log:
Fix error due to makeRelativePath.
Revision ChangesPath
1.9 +13 -19maven-plugins/jdiff/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven-plugins/jdiff/plugin.jelly,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- plugin.jelly 29 Aug 2003 06:27:52 - 1.8
+++ plugin.jelly 18 Dec 2003 22:44:11 - 1.9
@@ -41,13 +41,12 @@
-
+/>
@@ -65,10 +64,9 @@
value="${maven.jdiff.dir}/${maven.jdiff.old.tag}"/>
-
@@ -77,19 +75,17 @@
value="${maven.jdiff.old.dir}/${pom.repository.cvsModule}/${relativeSrcDir}"/>
-
-
+
+
-
+
-
+ packagenames="${pom.package}.*">
+
@@ -99,8 +95,7 @@
packagenames="${pom.package}.*"
sourcepath="${maven.jdiff.new.src}">
-
+
@@ -110,8 +105,7 @@
private="yes"
destdir="${maven.jdiff.changes.dir}"
packagenames="${pom.package}.*"
- sourcepath="${maven.jdiff.new.src}"
- >
+ sourcepath="${maven.jdiff.new.src}">
@@ -122,11 +116,11 @@
-
-
+
+
-
+
1.16 +10 -1 maven-plugins/jdiff/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven-plugins/jdiff/project.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- project.xml 10 Oct 2003 19:21:01 - 1.15
+++ project.xml 18 Dec 2003 22:44:11 - 1.16
@@ -5,7 +5,7 @@
3
maven-jdiff-plugin
Maven JDiff Plugin
- 1.1
+ 1.2-SNAPSHOT
Diff between CVS releases
http://maven.apache.org/reference/plugins/jdiff/
@@ -32,6 +32,15 @@
Architect
Release Manager
+
+
+
+ Emmanuel Venisse
+ evenisse
+ [EMAIL PROTECTED]
+
+
+Java Developer
1.3 +3 -0 maven-plugins/jdiff/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven-plugins/jdiff/xdocs/changes.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- changes.xml 29 Sep 2003 06:18:41 - 1.2
+++ changes.xml 18 Dec 2003 22:44:11 - 1.3
@@ -7,6 +7,9 @@
+
+ Fix error due to
makeRelativePath.
+
update to use
maven.docs.*/maven.gen.docs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
new maven goal
I have nearly finished creating a small plugin that I think could be integrated into the maven clean plugin. I would like to get feedback on it and ask about if/how to submit it to the maven community. I created a plugin that goes through the user's local repository and deletes out all timestamped artifacts EXCEPT the newest one (should be the same as SNAPSHOT). I needed to create this plugin because after several weeks of development, I'd have over 1 GB tied up in my local repo. It is not possible to just "blow away" my local repo since we may or may not be online to redownload the dependencies, so I created this plugin to do the grunt work for me. I see this as being useful to organizations that develop using SNAPSHOT dependencies (which kicks ass, and I thank maven for implementing this), and don't want to weed through their local repo to clean up old files. Any suggestions on how to go about this would be greatly appreciated. Thanks. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-1085) Maven site fails during test in touchstone
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1085 Here is an overview of the issue: - Key: MAVEN-1085 Summary: Maven site fails during test in touchstone Type: Bug Status: Closed Priority: Major Resolution: DUPLICATE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0-rc2 Versions: 1.0-rc2 Assignee: Reporter: dion gillard Created: Thu, 18 Dec 2003 1:01 AM Updated: Thu, 18 Dec 2003 4:03 PM Environment: Win2k 1.0 branch all plugins installed. Description: Tag library requested that is not present: 'dashboard' [echo] E will fail on purpose [echo] failure-1 failed correctly [echo] extra-failure failed correctly [echo] counter-pre [echo] counter-post [echo] Generating the Task List... [echo] Generating the Jelly Tag Documentation... [echo] Generating jellydoc for packages org.apache.maven.* [echo] Source directory is C:\source\maven\src\test\touchstone-build\src\reactor-build\failProperty\extra-failure\src\java BUILD FAILED C:\source\maven\src\test\touchstone-build\src\reactor-build\failProperty\extra-failure\src\java not found. Total time: 1 minutes 6 seconds Finished at: Thu Dec 18 17:50:39 EST 2003 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
artifact utilities
Are there any utility classes currently in the codebase for working with local artifacts? Specifically, I'm trying to go through the entire local repository and delete old snapshot artifacts. I need to parse out the "version" for all artifacts, and I thought someone might have done this before. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJBOSS-7) jboss:deploy-exploded-warfile no worky
The following comment has been added to this issue:
Author: Jim Crossley
Created: Thu, 18 Dec 2003 10:21 AM
Body:
After looking at this a bit more closely, I now realize it's not a jboss plugin issue
but a war plugin issue. I *think* it's just a matter of making this the default
setting in the war plugin:
maven.war.webapp.dir = ${maven.build.dir}/exploded/${pom.artifactId}.war/
I don't believe it breaks any existing functionality and it makes all the JBoss goals
work out of the box.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPJBOSS-7
Here is an overview of the issue:
-
Key: MPJBOSS-7
Summary: jboss:deploy-exploded-warfile no worky
Type: Bug
Status: Unassigned
Priority: Minor
Original Estimate: 1 day
Time Spent: Unknown
Remaining: 1 day
Project: maven-jboss-plugin
Assignee:
Reporter: Jim Crossley
Created: Thu, 11 Dec 2003 7:50 AM
Updated: Thu, 18 Dec 2003 10:21 AM
Environment: Any
Description:
It is often convenient to deploy an exploded warfile to jboss so that jsp changes
don't require a redeploy.
JBoss requires that the exploded directory name have a J2EE suffix, e.g. .war, .ear,
etc. Because the exploded directory and the war file are both created in the target
directory, they cannot have the same name.
I propose that the exploded warfile go in target/exploded/${id}.war/ so that both it
and target/${id}.war (the actual war) can peacefully coexist. That way, both
jboss:deploy-warfile and jboss:deploy-exploded-warfile will work correctly out of the
box.
I'll try to submit a patch soon (s/b trivial).
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit:maven-plugins/xdoc/src/plugin-resources/templatesdownloads.xml
On Thu, 2003-12-18 at 10:00, Vincent Massol wrote:
> Ok. So, are you going to modify the plugins so that calling xxx:deploy
> deploys the project's main artifact to pom.distributionURL?
This is the _user_ distribution URL. Where users go to get artifacts
provided by a project. You may deploy to one address for whatever reason
(virtual hosting, security, quirks in internal networks, or whatever)
but user goes to the specified distribution URL. Maybe a more clear name
like userDistributionUrl.
> Also, will the users have to duplicate information about project group,
> id and version in the POM:
>
> http://www.ibiblio.org/maven/mygroup/jars/myartifact-my
> version.jar
The distributionURL I was thinking would be a directory as we currently
have several distribution packages. This is for distributions not
artifacts like you have above.
> or will you allow using interpolation of the POM object:
>
> http://www.ibiblio.org/maven/${pom.groupId}/jars/${pom.
> artifactId}-${pom.currentVersion}.jar
>
> ?
>
> I think you're going to say option 1. So the user will have to remember
> to update the distributionURL whenever he changes the version for
> example (that's one more potential error - it will happen).
No, that's not what I'm saying.
> Maybe simply defining the URL path (excluding the artifact itself) would
> be better?
That's what I'm saying.
> Thanks
> -Vincent
>
> > -Original Message-
> > From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> > Sent: 18 December 2003 15:17
> > To: Maven Developers List
> > Subject: RE: cvs commit:maven-plugins/xdoc/src/plugin-
> > resources/templatesdownloads.xml
> >
> > On Thu, 2003-12-18 at 03:01, Vincent Massol wrote:
> > > Jason,
> > >
> > > This is what I'm doing in the multichanges plugin: it automatically
> > > lists all releases. I have not committed it yet but the way I
> planned to
> > > compute the URL was by:
> > >
> > > [Remote repo URL] + [group id] + [type (new POM element)] +
> [artifact
> > > id] + [version] + [type extension - directly computed from type]
> > >
> > > The best would be to ask the artifact handler (whatever that is) to
> > > return the URL by passing to it the different parameters.
> > >
> > > I see that you wish to have a distributionURL. Would that be
> optional
> > > and default to the strategy above if not specified?
> >
> > I think relying on the runtime mechanism to generate the distribution
> > url doesn't sound like a good idea. Where you distribute to and where
> a
> > user gets downloads from may not be the same.
> >
> > I would much prefer the simple approach of stating what the user
> > distribution url is instead of trying to calculate it which you may
> not
> > be able to do anyway. The addition of the element is clear, concise
> and
> > wouldn't leave much room for guessing.
> >
> > > Thanks
> > > -Vincent
> > >
> > > > -Original Message-
> > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> > > > Sent: 18 December 2003 08:23
> > > > To: Maven Developers List
> > > > Subject: Re: cvs commit: maven-plugins/xdoc/src/plugin-
> > > > resources/templatesdownloads.xml
> > > >
> > > > On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote:
> > > > > So this is not a 1.0 compatible plugin anymore??
> > > >
> > > > It still is, none of the default behaviour has changed. I'm just
> > > adding
> > > > stuff that >1.0 will be able to take advantage of.
> > > >
> > > > > --
> > > > > dIon Gillard, Multitask Consulting
> > > > > Blog: http://blogs.codehaus.org/people/dion/
> > > > >
> > > > >
> > > > >
> > > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM:
> > > > >
> > > > > > jvanzyl 2003/12/17 13:40:37
> > > > > >
> > > > > > Added: xdoc/src/plugin-resources/templates
> downloads.xml
> > > > > > Log:
> > > > > > o little template for an automatically created download
> page.
> > > This
> > > > is
> > > > > going
> > > > > > to require an addition to the POM of a distributionUrl for
> > > > > end-users.
> > > > > >
> > > > > > Revision ChangesPath
> > > > > > 1.1
> > > maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml
> > > > > >
> > > > > > Index: downloads.xml
> > > > > >
> > > ===
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Downloads
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > #set ($url =
> $escape.getText($project.distributionUrl))
> > > > > > $url
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > >
> -
> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> ---
RE: cvs commit:maven-plugins/xdoc/src/plugin-resources/templatesdownloads.xml
Ok. So, are you going to modify the plugins so that calling xxx:deploy
deploys the project's main artifact to pom.distributionURL?
Also, will the users have to duplicate information about project group,
id and version in the POM:
http://www.ibiblio.org/maven/mygroup/jars/myartifact-my
version.jar
or will you allow using interpolation of the POM object:
http://www.ibiblio.org/maven/${pom.groupId}/jars/${pom.
artifactId}-${pom.currentVersion}.jar
?
I think you're going to say option 1. So the user will have to remember
to update the distributionURL whenever he changes the version for
example (that's one more potential error - it will happen).
Maybe simply defining the URL path (excluding the artifact itself) would
be better?
Thanks
-Vincent
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: 18 December 2003 15:17
> To: Maven Developers List
> Subject: RE: cvs commit:maven-plugins/xdoc/src/plugin-
> resources/templatesdownloads.xml
>
> On Thu, 2003-12-18 at 03:01, Vincent Massol wrote:
> > Jason,
> >
> > This is what I'm doing in the multichanges plugin: it automatically
> > lists all releases. I have not committed it yet but the way I
planned to
> > compute the URL was by:
> >
> > [Remote repo URL] + [group id] + [type (new POM element)] +
[artifact
> > id] + [version] + [type extension - directly computed from type]
> >
> > The best would be to ask the artifact handler (whatever that is) to
> > return the URL by passing to it the different parameters.
> >
> > I see that you wish to have a distributionURL. Would that be
optional
> > and default to the strategy above if not specified?
>
> I think relying on the runtime mechanism to generate the distribution
> url doesn't sound like a good idea. Where you distribute to and where
a
> user gets downloads from may not be the same.
>
> I would much prefer the simple approach of stating what the user
> distribution url is instead of trying to calculate it which you may
not
> be able to do anyway. The addition of the element is clear, concise
and
> wouldn't leave much room for guessing.
>
> > Thanks
> > -Vincent
> >
> > > -Original Message-
> > > From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> > > Sent: 18 December 2003 08:23
> > > To: Maven Developers List
> > > Subject: Re: cvs commit: maven-plugins/xdoc/src/plugin-
> > > resources/templatesdownloads.xml
> > >
> > > On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote:
> > > > So this is not a 1.0 compatible plugin anymore??
> > >
> > > It still is, none of the default behaviour has changed. I'm just
> > adding
> > > stuff that >1.0 will be able to take advantage of.
> > >
> > > > --
> > > > dIon Gillard, Multitask Consulting
> > > > Blog: http://blogs.codehaus.org/people/dion/
> > > >
> > > >
> > > >
> > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM:
> > > >
> > > > > jvanzyl 2003/12/17 13:40:37
> > > > >
> > > > > Added: xdoc/src/plugin-resources/templates
downloads.xml
> > > > > Log:
> > > > > o little template for an automatically created download
page.
> > This
> > > is
> > > > going
> > > > > to require an addition to the POM of a distributionUrl for
> > > > end-users.
> > > > >
> > > > > Revision ChangesPath
> > > > > 1.1
> > maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml
> > > > >
> > > > > Index: downloads.xml
> > > > >
> > ===
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Downloads
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > #set ($url =
$escape.getText($project.distributionUrl))
> > > > > $url
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
-
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > >
> > > >
> > > >
> >
-
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > --
> > > jvz.
> > >
> > > Jason van Zyl
> > > [EMAIL PROTECTED]
> > > http://tambora.zenplex.org
> > >
> > > In short, man creates for himself a new religion of a rational
> > > and technical order to justify his work and to be justified in it.
> > >
> > > -- Jacques Ellul, The Technological Society
> > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> --
> jvz.
>
> Jason van Zyl
> [
RE: cvs commit: maven-plugins/xdoc/src/plugin-resources/templatesdownloads.xml
On Thu, 2003-12-18 at 03:01, Vincent Massol wrote: > Jason, > > This is what I'm doing in the multichanges plugin: it automatically > lists all releases. I have not committed it yet but the way I planned to > compute the URL was by: > > [Remote repo URL] + [group id] + [type (new POM element)] + [artifact > id] + [version] + [type extension - directly computed from type] > > The best would be to ask the artifact handler (whatever that is) to > return the URL by passing to it the different parameters. > > I see that you wish to have a distributionURL. Would that be optional > and default to the strategy above if not specified? I think relying on the runtime mechanism to generate the distribution url doesn't sound like a good idea. Where you distribute to and where a user gets downloads from may not be the same. I would much prefer the simple approach of stating what the user distribution url is instead of trying to calculate it which you may not be able to do anyway. The addition of the element is clear, concise and wouldn't leave much room for guessing. > Thanks > -Vincent > > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: 18 December 2003 08:23 > > To: Maven Developers List > > Subject: Re: cvs commit: maven-plugins/xdoc/src/plugin- > > resources/templatesdownloads.xml > > > > On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote: > > > So this is not a 1.0 compatible plugin anymore?? > > > > It still is, none of the default behaviour has changed. I'm just > adding > > stuff that >1.0 will be able to take advantage of. > > > > > -- > > > dIon Gillard, Multitask Consulting > > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > > > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM: > > > > > > > jvanzyl 2003/12/17 13:40:37 > > > > > > > > Added: xdoc/src/plugin-resources/templates downloads.xml > > > > Log: > > > > o little template for an automatically created download page. > This > > is > > > going > > > > to require an addition to the POM of a distributionUrl for > > > end-users. > > > > > > > > Revision ChangesPath > > > > 1.1 > maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml > > > > > > > > Index: downloads.xml > > > > > === > > > > > > > > > > > > > > > > > > > > > > > > > > > > Downloads > > > > > > > > > > > > > > > > > > > > > > > > #set ($url = $escape.getText($project.distributionUrl)) > > > > $url > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://tambora.zenplex.org > > > > In short, man creates for himself a new religion of a rational > > and technical order to justify his work and to be justified in it. > > > > -- Jacques Ellul, The Technological Society > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1084) Composition of dependencies from many projects (a route round multiple inheritance)
The following comment has been added to this issue: Author: Rafal Krzewski Created: Thu, 18 Dec 2003 6:24 AM Body: Valid concern - but missed concept. The thing that you seem to need is transitive dependencies support, which is orthogonal to POM inheritance. It has been discussed before and it is a wanted and planned feature. In short, you should be able to mark a project's dependency as transitive. Such dependency will be automatically exported to the projects that depend on that project. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1084 Here is an overview of the issue: - Key: MAVEN-1084 Summary: Composition of dependencies from many projects (a route round multiple inheritance) Type: New Feature Status: Unassigned Priority: Minor Original Estimate: 4 hours Time Spent: Unknown Remaining: 4 hours Project: maven Components: core Assignee: Reporter: Mike Melia Created: Wed, 17 Dec 2003 12:40 AM Updated: Thu, 18 Dec 2003 6:24 AM Description: I have an EAR project that has (mostly) the same dependencies as an EJB project. The EAR project includes the dependent jars in the EAR artifact. The EJB project requires the dependent jars for compilation and for them to be included in the manifest classpath. I also have another project that builds a utility jar for use by both the EAR and EJB project. All projects extend a base project with the usual info defined (developers names etc.). This single inheritance forces me to duplicate the common dependency declarations in each subproject. Ideally I would like an include tag in the dependencies section. I have coded a workaround which allows for a space separated list of project files in the tag. e.g ../project.xml ../common_dependencies.xml The first file would be the parent project and the subsequent files would contain common dependencies. i.e. inherit from the parent and have dependencies composed from siblings. I will submit a patch for that functionality as soon as I get away from the corporate firewall. Please let me know if this sort of functionality has already been planned. TIA. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with dashboard plugin (+ xdoc/site/core ?) in HEAD
Hi,
I've run into a weird problem in site generation recently.
When dashboard report is enabled in a my project, xdoc:jelly-transform
writes the html files into
$MAVEN_HOME/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target instead
of the projects target/docs directory.
>From what I've been able to determine, at some point of execution the
xdoc plugin the ${pom} variable switches to the dashboard plugin descriptor.
I've attached outuput of a minimal test project run of 'maven site'
note the following passage:
dashboard:xdoc:
[echo] end of dashboard:xdoc Test project
[echo] site before xdoc Test project
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
I've attached the diff for adding the low-tech Jelly debug that
generates the messages visible above, and the test project.
---
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1-SNAPSHOT
site:
[echo] site before reports Test project
You are working offline so the build will continue, but
maven-junit-report-plugin-1.4-SNAPSHOT.jar may be out of date!
xdoc:register-reports:
maven-jdepend-plugin:register:
maven-checkstyle-plugin:register:
maven-changes-plugin:register:
maven-changelog-plugin:register:
maven-developer-activity-plugin:register:
maven-file-activity-plugin:register:
maven-license-plugin:register:
maven-javadoc-plugin:register:
maven-jxr-plugin:register:
maven-junit-report-plugin:register:
maven-linkcheck-plugin:register:
maven-tasklist-plugin:register:
maven-dashboard-plugin:register:
site:run-reports:
[echo] Generating the Project License...
maven-license-plugin:report:
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
license:transfer:
[echo]
==
= W A R N I N G =
==
= Your project doesn't contain a header file specified as: =
= /home/fil/tmp/dashboard-test/LICENSE.txt
= The License Report Plugin needs it to display the license =
= for the project. =
= If it can't find this file, it creates a page mentioning that =
= no license file has been given to Maven. =
==
license:
[echo] Generating the Link Check Report...
maven-linkcheck-plugin:report:
[echo] Generating the Dashboard...
Starting the reactor...
Our processing order:
dashboard:report:
dashboard:aggregate:
dashboard:xdoc:
[echo] end of dashboard:xdoc Test project
[echo] site before xdoc Test project
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
xdoc:register-reports:
maven-changes-plugin:register:
maven-changelog-plugin:register:
maven-file-activity-plugin:register:
maven-developer-activity-plugin:register:
maven-license-plugin:register:
maven-linkcheck-plugin:register:
maven-dashboard-plugin:register:
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:transform:
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
xdoc:copy-resources:
[copy] Copying 2 files to
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/style
[copy] Copying 89 files to
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/images
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
xdoc:copy-user-resources:
xdoc:init:
[echo] xdoc:init Maven Dashboard Plugin
About to use JSL stylesheet
file:/home/fil/.maven/plugins/maven-xdoc-plugin-1.5-SNAPSHOT/plugin-resources/site.jsl
xdoc:jelly-init:
xdoc:register-reports:
maven-changes-plugin:register:
maven-changelog-plugin:register:
maven-file-activity-plugin:register:
maven-developer-activity-plugin:register:
maven-license-plugin:register:
maven-linkcheck-plugin:register:
maven-dashboard-plugin:register:
xdoc:jelly-transform:
[echo] Generating
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/cvs-usage.html
from
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/generated-xdocs/cvs-usage.xml
[echo] Generating
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/index.html
from
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/generated-xdocs/index.xml
[echo] Generating
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/maven-reports.html
from
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/generated-xdocs/maven-reports.xml
[echo] Generating
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/docs/dependencies.html
from
/home/fil/.maven/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target/generated-xdocs
[jira] Commented: (MAVEN-1084) Composition of dependencies from many projects (a route round multiple inheritance)
The following comment has been added to this issue: Author: Mike Melia Created: Thu, 18 Dec 2003 3:58 AM Body: I'm not sure I completely understand your comment. I think you agreed that currently you can only inherit dependencies from one source but you didn't say whether it was a planned (or required) future feature. If it is desirable then I'll upload a patch. I'll try to explain more the scenario a bit better this time. Dependencies can be inherited from the parent but sometimes you want to inherit dependencies from more than one source - usually to cut down on the duplication of dependency declaration. e.g. if an EJB project declares dependencies on jars A, B and C with the ejb.manifest.classpath value set to true then the chances are that the EAR project will declare the same dependencies (A, B and C) with the ear.bundle value set to true. A third project (the utility jar project) will have dependencies D and E - which, consequently, will also be ear.bundle dependencies for the EAR project. The scenario I would prefer would be the following: Master project.xml defines the usual project properties. --Util project.xml extends the Master project.xml and defines the dependencies for the utility project --EJB project.xml extends the Master project.xml and defines the dependencies for the EJB project --EAR project.xml extends the Master project.xml and also indicates that it is inheriting the dependencies from the Util and EJB project.xml files. So, the solution would allow inheritance of dependencies from more than one source which cuts down on duplication. This is a good thing if, like me, you are setting up project.xml files for 80+ inter-related projects. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1084 Here is an overview of the issue: - Key: MAVEN-1084 Summary: Composition of dependencies from many projects (a route round multiple inheritance) Type: New Feature Status: Unassigned Priority: Minor Original Estimate: 4 hours Time Spent: Unknown Remaining: 4 hours Project: maven Components: core Assignee: Reporter: Mike Melia Created: Wed, 17 Dec 2003 12:40 AM Updated: Thu, 18 Dec 2003 3:58 AM Description: I have an EAR project that has (mostly) the same dependencies as an EJB project. The EAR project includes the dependent jars in the EAR artifact. The EJB project requires the dependent jars for compilation and for them to be included in the manifest classpath. I also have another project that builds a utility jar for use by both the EAR and EJB project. All projects extend a base project with the usual info defined (developers names etc.). This single inheritance forces me to duplicate the common dependency declarations in each subproject. Ideally I would like an include tag in the dependencies section. I have coded a workaround which allows for a space separated list of project files in the tag. e.g ../project.xml ../common_dependencies.xml The first file would be the parent project and the subsequent files would contain common dependencies. i.e. inherit from the parent and have dependencies composed from siblings. I will submit a patch for that functionality as soon as I get away from the corporate firewall. Please let me know if this sort of functionality has already been planned. TIA. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPEAR-13) Sar-bundling ability hasn't been added to the plugin property page
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPEAR-13 Here is an overview of the issue: - Key: MPEAR-13 Summary: Sar-bundling ability hasn't been added to the plugin property page Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ear-plugin Versions: 1.3 Assignee: Reporter: Julien Kirch Created: Thu, 18 Dec 2003 3:58 AM Updated: Thu, 18 Dec 2003 3:58 AM Description: http://maven.apache.org/reference/plugins/ear/properties.html Including artifacts in the ear file Maven can bundle in ear artifacts of following types: jar, war, ejb. "sar" shoudl be added to the list. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
We should add plugin:download instructions to all [ANNOUNCE] messages for plugins
Hi all, Now that the plugin download functionality works (fixed about a week ago) when we get the next RC or 1.0 out we should mention in the ANNOUNCE emails how to use it to download new plugins. This should help speed up adoption of new plugins. For instance, for the JCoverage 1.0.2 version, this works: $ maven plugin:download -DartifactId=maven-jcoverage-plugin -DgroupId=maven -Dversio n=1.0.2 Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1084) Composition of dependencies from many projects (a route round multiple inheritance)
The following comment has been added to this issue: Author: dion gillard Created: Thu, 18 Dec 2003 2:50 AM Body: AFAIK, dependencies are cumulative when inherited, and the only case in the POM where they are. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1084 Here is an overview of the issue: - Key: MAVEN-1084 Summary: Composition of dependencies from many projects (a route round multiple inheritance) Type: New Feature Status: Unassigned Priority: Minor Original Estimate: 4 hours Time Spent: Unknown Remaining: 4 hours Project: maven Components: core Assignee: Reporter: Mike Melia Created: Wed, 17 Dec 2003 12:40 AM Updated: Thu, 18 Dec 2003 2:50 AM Description: I have an EAR project that has (mostly) the same dependencies as an EJB project. The EAR project includes the dependent jars in the EAR artifact. The EJB project requires the dependent jars for compilation and for them to be included in the manifest classpath. I also have another project that builds a utility jar for use by both the EAR and EJB project. All projects extend a base project with the usual info defined (developers names etc.). This single inheritance forces me to duplicate the common dependency declarations in each subproject. Ideally I would like an include tag in the dependencies section. I have coded a workaround which allows for a space separated list of project files in the tag. e.g ../project.xml ../common_dependencies.xml The first file would be the parent project and the subsequent files would contain common dependencies. i.e. inherit from the parent and have dependencies composed from siblings. I will submit a patch for that functionality as soon as I get away from the corporate firewall. Please let me know if this sort of functionality has already been planned. TIA. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJBUILDER-8) generate-project goal does not generate relative paths
The following comment has been added to this issue: Author: Emmanuel Venisse Created: Thu, 18 Dec 2003 2:44 AM Body: My personal opinion is that ide project files are personal and they never add to a scm repository because each developer can work with his preferred ide. But if you have a correct patch that satisfy everyone, I can apply it. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MPJBUILDER-8 Here is an overview of the issue: - Key: MPJBUILDER-8 Summary: generate-project goal does not generate relative paths Type: Bug Status: Open Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-jbuilder-plugin Assignee: Emmanuel Venisse Reporter: Charles Overbeck Created: Wed, 17 Dec 2003 6:49 PM Updated: Thu, 18 Dec 2003 2:44 AM Environment: All platforms Description: A JBuilder project file created by JBuilder stores paths relative to the project file's directory, unless the path is on a different root. The jbuilder-maven plugin always stores absolute paths. Relative paths are stored so that if the whole project, JPX and source, is checked in to a Version Control System and another user pulls the project to another machine, the path references will continue to work. For example, I pulled Jelly into c:\Documents and Settings\coverbeck\jbproject\jelly, and ran maven jbuilder:generate-project. For the outpath, the generated JPX file had: If I manually create the same setting with the JBuilder GUI when the JPX is located in C:\Documents and Settings\coverbeck\jbproject\jelly, the resulting JPX will have: DefaultPath, DocPath, SourcePath, and TestPath all have the same issue. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: maven-plugins/xdoc/src/plugin-resources/templates downloads.xml
Ok, so what does this page generate under 1.0? Junk? Shouldn't there be a check to see if it has a value, and not generate the file if it doesn't? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Jason van Zyl <[EMAIL PROTECTED]> wrote on 18/12/2003 06:23:00 PM: > On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote: > > So this is not a 1.0 compatible plugin anymore?? > > It still is, none of the default behaviour has changed. I'm just adding > stuff that >1.0 will be able to take advantage of. > > > -- > > dIon Gillard, Multitask Consulting > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM: > > > > > jvanzyl 2003/12/17 13:40:37 > > > > > > Added: xdoc/src/plugin-resources/templates downloads.xml > > > Log: > > > o little template for an automatically created download page. This is > > going > > > to require an addition to the POM of a distributionUrl for > > end-users. > > > > > > Revision ChangesPath > > > 1.1 maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml > > > > > > Index: downloads.xml > > > === > > > > > > > > > > > > > > > > > > > > > Downloads > > > > > > > > > > > > > > > > > > #set ($url = $escape.getText($project.distributionUrl)) > > > $url > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: maven-plugins/xdoc/src/plugin-resources/templatesdownloads.xml
Jason, This is what I'm doing in the multichanges plugin: it automatically lists all releases. I have not committed it yet but the way I planned to compute the URL was by: [Remote repo URL] + [group id] + [type (new POM element)] + [artifact id] + [version] + [type extension - directly computed from type] The best would be to ask the artifact handler (whatever that is) to return the URL by passing to it the different parameters. I see that you wish to have a distributionURL. Would that be optional and default to the strategy above if not specified? Thanks -Vincent > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 18 December 2003 08:23 > To: Maven Developers List > Subject: Re: cvs commit: maven-plugins/xdoc/src/plugin- > resources/templatesdownloads.xml > > On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote: > > So this is not a 1.0 compatible plugin anymore?? > > It still is, none of the default behaviour has changed. I'm just adding > stuff that >1.0 will be able to take advantage of. > > > -- > > dIon Gillard, Multitask Consulting > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM: > > > > > jvanzyl 2003/12/17 13:40:37 > > > > > > Added: xdoc/src/plugin-resources/templates downloads.xml > > > Log: > > > o little template for an automatically created download page. This > is > > going > > > to require an addition to the POM of a distributionUrl for > > end-users. > > > > > > Revision ChangesPath > > > 1.1 maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml > > > > > > Index: downloads.xml > > > === > > > > > > > > > > > > > > > > > > > > > Downloads > > > > > > > > > > > > > > > > > > #set ($url = $escape.getText($project.distributionUrl)) > > > $url > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven project.properties
dion2003/12/18 00:02:48
Modified:.Tag: MAVEN-1_0-BRANCH project.properties
Log:
Add back simian
Revision ChangesPath
No revision
No revision
1.51.2.4 +1 -1 maven/project.properties
Index: project.properties
===
RCS file: /home/cvs/maven/project.properties,v
retrieving revision 1.51.2.3
retrieving revision 1.51.2.4
diff -u -r1.51.2.3 -r1.51.2.4
--- project.properties9 Dec 2003 23:29:41 - 1.51.2.3
+++ project.properties18 Dec 2003 08:02:48 - 1.51.2.4
@@ -79,7 +79,7 @@
maven.plugins.includes = */project.xml
#maven.plugins.excludes = examples/**
# TODO [RC2] - simian plugin is broken
-maven.plugins.excludes = examples/**,simian/**
+maven.plugins.excludes = examples/**
maven.get.jars.baseUrl = http://www.ibiblio.org/maven
maven.bootstrap.dir = ${basedir}/bootstrap
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-faq-plugin fixes and svg plugin
On Wed, 2003-12-17 at 20:34, Martin van den Bemt wrote: > I'll have a look tomorrow.. Cool, thanks a bunch. > Mvgr, > Martin > > On Wed, 2003-12-17 at 16:35, Jason van Zyl wrote: > > On Tue, 2003-12-16 at 20:04, Martin van den Bemt wrote: > > > It just hit me, a solution for this can be to generate a faq page with > > > links to all faq pages found (if there are multiple). > > > Is that usefull ? > > > Or should we just remove the FAQs entry? > > > > Martin, can you try the FAQ plugin in conjunction with the new xdoc > > plugin and see what you get? It doesn't seem to be generating for me and > > I would like to release the FAQ plugin and the new version of the xdoc > > plugin. > > > > > Mvgr, > > > Martin > > > > > > On Tue, 2003-12-09 at 01:58, Jason van Zyl wrote: > > > > On Mon, 2003-12-08 at 19:41, Martin van den Bemt wrote: > > > > > I just added a fix for all the outstanding issues related to the > > > > > maven-faq-plugin (linked the issues together, to see how that works > > > > > out). So if someone could commit that and cut a release, that would be > > > > > cool. > > > > > > > > Applied, can you also make a patch for changes.xml and I will cut a > > > > little release for you. > > > > > > > > > Also It would be nice to have the batik 1.5 jars uploaded to ibiblio, so > > > > > I can release my svg plugin (see http://www.mvdb.org/maven/plugins/svg). > > > > > The jars are in my home on codehaus. > > > > > > > > > > It is issue mavenupload-39 on jira.codehaus.org > > > > > > > > > > Mvgr, > > > > > Martin > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: maven-plugins/xdoc/src/plugin-resources/templates downloads.xml
On Thu, 2003-12-18 at 01:19, [EMAIL PROTECTED] wrote: > So this is not a 1.0 compatible plugin anymore?? It still is, none of the default behaviour has changed. I'm just adding stuff that >1.0 will be able to take advantage of. > -- > dIon Gillard, Multitask Consulting > Blog: http://blogs.codehaus.org/people/dion/ > > > > [EMAIL PROTECTED] wrote on 18/12/2003 08:40:37 AM: > > > jvanzyl 2003/12/17 13:40:37 > > > > Added: xdoc/src/plugin-resources/templates downloads.xml > > Log: > > o little template for an automatically created download page. This is > going > > to require an addition to the POM of a distributionUrl for > end-users. > > > > Revision ChangesPath > > 1.1 maven-plugins/xdoc/src/plugin-resources/templates/downloads.xml > > > > Index: downloads.xml > > === > > > > > > > > > > > > > > Downloads > > > > > > > > > > > > #set ($url = $escape.getText($project.distributionUrl)) > > $url > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
