cvs commit: maven/src/plugins-build/war/xdocs changes.xml
michal 2003/07/01 01:43:52
Modified:src/plugins-build/war plugin.jelly project.xml
src/plugins-build/war/xdocs changes.xml
Log:
Iterating over artifacts not deps
Revision ChangesPath
1.20 +4 -2 maven/src/plugins-build/war/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/war/plugin.jelly,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- plugin.jelly 19 Jun 2003 14:01:51 - 1.19
+++ plugin.jelly 1 Jul 2003 08:43:51 - 1.20
@@ -125,8 +125,10 @@
/ant:copy
/j:if
-j:forEach var=dep items=${pom.dependencies}
-
+
+
+j:forEach var=lib items=${pom.artifacts}
+ j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar' }
ant:copy todir=${webapp.build.lib}
file=${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}/
1.12 +10 -1 maven/src/plugins-build/war/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven/src/plugins-build/war/project.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- project.xml 13 Apr 2003 02:32:15 - 1.11
+++ project.xml 1 Jul 2003 08:43:51 - 1.12
@@ -28,6 +28,15 @@
/roles
/developer
developer
+ nameMichal Maczka/name
+ idmichal/id
+ email[EMAIL PROTECTED]/email
+ organizationDimatics/organization
+ roles
+roleJava Developer/role
+ /roles
+/developer
+developer
nameVincent Massol/name
idvmassol/id
email[EMAIL PROTECTED]/email
@@ -35,7 +44,7 @@
roles
roleJava Developer/role
/roles
-/developer
+/developer
/developers
dependencies/
/project
1.5 +6 -0 maven/src/plugins-build/war/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven/src/plugins-build/war/xdocs/changes.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- changes.xml 13 Apr 2003 02:35:12 - 1.4
+++ changes.xml 1 Jul 2003 08:43:51 - 1.5
@@ -11,6 +11,12 @@
action dev=dion type=fix due-to=Ben Hogan
Allow war file to be updated
/action
+ action dev=michal type=fix
+Iterating artifacts not depedencies
+ /action
+ action dev=michal type=add
+Added deploy, deploy-snapshot and install-snapshot goals
+ /action
/release
release version=1.3 date=2002-04-08
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/ear/xdocs changes.xml
michal 2003/07/01 01:45:14
Modified:src/plugins-build/ear plugin.jelly
src/plugins-build/ear/xdocs changes.xml
Log:
o Iterating over artifacts not deps
o Added deploy, deploy-snapshot and install-shapshot goals
Revision ChangesPath
1.9 +77 -21maven/src/plugins-build/ear/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/ear/plugin.jelly,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- plugin.jelly 17 Jun 2003 17:57:47 - 1.8
+++ plugin.jelly 1 Jul 2003 08:45:13 - 1.9
@@ -6,6 +6,7 @@
xmlns:license=license
xmlns:util=jelly:util
xmlns:x=jelly:xml
+ xmlns:artifact=artifact
!--==--
@@ -48,7 +49,8 @@
excludes=**/META-INF/application.xml/
!-- include marked dependencies --
- j:forEach var=dep items=${pom.dependencies}
+ j:forEach var=lib items=${pom.artifacts}
+j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('ear.bundle')=='true'}
ant:echoBundling: ${dep.type}/ant:echo
j:choose
@@ -57,8 +59,8 @@
ant:include name=${dep.artifact}/
/ant:fileset
/j:when
-j:when test=${dep.type == 'war' }
- ant:fileset dir=${maven.repo.local}/${dep.artifactDirectory}/wars/
+j:when test=${dep.type == 'ear' }
+ ant:fileset dir=${maven.repo.local}/${dep.artifactDirectory}/ears/
ant:include name=${dep.artifact}/
/ant:fileset
/j:when
@@ -103,20 +105,7 @@
/goal
- !--==--
- !-- Install the ear in the local repository --
- !--==--
- goal name=ear:install
-prereqs=ear:ear
-description=Install the ear in the local repository
-
-ant:property name=maven.ear.install.dir
- value=${maven.repo.local}/${pom.artifactDirectory}/ears/
-ant:mkdir dir=${maven.ear.install.dir}/
-ant:copy file=${maven.build.dir}/${maven.final.name}.ear
- tofile=${maven.ear.install.dir}/${maven.final.name}.ear/
-
- /goal
+
!--==--
!-- Creates ear descriptor - application.xml file--
@@ -132,14 +121,15 @@
x:element name=application
x:element name=display-name${maven.ear.displayname}/x:element
-j:forEach var=dep items=${pom.dependencies}
+j:forEach var=lib items=${pom.artifacts}
+ j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('ear.bundle')=='true'}
j:choose
- j:when test=${dep.type=='war'}
+ j:when test=${dep.type=='ear'}
x:element name=module
x:element name=web
x:element name=web-uri${dep.getArtifact()}/x:element
-x:element
name=context-root${dep.getProperty('ear.appxml.war.context-root')}/x:element
+x:element
name=context-root${dep.getProperty('ear.appxml.ear.context-root')}/x:element
/x:element
/x:element
/j:when
@@ -158,8 +148,74 @@
/j:forEach
/x:element
/j:file
-
+
/goal
+
+
+
+ !--==--
+ !-- Install the ear in the local repository --
+ !--==--
+ goal name=ear:install
+prereqs=ear:ear
+description=Install the ear in the local repository
+
+ artifact:install
+artifact=${maven.build.dir}/${maven.final.name}.ear
+type=ear
+project=${pom}/
+
+ /goal
+
+ !--==--
+ !-- Install the snapshot version of the ear in the local repository --
+ !--==--
+ goal name=ear:install-snapshot
+prereqs=ear:ear
+description=Install the snapshot version of the ear in the local
repository
+
+ artifact:install-snapshot
+artifact=${maven.build.dir}/${maven.final.name}.ear
+type=ear
+project=${pom}/
+
+ /goal
+
+ !--==--
+ !-- Deploys the ear
RE: cvs commit: maven/src/plugins-build/war/xdocs changes.xml
Sorry! I'll try to be clearer next time. I will also fix/improve those comments It was a fix for Issue#518 regards Michal -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 11:52 AM To: 'Maven Developers List' Subject: RE: cvs commit: maven/src/plugins-build/war/xdocs changes.xml Hi Michal, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 01 July 2003 10:44 To: [EMAIL PROTECTED] Subject: cvs commit: maven/src/plugins-build/war/xdocs changes.xml [snip] Index: changes.xml === RCS file: /home/cvs/maven/src/plugins-build/war/xdocs/changes.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- changes.xml 13 Apr 2003 02:35:12 - 1.4 +++ changes.xml 1 Jul 2003 08:43:51 - 1.5 @@ -11,6 +11,12 @@ action dev=dion type=fix due-to=Ben Hogan Allow war file to be updated /action + action dev=michal type=fix +Iterating artifacts not depedencies + /action Can you please explain better in changes.xml why you did that (the reason for it)? There are also some typos: Iterating over artifacts and dependencies. Also, I think the rule is to have new changes added first in the list so that the list always contains the latest changes first. Thanks -Vincent - 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/src/plugins-build/war/xdocs changes.xml
I am working on other problems with war plugin to completely fix Issue 518 ... so don't worry Vincent! mm -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 12:47 PM To: 'Maven Developers List' Subject: RE: cvs commit: maven/src/plugins-build/war/xdocs changes.xml Sorry! I'll try to be clearer next time. I will also fix/improve those comments It was a fix for Issue#518 regards Michal -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 11:52 AM To: 'Maven Developers List' Subject: RE: cvs commit: maven/src/plugins-build/war/xdocs changes.xml Hi Michal, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 01 July 2003 10:44 To: [EMAIL PROTECTED] Subject: cvs commit: maven/src/plugins-build/war/xdocs changes.xml [snip] Index: changes.xml === RCS file: /home/cvs/maven/src/plugins-build/war/xdocs/changes.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- changes.xml 13 Apr 2003 02:35:12 - 1.4 +++ changes.xml 1 Jul 2003 08:43:51 - 1.5 @@ -11,6 +11,12 @@ action dev=dion type=fix due-to=Ben Hogan Allow war file to be updated /action + action dev=michal type=fix +Iterating artifacts not depedencies + /action Can you please explain better in changes.xml why you did that (the reason for it)? There are also some typos: Iterating over artifacts and dependencies. Also, I think the rule is to have new changes added first in the list so that the list always contains the latest changes first. Thanks -Vincent - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/ear plugin.jelly
michal 2003/07/01 07:57:57
Modified:src/plugins-build/ear/xdocs goals.xml changes.xml
src/plugins-build/ear plugin.jelly
Log:
Fixes for MAVEN-518.
Artifact processing in the plugin was slightly changed and now it supports jar
overriding mechanism
Revision ChangesPath
1.3 +14 -3 maven/src/plugins-build/ear/xdocs/goals.xml
Index: goals.xml
===
RCS file: /home/cvs/maven/src/plugins-build/ear/xdocs/goals.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- goals.xml 8 May 2003 20:53:55 - 1.2
+++ goals.xml 1 Jul 2003 14:57:56 - 1.3
@@ -26,15 +26,26 @@
description
Installs the generated ear file into the local repository
/description
+ /goal
+ goal
+nameear:install-snapshot/name
+descriptionInstall the snapshot version of the ear in the local
repository/description
+ /goal
+ goal
+nameear:deploy/name
+descriptionDeploy the ear to the remote repository(ies)/description
/goal
-/goals
-
-goal
+ goal
+nameear:deploy-snapshot/name
+descriptionDeploy the snapshot version of the ear to the remote
repository(ies)/description
+ /goal
+ goal
nameear:generate-ear-descriptor/name
description
Generates application.xml
file based on information from POM
/description
/goal
+/goals
/body
/document
1.5 +8 -6 maven/src/plugins-build/ear/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven/src/plugins-build/ear/xdocs/changes.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- changes.xml 1 Jul 2003 08:45:14 - 1.4
+++ changes.xml 1 Jul 2003 14:57:56 - 1.5
@@ -6,16 +6,18 @@
/properties
body
release version=1.2 date=in CVS
- action dev=vmassol type=fix
-Removed warning about application.xml being added twice to the
-EAR.
- /action
action dev=michal type=fix
-Iterating artifacts not depedencies
+Fixes for MAVEN-518.
+Artifact processing in the plugin
+was slightly changed and now it supports jar overriding mechanism
/action
action dev=michal type=add
-Added deploy, deploy-snapshot and install-snapshot goals
+Added 'deploy', 'deploy-snapshot' and 'install-snapshot' goals
/action
+ action dev=vmassol type=fix
+Removed warning about application.xml being added twice to the
+EAR.
+ /action
/release
release version=1.1 date=2003-05-08
action dev=michal type=add
1.10 +35 -20maven/src/plugins-build/ear/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/ear/plugin.jelly,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- plugin.jelly 1 Jul 2003 08:45:13 - 1.9
+++ plugin.jelly 1 Jul 2003 14:57:57 - 1.10
@@ -52,25 +52,40 @@
j:forEach var=lib items=${pom.artifacts}
j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('ear.bundle')=='true'}
- ant:echoBundling: ${dep.type}/ant:echo
- j:choose
-j:when test=${dep.type == 'jar'}
- ant:fileset dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
- ant:include name=${dep.artifact}/
- /ant:fileset
-/j:when
-j:when test=${dep.type == 'ear' }
- ant:fileset dir=${maven.repo.local}/${dep.artifactDirectory}/ears/
-ant:include name=${dep.artifact}/
- /ant:fileset
-/j:when
-j:when test=${dep.type == 'ejb' }
- ant:fileset dir=${maven.repo.local}/${dep.artifactDirectory}/ejbs/
-ant:include name=${dep.artifact}/
- /ant:fileset
-/j:when
- /j:choose
-/j:if
+
+ !--
+
+ We know that this dep wants to be bundled.
+ We should bundle only jars, wars and ejbs
+
+ --
+
+ !-- I want to have
+ j:if test=${dep.type == 'jar' or dep.type == 'war' or dep.type ==
'ejb'}
+ but jexl sucks so I have to write extra 10 lines...
+ --
+
+ j:set var=bundle value=false/
+ j:if test
cvs commit: maven/src/plugins-build/war/xdocs changes.xml goals.xml
michal 2003/07/01 07:58:52
Modified:src/plugins-build/war plugin.jelly
src/plugins-build/war/xdocs changes.xml goals.xml
Log:
Fixes for MAVEN-518.
Artifact processing in the plugin was slightly changed and now it supports jar
overriding mechanism
Revision ChangesPath
1.21 +14 -11maven/src/plugins-build/war/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/war/plugin.jelly,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- plugin.jelly 1 Jul 2003 08:43:51 - 1.20
+++ plugin.jelly 1 Jul 2003 14:58:52 - 1.21
@@ -49,21 +49,24 @@
/ant:fileset
/j:if
- j:forEach var=dep items=${pom.dependencies}
+ j:forEach var=lib items=${pom.artifacts}
+j:set var=dep value=${lib.dependency}/
+j:set var=bundle value=false/
j:if test=${dep.getProperty('war.bundle.jar')=='true'}
ant:echo
DEPRECATION WARNING:
-Use : war.bundle instead of war.bundle.jar
+Use : war.bundle instead of war.bundle.jar
/ant:echo
- ant:lib dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
-ant:include name=${dep.artifact}/
- /ant:lib
+ j:set var=bundle value=true/
/j:if
-j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar' }
- ant:lib dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
-ant:include name=${dep.artifact}/
+j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar'}
+ j:set var=bundle value=true/
+/j:if
+j:if test=${bundle == 'true'}
+ ant:lib dir=${lib.file.parent}
+ant:include name=${lib.file.name}/
/ant:lib
-/j:if
+/j:if
/j:forEach
j:if test=${sourcesPresent == 'true'}
@@ -131,7 +134,7 @@
j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar' }
ant:copy todir=${webapp.build.lib}
-
file=${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}/
+ file=${lib.path}/
/j:if
j:if test=${dep.getProperty('war.bundle.jar')=='true'}
ant:echo
@@ -139,7 +142,7 @@
Use : war.bundle instead of war.bundle.jar
/ant:echo
ant:copy todir=${webapp.build.lib}
- file=${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}/
+ file=${lib.path}/
/j:if
/j:forEach
1.6 +7 -4 maven/src/plugins-build/war/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven/src/plugins-build/war/xdocs/changes.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- changes.xml 1 Jul 2003 08:43:51 - 1.5
+++ changes.xml 1 Jul 2003 14:58:52 - 1.6
@@ -8,15 +8,18 @@
body
release version=1.4 date=in CVS
- action dev=dion type=fix due-to=Ben Hogan
-Allow war file to be updated
- /action
action dev=michal type=fix
-Iterating artifacts not depedencies
+Fixes for MAVEN-518.
+Artifact processing in the plugin
+was slightly changed and now
+it supports jar overriding mechanism
/action
action dev=michal type=add
Added deploy, deploy-snapshot and install-snapshot goals
/action
+ action dev=dion type=fix due-to=Ben Hogan
+Allow war file to be updated
+ /action
/release
release version=1.3 date=2002-04-08
1.2 +12 -0 maven/src/plugins-build/war/xdocs/goals.xml
Index: goals.xml
===
RCS file: /home/cvs/maven/src/plugins-build/war/xdocs/goals.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- goals.xml 24 Jan 2003 03:46:24 - 1.1
+++ goals.xml 1 Jul 2003 14:58:52 - 1.2
@@ -20,6 +20,18 @@
descriptionInstall the war in the local repository/description
/goal
goal
+namewar:install-snapshot/name
+descriptionInstall the snapshot version of the war in the local
repository/description
+ /goal
+ goal
+namewar:deploy/name
+descriptionDeploy the war to the remote repository(ies)/description
+ /goal
+ goal
+namewar:deploy
cvs commit: maven/src/plugins-build/artifact/xdocs - New directory
michal 2003/06/29 04:57:08 maven/src/plugins-build/artifact/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy DeployRequest.java DeployTool.java
michal 2003/06/29 04:57:40
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions
DeployException.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java DeployBean.java
DeployRequestBuilder.java ArtifactDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
HttpDeployer.java FtpDeployer.java
SFtpDeployer.java ScpDeployer.java
FileDeployer.java Deployer.java
GenericSshDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/deploy
DeployRequest.java DeployTool.java
Added: src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions
UnsupportedProtocolException.java
TransferFailedException.java
WrongParameterException.java
src/plugins-build/artifact/xdocs protocols.xml examples.xml
index.xml tags.xml navigation.xml
authentification.xml properties.xml changes.xml
security.xml .cvsignore
Removed: src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions
UnsupportedProtocolDeployException.java
Log:
Code clean-up and docs provided
Revision ChangesPath
1.2 +3 -3
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions/DeployException.java
Index: DeployException.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions/DeployException.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DeployException.java 17 Jun 2003 22:06:00 - 1.1
+++ DeployException.java 29 Jun 2003 11:57:39 - 1.2
@@ -58,11 +58,11 @@
/**
- *
+ * Root class for all exception thrown by Deployers
* @author a href=[EMAIL PROTECTED]Michal Maczka/a
* @version $Id$
*/
-public class DeployException extends Exception
+public abstract class DeployException extends Exception
{
private final String message;
private final Throwable cause;
1.1
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/exceptions/UnsupportedProtocolException.java
Index: UnsupportedProtocolException.java
===
package org.apache.maven.deploy.exceptions;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Maven must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*Apache Maven, nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
RE: Deploy API (artifact plugin)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 6:16 AM To: Maven Developers List Subject: RE: Deploy API (artifact plugin) I think I've asked this before, but AFAIK, distributionSiteare not related AT ALL to maven.repo.central. Last time you asked: siteAddressmaven.apache.org/siteAddress siteDirectory/www/maven.apache.org//siteDirectory This is the web site address and directory, not a repo??? :) I was sure that you just wanted to get sure that I use distributionSite and distributionDirectory. distributionSite is not described in http://maven.apache.org/reference/project-descriptor.html While distributionDirectory: Optional. The directory on the web server where the final distributions will be published. This is used when the distributions are deployed (the word deployed is a hyper link which points to site plugin) I though that final distributions are the distribution of artifacts delivered by projects: jars, javadoc, project src zipped, Now I see I finaly understand that you might want e.g to publish distribution of entire project at sourceforge... and not to deploy to any repository. If I am still wrong: can you then explain briefly the difference? I want to centralized the code which does remote copying of the files And I see now that distribution requires special handling ... I will/want to change my code to support it. BTW: For the moment I have tested my API with username, user password kept in properties file. I think such approach is not acceptable. You can use command line to pass properties to maven: maven war:deloy -Dmaven.repo.ibiblio.password = ** This is already better ... but still not perfect. I will try to implement/use(if I find one) simple Prompter which will ask to type your password (eventually to enter other required parameters which are missing) regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New 'reactor' plugin
I also need it!
Just in case you find it useful/worthed to put to this plugin:
I often use such generic goal (bit modified here, hope that it still
works)
goal
name=reactor:for-all
maven:reactor
basedir=${basedir}/..
includes=${includes}
excludes=${excludes}
goals=${goals}
banner=Building
ignoreFailures=false
/
/goal
Then from command line
maven reactor:for-all -Dgoals=jar:install-snapshot
I find it very useful.
Michal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 9:19 AM
To: [EMAIL PROTECTED]
Subject: New 'reactor' plugin
I've just added this plugin as it has come in handy when working with
multiple projects in my day job.
I haven't yet add the site aggregation I was hoping to have done by now.
The plan is to allow for multiple strategies for implementing site
aggregation:
1) independent sites, ala db.apache.org and subprojects with templated
navigation
2) aggregated site where site docs are copied to
masterProject/target/docs/subprojectName at completion
3) custom aggregation
If anyone wants to help, let me know
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Aligning plugin artifacts with normal projects
We also need it for documentation. Its quite common for people to ask 'what property do I set to do' because there are so many undocumented properties. If there was a metadata file that described plugin properties, it could be used to generate the xdocs. There is one. It's called plugin.properties, and it can be used to generate the xdocs :-) The reason the documentation is lacking is noone has been willing to do it. -- I think we soon will need more flexibility with documentation of properties. Sorry for being ridiculous (I know even English documentation su..) I suppose that we might need also localized documentation of the properties (translation) and possibly also definition of some constrains for those properties. If we have it: we can finally imagine that somebody will write a GUI front-end to maven which will dynamically create user interface. I really would prefer to use maven integrated with my Eclipse :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Summary
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 3:08 PM
To: Maven Developers List
Subject: Plugin Summary
Hi,
I'll do the Plugin Summary again as a few people missed it and I
probably didn't explain myself clearly.
As far as plugin property access I am proposing:
${plugins.short-plugin-id.property}
Across the board in all plugins for values even for values that belong
to a particular plugin. So something like:
${plugins.antlr.srcDir}
Inside and outside the Antlr plugin.
Users would then override the properties using the same exact notation
where:
plugins.antlr.srcDir = /path
+1
As far as the structure of the plugin, I propose what Mark H. Wilkinson
suggested where we use different directories to distinguish between
build time and runtime. So the structure would look something like:
plugin
src/
plugin-resources/
plugin-runtime/
project.properties | run time
maven.xml |
project.properties |
maven.xml| build time
After the 1.0 release these things will never change.
Never say never ;)
But with the
separation now in place and for clarity and uniformity and ease of
documentation I think would be a good thing.
I propose:
plugin
src/
main/
resources/
java/
runtime/
project.properties | run time
maven.xml |
test/
resources/
java/
project.properties |
maven.xml| build time
xdocs/
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: New 'reactor' plugin
Dion!
I just looked at your description ... you already did it!
Great!
Michal
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 10:18 AM
To: 'Maven Developers List'
Subject: RE: New 'reactor' plugin
I also need it!
Just in case you find it useful/worthed to put to this plugin:
I often use such generic goal (bit modified here, hope that it still
works)
goal
name=reactor:for-all
maven:reactor
basedir=${basedir}/..
includes=${includes}
excludes=${excludes}
goals=${goals}
banner=Building
ignoreFailures=false
/
/goal
Then from command line
maven reactor:for-all -Dgoals=jar:install-snapshot
I find it very useful.
Michal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 9:19 AM
To: [EMAIL PROTECTED]
Subject: New 'reactor' plugin
I've just added this plugin as it has come in handy when working with
multiple projects in my day job.
I haven't yet add the site aggregation I was hoping to have done by now.
The plan is to allow for multiple strategies for implementing site
aggregation:
1) independent sites, ala db.apache.org and subprojects with templated
navigation
2) aggregated site where site docs are copied to
masterProject/target/docs/subprojectName at completion
3) custom aggregation
If anyone wants to help, let me know
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
-
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: New 'reactor' plugin
aggregate:build, aggregate:site [3] aggregator? mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy API (artifact plugin)
I would avoid the command line passed password. It is much less secure on unix than the password kept in a file. Command line can be seen by simple ps commands, or e.g. linux systems store the in the /proc filesystem. It should be used only from command files. incze I want to support all 3 possiblites: a)files b)command line parameters c) ask the user to enter the password (this is just plan at the moment) In fact I would need to make tricks to support a) and not to support b) as this is build-in in Maven so I am not going to block this possibility It will be nice to explain in documentaion all security risks. They cleary are platform depended (e..g files containing passwords are bad idea under MS Windows) mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy API (artifact plugin)
-Original Message- From: Martin Skopp [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 8:40 AM To: Maven Developers List Subject: Re: Deploy API (artifact plugin) On Wed, 2003-06-25 at 15:20, Michal Maczka wrote: I have progressed with Deployer API. Wow, that *really* looks good... #list of repositories to which we will deploy maven.repo.repos= R1, R2, R3, R4, ibiblio Is there really need for this property? I am just afraid of users forgetting to add to this property which will raise question on the mailinglist Possible reaons from my point of view: a) convenience for Michal :-) He does not need to loop over all properties check for a maven.repo.* match... I think that looping over project properties is quite dangerous. If you use project inheritance, sometimes you might be interested in overriding some properties of parent project. In this case you cannot switch off any repository defined in parent project, And you should not be aware of them. But you are 100% right that it should be simpler. That's why I asked for comments, hoping that somebody will have an idea how to simplify. BTW: It's even more complicated then I have described last time. Silently I assume existence of default (central repository). Some setting of this repository are matching /distributionDirectory /distributionSite Tags in POM This repository is silently named central. It's clear that in POM there is no place for some properties of this repository (like username, password, passpharse of private key, proxy host etc). Other settings used this repository are currently described in (BTW: why they are there? It's very hard to find them!) http://maven.apache.org/reference/plugins/jar/properties.html Namely: maven.repo.central maven.repo.central.directory maven.username maven.remote.group I will try to hack my code to make it backward compatible ... but among those settings you won't find e.g. user's password. I need to know it. :( For the moment using my (poor!!) naming convention you can use: #(don't have to use it if tag /distributionSite was used in POM maven.repo.central=www.apache.org #(don't have to use it if tag /distributionSite was used) maven.repo.central.directory= maven.repo.central.username maven.repo.central.group maven.repo.central.password maven.repo.central.passphrase maven.repo.central.privatekey maven.repo.central.port maven.repo.central.proxy.host maven.repo.central.proxy.port maven.repo.central.proxy.username maven.repo.central.proxy.password I think that it is more consistent...but way too complicated. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: maven/src/plugins-build/artifact project.xml
SCP has really pure functionality comparing to SFTP. I wanted to write poor. (Spell checkers:) ) mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy DeployRequest.java
michal 2003/06/25 08:25:19
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
FtpDeployer.java SFtpDeployer.java ScpDeployer.java
FileDeployer.java HttpDeployer.java
GenericSshDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java DeployBean.java
src/plugins-build/artifact/src/main/org/apache/maven/deploy
DeployRequest.java
Added: src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DeployRequestBuilder.java
Removed: src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
MavenDeployRequest.java
Log:
Code cleanup
Revision ChangesPath
1.4 +5 -5
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java
Index: FtpDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FtpDeployer.java 24 Jun 2003 22:22:54 - 1.3
+++ FtpDeployer.java 25 Jun 2003 15:25:18 - 1.4
@@ -95,7 +95,7 @@
public void deploy(DeployRequest request) throws DeployException
{
String username = request.getUser();
-String password = request.getPass();
+String password = request.getPassword();
String host = request.getHost();
FTPClient ftp = new FTPClient();
@@ -159,13 +159,13 @@
// Use passive mode as default because most of us are
// behind firewalls these days.
ftp.enterLocalPassiveMode();
-String workingDir = request.getOutputDir();
-String filename = request.getOutputFile();
+String workingDir = request.getDestDir();
+String filename = request.getDestFile();
System.out.println(Working directory + workingDir);
System.out.println(Filename: + filename);
ftp.makeDirectory(workingDir);
ftp.changeWorkingDirectory( workingDir);
-ftp.storeFile(filename, new FileInputStream(request.getInputFile()));
+ftp.storeFile(filename, new FileInputStream(request.getSrcFile()));
ftp.logout();
}
catch (FTPConnectionClosedException e)
1.3 +21 -35
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/SFtpDeployer.java
Index: SFtpDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/SFtpDeployer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SFtpDeployer.java 25 Jun 2003 12:33:11 - 1.2
+++ SFtpDeployer.java 25 Jun 2003 15:25:18 - 1.3
@@ -67,7 +67,7 @@
import com.jcraft.jsch.SftpException;
/**
- * An SSH2 SFTP deployer
+ * An SSH2/SFTP deployer
*
* @author Michal Maczka
* @version $Revision$ $Date$
@@ -76,8 +76,8 @@
{
public final static String PROTOCOL = sftp://;;
-public final static String SFTP_CHANNEL = sftp;
-
+private final static String SFTP_CHANNEL = sftp;
+private static final int S_IFDIR = 0x4000;
/**
* @see Deployer#project
@@ -96,7 +96,7 @@
}
catch (NumberFormatException e)
{
-throw new DeployException(For sftp protocol remote group should be an
integer);
+throw new DeployException(SFTP deployer: remote group should be an
integer);
}
Session session = getSession(request);
@@ -107,10 +107,9 @@
channel.connect();
// iterate over all directories in the path. try to create
// directory
-String[] dirs = StringUtils.split(request.getOutputDir(), /);
+String[] dirs = StringUtils.split(request.getDestDir(), /);
for (int i = 0; i dirs.length; i++)
-{
-System.out.println(processing: + dirs[i]);
+{
try
{
SftpATTRS attrs = channel.stat(dirs[i]);
@@ -122,9 +121,7 @@
else
{
throw new DeployException(
-Remote path:
-+ request.getOutputDir()
-+ is not correct
cvs commit: maven/src/plugins-build/artifact project.xml
michal 2003/06/24 15:22:55
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
FtpDeployer.java FileDeployer.java
HttpDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
MavenDeployRequest.java
src/plugins-build/artifact/src/main/org/apache/maven/deploy
DeployRequest.java DeployTool.java
src/plugins-build/artifact project.xml
Added: src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SFtpDeployer.java
Removed: src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SshDeployer.java
Log:
Changed SCP Deployer to SFTP deployer. I am done with functionality
(except of Http Deployer)
Now I will test it deeper and assure that everything works.
Revision ChangesPath
1.3 +11 -7
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java
Index: FtpDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FtpDeployer.java 19 Jun 2003 22:02:36 - 1.2
+++ FtpDeployer.java 24 Jun 2003 22:22:54 - 1.3
@@ -75,15 +75,20 @@
/**
* An FTP deployer based on the FTPClient in the Commons Net package.
*
+ * Proxy server for FTPClient is not supported:
+ * [EMAIL PROTECTED] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18039}
+ *
* @author a href=mailto:[EMAIL PROTECTED]Jason van Zyl/a
- *
+ * @author a href=[EMAIL PROTECTED]Michal Maczka/a
* @version $Id$
- *
- * @todo account for username and password.
+ *
+ *
*/
public class FtpDeployer extends AbstractDeployer
{
-
+
+public final static String PROTOCOL = ftp://;;
+
/**
* Description of the Method
*/
@@ -140,8 +145,7 @@
}
__main : try
-{
-System.out.println(username: ' + username +' password: '+
password+');
+{
if (ftp.login(username.trim(), password.trim()) == false)
{
ftp.logout();
1.4 +3 -1
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FileDeployer.java
Index: FileDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FileDeployer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FileDeployer.java 20 Jun 2003 15:24:52 - 1.3
+++ FileDeployer.java 24 Jun 2003 22:22:54 - 1.4
@@ -71,6 +71,8 @@
public class FileDeployer implements Deployer
{
+public final static String PROTOCOL = file://;
+
/**
* @see org.apache.maven.fetch.fetchers.Fetcher#fetchUrl(java.lang.String,
java.io.OutputStream)
*/
1.2 +2 -1
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/HttpDeployer.java
Index: HttpDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/HttpDeployer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HttpDeployer.java 17 Jun 2003 22:05:59 - 1.1
+++ HttpDeployer.java 24 Jun 2003 22:22:54 - 1.2
@@ -87,6 +87,7 @@
public class HttpDeployer extends AbstractDeployer
{
+public final static String PROTOCOL = http://;;
/**
* Description of the Method
*/
1.1
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/SFtpDeployer.java
Index: SFtpDeployer.java
===
package org.apache.maven.deploy.deployers;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list
RE: private jar dependencies
-Original Message-
From: dion gillard [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 5:35 AM
To: [EMAIL PROTECTED]
Subject: Re: private jar dependencies
Michal Maczka wrote:
There is one more mean for realizing such scenario which was not
mentioned
here:
jar overriding mechanism (or more generally artifact overriding
mechanism).
I am personally for dropping the jar overriding mechanism.
and for replacing them with such fake remote repository as Aslak has
described.
Big, big -1 on this. I have a real need for the jar override facility.
We have maven users who run common sql through db2. they each have their
own db2 release, and MUST use the jar file that corresponds to their db2
install.
So they just override version? Not paths?
I am surly +1 for allowing overriding version.
This is also a must from the perspective of transitive dependencies
There must be some way of setting the preferred version or artifacts
Even if they are not listed as dependencies in project.xml
But we have two kinds of overrides:
maven.jar.artifactId = [path]
maven.jar.artifactId = [version]
First of all it's just heuristic guessing if user has overridden version or
path. And sometimes this guessing can fail (even ofen).
Secondly the version with [path] overriding is against maven philosophy of
forcing users to keep artifact in repositories.
Say that users have unversion artifacts inside his project (e.g in the
${basedir}/lib directory). They want to quickly switch to maven.
Maven should help them, but such help can be also resolved outside of maven
core using special fetchers.
Say you use fetcher which will during download convert paths like
/groupId/jars/artifactId-version.jar to ${basedir}/lib/artifactId.jar.
So after first run of such fetcher the local repository will be populated
with those jars. After some time when this operation was performed by all
team members the lib directory can be erased.
So -1 on first kind of overriding but +1 on second.
I also think that we should support per project repositories (they are in
practice threaten as another remote repository). This will allow easier
transition for project using e.g. ant to maven.
This will make the implementation cleaner.
And less functional.
There is a lot of places in maven where the fact that artifact was
overriden
is simply ignored.
This is a bug and should be fixed. Before 1.0
This feature probably is not used so often but surly plugins like
war, ear, eclipse are not aware of the fact that artifact can be
overriden!
and what they do is something like:
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type
=='jar' }
ant:lib
dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
ant:include name=${dep.artifact}/
/ant:lib
/j:if
So basiclly they require that artifact must be in local repository.
Any artifact thats listed as a dependency MUST be available in the local
repository.
Not really. If we use jar overriding with
maven.jar.artifactId = [path]
it can be anywhere.
[...]
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer DefaultArtifactDeployer.java
michal 2003/06/23 02:49:38
Modified:src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
Log:
Implemented 5 file method.
Revision ChangesPath
1.6 +119 -99
maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Index: DefaultArtifactDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DefaultArtifactDeployer.java 20 Jun 2003 15:24:52 - 1.5
+++ DefaultArtifactDeployer.java 23 Jun 2003 09:49:38 - 1.6
@@ -56,9 +56,7 @@
*/
import java.io.File;
-import java.io.FileWriter;
import java.io.IOException;
-import java.io.Writer;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
@@ -89,6 +87,15 @@
/**
* @see ArtifactDeployer#deploy(String, String, Project)
+ * This is 5 files version.
+ * It deploys (example):
+ * foo-20030620.124616.jar,
+ * foo-20030620.124616.jar.md5 ,
+ * foo-SNAPSHOT.jar
+ * foo-SNAPSHOT.jar.md5
+ * foo-snapshot-version
+ *
+ *
*/
public void deploy(String artifact, String type, Project project)
throws MavenException
@@ -100,7 +107,13 @@
getRepositoryPath(type, project, project.getCurrentVersion());
String repositoryFile =
getRepositoryFile(type, project, project.getCurrentVersion());
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
+
+String[] inputFilenames =
+{ file.getAbsolutePath(), md5File.getAbsolutePath()};
+
+String[] outputFilenames = { repositoryFile, repositoryFile + .md5 };
+
+doDeploy(inputFilenames, outputFilenames, repositoryPath, project);
}
/**
@@ -109,16 +122,35 @@
public void deploySnapshot(String artifact, String type, Project project)
throws MavenException
{
+
+String snapshotVersion = getSnapshotVersion();
File file = getFileForArtifact(artifact);
File md5File = createMD5Checksum(file);
+File snapshotVersionFile =
+createSnapshotVersionFile(file, snapshotVersion, project, type);
String repositoryPath =
getRepositoryPath(type, project, MavenConstants.SNAPSHOT_SIGNIFIER);
-String repositoryFile =
+
+String[] inputFilenames = new String[5];
+inputFilenames[0] = file.getAbsolutePath();
+inputFilenames[1] = file.getAbsolutePath();
+inputFilenames[2] = md5File.getAbsolutePath();
+inputFilenames[3] = md5File.getAbsolutePath();
+inputFilenames[4] = snapshotVersionFile.getAbsolutePath();
+
+String out1 =
getRepositoryFile(type, project, MavenConstants.SNAPSHOT_SIGNIFIER);
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
-doDeploy(file, md5File, project, repositoryPath, repositoryFile);
+String out2 = getRepositoryFile(type, project, snapshotVersion);
-}
+String[] outputFilenames = new String[5];
+outputFilenames[0] = out1;
+outputFilenames[1] = out2;
+outputFilenames[2] = out1 + .md5;
+outputFilenames[3] = out2 + .md5;
+outputFilenames[4] = project.getArtifactId() + -snapshot-version;
+doDeploy(inputFilenames, outputFilenames, repositoryPath, project);
+
+};
/**
* @see ArtifactDeployer#install(String, String, Project)
@@ -207,11 +239,10 @@
* @param snapshot
*/
private void doDeploy(
-File file,
-File md5File,
-Project project,
-String repositoryPath,
-String repositoryFile)
+String[] inputFilenames,
+String[] outputFilenames,
+String outputPath,
+Project project)
throws MavenException
{
@@ -247,60 +278,45 @@
System.out.println(
Will deploy to + repoArray.length + repo(s): + repos);
-
-
for (int i = 0; i repoArray.length; i++)
{
String repo = repoArray[i].trim();
System.out.println(Deploying to repo: + repo);
-MavenDeployRequest deployRequest =
-new MavenDeployRequest(
-repo,
-project,
-repo,
-file.getAbsolutePath(),
-repositoryPath,
-repositoryFile
War plugin
I am bit busy at the moment but hope to have time to work a bit on war plugin soon (hope to have it done before rc1 is out) There was a request to support bundling of TLD files in war archive. I am going to implement it. I am planning to set default directory for TLDS files accordingly to: http://developer.java.sun.com/developer/technicalArticles/javaserverpages/co de_convention/ so it will be context root/WEB-INF/tld/ and have property: maven.war.build.tld.dir which will allow to customize it I personally use following layout: context root/WEB-INF/tld/jstl/ context root/WEB-INF/tld/struts/ context root/WEB-INF/tld/foo/ for grouping certain taglibs. Such layout can be easily supported using groupId property of the dependency. Somebody else likes it? Maybe somebody knows better strategies? Any other types of artifact should be supported? Should we go down to the level of css, JavaScript files or even images (gifs, jpegs). I personally don't think so. I like the concept of web component dissussed some time ago. We can also think if we are going to have extra features like: appending tag libs dynamically to web.xml file. From the point of view of XML manipulation it is very simple. But then some extra metadata should be provided along with tlds dependency (like uri). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: War plugin
The location you've suggested is sensible, but personally I'd prefer if the tlds were delivered inside their jars. It seems more of a 'best practice' thing to do (eg it avoids problems with jars mismatching tlds) How nice! So you are suggesting that best practice is to use tag libs only inside jars and not to bother at all! mm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: War plugin
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 2:18 PM
To: 'Maven Developers List'
Subject: RE: War plugin
Tld bundling is supported right now by the war plugin. You can even put
them wherever you want provided it's under the webapp/ source directory.
I meant the bundling of tag descriptor files (tlds) defined as project
dependencies
dependency
groupIdstruts/groupId
artifactIdstruts-tiles/artifactId
version1.1-rc2/type
typetld/type
/dependency
In war plugin we have:
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type =='jar' }
ant:copy todir=${webapp.build.lib}
file=${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}/
/j:if
Such bundling is not supported for tlds.
But after reading Brian's post I suppose that it should not be supported at
all.
The JSP spec defines clean and more natural way of making it.
I'm not sure adding a tld property helps a lot. I personally think it
makes this simple plugin more complex.
For the moment war plugin is indeed almost a wrapper around Ant war task.
But I don't see anything wrong in making this plugin (or any other) more
powerful or highly customizable.
For example we can add validation of web.xml file to this plugin.
But I admit that this particular idea was __stupid__
Please forget about it!
[...]
regards
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: private jar dependencies
-Original Message-
From: Aslak Hellesøy [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 21, 2003 12:33 PM
To: Maven Developers List
Subject: Re: private jar dependencies
We're doing this in the http://www.nanocontainer.org/ project. Have a
look at:
Oops, this example is from xdoclet2 and not nanocontainer. Oh well.
http://tinyurl.com/ew5l (look at the end of the 1st property)
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet2/lib/
(this is our own local repo treated as a remote one)
Of course, if you're in a corporate environment, you should be able to
set up a real remote repository on an internal webserver, whihch is an
even cleaner solution.
Aslak
There is one more mean for realizing such scenario which was not mentioned
here:
jar overriding mechanism (or more generally artifact overriding mechanism).
I am personally for dropping the jar overriding mechanism.
and for replacing them with such fake remote repository as Aslak has
described.
This will make the implementation cleaner.
There is a lot of places in maven where the fact that artifact was overriden
is simply ignored.
This feature probably is not used so often but surly plugins like
war, ear, eclipse are not aware of the fact that artifact can be overriden!
and what they do is something like:
j:if test=${dep.getProperty('war.bundle')=='true' and dep.type
=='jar' }
ant:lib dir=${maven.repo.local}/${dep.artifactDirectory}/jars/
ant:include name=${dep.artifact}/
/ant:lib
/j:if
So basiclly they require that artifact must be in local repository.
I think that this assumption is correct and it is the idea of jar overriding
which is wrong.
Moreover there is no easy way of determining if artifact was overriden or
not (it is in maven-new, but that's different story)
So I am really +1 on scenario described by Aslak.
First time you start you maven -- artifact from fake remote repository
will appear in local repository.
And this forces you to __always__ keep repository layout which adheres to
maven standards. Even if this repository
is kept in CVS.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFC: Deployer properties
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2003 6:12 AM
To: Maven Developers List
Subject: Re: RFC: Deployer properties
Michal Maczka [EMAIL PROTECTED] wrote on 19/06/2003 10:48:48 PM:
Please comment this:
With new deployer API I am going to support deployment to many remote
repositories.
In reality many = 2 in most of the cases. But 21 ..
I am proposing to use following properties:
#the list of repositories. repo1, repo2 are aliases or nicknames of
repositories
maven.deploy.repos = repo1, repo2, ibiblio
What's the difference between deploy.repos and remote.repos. Shouldn't we
stick with remote as it's already being used?
I want to distinguish read-only repositories (like ibiblio for most for the
users) from repositories to which we will deploy artifacts.
I guess those lists can be different.
But maybe we can unify those things?
I mean having somethinh like
maven.remote.repos = repo1, repo2
maven.remote.repo1= http://www.ibiblio.org
maven.remote.repo2= ftp://frp.mycomany.com
maven.remote.repo2.writable = true
But this makes it more complicated. I don't want that!
I want that this is as simple as possible
(I think individual settings for each repository can be shared between
deployer and fetch)
maven.repo.repo1= ftp://www.foo.com
maven.repo.repo1.dir = /repository
maven.repo.repo1.username= foo
maven.repo.repo1.password= baa
maven.repo.repo1.remote.group= goo
maven.repo.repo2 = file:///c:/temp
maven.repo.repo2.directory = /repository
maven.deploy.repo.ibiblio = http://www.ibiblio.org
maven.deploy.repo.ibiblio.directory = /maven
Ditto.
For each repository following properties can be set ( I hope that names
are
selfexplaing):
maven.repo.${repo alias}.dir = /repository
maven.repo.${repo alias}.username= foo
maven.repo.${repo alias}.password= baa
maven.repo.${repo alias}.remote.group= goo
maven.repo.${repo alias}.port= 23
maven.repo.${repo alias}.privatekey= ./ssh/keys/somefile
maven.repo.${repo alias}.passphrase= baa
maven.repo.proxy=192.168.2.15
maven.repo.proxy.username= foo
maven.repo.proxy.password= foo
maven.repo.proxy.port= 81
Arent the set of properties that can be set deployer-specific, e.g. ssh
deployer needs stuff that filesystem deployer doesn't?
I hope that we can find common set of properties.
If not the configuration schema will get more complicated.
Thing is that this information is highly hierarchical.
I already see that we will need things like http proxy, socks proxy etc.
There is one special case:
In POM (project.xml) we have
...
siteAddressmaven.apache.org/siteAddress
siteDirectory/www/maven.apache.org//siteDirectory
This is the web site address and directory, not a repo???
Sure! Sorry it was mistake! I mean pom.distributionSite
pom.distributionDirectory
Note what deploy plugin does:
j:set var=distributionSiteX value=${pom.distributionSite}X/
j:choose
j:when test=${distributionSiteX != 'X'}
j:set var=siteAddress value=${pom.distributionSite}/
j:set var=siteDirectory value=${pom.distributionDirectory}/
/j:when
j:otherwise
j:set var=siteAddress
value='${context.getVariable(maven.repo.central)}'/
j:set var=siteDirectory
value='${context.getVariable(maven.repo.central.directory)}'/
/j:otherwise
/j:choose
In this case properties for this repository can be set
using alias central
so e.g.
maven.repo.central.username= foo
maven.repo.central.privatekey= ./ssh/keys/somefile
Isn't the central repo the 'main' remote one?
Nope.
This corresponds to properties described in
http://maven.apache.org/reference/plugins/jar/properties.html
See also example above.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer DefaultArtifactDeployer.java MavenDeployRequest.java
michal 2003/06/19 03:52:25
Modified:src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
MavenDeployRequest.java
Log:
Install goal fixed
Revision ChangesPath
1.3 +22 -12
maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Index: DefaultArtifactDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DefaultArtifactDeployer.java 17 Jun 2003 22:06:00 - 1.2
+++ DefaultArtifactDeployer.java 19 Jun 2003 10:52:25 - 1.3
@@ -142,7 +142,7 @@
}
/**
- * Istall given file in repsoitory
+ * Install given file in local repsoitory
* @param artifact the artifact file to insatall
* @param type The type of the artiafct
* @param project
@@ -156,22 +156,32 @@
String version)
throws MavenException
{
-String repositoryPath = getRepositoryPath(type, project, version);
+
try
-{
-String dest = getLocalRepository(project) + / + repositoryPath;
+{
+File file =
+new File(
+getLocalRepository(project),
+getRepositoryPath(type, project, version));
+
+if (!file.exists())
+{
+file.mkdirs();
+}
+file = new File(file, getRepositoryFile(type, project, version));
System.out.println(
-Copying: from ' + artifact + ' to: ' + dest + ');
-FileUtils.copyFile(new File(artifact), new File(dest));
+Copying: from ' + artifact + ' to: ' + file + ');
+FileUtils.copyFile(new File(artifact), file);
+
}
catch (IOException e)
{
String msg =
Cannot install file: '
-+ repositoryPath
++ artifact
+ '. Reason:
+ e.getMessage();
-throw new MavenException(msg);
+throw new MavenException(msg, e);
}
}
@@ -201,13 +211,13 @@
if (distSite != null distSite.length() 0)
{
project.getContext().setVariable(
-maven.deploy.default.url,
+maven.deploy.repo.central,
project.getDistributionSite());
project.getContext().setVariable(
-maven.deploy.default.dir,
+maven.deploy.repo.central.directory,
project.getDistributionDirectory());
-repos = default, + repos;
+repos = central, + repos;
}
String repositoryPath = getRepositoryPath(type, project, version);
1.2 +17 -11
maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/MavenDeployRequest.java
Index: MavenDeployRequest.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/MavenDeployRequest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MavenDeployRequest.java 17 Jun 2003 22:06:00 - 1.1
+++ MavenDeployRequest.java 19 Jun 2003 10:52:25 - 1.2
@@ -88,44 +88,49 @@
super();
String username =
(String) project.getContext().getVariable(
-maven.deploy. + repository + .username);
+maven.deploy.repo. + repository + .username);
System.out.println(repository + username: + username);
String password =
(String) project.getContext().getVariable(
-maven.deploy. + repository + .password);
+maven.deploy.repo. + repository + .password);
System.out.println(repository + password: ' + password + ');
String passphrase =
(String) project.getContext().getVariable(
-maven.deploy. + repository + .passphrase);
+maven.deploy.repo. + repository + .passphrase);
String privateKey =
(String) project.getContext().getVariable(
-maven.deploy. + repository + .privatekey);
+maven.deploy.repo. + repository + .privatekey);
String url =
(String) project.getContext().getVariable(
-maven.deploy. + repository + .url
RE: new Artifact plugin and WAR plugin war:install goal
I quickly committed latest version which has install goal fixed. Install snapshot should also work. So I guess functionality is matching the old code. But no problem fell free to use old install goal if you still have a problems. Michal P.S Note that war plugin haven't got deploy and deploy-snapshot install-snapshot goals before -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 12:33 PM To: 'Maven Developers List' Subject: new Artifact plugin and WAR plugin war:install goal Hi Michal, I've had a look at the source code for the new artifact plugin... and it is really proof-of-concept code at this stage and I'm totally sure there are lots of bugs (it is really far from production quality right now). I don't mind that but I do mind using it in our WAR plugin at this point in time. Especially as we're so close from a release. I'd like to restore the old war:install goal for the time being. Once the artifact plugin works we will then be able to swap for it. What do you think? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Klikaj!!! I skorzystaj!!! http://link.interia.pl/f1739 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Deployer properties
With new deployer API I am going to support deployment to many remote
repsoitories.
In reality many = 2 in most of the cases. But 21 ..
I am proposiing to use follwoing properties:
#the list of repositories. repo1, repo2 are aliases or nicknames of
repositories
maven.repo.deploy = repo1, repo2, ibiblio
maven.repo.repo1= ftp://www.foo.com
maven.repo.repo1.dir = /repository
maven.repo.repo1.username= foo
maven.repo.repo1.password= baa
maven.repo.repo1.remote.group= goo
maven.repo.repo2 = file:///c:/temp
maven.repo.repo2.directory = /repository
maven.repo.ibiblio = http://www.ibiblio.org
maven.repo.ibiblio.directory = /maven
etc.
For each repository following properties can be set ( I hope that names are
selfexplaing):
maven.repo.${repo alias}.dir = /repository
maven.deploy.repo.${repo alias}.username= foo
maven.repo.${repo alias}.password= baa
maven.repo.${repo alias}.remote.group= goo
maven.repo.${repo alias}.port= 23
maven.repo.${repo alias}.privatekey= ./ssh/keys/somefile
maven.repo.${repo alias}.passphrase= baa
maven.repo.proxy=192.168.2.15
maven.repo.proxy.username= foo
maven.repo.proxy.password= foo
maven.repo.proxy.port= 81
There is one special case:
In POM (project.xml) we have
...
siteAddressmaven.apache.org/siteAddress
siteDirectory/www/maven.apache.org//siteDirectory
...
In this case properties for this repository can be set
using alias central
so e.g.
maven.deploy.repo.central.dir = /repository
maven.deploy.repo.central.username= foo
maven.deploy.repo.central.privatekey= ./ssh/keys/somefile
Michal
P.S.
Am I right that we need just one proxy server?
I think repos setting and proxy server settings can be shared beween
deployer and fetch.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Deployer properties
Please comment this:
With new deployer API I am going to support deployment to many remote
repositories.
In reality many = 2 in most of the cases. But 21 ..
I am proposing to use following properties:
#the list of repositories. repo1, repo2 are aliases or nicknames of
repositories
maven.deploy.repos = repo1, repo2, ibiblio
(I think individual settings for each repository can be shared between
deployer and fetch)
maven.repo.repo1= ftp://www.foo.com
maven.repo.repo1.dir = /repository
maven.repo.repo1.username= foo
maven.repo.repo1.password= baa
maven.repo.repo1.remote.group= goo
maven.repo.repo2 = file:///c:/temp
maven.repo.repo2.directory = /repository
maven.deploy.repo.ibiblio = http://www.ibiblio.org
maven.deploy.repo.ibiblio.directory = /maven
etc.
For each repository following properties can be set ( I hope that names are
selfexplaing):
maven.repo.${repo alias}.dir = /repository
maven.repo.${repo alias}.username= foo
maven.repo.${repo alias}.password= baa
maven.repo.${repo alias}.remote.group= goo
maven.repo.${repo alias}.port= 23
maven.repo.${repo alias}.privatekey= ./ssh/keys/somefile
maven.repo.${repo alias}.passphrase= baa
maven.repo.proxy=192.168.2.15
maven.repo.proxy.username= foo
maven.repo.proxy.password= foo
maven.repo.proxy.port= 81
There is one special case:
In POM (project.xml) we have
...
siteAddressmaven.apache.org/siteAddress
siteDirectory/www/maven.apache.org//siteDirectory
...
In this case properties for this repository can be set
using alias central
so e.g.
maven.repo.central.username= foo
maven.repo.central.privatekey= ./ssh/keys/somefile
Michal
P.S.
Am I right that we need just one proxy server?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why is the java source directory named main for plugins?
I also think it is bit inconsistent. But think that the most consistent approach is / basedir main java resources aspects conf test java test-resources ... Michal P.S. I am not saying we should change anything ... -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 3:23 PM To: 'Maven Developers List' Subject: RE: Why is the java source directory named main for plugins? -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: 19 June 2003 15:02 To: Maven Developers List Subject: Re: Why is the java source directory named main for plugins? On Thu, 2003-06-19 at 06:32, Vincent Massol wrote: Hi, Why is the java source directory named main for plugins (instead of java)? /src/test /src/main Seem to make more sense as a pattern as the testing code is also 'java' code. Ok, my comment wasn't about whether the name made more sense or not about consistency. At present we use src/java everywhere else and everyone I know who uses maven also uses this convention. In cvs we also src/java for Maven... -Vincent Thanks -Vincent - 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] - Limit kredytowy nawet o 20% wyzszy, niz masz teraz. Sprawdz TSL+: http://link.interia.pl/f173e - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy DeployRequest.java DeployTool.java
michal 2003/06/19 15:02:37
Modified:src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
FtpDeployer.java FileDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
MavenDeployRequest.java
src/plugins-build/artifact/src/main/org/apache/maven/deploy
DeployRequest.java DeployTool.java
Log:
FTP, FILE deployers work. ssh(scp) on the way
Revision ChangesPath
1.2 +4 -4
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java
Index: FtpDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FtpDeployer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FtpDeployer.java 17 Jun 2003 22:05:59 - 1.1
+++ FtpDeployer.java 19 Jun 2003 22:02:36 - 1.2
@@ -91,8 +91,7 @@
{
String username = request.getUser();
String password = request.getPass();
-String host = request.getHost();
-
+String host = request.getHost();
FTPClient ftp = new FTPClient();
@@ -142,7 +141,8 @@
__main : try
{
-if (ftp.login(username, password) == false)
+System.out.println(username: ' + username +' password: '+
password+');
+if (ftp.login(username.trim(), password.trim()) == false)
{
ftp.logout();
break __main;
1.2 +18 -8
maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FileDeployer.java
Index: FileDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers/FileDeployer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FileDeployer.java 17 Jun 2003 22:05:59 - 1.1
+++ FileDeployer.java 19 Jun 2003 22:02:36 - 1.2
@@ -63,7 +63,6 @@
import org.apache.maven.deploy.DeployRequest;
import org.apache.maven.deploy.exceptions.DeployException;
-
/**
*
* @author a href=[EMAIL PROTECTED]Michal Maczka/a
@@ -76,16 +75,27 @@
* @see org.apache.maven.fetch.fetchers.Fetcher#fetchUrl(java.lang.String,
java.io.OutputStream)
*/
public void deploy(DeployRequest request) throws DeployException
-{
+{
try
{
-File inputFile = new File( request.getInputFile() );
-File outputFile = new File( request.getOutputDir(),
request.getOutputFile());
+File inputFile = new File(request.getInputFile());
+
+File outputFile =
+new File(request.getHost(), request.getOutputDir());
+
+if (! outputFile.exists())
+{
+ outputFile.mkdirs();
+}
+outputFile = new File( outputFile, request.getOutputFile());
+System.out.println(Copining from: + inputFile + to: +
outputFile);
+
+
FileUtils.copyFile(inputFile, outputFile);
}
catch (IOException e)
{
- throw new DeployException(Cannot copy file: + e.getMessage());
-}
-}
+throw new DeployException(Cannot copy file: + e.getMessage());
+}
+}
}
1.4 +20 -9
maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Index: DefaultArtifactDeployer.java
===
RCS file:
/home/cvs/maven/src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DefaultArtifactDeployer.java 19 Jun 2003 10:52:25 - 1.3
+++ DefaultArtifactDeployer.java 19 Jun 2003 22:02:37 - 1.4
@@ -205,35 +205,45 @@
// trick add special values to context for default repository;
String repos =
-(String) project.getContext().getVariable(maven.deploy.repos);
+(String) project.getContext().getVariable(maven.repo.repos);
+
+System.out.println( repos: + repos );
String distSite = project.getDistributionSite();
if (distSite != null distSite.length() 0)
{
project.getContext().setVariable(
-maven.deploy.repo.central
RE: Recent changes in war plugin
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two distinct
steps?
a) copying to build area (somewhere in target/ )
b) making a jar archive
For this release I want to add inclusion of tld files.
This (as any other such changes) requires the duplication of the code
between
war:war
war:webapp
goals
The other probles is that
war:war goal is not extendible in simple way.
I myself almost always are writing the preGoal for war:war which does:
preGoal name=war:war
ant:mkdir dir=${maven.war.src}/
ant:copy todir=${maven.war.src}
ant:fileset dir=${basedir}/src/webapp/
/ant:copy
/preGoal
The change which I am proposing means simpler and shorted plugin's code
but also minor performance increase. I think that there is more
advantages...
Michal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 1:32 AM
To: Maven Developers List
Subject: RE: Recent changes in war plugin
By this do you mean the war plugin??
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Michal Maczka [EMAIL PROTECTED] wrote on 17/06/2003 08:21:41 PM:
Thanks for pointing that!
I also realized that I did this change (bit unintentionally)
Not sure either if it should stay for release.
Any other problems with the plugin?
BTW:
This plugin has not yet reached release quality.
I still need to work on it before beta-10 is out..
mm
-Original Message-
From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 11:58 AM
To: [EMAIL PROTECTED]
Subject: Recent changes in war plugin
Hi Michal,
Last changes in war plugin seem suboptimal for
me.
I'm not sure that war artifact always needs version
name on it. Well, from one point of view it would be
nice to have versioned one if we are assembling ear.
But from other point of view if we just assemble web
app
versioned war is not cool...
=
[ Konstantin Pribluda ( ko5tik ) ]
Zu Verstärkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] für die Festanstellung.
Arbeitsort: Mainz
Skills: Programieren, Kentnisse in OpenSource-Bereich
[ http://www.pribluda.de ]
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 10:33 AM
To: 'Maven Developers List'
Subject: RE: Recent changes in war plugin
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 10:01
To: 'Maven Developers List'
Subject: RE: Recent changes in war plugin
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change
also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two
distinct
steps?
I don't think I like it. At least I would like to keep using the Ant war
task which does a lot of things your implementation will not be doing
right away. And we will benefit from any improvement to Ant war task.
What's so magical in ant war task?
As I get it it's just simple extension of jar task
which often prints stupid warning messages like:
Taken from ANT code -
if (deploymentDescriptor == null
|| !fu.fileNameEquals(deploymentDescriptor, file)
|| descriptorAdded) {
log(Warning: selected + archiveType
+ files include a WEB-INF/web.xml which will be
ignored
+ (please use webxml attribute to
+ archiveType + task), Project.MSG_WARN);
} else
--
Why web.xml should not be kept in src/webapp/WEB-INF?
What's so wrong in it? Why Ant dislikes this?
I don't see any benefits which we gain using this ant target.
And personally I think that as much as possible of the code should be done
in pure java - not in jelly with help of ant. I think that that's the
direction Maven should take.
This will increase quality of the code, speed and code reuse.
So from my point of view less dependencies on ant - better code.
So I'm -1 to drop usage of the Ant war task.
I'm -0 (maybe even -1) to always build in 2 steps
I'm +1 to add a goal or any other property to support building in 2
steps. For example:
- Define the following properties in war's plugin.properties file:
maven.war.src.extra = ${maven.build.dir}/war
- Modify plugin.jelly to:
war warfile=${maven.war.build.dir}/${maven.war.final.name}
webxml=${maven.war.webxml} update=true
[...]
j:if test=${SrcExtraDirExists == 'true'}
fileset dir=${maven.war.src.extra}/
/j:if
That's some idea...
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. This will solve a lot of problems (e.g. classloaders) But I am too extreme with this subject ... so please ignore me :) And personally I think that as much as possible of the code should be done in pure java - not in jelly with help of ant. I think that that's the direction Maven should take. This will increase quality of the code, speed and code reuse. So from my point of view less dependencies on ant - better code. I'm completely +1 with this. Why do you say that War.java is not java? It is java. But is has a lot of unnecessary stuff which makes plugins which are using ant more heavy. This price is worthed to pay as we can reuse a lot of nice ant's features. But if we are able in simple way to replace it with our own code which does the same but in better way - I think we should go for it. [...] BTW, I think identifying the web.xml file is a good idea as it allows you perform any kind of thing like validation, etc. Sure it is. We can even add a goal like war:validate-web-xml Note that in Ant you don't have standard properties which e.g. are pointing to location of your web.xml file. So Ant knows nothing about web.xml. In Maven we already have it. So we are already ahead with some conceptions and formalisms. I am sure this advantage will grow and we will be able to use it. You already do this with maven cactus plugin ... a lot of things is happening automatically. But if you have common set of classes which does a thing you can use it in maven-plugin, eclipse-plugin and in ant. You do not necessarily need to write code for ant and then try to reuse it. This was (as for me) one of the biggest problems with XDoclet1. But the lesson was learnt and Xdoclet2 will not have this limitation. BTW: Other thing I am trying to achieve is to centralize the generation of manifest file from POM. I am almost done with that. Will see how it overlaps with subject of this discussion. I don't know if I should always create a manifest file (physical file) or just an object in memory (String). Then manifest (file, object) can be used by jar, war and other plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New WAR changes problems
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 5:45 PM
To: 'Maven Developers List'
Subject: New WAR changes problems
Hi,
I have 2 problems with the new changes brought to the war plugin WRT
artifact deployment:
1/ When I run maven, I get:
Install deploy component is under development. I hope to have it finished
for tommorow.
Anomalies are expected. Sorry for that!
2/ The war:install goal fails to add the version to the artifact and no
artifact should go in the Maven repository without having a version in
its name.
With the previous implementation it was easy to add the version. However
with the new one:
artifact:install
artifact=${maven.war.build.dir}/${maven.war.final.name}
type=war
project=${pom}
/
there is no way to rename the war... One solution (not nice) would to
perform a copy prior to calling artifact:install.
It's different story here:
artifact:install is taking care to create repository root relative path,
file name (with version) using information taken from
POM and the artifact type (we will be able here to use RepositoryLayout
service from maven-new).
artifact:install
artifact=foo
type=war
project=${pom}
artifact:install
artifact=lkjlkjlkjlkjlklk
type=war
project=${pom}
will do the same. The original file name is simply ignored.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems of EJB plugin and Dependencies download
This is partially fixed in maven-new (Repository Layout Service)
So you can assign different layouts for different types.
E.g. for ejb it is (see layout-properties in maven-new/core/src/conf)
# EJB
ejb=${groupId}/ejbs/${artifactId}-${version}.jar
There is one more problem with ejbs.
There are not added to build class path.
This will be also fixed in maven-new (ArtifactHandlers)
but I would propose a temporary hack in maven-old and to hard code more
artifact type
which should be added to class path.
see org.apache.maven.DependencyClasspathBuilder.
Michal
P.S.
A workaround for 1st problem for ejbs is:
dependency
typeejbtype
jaractual file name /jar
/dependency
AFAIK There is no workaround for 2nd problem,
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 6:01 PM
To: 'Maven Developers List'
Subject: Problems of EJB plugin and Dependencies download
Hi,
The EJB plugin ejb:install goal installs its artifacts in
groupId/ejbs/artifactId-version.jar (note the jar extension).
However, the maven dependency resolver looks for a file named:
groupId/ejbs/artifactId-version.ejb (not the ejb extension)
Thus it fails to find the artifact...
Several solutions:
1/ All jar files (.ear, .jar, .war are considered of the jar type)
2/ The dependency resolver supports .jar extensions when using the ejb
type. In other words there is mapping between artifact type and
artifact extension instead of assuming extension = artifact type.
Currently the EJB, WAR and EAR plugins put their artifacts in
**/ejbs/**, **/wars/** and **/ears/**.
What do we do?
Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Newsowy portal INTERIA.PL http://link.interia.pl/f1735
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
This already exists in Ant: it's called manifest (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? It's about different thing. There is no central place in maven which maps POM to manifest attributes. We have duplicated code in JAR, EJB and WAR plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:46 PM To: 'Maven Developers List' Subject: RE: Recent changes in war plugin -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 12:44 To: 'Maven Developers List' Subject: RE: Recent changes in war plugin What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing If you keep using the Ant jar task and do not write a single line of java, then I'm 0. BTW, why would you need to write some java code? Nope. No Java code. [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. That's easy to fix by excluding it (same as what is done for the ear plugin). I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. Oh ok, so you're also saying that the Ant Jar/Zip tasks do nothing... I'm definitely -10 to reimplement the Jar task from Ant. I not going to reemployment them :) Don't worry. [...] No. I would continue to be -1 for a reimplementation of the Zip/Jar/War tasks in java. You seem to be missing that for every line of code you write instead of reusing: - you have to test it - you have to document it - you are upping the bar for any newcomer to participate to development (the more code the less easy it is usually) - you must maintain it - fix bugs - add new features that you had forgotten to add initially No! I am trying to say that development in Java is: a) simpler (tools, tools tools) b) faster (tools, tools, tools) c) simulates code reuse (much more than in jelly) d) the code is easier to test e) you can debug d) you know when any API changes breaks the code (compiler tells you) f) is simpler for newcomers (so bar is definitely not raised, as much more people knows java then jelly) d) resulting code is faster Surly jelly is nice for some things, but maintain the project of maven size developed in jelly is a nightmare.. I am definitely not going to change anything in Maven because of that. But I am sure that if more things were done in Java it will be better. Even/Because in Java we can use reuse code from ANT. And when Maven will have more java code (libraries like Bob's fetch ) it will be possible to reuse output of maven in other worlds. Ant can will profit. Nobody can ever reuse our jelly scripts. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 21:13 To: Maven Developers List Subject: RE: Recent changes in war plugin This already exists in Ant: it's called manifest (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? It's about different thing. There is no central place in maven which maps POM to manifest attributes. We have duplicated code in JAR, EJB and WAR plugins. I think we're talking about the same thing. You can have a jelly taglib that wraps the Ant manifest task. Hmm. Haven't thought of that... I think that jelly or velocity were born for that! I am using velocity at the moment. And want to give to user a chance to provide his own template. Can you take a look at \plugins-build\artifact\src\plugin-resources\templates\manifest.vm? Do you think it is possible to make the same with ant manifest task? Michal It's a pity that we have communicate via emails. Normalment on porrait aller au cafeteria pour disscuter :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems of EJB plugin and Dependencies download
I see 2 solutions: 1/ Add a property called classpathfalse/classpath and if found the said dependency is not added to the Classpath? or 2/ Define a list of well known artifact types. That would server 2 purposes: a- to know if the said dependency type should be added to the classpath b- to know what extension this type has I prefer 2. -Vincent Jason was saying that it will be possible to reuse some components of maven-new. If we are not going to make I can also propose two other options: 1) Add all artifacts to class path. I don't think people are using too many non jar like artifacts. Too many things in classspath makes no harm. Regarding your propositions: ad 1) -1 : I think that option with marking deps in POM..is bad. -1 ad 2) +1 I did it already with XML based configuration files sometimes ago. But think XML or even java properties are too heavy there. Why just not put it to Java code? Michal P.S. I would not rush with those changes for rc1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: maven/src/plugins-build/artifact/src/plugin-resources/templates manifest.vm
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 6:18 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: maven/src/plugins-build/artifact/src/plugin-
resources/templates manifest.vm
Generic code for:
- deployment of artifact to remote repositry
- installaton of artifact to local repository
This seems like code that is duplicating the repository and deploy
plugins. Why do we want a third way of doing this
This one is developed in pure Java + supports deployment to various types
of repositories. Soon it will support deployment to multiple repositories.
And I think it is easier to use it then other ones + the code is more
centralized. I hope to test it with junit. This was rather hard in case of
old plugins.
Can you please change the others to use this code if it works?
It is not yet fully finished. Once I will be sure that it works I am
planning to change other plugins.
For the moment I use war plugin as demonstration how this is supposed
to work from the point of other plugins, so if any body has some remarks...
let me know.
FYI:
package org.apache.maven.artifact.deployer.deploy;
is meant to be refactored. I think the best will be to make a sister
component of fetch in maven-new.
This code is not depending on any maven apis, and can be possibly reused
like does fetch component.
Package org.apache.maven.artifact.deployer;
Contains higher level API, which uses maven API and it is supposed to be
used in plugins.
[OT]
I am thinking about deploying java sources and javadocs to repository.
Any idea about naming convention of those artifacts? With maven-new it
will be easy to control, with maven-old it is not so easy.
I am thinking about:
/${groupId}/apis/${artitifactId}_api-${version}.jar (for javadocs)
/${groupId}/srcs/${artitifactId}_src-${version}.jar (for sources).
Any better ideas?
Other question is where is the best place for such functionality?
I think for javadoc it is javadoc plugin. But for sources?
Any hints what else can we deploy?
Other idea:
We have;
jar:jar
war:war
ear:ear
etc..
Wouldn't it be more consistent to have:
jar:archive
war:archive
ear:archive
javadoc:archive
java:src-archive
etc?
regards
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
Thanks for pointing that! I also realized that I did this change (bit unintentionally) Not sure either if it should stay for release. Any other problems with the plugin? BTW: This plugin has not yet reached release quality. I still need to work on it before beta-10 is out.. mm -Original Message- From: Konstantin Priblouda [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 11:58 AM To: [EMAIL PROTECTED] Subject: Recent changes in war plugin Hi Michal, Last changes in war plugin seem suboptimal for me. I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. But from other point of view if we just assemble web app versioned war is not cool... = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - 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: Recent changes in war plugin
It was mistake! will fix that Michal -Original Message- From: Kurt Schrader [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:36 PM To: Maven Developers List Subject: Re: Recent changes in war plugin I thought that we voted on this and decided that a war qould remained unversioned for easy deployment, but there would be a property to switch it to a versioned war. I am still -1 on making a versioned war the default behavior. -Kurt On Tue, 17 Jun 2003, Konstantin Priblouda wrote: I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glosuj na NIE! NIE dla oplat za otwarcie i prowadzenie rachunku! http://link.interia.pl/f173b - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/war plugin.jelly
michal 2003/06/17 10:50:16
Modified:src/plugins-build/war plugin.jelly
Log:
war archive creted in target directory is unversioned
Revision ChangesPath
1.18 +2 -5 maven/src/plugins-build/war/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/war/plugin.jelly,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- plugin.jelly 16 Jun 2003 14:40:25 - 1.17
+++ plugin.jelly 17 Jun 2003 17:50:16 - 1.18
@@ -27,11 +27,8 @@
/j:if
ant:property name=maven.war.final.name
- value=${maven.final.name}.war/
-
-ant:echofinal:${maven.final.name}/ant:echo
-
-ant:echoWAR final:${maven.war.final.name}/ant:echo
+ value=${pom.artifactId}.war/
+
/goal
!--==--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy - New directory
michal 2003/06/17 15:05:36 maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers - New directory
michal 2003/06/17 15:05:37 maven/src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Strange behavior of war plugin
My teammate has also strange problems with war plugin.
For him just java files are included in war.
FYI:
I am working on generic java code for installing and deploying artifacts and
generating manifest file. I am almost done with that
I am rewriting also WAR plugin to use this code.
I plan to build a war archive always in two steps:
1) copy web sources to assembly directory
2) jar this directory
I think that this will be cleaner and will simplify some things.
I hope that my changes will fix those strange bugs.
Michal
-Original Message-
From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2003 10:15 AM
To: [EMAIL PROTECTED]
Subject: Strange behavior of war plugin
Hi all,
I'm experiencing strange behaviour of war plugin.
It just stopped to include classes into war.
I' just using war:war, and here is maven -X output
---%
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/.maven/repository/odmg/jars with
patternSet{ includes: [odmg-3.0.jar] excludes: [] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/.maven/repository/cglib/jars with
patternSet{ includes: [cglib-rc2-1.0.jar] excludes: []
}
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/.maven/repository/dom4j/jars with
patternSet{ includes: [dom4j-1.4-dev-8.jar] excludes:
[] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/.maven/repository/commons-lang/jars
with patternSet{ includes: [commons-lang-1.0.1.jar]
excludes: [] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/.maven/repository/hibernate/jars with
patternSet{ includes: [hibernate-2.0-final.jar]
excludes: [] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/webgui/target/classes with
patternSet{ includes: [**/*.properties, **/*.class]
excludes: [**/package.html] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/webgui with patternSet{ includes:
[LICENSE.txt] excludes: [] }
[war] [DEBUG] ZipFileSet: Setup scanner in dir
/home/konstantin/webgui/src/web/WEB-INF with
patternSet{ includes: [web.xml] excludes: [] }
[war] Building war:
/home/konstantin/webgui/target/webgui.war
[war] [VERBOSE] adding directory META-INF/
[war] [VERBOSE] adding entry META-INF/MANIFEST.MF
[war] [VERBOSE] adding directory noframeapp/
%
I'm living off CVS, with today clear checkout.
Anybody seen this?
regards,
=
[ Konstantin Pribluda ( ko5tik ) ]
Zu Verstärkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] für die Festanstellung.
Arbeitsort: Mainz
Skills: Programieren, Kentnisse in OpenSource-Bereich
[ http://www.pribluda.de ]
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
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/src/plugins-build/artifact - New directory
michal 2003/06/16 07:25:47 maven/src/plugins-build/artifact - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org/apache - New directory
michal 2003/06/16 07:25:47 maven/src/plugins-build/artifact/src/main/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main/org - New directory
michal 2003/06/16 07:25:47 maven/src/plugins-build/artifact/src/main/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/plugin-resources - New directory
michal 2003/06/16 07:25:48 maven/src/plugins-build/artifact/src/plugin-resources - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/main - New directory
michal 2003/06/16 07:25:47 maven/src/plugins-build/artifact/src/main - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/plugin-resources/templates - New directory
michal 2003/06/16 07:25:48 maven/src/plugins-build/artifact/src/plugin-resources/templates - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/artifact/src/plugin-resources/templates manifest.vm
michal 2003/06/16 07:26:02
Added: src/plugins-build/artifact project.properties
plugin.properties .cvsignore project.xml
plugin.jelly
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
MavenAuthenticationInfo.java
DefaultArtifactDeployer.java DeployBean.java
ArtifactDeployer.java
src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer/deploy
SshDeployer.java HttpDeployer.java
AbstractDeployer.java Deployer.java
GenericAuthenticationInfo.java
AuthenticationInfo.java FtpDeployer.java
src/plugins-build/artifact/src/plugin-resources/templates
manifest.vm
Log:
Generic code for:
- deployment of artifact to remote repositry
- installaton of artifact to local repository
- manifest generation
Revision ChangesPath
1.1 maven/src/plugins-build/artifact/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
1.1 maven/src/plugins-build/artifact/plugin.properties
Index: plugin.properties
===
# ---
# P L U G I N P R O P E R T I E S
# ---
maven.artifact.manifest.extensions.add=false
maven.artifact.manifest.basedir=${plugin.dir}/plugin-resources/templates
maven.artifact.manifest.template=manifest.vm
1.1 maven/src/plugins-build/artifact/.cvsignore
Index: .cvsignore
===
target
velocity.log
maven.log
1.1 maven/src/plugins-build/artifact/project.xml
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
extend${basedir}/../project.xml/extend
pomVersion3/pomVersion
idmaven-artifact-plugin/id
nameMaven Artifact Plug-in/name
currentVersion1.0/currentVersion
description/
shortDescriptionJava Project Management Tools/shortDescription
urlhttp://maven.apache.org/reference/plugins/artifact//url
siteDirectory/www/maven.apache.org/reference/plugins/artifact//siteDirectory
repository
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:maven/src/plugins-build/artifact//connection
urlhttp://cvs.apache.org/viewcvs/maven/src/plugins-build/artifact//url
/repository
developers/
dependencies
dependency
groupIdmaven/groupId
artifactIdmaven/artifactId
versionSNAPSHOT/version
typejar/type
/dependency
dependency
groupIdcommons-io/groupId
artifactIdcommons-io/artifactId
version20030203.000550/version
typejar/type
/dependency
dependency
groupIdcommons-net/groupId
artifactIdcommons-net/artifactId
version1.0.0/version
typejar/type
/dependency
dependency
groupIdcommons-httpclient/groupId
artifactIdcommons-httpclient/artifactId
version2.0-beta1/version
typejar/type
/dependency
dependency
groupIdjsch/groupId
artifactIdjsch/artifactId
version0.0.9/version
typejar/type
/dependency
dependency
groupIdcommons-jelly/groupId
artifactIdcommons-jelly/artifactId
version20030310.073407/version
urlhttp://jakarta.apache.org/commons/jelly//url
typejar/type
/dependency
dependency
groupIdcommons-jelly/groupId
artifactIdcommons-jelly-tags-velocity/artifactId
version20030303.205659/version
typejar/type
/dependency
dependency
groupIdvelocity/groupId
artifactIdvelocity/artifactId
version1.3/version
typejar/type
/dependency
/dependencies
/project
1.1 maven/src/plugins-build/artifact/plugin.jelly
Index: plugin.jelly
===
?xml version=1.0?
project
xmlns:j=jelly:core
xmlns:define=jelly:define
xmlns:ant=jelly:ant
xmlns:velocity=jelly:velocity
define:taglib uri=artifact
!-- For times the same bean is used
RE: JBoss plugin - new modifications
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2003 6:33 PM To: 'Maven Developers List' Subject: JBoss plugin - new modifications Hi, I don't like the way the jboss plugin works. ATM, it assumes the EAR and the jboss packaging is done in the same project. I think they are 2 separate activities that should be done in 2 separate projects. Why? Because packaging something in JBoss can mean packaging several modules: An EAR module, an EJB-JAR one, a WAR one, etc. and this won't work in a single project. Proposal: * Add a jboss.bundle property for dependencies. Example: dependencies dependency groupIdeverest/groupId artifactIdregistration/artifactId version1.0-SNAPSHOT/version typeear/type properties jboss.bundletrue/jboss.bundle /properties /dependency /dependencies * Keep only a jboss:package goal (remove the jboss:package-ear, etc) as they are no longer needed. The modules to package are now listed in the dependencies list If no one has any objection, I'll implement this in the coming 1-2 days. Thanks -Vincent Question: In this project for jboss all dependecies will be bundled, right? Why to mark them in special way? BTW: Are you going to make jboss plugin compatible with jboss 3.2x series? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/jar/src/plugin-resources - New directory
michal 2003/06/11 14:51:29 maven/src/plugins-build/jar/src/plugin-resources - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/jar/src/plugin-resources/templates - New directory
michal 2003/06/11 14:51:30 maven/src/plugins-build/jar/src/plugin-resources/templates - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/plugins-build/jar/src/plugin-resources/templates manifest.vm
michal 2003/06/11 14:51:38
Modified:src/plugins-build/jar project.xml plugin.jelly
Added: src/plugins-build/jar/src/plugin-resources/templates
manifest.vm
Log:
Added dynamic tag library for generation of manifest file
Revision ChangesPath
1.3 +17 -0 maven/src/plugins-build/jar/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven/src/plugins-build/jar/project.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.xml 9 Apr 2003 01:06:46 - 1.2
+++ project.xml 11 Jun 2003 21:51:37 - 1.3
@@ -15,4 +15,21 @@
urlhttp://cvs.apache.org/viewcvs/maven/src/plugins-build/jar//url
/repository
developers/
+
+ dependencies
+dependency
+ groupIdcommons-jelly/groupId
+ artifactIdcommons-jelly-tags-velocity/artifactId
+ version20030303.205659/version
+ properties
+classloaderroot.maven/classloader
+ /properties
+/dependency
+
+dependency
+ idvelocity/id
+ version1.3/version
+/dependency
+
+ /dependencies
/project
1.10 +41 -1 maven/src/plugins-build/jar/plugin.jelly
Index: plugin.jelly
===
RCS file: /home/cvs/maven/src/plugins-build/jar/plugin.jelly,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- plugin.jelly 10 Apr 2003 10:21:23 - 1.9
+++ plugin.jelly 11 Jun 2003 21:51:37 - 1.10
@@ -9,7 +9,47 @@
xmlns:resources=resources
xmlns:util=jelly:util
xmlns:doc=doc
- xmlns:m=maven
+ xmlns:m=maven
+ xmlns:define=jelly:define
+ xmlns:velocity=jelly:velocity
+
+
+
+
+
+ define:taglib uri=manifest
+
+ !--
+ |
+ | @destFile
+ |
+ --
+define:tag name=create-file
+
+j:set
+var=templatePath
+
value=${pom.getPluginContext('maven-jar-plugin').getVariable('plugin.dir')}/plugin-resources/templates/
+
+j:set
+var=mainclass
+
value=${$pom.getPluginContext('maven-java-plugin').getVariable('maven.jar.mainclass')}/
+
+j:set
+var=addExtension
+
value=${pom.getPluginContext('maven-jar-plugin').getVariable('${maven.jar.manifest.extensions.add')}/
+
+
+
+ ant:echoCreating MANIFEST file:${destFile}/ant:echo
+
+ velocity:merge
+name=${destFile}
+basedir=${templatePath}
+template=manifest.vm/
+/define:tag
+
+ /define:taglib
+
!-- == --
!-- J A R --
1.1
maven/src/plugins-build/jar/src/plugin-resources/templates/manifest.vm
Index: manifest.vm
===
Built-By=${user.name}
Created-By=Apache Jakarta Maven
Package=${pom.package}
Build-Jdk=${java.version}
Extension-Name=${pom.artifactId}
Specification-Version=${pom.specificationVersion}
Specification-Vendor=${pom.organization.name}
Specification-Title=${pom.shortDescription}
Implementation-Version=${pom.currentVersion}
Implementation-Vendor=${pom.organization.name}
Implementation-Vendor-Id=${pom.organization.identifier}
#if(${mainclass})
Main-Class=${mainclass}
#end
#if( ${addExtension})
#foreach($artifact in $project.artifacts)
#set($extensionList = $artifact.artifactId)
#end
Extension-List ${extensionList}
#foreach($artifact in $project.artifacts)
${dep.artifactId}-Extension-Name${dep.artifactId}
${dep.artifactId}-Implementation-Version${dep.version}
${dep.artifactId}-Implementation-URLhttp://www.ibiblio.org/maven${artifact.urlPath}
#end
#end
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sun JARs
Is there a chance for: JAXB JAX-RPC JAXB is distributed in Java Web Services Developer Pack http://java.sun.com/webservices/downloads/webservicespack.html which contains ... a lot of Jakarta products (tomcat, ant). Michal P.S. Is this list going to be approved as a whole or each item will be considered separately. If it is the second option...well at least it is nice to try. Michal -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 4:42 PM To: Maven Developers List Subject: Sun JARs Hi, I have updated the sun-licensing-journey.xml file in the xdocs/ directory. I have started an initial list of JARs that we would like permission to scrape off their sites. If anyone can add to this list that would be appreciated. Once the list is complete, I will send the list off to Tom Kincaid and await official approval to use the scraper. -- 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] -- Sportowy portal INTERIA.PL http://link.interia.pl/f1730 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Maven POM re-org to address deps + test issues
Hi Brett! I would rather prefer to make it differently. a) junit tests should be left as they are. (still no way to skip them!) b) For other types of tests (integration tests, stress tests etc.) we can make it similarly as it was done with Reports (plugable API): iuTests iuTestcactus/iuTest iuTesthttpUnit/iuTest iuTestdbunit/iuTest iuTestsurefire/iuTest (once Jason will finish it ;) ) /iuTests Each of those tests types will keep its own configuration settings etc and course the possibility of running e.g.just cactus tests will still remain. Then integration test can be even integrated with of reports. reports ... reportiutest/report /reports There is a lot of details which I skipped (for example resource processing for tests), but this is just a fresh idea. what you think? regards Michal -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 2:34 AM To: Maven Developers List Subject: [PROPOSAL] Maven POM re-org to address deps + test issues Hi, Based on the discussions about test levels and about isolating test, runtime and compile time dependencies, I thought about some changes to the POM that might help, and got a bit carried away ;) This is a work in progress with a few limitations discussed later, but I thought it might be a good starting point for a discussion to address some of the issues. Bear in mind I wrote this on the train at 7am this morning ;) What I propose is remove build/ and everything in it. Move nagEmailAddress/ to that level, and then add the following elements: sets set namerequired-name/name extends extendset-name/extend extendother-set-name/extend /extends src directory.../directory includes include.../include /includes excludes exclude.../exclude /excludes /src dependencies !-- as before -- /dependencies resources !-- as before -- /resources plugins !-- Default is include all -- includes include.../include /includes excludes exclude.../exclude /excludes /plugins properties !-- Actually put these into Jelly context (or Ant?) during processing of plugin -- property.namevalue/property.name /properties /set !-- repeat for test set, java set, JAXB set, cactus test set, performance test set, ... -- /sets Finally, you can includes/exclude sets from the command line to avoid processing certain sets: maven -Dexclude.sets=perf-test,integ-test or maven -Dinclude.sets=gen-jaxb,default Now the problems I see with it: * Not that comfortable with the extends syntax - bit too similar to POM inheritance. Could be used to fold subprojects. However, need a way to include deps and classpath built sources of other sets without duplication. Any thoughts on this? * This pattern allows multiple source trees. It does takes care of generated source (antlr, jaxb) more cleanly (source would be the descriptor files, then plugin uses addPath for java sources). However, could be used to have multiple java source trees for a real project. Maybe this is ok - let those who've demanded it have it, but perhaps display a warning every run that it is a bad practice :) * The specification of plugins does worry me a bit, but I don't see alternatives. Certain things should make use of new plugins automatically (some site related plugin should apply to all source trees), but others must be blocked out. Also, how does this fit with maven-new's structure? Cheers, Brett -- Web Developer f2 network ~ everything essential 02 8596 4437 - 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: Setting up Maven-New
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:26 PM To: [EMAIL PROTECTED] Subject: RE: Setting up Maven-New I know that Maven new is not really usable yet, I would say: it is really unusable ;) but the committers have got a setup that they can use to test their changes, right? I want to have this kind of setup, enabling me to evaluate Maven new. There is ongoing development in maven-new/core maven-new/fetcher etc... But as a whole it is still a puzzle box in 100 pieces, which needs to be assembled. If I have to create my own plugins, I want to make sure I use Maven new instead of Maven. Maven-new should be backward compatible (not sure if in 100% but close). So you can still write your plugins without looking at what is going on with maven-new In particular because I have seen better decomposition allowing me to e.g. extend the Project class and parse the project.xml myself. Certainly there are side effects of the decomposition made in maven-new which might result in such temptation to personalize your instance of maven. But if something is technicaly possible it does not necessarily mean that it should be applied/used. Michal Regards, Gino. -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:15 PM To: Maven Developers List Subject: RE: Setting up Maven-New AFAIK: maven-new is not yet usable. Michal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:09 PM To: [EMAIL PROTECTED] Subject: Setting up Maven-New Can someone guide me through the process of setting up and using Maven New? I always seem to get an XMLRPC exception upon execution of run-client -g, so I must be doing something wrong... On the client Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm pl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc cessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.classworlds.Launcher.launchStandard(Launcher.java:408) at com.werken.classworlds.Launcher.launch(Launcher.java:342) at com.werken.classworlds.Launcher.main(Launcher.java:470) Caused by: org.apache.xmlrpc.XmlRpcException: java.lang.NullPointerException at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(Xm lRpcClient ResponseProcessor.java:133) at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(Xml RpcClientR esponseProcessor.java:101) at org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:102) at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:187) at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:178) at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:172) at org.apache.maven.cli.CLI.doMain(CLI.java:116) at org.apache.maven.cli.CLI.main(CLI.java:83) ... 7 more On the server [DEBUG] Found a service descriptor for key: org.apache.maven.Maven [ERROR] Cannot start component lifecycle with role : org.apache.maven.Maven java.lang.NullPointerException at org.apache.maven.DefaultMaven.service(DefaultMaven.java;org/apache /maven/Pom InheritanceAspect.java[1k]:207) at org.apache.plexus.lifecycle.phase.ServicePhase.execute(ServicePhas e.java:24) at org.apache.plexus.lifecycle.AbstractLifecycleHandler.startLifecycl e(Abstract LifecycleHandler.java:145) at org.apache.plexus.service.repository.DefaultComponentRepository.st artCompone ntLifecycle(DefaultComponentRepository.java:426) at org.apache.plexus.service.repository.DefaultComponentRepository.lo okup(Defau ltComponentRepository.java:316) at org.apache.maven.server.XMLThing.execute(XMLThing.java:80) at org.apache.xmlrpc.XmlRpcWorker.invokeHandler(XmlRpcWorker.java:128) at org.apache.xmlrpc.XmlRpcWorker.execute(XmlRpcWorker.java:185) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:151) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:139) at org.apache.xmlrpc.WebServer$Connection.run(WebServer.java:773) at org.apache.xmlrpc.WebServer$Runner.run(WebServer.java:656) at java.lang.Thread.run(Thread.java:536) basedir is set to Maven Many thanks, Gino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
cvs commit: maven-new/core/src/test/org/apache/maven/artifact/handlers JarHandlerTest.java
michal 2003/05/30 08:13:43 Modified:core/src/test/org/apache/maven/artifact/handlers JarHandlerTest.java Log: Small typo fixed Revision ChangesPath 1.3 +2 -2 maven-new/core/src/test/org/apache/maven/artifact/handlers/JarHandlerTest.java Index: JarHandlerTest.java === RCS file: /home/cvs/maven-new/core/src/test/org/apache/maven/artifact/handlers/JarHandlerTest.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- JarHandlerTest.java 30 May 2003 15:12:34 - 1.2 +++ JarHandlerTest.java 30 May 2003 15:13:43 - 1.3 @@ -159,7 +159,7 @@ Classpath does not contain entry for: + testA, hasEntryForA); assertTrue( -Classpath does not contain entry for: + testA, +Classpath does not contain entry for: + testB, hasEntryForB); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-new/core/src/java/org/apache/maven/artifact/satisfy DefaultDependencySatisfier.java
michal 2003/05/30 03:13:26
Modified:core/src/java/org/apache/maven/artifact/satisfy
DefaultDependencySatisfier.java
Log:
added special threatment for unsatisfied overriden deps
Revision ChangesPath
1.8 +12 -5
maven-new/core/src/java/org/apache/maven/artifact/satisfy/DefaultDependencySatisfier.java
Index: DefaultDependencySatisfier.java
===
RCS file:
/home/cvs/maven-new/core/src/java/org/apache/maven/artifact/satisfy/DefaultDependencySatisfier.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- DefaultDependencySatisfier.java 29 May 2003 20:26:22 - 1.7
+++ DefaultDependencySatisfier.java 30 May 2003 10:13:26 - 1.8
@@ -129,6 +129,7 @@
I18NUtils.getMessage( remote.repository.disabled.warning ) );
}
+List failedOverridenDependencies = new ArrayList();
for ( Iterator i = project.getArtifacts().iterator(); i.hasNext(); )
{
Artifact artifact = (Artifact) i.next();
@@ -137,12 +138,10 @@
if ( artifact.exists() == false )
{
-// I think that we should stop here as this means
-// the user has made an error and build cannot continue
+
if (artifact.isFileOverridden())
{
- String msg = ;
- throw new UnsatisfiedDependencyException( msg );
+ failedOverridenDependencies.add( artifact );
}
failedDependencies.add( artifact );
@@ -171,6 +170,14 @@
}
}
+// If we have ovveriden dependicies which failed
+// we will not make any attempt to downaloed them
+if ( failedOverridenDependencies.isEmpty() == false )
+{
+throw new UnsatisfiedDependencyException(
+ createUnsatisfiedDependenciesMessage( failedDependencies
) );
+
+}
// If we have any failed dependencies then we will attempt to download
// them for the user if the remote repository is enabled.
if ( failedDependencies.isEmpty() == false remoteRepoEnabled online )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-new/core/src/test-input project.xml
michal 2003/05/30 03:27:42 Modified:core/src/test-input project.xml Log: Added code for testing experimental way of declaring properties Revision ChangesPath 1.2 +4 -0 maven-new/core/src/test-input/project.xml Index: project.xml === RCS file: /home/cvs/maven-new/core/src/test-input/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 26 Apr 2003 16:52:17 - 1.1 +++ project.xml 30 May 2003 10:27:42 - 1.2 @@ -80,6 +80,10 @@ artifactIdd2/artifactId version2.0/version urld2-url/url + properties +a.key=a.value +b.key=b.value + /properties /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-new/core/src/java/org/apache/maven/artifact/handlers JarHandler.java
michal 2003/05/30 04:26:53
Modified:core/src/java/org/apache/maven/project Dependency.java
Project.java
core/src/java/org/apache/maven MavenConstants.java
core/src/java/org/apache/maven/artifact/handlers
JarHandler.java
Added: core/src/test/org/apache/maven/artifact/handlers
JarHandlerTest.xml JarHandlerTest.java
Log:
Added experimental code for dependecy.kind
Revision ChangesPath
1.5 +31 -1 maven-new/core/src/java/org/apache/maven/project/Dependency.java
Index: Dependency.java
===
RCS file:
/home/cvs/maven-new/core/src/java/org/apache/maven/project/Dependency.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Dependency.java 29 May 2003 20:26:22 - 1.4
+++ Dependency.java 30 May 2003 11:26:52 - 1.5
@@ -80,6 +80,9 @@
/** The dependency type */
private String type;
+
+/** EXPERIMENTAL The dependecy kind (like global, runtime, compile )*/
+private String kind;
/** Flag to indicate the artifact is poorly named. */
//private boolean isPoorlyNamed = false;
@@ -287,6 +290,33 @@
this.type = type;
}
+/**
+ * Get the type of the dependency. If no type was set it is
+ * assumed that is of type codejar/code
+ *
+ * @return dependency type such as codejar/code or codewar/code
+ */
+public String getKind()
+{
+if ( kind == null || kind.trim().length() == 0 )
+{
+ return global;
+}
+return type;
+}
+
+/**
+ * Sets the dependency type such as compile or test
+ *
+ * @param type The type of dependency.
+ */
+public void setKind( String kind )
+{
+this.kind = kind;
+}
+
+
+
/**
* Debug string.
*
1.8 +53 -6 maven-new/core/src/java/org/apache/maven/project/Project.java
Index: Project.java
===
RCS file: /home/cvs/maven-new/core/src/java/org/apache/maven/project/Project.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Project.java 24 May 2003 18:30:26 - 1.7
+++ Project.java 30 May 2003 11:26:52 - 1.8
@@ -56,10 +56,6 @@
*
*/
-import org.apache.maven.Maven;
-import org.apache.maven.MavenConstants;
-import org.apache.plexus.util.StringUtils;
-
import java.io.File;
import java.util.ArrayList;
import java.util.HashMap;
@@ -70,12 +66,17 @@
import java.util.StringTokenizer;
import java.util.TreeSet;
+import org.apache.commons.lang.SystemUtils;
+import org.apache.maven.Maven;
+import org.apache.maven.MavenConstants;
+import org.apache.plexus.util.StringUtils;
+
/**
* @author a href=mailto:[EMAIL PROTECTED]Jason van Zyl/a
* @author a href=mailto:[EMAIL PROTECTED]Vincent Massol/a
* @author a href=mailto:[EMAIL PROTECTED]dIon Gillard/a
* @author a href=mailto:[EMAIL PROTECTED]Glenn McAllister/a
- *
+ * @author a href=mailto:[EMAIL PROTECTED]Michal Maczka/a
* @version $Id$
*
* @todo Change the file reference for the source POM to an URL.
@@ -87,6 +88,7 @@
private List dependencies;
public static final String CONTEXT_KEY = Project.class.getName();
+
/** Repository where this project is stored. */
private Repository repository;
@@ -188,6 +190,22 @@
* be retrieved by id.
*/
private Map dependencyMap;
+
+
+/**
+ * E X P E R I M E N T A L
+ * Classpath Map. There is one classpath for each of supported
+ * kinds of dependencies
+ *
+ * dependency
+ *...
+ * kindruntime | compile | test | global /kind
+ * dependency
+ *
+ */
+private Map classpathMap;
+
+
/** Artifact list. */
private List artifactList;
@@ -629,6 +647,35 @@
{
dependencyPaths.put( id, path );
}
+
+
+
+/**
+ * Add entry to given named classpath
+ *
+ * @param id Classpath id (like global, test, runtime, compile).
+ * @param path Classpath for the given dependency.
+ */
+public void addToClassPath( String id, String path )
+{
+String classpath = getClassPath( id );
+classpath = path + SystemUtils.PATH_SEPARATOR + classpath;
+classpathMap.put( id, classpath);
+}
+
+
+public String getClassPath( String id )
+{
+String classpath
RE: maven-new tests failing
My repository path does not start with ${maven.home}...so this problem did
not show up.
I have something like:
/repository
/maven
It seems like interpolation problem.
Michal
-Original Message-
From: Rafal Krzewski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 12:05 PM
To: Maven Developers List
Subject: Re: maven-new tests failing
Ben Walding wrote:
This stuff is in so much flux that I'd expect tests to fail on a regular
basis. That being said, attaching the output of test results would be a
good start.
target/test-reports/whichever ones failed
Ha! Didn't know about that one... (I'm not using Junit in my project
yet, tests are cool when you have them already :-()
Here you go...
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-new/core/src/java/org/apache/maven/util IOUtility.java
michal 2003/05/27 11:38:29
Added: core/src/java/org/apache/maven/util IOUtility.java
Log:
Added what Ben has forgotten
Revision ChangesPath
1.1 maven-new/core/src/java/org/apache/maven/util/IOUtility.java
Index: IOUtility.java
===
package org.apache.maven.util;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation and
*Apache Maven must not be used to endorse or promote products
*derived from this software without prior written permission. For
*written permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*Apache Maven, nor may Apache appear in their name, without
*prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*
*/
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
/**
* @author Ben Walding
* @version $Id: IOUtility.java,v 1.1 2003/05/27 18:38:29 michal Exp $
*/
public class IOUtility
{
protected static final int BUFFER_SIZE = 16384;
/**
* Transfers all remaining data in the input stream to the output stream
*
* Neither stream will be closed at completion.
**/
public static void transferStream(InputStream is, OutputStream os) throws
IOException
{
final byte[] buffer = new byte[BUFFER_SIZE];
while (true)
{
int bytesRead = is.read(buffer, 0, buffer.length);
if (bytesRead == -1)
{
break;
}
os.write(buffer, 0, bytesRead);
}
}
/**
* Closes an InputStream without throwing an IOException.
* The IOException is swallowed.
* @param in the input stream to close. If null, nothing is closed.
*/
public static final void close(InputStream in)
{
try
{
if (in != null)
{
in.close();
}
}
catch (IOException ioex)
{
//Do nothing
}
}
/**
* Closes an OutputStream without throwing an IOException.
* The IOException is swallowed.
* @param in the OutputStream to close. If null, nothing is closed.
*/
public static final void close(OutputStream out)
{
try
{
if (out != null)
{
out.close();
}
}
catch
