RE: Problems of EJB plugin and Dependencies download
Ok cool... pfeww... I'm lucky as I've implemented 2/ yesterday night (now in CVS) :-) Thanks -Vincent > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 19 June 2003 08:03 > To: Maven Developers List > Subject: Re: Problems of EJB plugin and Dependencies download > > I'm +0 on 2/ and -1 on 1/ > -- > dIon Gillard, Multitask Consulting > Blog: http://blogs.codehaus.org/people/dion/ > Work: http://www.multitask.com.au > > > "Vincent Massol" <[EMAIL PROTECTED]> wrote on 19/06/2003 02:01:04 AM: > > > Hi, > > > > The EJB plugin ejb:install goal installs its artifacts in > > /ejbs/-.jar (note the "jar" extension"). > > > > However, the maven dependency resolver looks for a file named: > > /ejbs/-.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 = . > > > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems of EJB plugin and Dependencies download
I'm +0 on 2/ and -1 on 1/ -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au "Vincent Massol" <[EMAIL PROTECTED]> wrote on 19/06/2003 02:01:04 AM: > Hi, > > The EJB plugin ejb:install goal installs its artifacts in > /ejbs/-.jar (note the "jar" extension"). > > However, the maven dependency resolver looks for a file named: > /ejbs/-.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 = . > > 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] >
[jira] Created: (MAVEN-505) upload stxx 1.2 to repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-505 Here is an overview of the issue: - Key: MAVEN-505 Summary: upload stxx 1.2 to repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Simon Lau Created: Wed, 18 Jun 2003 9:03 PM Updated: Wed, 18 Jun 2003 9:03 PM Description: This can be found at http://sourceforge.net/project/showfiles.php?group_id=48439 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-504) upload xmlunit 1.0 to repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-504 Here is an overview of the issue: - Key: MAVEN-504 Summary: upload xmlunit 1.0 to repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Simon Lau Created: Wed, 18 Jun 2003 9:01 PM Updated: Wed, 18 Jun 2003 9:01 PM Description: This can be found at http://sourceforge.net/project/showfiles.php?group_id=23187&release_id=155097 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-503) upload strutstestcase 2.0 to repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-503 Here is an overview of the issue: - Key: MAVEN-503 Summary: upload strutstestcase 2.0 to repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Simon Lau Created: Wed, 18 Jun 2003 8:58 PM Updated: Wed, 18 Jun 2003 8:58 PM Description: This can be found at http://sourceforge.net/project/showfiles.php?group_id=39190 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/src/java/org/apache/maven/cli CLIManager.java
bwalding2003/06/18 15:35:13 Modified:src/java/org/apache/maven/cli CLIManager.java Log: Clarifying comments Revision ChangesPath 1.9 +5 -3 maven/src/java/org/apache/maven/cli/CLIManager.java Index: CLIManager.java === RCS file: /home/cvs/maven/src/java/org/apache/maven/cli/CLIManager.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- CLIManager.java 18 Jun 2003 02:48:08 - 1.8 +++ CLIManager.java 18 Jun 2003 22:35:13 - 1.9 @@ -94,9 +94,11 @@ options = new Options(); /* - * XXX the usage here looks broken / confusing. - * If .create is static, then it can't be using the longopt / description state - * Which then raises the question, are we misusing OptionBuilder? + * Although this looks broken and confusing, it is by design (commons-cli, not ours). + * It only presents an issue if this can be called in multiple threads in the + * same classloader simultaneously. Which it can't, as this is a static initializer. + * The new commons-cli fixes the Builder pattern to work in a better way (OptionBuilder + * no longer static). */ options.addOption( OptionBuilder .withLongOpt( "nobanner" ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-490) Jelly Errors (maven.log full of them)
The following issue has been updated: Updater: Steve Ovens (mailto:[EMAIL PROTECTED]) Date: Wed, 18 Jun 2003 5:40 PM Comment: Here is my log from doing a "maven clean". Changes: Attachment changed from to maven.log - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-490&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-490 Here is an overview of the issue: - Key: MAVEN-490 Summary: Jelly Errors (maven.log full of them) Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Versions: 1.0-beta-10 Assignee: Reporter: Nick Minutello Created: Sat, 14 Jun 2003 2:02 PM Updated: Wed, 18 Jun 2003 5:40 PM Description: Building my current project seems to generate 10,000's of Jelly AntTag errors. Building Maven itself generates a few. Here are some examples ERROR org.apache.commons.jelly.tags.ant.AntTag - Class org.apache.commons.jelly.tags.core.IfTag doesn't support the nested "available" element. ERROR org.apache.commons.jelly.tags.ant.AntTag - Class com.werken.werkz.jelly.ProjectTag doesn't support the nested "path" element. WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: td into an Ant task, data type or property There are some other errors with stack traces - I will attach two macen.logs - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems of EJB plugin and Dependencies download
Michal, I have committed a quick patch for EJB dependency handling so that extensions for the EJB type artifacts is ".jar" and not ".ejb". I hope I haven't broken anything. I have tested it successfully on my current project. Thanks -Vincent > -Original Message- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 18 June 2003 22:52 > To: Maven Developers List > Subject: RE: Problems of EJB plugin and Dependencies download > > > I see 2 solutions: > > > > 1/ Add a property called false 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs changes.xml
vmassol 2003/06/18 14:50:14
Modified:src/java/org/apache/maven/project Dependency.java
xdocschanges.xml
Added: src/java/org/apache/maven/project ArtifactType.java
Log:
Added dependency type mapping to support extensions different than the artifact
type. This fixes the EJB plugin issue (MAVEN-196).
Revision ChangesPath
1.34 +29 -10maven/src/java/org/apache/maven/project/Dependency.java
Index: Dependency.java
===
RCS file: /home/cvs/maven/src/java/org/apache/maven/project/Dependency.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- Dependency.java 12 Apr 2003 00:02:03 - 1.33
+++ Dependency.java 18 Jun 2003 21:50:14 - 1.34
@@ -58,6 +58,7 @@
/**
* @author mailto:[EMAIL PROTECTED]">Jason van Zyl
+ * @author mailto:[EMAIL PROTECTED]">Vincent Massol
* @version $Id$
*/
public class Dependency
@@ -79,7 +80,7 @@
private String groupId;
/** The dependency type */
-private String type;
+private ArtifactType type;
/** Flag to indicate the artifact is poorly named. */
//private boolean isPoorlyNamed = false;
@@ -222,7 +223,7 @@
return jar;
}
-return getArtifactId() + "-" + getVersion() + "." + getType();
+return getArtifactId() + "-" + getVersion() + "." + getExtension();
}
/**
@@ -297,15 +298,33 @@
/**
- * Set the type of the dependency.
- *
- * @return dependency type such as "jar" or "war"
+ * @return dependency type such as "jar", "war", etc.
*/
public String getType()
{
-return type;
-}
-
+ String result = null;
+
+ if (this.type != null)
+ {
+ result = this.type.getType();
+ }
+return result;
+}
+
+ /**
+ * @return dependency extension such as "jar", "war", etc.
+ */
+ public String getExtension()
+ {
+ String result = null;
+
+ if (this.type != null)
+ {
+ result = this.type.getExtension();
+ }
+ return result;
+ }
+
/**
* Sets the dependency type such as "jar" or "war"
*
@@ -313,7 +332,7 @@
*/
public void setType( String type )
{
-this.type = type;
+this.type = ArtifactType.findType(type);
}
/**
1.1 maven/src/java/org/apache/maven/project/ArtifactType.java
Index: ArtifactType.java
===
package org.apache.maven.project;
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002 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,
[jira] Closed: (MAVEN-196) Dependency type handling - dependency type can diffrent than artifact file extension
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-196 Here is an overview of the issue: - Key: MAVEN-196 Summary: Dependency type handling - dependency type can diffrent than artifact file extension Type: Bug Status: Closed Priority: Major Resolution: FIXED Time Spent: Unknown Estimate: 0 minutes Project: maven Fix Fors: 1.0-beta-10 Versions: 1.0-beta-8 Assignee: Vincent Massol Reporter: Michal Maczka Created: Sun, 12 Jan 2003 11:36 AM Updated: Wed, 18 Jun 2003 5:05 PM Description: Currenly there is asuumption that artifact/dependecy type is alway the same as artifact file extension. This is not always true. As example of such dependecy myejb 1.0.1 ejb Maven will try to lookup this artifact as REPO/myejb/ejbs/myejb-1.0.1.ejb while correct path is REPO/myejb/ejbs/myejb-1.0.1.ejb EJB artifact have file extension ".jar" (that is the correct approach, and that is how ejb pluging names them. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-497) Missing information for resolving problems when using Maven
Message: The following issue has been closed. Resolver: Vincent Massol Date: Wed, 18 Jun 2003 5:04 PM Duplicate for 496 - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-497 Here is an overview of the issue: - Key: MAVEN-497 Summary: Missing information for resolving problems when using Maven Type: Bug Status: Closed Priority: Major Resolution: DUPLICATE Time Spent: Unknown Estimate: 0 minutes Project: maven Components: core Fix Fors: 1.0-beta-10 Versions: 1.0-beta-10 Assignee: Vincent Massol Reporter: Vincent Massol Created: Wed, 18 Jun 2003 10:56 AM Updated: Wed, 18 Jun 2003 5:04 PM Description: I type "maven" and I got: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-beta-10-SNAPSHOT Fatal Error [line 142, row 19]: The prefix "ant" for element "ant:echo" is not bound. org.xml.sax.SAXParseException: The prefix "ant" for element "ant:echo" is not bound. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.apache.maven.plugin.PluginCacheManager.parse(PluginCacheManager.java:357) at org.apache.maven.plugin.PluginManager.cachePlugin(PluginManager.java:795) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:335) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:293) at org.apache.maven.MavenSession.initialize(MavenSession.java:233) at org.apache.maven.cli.App.doMain(App.java:514) at org.apache.maven.cli.App.main(App.java:1088) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) Starting the reactor... [...] How do I know in which file the ant:echo problem is? The maven.log doesn't help. Shouldn't we print the file name in addition to the line and row? Thanks -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-502) Upload xmtp 2.0 to remote repo?
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-502 Here is an overview of the issue: - Key: MAVEN-502 Summary: Upload xmtp 2.0 to remote repo? Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 5:04 PM Updated: Wed, 18 Jun 2003 5:04 PM Description: Hi all, If someone could upload XMTP to the remote repo that would be great. I have been calling the version 2.0, but there is no versioning listed on their page, only a jar file. http://www.openhealth.org/xmtp/xmtp.jar thanks -warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-500) please upload xdoclet-1.2b3 to remote repo
The following comment has been added to this issue: Author: Aslak Hellesøy Created: Wed, 18 Jun 2003 5:00 PM Body: NO!! The current XDoclet 1.2b3 release is broken, so don't upload the jars before it's been fixed. Someone from the XDoclet team will upload the jars. Actually, XDoclet is maintaining its own jar repository at http://xdoclet.sourceforge.net/maven-repo/ We can upload it there when we're sure it's ok. Aslak (XDoclet team) - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-500 Here is an overview of the issue: - Key: MAVEN-500 Summary: please upload xdoclet-1.2b3 to remote repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 4:53 PM Updated: Wed, 18 Jun 2003 4:53 PM Description: Hi all, Could someone upload the latest set of jars from xdoclet (1.2b3) up to the remote repo? In addition the xjavadoc 1.0 needs to be uploaded as well now (due to the breakage in the plugin configuration this file will need to be named xdoclet-xjavadoc-1.0). Both can be found here: http://sourceforge.net/project/showfiles.php?group_id=31602 thanks -warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-501) Please upload RDF Filter to maven remote repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-501 Here is an overview of the issue: - Key: MAVEN-501 Summary: Please upload RDF Filter to maven remote repo Type: Wish Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 5:00 PM Updated: Wed, 18 Jun 2003 5:00 PM Description: Hi all, If someone could upload rdffilter to the remote repo, I would be grateful. It can be found here: http://sourceforge.net/project/showfiles.php?group_id=29451 Thanks -warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-501) Please upload RDF Filter to maven remote repo
The following comment has been added to this issue: Author: Warner Onstine Created: Wed, 18 Jun 2003 5:01 PM Body: Forgot to mention it's the 1.0-dev (or alpha) version) - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-501 Here is an overview of the issue: - Key: MAVEN-501 Summary: Please upload RDF Filter to maven remote repo Type: Wish Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 5:00 PM Updated: Wed, 18 Jun 2003 5:00 PM Description: Hi all, If someone could upload rdffilter to the remote repo, I would be grateful. It can be found here: http://sourceforge.net/project/showfiles.php?group_id=29451 Thanks -warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-500) please upload xdoclet-1.2b3 to remote repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-500 Here is an overview of the issue: - Key: MAVEN-500 Summary: please upload xdoclet-1.2b3 to remote repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 4:53 PM Updated: Wed, 18 Jun 2003 4:53 PM Description: Hi all, Could someone upload the latest set of jars from xdoclet (1.2b3) up to the remote repo? In addition the xjavadoc 1.0 needs to be uploaded as well now (due to the breakage in the plugin configuration this file will need to be named xdoclet-xjavadoc-1.0). Both can be found here: http://sourceforge.net/project/showfiles.php?group_id=31602 thanks -warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-499) upload kxml 2.1.7 to repo
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-499 Here is an overview of the issue: - Key: MAVEN-499 Summary: upload kxml 2.1.7 to repo Type: Wish Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Components: Repo Jar Requests Versions: 1.0-beta-10 Assignee: Reporter: Warner Onstine Created: Wed, 18 Jun 2003 4:45 PM Updated: Wed, 18 Jun 2003 4:45 PM Description: This can be found here: http://sourceforge.net/project/showfiles.php?group_id=9157 Thanks, Warner - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems of EJB plugin and Dependencies download
> I see 2 solutions: > > 1/ Add a property called false 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: 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 > > > (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 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: Recent changes in war plugin
Michal, It seems we are in agreement in the end :-) I'm all for using Java as I mentioned in my first email on this subject (and I do agree with all your points below except point f)). My only comment was about re-implementing the Zip/Jar/War tasks (and possibly the Manifest one too). Thanks -Vincent > -Original Message- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 18 June 2003 21:40 > To: Maven Developers List > Subject: 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] - 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: New WAR changes problems
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 21:09
> To: Maven Developers List
> Subject: RE: New WAR changes problems
[snip]
> > >
> > > > > artifact="foo"
> > > type="war"
> > > project="${pom}"
> > >
> > > > > artifact="lkjlkjlkjlkjlklk"
> > > type="war"
> > > project="${pom}"
> > >
> > > will do the same. The original file name is simply ignored.
> >
> > Sorry you've lost me. If the artifact attribute has no meaning, why
is
> > there one? Also what you're saying is not completely true as I've
tried
> > the war plugin (which uses artifact:install) and the war artifact
was
> > copied to the local repository *without* the version in its name.
> >
>
> This simply points to a file which will be deployed.
> This can be any file in any place. But deployer, installer must know
the
> name of this file.
Nie rozumiem! You just said a few lines above that using any name does
the same and that the original file name is simply ignored???
So it is used after all...
>
> If it is installed without version it is an error.
Then there is a bug... :-)
> I am working in
> deployer
> (remote deployer).
> I was bit busy today.. but hope to have ssh:// , file://' (not much
> needed
> but easy to support) and ftp:// deployer
> for tommorow. There is also http:// deployer.
I only need a normal copy working! Why would you need all these fancy
ssh, ftp, http to copy only a file from one directory to another
directory on the *same* machine. This is used to copy artifacts to the
local repository, right?
>
>
>
> > Also, why do you pass the pom object? Is the full POM really needed?
You
> > probably only need some elements from the pom, like the
currentVersion,
> > groupId field, etc. I think it is a much better design to make these
> > fields visible and not hidden by a global object.
> >
>
> You need much more. In pom you have
>
> distributionDirectory
> distributionSite
> groupId
> artifactId
> version
> + pom has associated JellyContext which contains many behavioral
> properties
> for deplorers
> (password, paths to private key, proxy servers etc)
ok, we're definitely not talking about the same thing here. I'm talking
about copying artifacts to the *Local* repository. This is what
war:install was previously doing and it seems this is also what the
artifact:install seems to be doing when I execute it...
You seem to be talking about remote repositories.
>
> I think POM is good for passing such data.
>
> In framework I am propagating the POM till some level, Then API
becomes
> independent of it. Those classes can be reused for low level operation
as
> they are
> completely independent of Maven,
ok
>
> I will send a post asking for your opinion about naming convention of
new
> properties
> which I will introduce by supporting multiple repositories.
-Vincent
-
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 > > (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 task. -Vincent > > > Michal > > > > > - > 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
> This already exists in Ant: it's called > (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: New WAR changes problems
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 8:23 PM
> To: 'Maven Developers List'
> Subject: RE: New WAR changes problems
>
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 18 June 2003 19:44
> > To: Maven Developers List
> > Subject: RE: New WAR changes problems
> >
>
> [snip]
>
> > > there is no way to rename the war... One solution (not nice) would
> to
> > > perform a copy prior to calling .
> > >
> >
> >
> > 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="foo"
> > type="war"
> > project="${pom}"
> >
> > > artifact="lkjlkjlkjlkjlklk"
> > type="war"
> > project="${pom}"
> >
> > will do the same. The original file name is simply ignored.
>
> Sorry you've lost me. If the artifact attribute has no meaning, why is
> there one? Also what you're saying is not completely true as I've tried
> the war plugin (which uses artifact:install) and the war artifact was
> copied to the local repository *without* the version in its name.
>
This simply points to a file which will be deployed.
This can be any file in any place. But deployer, installer must know the
name of this file.
If it is installed without version it is an error. I am working in deployer
(remote deployer).
I was bit busy today.. but hope to have ssh:// , file://' (not much needed
but easy to support) and ftp:// deployer
for tommorow. There is also http:// deployer.
> Also, why do you pass the pom object? Is the full POM really needed? You
> probably only need some elements from the pom, like the currentVersion,
> groupId field, etc. I think it is a much better design to make these
> fields visible and not hidden by a global object.
>
You need much more. In pom you have
distributionDirectory
distributionSite
groupId
artifactId
version
+ pom has associated JellyContext which contains many behavioral properties
for deplorers
(password, paths to private key, proxy servers etc)
I think POM is good for passing such data.
In framework I am propagating the POM till some level, Then API becomes
independent of it. Those classes can be reused for low level operation as
they are
completely independent of Maven,
I will send a post asking for your opinion about naming convention of new
properties
which I will introduce by supporting multiple repositories.
mm
-
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 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? > > > > [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. > > This will solve a lot of problems (e.g. classloaders) I have heard of these "issues" but I've never encountered any when using the Ant War/Jar/Zip java tasks. > > 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. I don't call War.setProject(new Project().init()) a "lot of unnecessary stuff". Ok, it would have been better without, but it's not that bad compared to the benefits you get. > 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. 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 I'd much rather have all these done by another project... Thus, I also like to write code but it really has to be worth it, IMO especially as we have so many other important areas of improvements in maven land... :-) > > [...] > > > > 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. I was talking about the fact that you said it wasn't interesting to have a wewbxml attribute in the war task. I was not agreeing to that. > 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. Err... we're changing subject here, no? :-) > > > > 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 manifes
RE: New WAR changes problems
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 19:44
> To: Maven Developers List
> Subject: RE: New WAR changes problems
>
[snip]
> > there is no way to rename the war... One solution (not nice) would
to
> > perform a copy prior to calling .
> >
>
>
> 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="foo"
> type="war"
> project="${pom}"
>
>artifact="lkjlkjlkjlkjlklk"
> type="war"
> project="${pom}"
>
> will do the same. The original file name is simply ignored.
Sorry you've lost me. If the artifact attribute has no meaning, why is
there one? Also what you're saying is not completely true as I've tried
the war plugin (which uses artifact:install) and the war artifact was
copied to the local repository *without* the version in its name.
Also, why do you pass the pom object? Is the full POM really needed? You
probably only need some elements from the pom, like the currentVersion,
groupId field, etc. I think it is a much better design to make these
fields visible and not hidden by a global object.
Thanks
-Vincent
>
>
>
> Michal
>
>
>
> -
> 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: Problems of EJB plugin and Dependencies download
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 19:53
> To: Maven Developers List
> Subject: 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
>
ok. That's cool to know. However, my belief is that it still needs to be
fixed for Maven 1.0.
> 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:
>
>
> ejb
> actual file name
>
>
> AFAIK There is no workaround for 2nd problem,
I see 2 solutions:
1/ Add a property called false 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-498) [Upload] javassist
The following issue has been updated: Updater: Howard M. Lewis Ship (mailto:[EMAIL PROTECTED]) Date: Wed, 18 Jun 2003 1:32 PM Comment: This is from the 2.5.1 release. The complete distro is at: http://prdownloads.sourceforge.net/jboss/javassist-2.5.1.zip?use_mirror=aleron Changes: Attachment changed from to javassist.jar - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498 Here is an overview of the issue: - Key: MAVEN-498 Summary: [Upload] javassist Type: Task Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Assignee: Reporter: Howard M. Lewis Ship Created: Wed, 18 Jun 2003 1:30 PM Updated: Wed, 18 Jun 2003 1:32 PM Description: Please upload Javassist framework to ibiblio. I'm attaching a POM and the JAR. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-498) [Upload] javassist
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498 Here is an overview of the issue: - Key: MAVEN-498 Summary: [Upload] javassist Type: Task Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Assignee: Reporter: Howard M. Lewis Ship Created: Wed, 18 Jun 2003 1:30 PM Updated: Wed, 18 Jun 2003 1:30 PM Description: Please upload Javassist framework to ibiblio. I'm attaching a POM and the JAR. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-498) [Upload] javassist
The following issue has been updated: Updater: Howard M. Lewis Ship (mailto:[EMAIL PROTECTED]) Date: Wed, 18 Jun 2003 1:31 PM Changes: Attachment changed from to javassist.txt - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498 Here is an overview of the issue: - Key: MAVEN-498 Summary: [Upload] javassist Type: Task Status: Unassigned Priority: Minor Time Spent: Unknown Estimate: 0 minutes Project: maven Assignee: Reporter: Howard M. Lewis Ship Created: Wed, 18 Jun 2003 1:30 PM Updated: Wed, 18 Jun 2003 1:31 PM Description: Please upload Javassist framework to ibiblio. I'm attaching a POM and the JAR. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 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:
ejb
actual file name
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
> /ejbs/-.jar (note the "jar" extension").
>
> However, the maven dependency resolver looks for a file named:
> /ejbs/-.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 = .
>
> 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: 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="${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 .
>
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).
Problems of EJB plugin and Dependencies download
Hi, The EJB plugin ejb:install goal installs its artifacts in /ejbs/-.jar (note the "jar" extension"). However, the maven dependency resolver looks for a file named: /ejbs/-.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 = . 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]
RE: New WAR changes problems
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 18 June 2003 17:45 > 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: > > war:war: > [echo] Building WAR everest-csrweb > [war] Updating war: > E:\Vma\Projets\Encours\tsss\everest\dev\modules\csrweb\target\everest-cs > rweb > .war > Copying: from > 'E:\Vma\Projets\Encours\tsss\everest\dev\modules\csrweb/target/everest-c > srweb.war' to: > 'C:\Documents and Settings\Vincent > Massol/.maven/repository/everest/wars' > > BUILD FAILED > Unable to obtain goal [war:install] -- null:165:11: > null > Total time: 22 seconds > > Note1: If I run "maven war" from the project it works fine > Note2: It fails when I run maven through the reactor... Sorry, this is wrong! I'm getting the same error whether I run it with or without the reactor. Here's some more information: BUILD FAILED java.lang.reflect.InvocationTargetException com.werken.werkz.UnattainableGoalException: Unable to obtain goal [war:install] -- null:165:11: null [...] Caused by: org.apache.maven.MavenException: Cannot install file: 'everest/wars'. Reason: C:\Document s and Settings\Vincent Massol\.maven\repository\everest\wars (Access is denied) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doInstall(Def aultArtifactDeplo yer.java:174) I don't understand why the access is denied. Anyway, after removing manually the everest/wars directory it worked fine. [snip] Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: war:war: [echo] Building WAR everest-csrweb [war] Updating war: E:\Vma\Projets\Encours\tsss\everest\dev\modules\csrweb\target\everest-cs rweb .war Copying: from 'E:\Vma\Projets\Encours\tsss\everest\dev\modules\csrweb/target/everest-c srweb.war' to: 'C:\Documents and Settings\Vincent Massol/.maven/repository/everest/wars' BUILD FAILED Unable to obtain goal [war:install] -- null:165:11: null Total time: 22 seconds Note1: If I run "maven war" from the project it works fine Note2: It fails when I run maven through the reactor... 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: there is no way to rename the war... One solution (not nice) would to perform a copy prior to calling . Note: I'm assuming we want to keep maven.war.final.name without the version in it as some have expressed this need. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-497) Missing information for resolving problems when using Maven
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-497 Here is an overview of the issue: - Key: MAVEN-497 Summary: Missing information for resolving problems when using Maven Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Components: core Fix Fors: 1.0-beta-10 Versions: 1.0-beta-10 Assignee: Reporter: Vincent Massol Created: Wed, 18 Jun 2003 10:56 AM Updated: Wed, 18 Jun 2003 10:56 AM Description: I type "maven" and I got: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-beta-10-SNAPSHOT Fatal Error [line 142, row 19]: The prefix "ant" for element "ant:echo" is not bound. org.xml.sax.SAXParseException: The prefix "ant" for element "ant:echo" is not bound. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.apache.maven.plugin.PluginCacheManager.parse(PluginCacheManager.java:357) at org.apache.maven.plugin.PluginManager.cachePlugin(PluginManager.java:795) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:335) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:293) at org.apache.maven.MavenSession.initialize(MavenSession.java:233) at org.apache.maven.cli.App.doMain(App.java:514) at org.apache.maven.cli.App.main(App.java:1088) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) Starting the reactor... [...] How do I know in which file the ant:echo problem is? The maven.log doesn't help. Shouldn't we print the file name in addition to the line and row? Thanks -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-496) Missing information for resolving problems when using Maven
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-496 Here is an overview of the issue: - Key: MAVEN-496 Summary: Missing information for resolving problems when using Maven Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Assignee: Reporter: Vincent Massol Created: Wed, 18 Jun 2003 10:56 AM Updated: Wed, 18 Jun 2003 10:56 AM Description: I type "maven" and I got: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-beta-10-SNAPSHOT Fatal Error [line 142, row 19]: The prefix "ant" for element "ant:echo" is not bound. org.xml.sax.SAXParseException: The prefix "ant" for element "ant:echo" is not bound. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.apache.maven.plugin.PluginCacheManager.parse(PluginCacheManager.java:357) at org.apache.maven.plugin.PluginManager.cachePlugin(PluginManager.java:795) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:335) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:293) at org.apache.maven.MavenSession.initialize(MavenSession.java:233) at org.apache.maven.cli.App.doMain(App.java:514) at org.apache.maven.cli.App.main(App.java:1088) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:543) at com.werken.forehead.Forehead.main(Forehead.java:573) Starting the reactor... [...] How do I know in which file the ant:echo problem is? The maven.log doesn't help. Shouldn't we print the file name in addition to the line and row? Thanks -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent changes in war plugin
Michal Maczka wrote: ... 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 Yes, this is the best way to do it. If your servlet engine can use exploded webapps it's much faster to develop this way. My ant build scripts always build webapps in two stages like this. - 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: Recent changes in war plugin
--- Michal Maczka <[EMAIL PROTECTED]> wrote: > What's so magical in ant war task? Nothing. I would say, that I never used it before maven - jar was just fine for 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. I must disagree. Maven plugins are ( partly ) pre-cooked ant intelligence, and ant does his work rightplus some internal logic to stremline ant taks setup. > This will increase quality of the code, speed and > code reuse. > So from my point of view less dependencies on ant - > better code. Not always. Or do you like to duplicate javac task? There are things which ant does really good - compilation support, file copy etc. Maven itself is a tool which offers much more than plain compilation - dependency tracking etc. Why not concwentrate on important stuff and let ant folks do their job? 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]
[jira] Commented: (MAVEN-495) Use of SNAPSHOT jars when remote repo is disabled
The following comment has been added to this issue: Author: Martin Skopp Created: Wed, 18 Jun 2003 5:15 AM Body: IMHO even if the snapshot exists in the remote repo, the freshest/newest should be taken. maven downloads snapshots from remote repo even if locally a fresher version exists. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-495 Here is an overview of the issue: - Key: MAVEN-495 Summary: Use of SNAPSHOT jars when remote repo is disabled Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Fix Fors: 1.0-beta-10 Versions: 1.0-beta-10 Assignee: Reporter: Vincent Massol Created: Wed, 18 Jun 2003 4:38 AM Updated: Wed, 18 Jun 2003 4:38 AM Description: I have the following in my build.properties: maven.repo.remote.enabled = false offline=true Now, my project depends on a snapshot jar that is available in my local repository. But when I build it, I get: " The use of the remote repository has been disabled. BUILD FAILED The build cannot continue because of the following unsatisfied dependency: everest-bedrock-1.0-SNAPSHOT.jar " I think that when the remote repository is disabled, snapshot jars should be taken from the local repository. -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 11:20
> To: 'Maven Developers List'
> Subject: 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?
It's written, fully supports the war model and has gone through lots of
testing.
[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 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?
>
> 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?
Here's an example on how to use it (taken from the Cactus Eclipse
plugin):
War warTask = new War();
warTask.setProject(new Project().init());
warTask.setDestFile(outputWar);
warTask.addClasses(classes);
warTask.addFileset(webFiles);
warTask.setWebxml(userWebXML);
warTask.setUpdate(true);
warTask.addLib(libs);
warTask.execute();
BTW, I think identifying the web.xml file is a good idea as it allows
you perform any kind of thing like validation, etc.
>
>
> > 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:
> >
> > > webxml="${maven.war.webxml}" update="true">
> > [...]
> >
> >
> >
> >
>
> That's some idea...
>
> Michal
>
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVEN-495) Use of SNAPSHOT jars when remote repo is disabled
The following issue has been updated: Updater: Vincent Massol (mailto:[EMAIL PROTECTED]) Date: Wed, 18 Jun 2003 4:38 AM Changes: Version changed from to 1.0-beta-10 Fix Version changed from to 1.0-beta-10 - For a full history of the issue, see: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-495&page=history - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-495 Here is an overview of the issue: - Key: MAVEN-495 Summary: Use of SNAPSHOT jars when remote repo is disabled Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Fix Fors: 1.0-beta-10 Versions: 1.0-beta-10 Assignee: Reporter: Vincent Massol Created: Wed, 18 Jun 2003 4:38 AM Updated: Wed, 18 Jun 2003 4:38 AM Description: I have the following in my build.properties: maven.repo.remote.enabled = false offline=true Now, my project depends on a snapshot jar that is available in my local repository. But when I build it, I get: " The use of the remote repository has been disabled. BUILD FAILED The build cannot continue because of the following unsatisfied dependency: everest-bedrock-1.0-SNAPSHOT.jar " I think that when the remote repository is disabled, snapshot jars should be taken from the local repository. -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-495) Use of SNAPSHOT jars when remote repo is disabled
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-495 Here is an overview of the issue: - Key: MAVEN-495 Summary: Use of SNAPSHOT jars when remote repo is disabled Type: Bug Status: Unassigned Priority: Major Time Spent: Unknown Estimate: 0 minutes Project: maven Fix Fors: 1.0-beta-10 Versions: 1.0-beta-10 Assignee: Reporter: Vincent Massol Created: Wed, 18 Jun 2003 4:38 AM Updated: Wed, 18 Jun 2003 4:38 AM Description: I have the following in my build.properties: maven.repo.remote.enabled = false offline=true Now, my project depends on a snapshot jar that is available in my local repository. But when I build it, I get: " The use of the remote repository has been disabled. BUILD FAILED The build cannot continue because of the following unsatisfied dependency: everest-bedrock-1.0-SNAPSHOT.jar " I think that when the remote repository is disabled, snapshot jars should be taken from the local repository. -Vincent - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 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:
>
> webxml="${maven.war.webxml}" update="true">
> [...]
>
>
>
>
That's some idea...
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 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.
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:
[...]
-Vincent
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent changes in war plugin
Michal Maczka wrote: > 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 Go for it - it seems to simplify things, and people might want to run their application off that "exploded" directory for their ordinary development cycle. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: 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]
cvs commit: maven/xdocs navigation.xml
dion2003/06/18 00:19:02 Modified:xdocsnavigation.xml Log: - Move web stats and wiki to new Apache Menu - Add Apache Developer resources link Revision ChangesPath 1.20 +4 -1 maven/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/maven/xdocs/navigation.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- navigation.xml12 Jun 2003 08:42:19 - 1.19 +++ navigation.xml18 Jun 2003 07:19:01 - 1.20 @@ -44,12 +44,15 @@ - http://nagoya.apache.org/wiki/apachewiki.cgi?Maven"/> + + + http://www.apache.org/dev/"/> http://www.apache.org/~vgritsenko/stats/projects/maven.html"/> + http://nagoya.apache.org/wiki/apachewiki.cgi?Maven"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
