Re: Multi-module project: One jar with dependencies
Hello Matthew Horridge, I am interested in your way generating one zip-file in a multi-module-project. Can Post the affected part of the pom, where you generate the zip-file? Thank you! Tim -- View this message in context: http://maven.40175.n5.nabble.com/Multi-module-project-One-jar-with-dependencies-tp86011p3211557.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Error transferring file: sun.security.validator.ValidatorException:
Hi，all I don't know how to do it correctly. the log as follows: Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.Sun CertPathBuilderException: unable to find valid certification path to requested t arget thanks wang xiao
Re: maven is a swamp
Flexible and elegant aren't necessarily the same thing... Any language that prides itself on its ability to be obfuscated can't be elegant ;-) That said, I do love it. As far as Maven goes, the elegance of maven is that it does 90% of what you need it to do with very little or no effort and the other 10% can be done without much hassle. On 10/13/10 10:48 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: It does. The rest of the language is rather ugly, though. -K On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote: I just enjoyed the bit about perl having elegant and concise data structures :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module project: One jar with dependencies
2007/4/20 Matthew Horridge matthew.horri...@cs.man.ac.uk: project.jar - This jar file contains all classes from ModuleA, ModuleB and ModuleC I suggest you to create an additional module that uses Shade plugin to create an uberjar: http://maven.apache.org/plugins/maven-shade-plugin/index.html You can see a working example here: http://svn.apache.org/repos/asf/velocity/engine/branches/2.0_Exp/velocity-engine-uberjar/ Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Error transferring file: sun.security.validator.ValidatorException:
Hi, Are you trying to download an artifact from an repository via https? It seems, that your certificate is not valid for Java (e.g. it is an self signed certificate). Add your certificate to an keystore and pass that keystore to maven (e.g. -Djavax.net.ssl.trustStore=%M2_HOME%\conf\trust.jks in your MAVEN_OPTS) Greetings Jens -Ursprüngliche Nachricht- Von: wang xiao [mailto:cquptwan...@gmail.com] Gesendet: Donnerstag, 14. Oktober 2010 08:29 An: users@maven.apache.org Betreff: Error transferring file: sun.security.validator.ValidatorException: Hi，all I don't know how to do it correctly. the log as follows: Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.Sun CertPathBuilderException: unable to find valid certification path to requested t arget thanks wang xiao - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Java is a swamp
Haha :D
On Wed, Oct 13, 2010 at 7:38 PM, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Kenneth,
now, after your mail, I realize that Java is also a swamp, too:
= % =
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
public class HelloWorld {
public void main(String[] args) {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName(JavaScript);
engine.put(world, world);
String result;
try {
result = (String)engine.eval('Hello ' + world + '!');
} catch (ScriptException e) {
return;
}
System.out.println(result);
}
}
= % =
Take a look at the most obvious problems in the above:
= % =
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName(JavaScript);
engine.put(world, world);
String result;
try {
result = (String)engine.eval('Hello ' + world + '!');
} catch (ScriptException e) {
return;
}
= % =
I am very new to Java, but it strikes me that what the above is saying is
(in shell script):
echo Hello world!
I am just so sick of using crappy solutions (read: Java) layered over top
of what could be good solutions.
Sorry, I had to vent.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module project: One jar with dependencies
Thank you! Works fine ! -- View this message in context: http://maven.40175.n5.nabble.com/Multi-module-project-One-jar-with-dependencies-tp86011p3211811.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
+ [ Detail ] display in Surefire reports - malfunction?
Hi,
I´ve generated a Surefire report about my TestNG results and wondered why
the + [ Detail ] Link (javascript:toggleDisplay('methodname') does not
work, either in Mozilla Firefox nor in Windows Explorer
I found (SUREFIRE-260) Detail display doesn't work if there are tests with
the same name that could be a reason for that.
= isn´t there any fix available? How do others browse the detailed
information, if a test is broken ? If I copy/paste the html code to a text
editor, i can see the stacktrace.
thanx for any advice,
Torsten
Re: Heap overflow in deploy:deploy
On Wed, Oct 13, 2010 at 8:31 PM, Wayne Fay wayne...@gmail.com wrote: You probably want to look at the following lines in particular: 457 transfer( resource, input, output, requestType, Integer.MAX_VALUE ); 480 int remaining = maxSize; //maxSize is Integer.MAX_VALUE 483 int n = input.read( buffer, 0, Math.min( buffer.length, remaining ) ); //read in full file (up to Integer.MAX_VALUE in length) into buffer [memory] 492 output.write( buffer, 0, n ); //then write it out So yes, it seems like it does read in the entire file into memory. I don't know. To me it looks like the code limits it to sending DEFAULT_BUFFER_SIZE (4K) at a time. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran dant...@gmail.com wrote: It is a known problem where maven (wagon) uses jvm's httpclient to do the upload. Good to know, thanks. So it is actually a bug in sun.net.www.http.PosterOutputStream you say? So what is the game plan? Just wait for Sun (well, Oracle) to fix it? In the meantime should we set a (higher) default max mem values in mvn.bat? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Site plugin version management
Site:site says this over and over, in addition to running the javadoc over and over. INFO] Generating Project License report. [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin. What should I be specifying, and where should I be specifying it (reporting versus plugin management). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Retry failed artifact deployments during release
Is it possible to configure Maven to retry artifact deployments that fail during the release process? Artifactory seems to have a habit of returning 502s and I'd like Maven to at least try to upload the artifacts several times before giving up on a lengthy build process. -- C. Benson Manica cbman...@gmail.com
Re: Site plugin version management
Did you google for it? http://jira.codehaus.org/browse/MSITE-490 Why the javadoc doesn't work I don't know... -Lukas Benson Margulies wrote: Site:site says this over and over, in addition to running the javadoc over and over. INFO] Generating Project License report. [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin. What should I be specifying, and where should I be specifying it (reporting versus plugin management). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven SQL plugin
Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Re: Maven SQL plugin
Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Re: maven is a swamp
As much fun as all this commentary is, unless Ken comes back and posts a reply, I feel like we're simply the victims of a drive-by trolling... As such, I recommend letting this thread die, at least until Ken comes back and adds something to the discussion... Ken??? Wayne On Wed, Oct 13, 2010 at 5:13 PM, Rick Mangi rick.ma...@mtvn.com wrote: Flexible and elegant aren't necessarily the same thing... Any language that prides itself on its ability to be obfuscated can't be elegant ;-) That said, I do love it. As far as Maven goes, the elegance of maven is that it does 90% of what you need it to do with very little or no effort and the other 10% can be done without much hassle. On 10/13/10 10:48 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: It does. The rest of the language is rather ugly, though. -K On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote: I just enjoyed the bit about perl having elegant and concise data structures :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
I don't know. To me it looks like the code limits it to sending DEFAULT_BUFFER_SIZE (4K) at a time. Heh, you're right... doh. In my defense, I was looking for a place where maybe the code had a bug and was reading entirely too much into memory. Oh well, guess its just jvm's httpclient bug then like Dan said. ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven SQL plugin
Hi John, I never noticed the option of srcFiles as against fileset My understanding is the list of files specified using srcFiles are executed in the order they are specified whereas it is not so in the case of fileset(this is when orderFile attribute is not specified). Am I wrong? Thanks for the reply, Chris. On Thu, Oct 14, 2010 at 7:33 PM, John Singleton john.te...@gmail.comwrote: Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Missing menus in leaf projects with current site plugin
I just spend the morning setting up the site plugin and reporting for a new project. It is a parent with children. The parent has a site.xml with some custom navigation to add additional pages to the menu. The site specified 2.1.1 for the maven-site-plugin in the build/pluginManagement, and m-p-i-r-p version 2.2 in reporting/plugins. I've called out 2.7 of the javadoc plugin in reporting as well, and turned off test-javadoc by using reportSets to enable only the 'javadoc' report. I should say, having whined about the site plugin in the the past, that this runs in a reasonable amount of time and is not doing anything really bizarre from the log output. HOWEVER. Running site:site, the child projects, which do not have anything at all in src/site, get no navigation at all. Not even the default menu to their reports. All the content is generated, but the index.html does not have any navigation. Before I go add cookie-cutter site.xml files to all of them, can anyone rescue me? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mavenicing bpel module
Hi:
I’m mavenicing a BPEL Module but i has this error:
Embedded error: The following error occurred while executing this line:
C:\caps\NETBEA~1\EchoDeAfirma\BpelConexions\nbproject\build-impl.xml:79:
taskdef class
org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask
cannot be found
do you have any idea ?
pom.xml:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
artifactIdBpelConexions/artifactId
groupIdBpelConexions/groupId
packagingjar/packaging
version1.0-SNAPSHOT/version
build
plugins
!-- DISABLE COMPILER PLUGIN AS ANT RUN WOUDL COMPILE THE CODE
--
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
skiptrue/skip
source1.5/source
target1.5/target
excludes
exclude**/*.java/exclude
/excludes
/configuration
/plugin
!-- DISABLE the test code run as a junit test as this test is
integration test code.--
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.1.3/version
inheritedtrue/inherited
configuration
skiptrue/skip
excludes
exclude**/enginetest/*.java/exclude
/excludes
/configuration
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
idjbicomp-build-package/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
tasks
ant antfile=build.xml inheritAll=false
target=dist_se
/ant
copy overwrite=true file=dist/${
jbi.component.name}.jar
toFile=${project.build.directory}/${project.artifactId}-${project.version}.jar
/
!--
dist/EJBWSAfirma.jar
--
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
properties
jbi.component.name${project.artifactId}/jbi.component.name
/properties
/project
build-impl.xml :
?xml version=1.0 encoding=UTF-8?
!--
*** GENERATED FROM project.xml - DO NOT EDIT ***
*** EDIT ../build.xml INSTEAD ***
--
project name=BpelConexions-impl default=default basedir=..
target name=default depends=dist_se/
!--
INITIALIZATION SECTION
--
target name=pre-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-private depends=pre-init
property file=nbproject/private/private.properties/
/target
target name=init-userdir depends=pre-init,init-private
property name=user.properties.file
location=${netbeans.user}/build.properties/
/target
target name=init-user depends=pre-init,init-private,init-userdir
property file=${user.properties.file}/
/target
target name=init-project
depends=pre-init,init-private,init-userdir,init-user
property file=nbproject/project.properties/
/target
target name=do-init
depends=pre-init,init-private,init-userdir,init-user,init-project
available file=${src.dir}/../retrieved
property=retrieved.exists/
/target
target name=post-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-check
depends=pre-init,init-private,init-userdir,init-user,init-project,do-init
fail unless=src.dirMust set src.dir/fail
fail unless=build.dirMust set build.dir/fail
fail unless=dist.dirMust set dist.dir/fail
fail unless=dist.jarMust set dist.jar/fail
/target
target name=init-taskdefs if=from.commandline
path id=ant.task.classpath
pathelement
location=${esb.netbeans.platform}/../ide10/modules/ext/resolver-1.2.jar/
pathelement
location=${esb.netbeans.platform}/../ide10/modules/org-apache-xml-resolver.jar/
pathelement
location=${esb.netbeans.platform}/../ide10/modules/org-netbeans-modules-project-ant.jar/
pathelement
Re: mavenicing bpel module
I don't know what the actual problem you are facing is, but you might want
to consider starting with maven from scratch and only add tasks (or better
convert tasks to plugins) as the need arises.
Milos
On Thu, Oct 14, 2010 at 5:08 PM, José Vicente jvia...@gmail.com wrote:
Hi:
I’m mavenicing a BPEL Module but i has this error:
Embedded error: The following error occurred while executing this line:
C:\caps\NETBEA~1\EchoDeAfirma\BpelConexions\nbproject\build-impl.xml:79:
taskdef class
org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask
cannot be found
do you have any idea ?
pom.xml:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
modelVersion4.0.0/modelVersion
artifactIdBpelConexions/artifactId
groupIdBpelConexions/groupId
packagingjar/packaging
version1.0-SNAPSHOT/version
build
plugins
!-- DISABLE COMPILER PLUGIN AS ANT RUN WOUDL COMPILE THE CODE
--
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
skiptrue/skip
source1.5/source
target1.5/target
excludes
exclude**/*.java/exclude
/excludes
/configuration
/plugin
!-- DISABLE the test code run as a junit test as this test is
integration test code.--
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.1.3/version
inheritedtrue/inherited
configuration
skiptrue/skip
excludes
exclude**/enginetest/*.java/exclude
/excludes
/configuration
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
idjbicomp-build-package/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
tasks
ant antfile=build.xml inheritAll=false
target=dist_se
/ant
copy overwrite=true file=dist/${
jbi.component.name}.jar
toFile=${project.build.directory}/${project.artifactId}-${project.version}.jar
/
!--
dist/EJBWSAfirma.jar
--
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
properties
jbi.component.name${project.artifactId}/jbi.component.name
/properties
/project
build-impl.xml :
?xml version=1.0 encoding=UTF-8?
!--
*** GENERATED FROM project.xml - DO NOT EDIT ***
*** EDIT ../build.xml INSTEAD ***
--
project name=BpelConexions-impl default=default basedir=..
target name=default depends=dist_se/
!--
INITIALIZATION SECTION
--
target name=pre-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-private depends=pre-init
property file=nbproject/private/private.properties/
/target
target name=init-userdir depends=pre-init,init-private
property name=user.properties.file
location=${netbeans.user}/build.properties/
/target
target name=init-user depends=pre-init,init-private,init-userdir
property file=${user.properties.file}/
/target
target name=init-project
depends=pre-init,init-private,init-userdir,init-user
property file=nbproject/project.properties/
/target
target name=do-init
depends=pre-init,init-private,init-userdir,init-user,init-project
available file=${src.dir}/../retrieved
property=retrieved.exists/
/target
target name=post-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-check
depends=pre-init,init-private,init-userdir,init-user,init-project,do-init
fail unless=src.dirMust set src.dir/fail
fail unless=build.dirMust set build.dir/fail
fail unless=dist.dirMust set dist.dir/fail
fail unless=dist.jarMust set dist.jar/fail
/target
target name=init-taskdefs if=from.commandline
path id=ant.task.classpath
pathelement
Checkstyle/maven/parent POM
Consider the following hierarchy: |-- module1 |`-- pom.xml | |-- checkstyle-exclusions.xml |-- module2 | `-- pom.xml | |-- checkstyle-exclusions.xml |-- ... ` pom.xml ` checkstyle.xml The goal is to have a centrally shared checkstyle.xml configuration, while allowing exclusions on a per-module basis. Here are the issues I'm struggling with: * In checkstyle plugin 2.6, it appears that the suppressionsLocation/suppressionsFileExpression don't work. I spent a significant amount of time trying all manner of settings for those, but the exclusions file was never found. * In lieu of that, I had to resort to using SuppressionFilter in the checkstyle.xml. The challenge with that is that it needs a relative path, and the path is different when running the parent POM vs. one of the module POMs Does anybody have a setup such as this running? Am I missing something here? Stefan Zier ste...@zier.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: naming now that Maven 3 is out..
-Original Message- From: Wendy Smoak [mailto:wsm...@gmail.com] On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com wrote: Kind of a random thought -- now that Maven 3 is out, are all those M2 based names going to be changed to M3, or more preferably a non-version specific name? i.e. M2_HOME, m2eclipse, etc.? This was discussed on the dev list a while back, you can check the archives to see how it turned out. Ok, *where* on the dev list? I just spent 15 minutes looking for mention of this and the only thing I found that said anything about this was: http://www.mail-archive.com/d...@maven.apache.org/msg84980.html but hardly counts as being discussed. How about providing a link to what you're talking about? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: naming now that Maven 3 is out..
It looks like he's also using the luminary jar, do you have that one too? On Thu, 2010-10-14 at 11:33 -0500, Haszlakiewicz, Eric wrote: -Original Message- From: Wendy Smoak [mailto:wsm...@gmail.com] On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com wrote: Kind of a random thought -- now that Maven 3 is out, are all those M2 based names going to be changed to M3, or more preferably a non-version specific name? i.e. M2_HOME, m2eclipse, etc.? This was discussed on the dev list a while back, you can check the archives to see how it turned out. Ok, *where* on the dev list? I just spent 15 minutes looking for mention of this and the only thing I found that said anything about this was: http://www.mail-archive.com/d...@maven.apache.org/msg84980.html but hardly counts as being discussed. How about providing a link to what you're talking about? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail and any attachments are for the intended recipient(s) only and may contain proprietary, confidential material. If you are not the intended recipient, (even if the email address above is yours) do not use, retain, copy or disclose any part of this communication or any attachment as it is strictly prohibited and may be unlawful. If you believe that you have received this e-mail in error, please notify the sender immediately and permanently delete. This email may be a personal communication from the sender and as such does not represent the views of the company.
Re: naming now that Maven 3 is out..
Eric, you can look at these: http://jira.codehaus.org/browse/MNG-4483 http://maven.40175.n5.nabble.com/Setting-goals-for-upcoming-releases-td2801569.html Paul On Thu, Oct 14, 2010 at 11:33 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- From: Wendy Smoak [mailto:wsm...@gmail.com] On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com wrote: Kind of a random thought -- now that Maven 3 is out, are all those M2 based names going to be changed to M3, or more preferably a non-version specific name? i.e. M2_HOME, m2eclipse, etc.? This was discussed on the dev list a while back, you can check the archives to see how it turned out. Ok, *where* on the dev list? I just spent 15 minutes looking for mention of this and the only thing I found that said anything about this was: http://www.mail-archive.com/d...@maven.apache.org/msg84980.html but hardly counts as being discussed. How about providing a link to what you're talking about? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
Hello, On Wed, Oct 13, 2010 at 10:53 PM, Graham Leggett minf...@sharp.fm wrote: On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote: Many traditional programming languages are declarative and not procedural or are based on declarative concepts, most of the time the declarative nature of such languages proved itself problematic. But seriously is there a comparison matrix somewhere which compares ant+ivy vs maven? A comparison would make little sense, because ant and maven aren't alternatives for one another. Ant is a language that allows you to create custom build scripts, but you are required to write those build scripts yourself, over and over again. Maven on the other hand arrives with built in knowledge on how to build things, you are only required to tell maven the basics, like the name of the artifact, the version, etc. Maven does everything else for you without you having to tell it how to do it. This isn't quite true since ant allows you to build 'your own maven' in few hours. The effort to learn maven is much higher, at least I had to spend a lot more time since now. On the other side the effort to learn ant is moderate. But maybe I'm biased here ;-) And, you can't deploy with maven... As an ant+ivy user I have recently tried out maven (yes, i hand-wrote poms for about 15 projects) which mostly depend on each other, I got them all published in nexus etc. I must say that I'm pretty shaken how unreliable maven build are. I predict the core of your problem is as an ant+ivy user With ant, you adopt the mindset I need to tell ant to do X, then Y, then Z. With maven, you don't tell it how to do anything, it already knows how to do stuff. Well actually what bothers me is that my build scripts very shorter than my poms. My typical build script in my pre-maven time was 3 rows long: ?xml version=1.0? project name=ano-prise default=dist basedir=. import file=../build/basic-project.xml/ property name=ivy.organisation value=anotheria.net/ property name=ivy.module value=ano-prise/ !-- checkout svn://svn.anotheria.net/opensource/build/trunk as ../build in order for this build script to work. -- /project If you try and approach maven with the idea that you want to tell maven to do X, Y and then Z, you'll very quickly come unstuck, because you'll be fighting with maven, trying to convince it to do things in your order instead of maven's built in order. Maven already knows how to do stuff. All you need to do is fill in the blanks. Tell maven what kind of artifact it is, what it is called. And don't stray from the defaults - you don't need to put your source code in some weird directory structure, if maven defaults to src/main/java, put your code in src/main/java and leave it at that. Well thats another point, what if I have more than one source code directory? For example I have a project which contains an apt-based code generator. The other source-directory of the project is annotated with apt annotations from the first source part and can't be compiled before the first part is compiled. Further on, the generated code itself has to be compiled as well. And yes it works with maven and some plugins but in much less elegant way as in ant. When you find yourself in a situation where you have a 5 line pom file, with hundreds of plugins all custom configured, you're fighting against maven. This isn't maven's fault, this is the fault of the person who created the pom. Keep it simple, keep it to default behaviour. With ant it either works or not. If it works, it works everywhere, in console, in eclipse in hudson. In my experience, I have not once encountered an ant build that worked, ever. The reason was simple: the build is always secondary to the code itself. Inevitably, the ant build only performed the basics, even ant clean was left out most of the time. Every single one I encountered had some or other path that was hard coded to C:\Program Files\... with the developer expecting everyone else to just recreate the same directory structure, it was ridiculous. Maven has gone off and solved the build problem, it does not rely on every developer's half hearted attempt to write a build script when they're under pressure to produce code, not build. At the core of ant is the question how do I make ant do this?. At the core of maven is the question how does maven do this.. Remove the I from the equation, and just do it like maven wants you to do it, and suddenly everything becomes a *lot* more reliable. I don't know.. I have use-cases over use-cases with stuff that maven isn't doing per default. Example: get cobertura/findbugs/pdm reports without site phase. I actually expect the CI to call verify instead of building a site. I spent three days trying to get a cobertura report out of verify and finally gave up. Example: pack and unpack additional files into jar files. We have a
RE: naming now that Maven 3 is out..
Thank you. So, based on the three different urls below, plus the installation instructions at http://maven.apache.org/download.html#Installation, it seems like a summary of the current status is: The Maven 3 user directory is still .m2 The Maven 3 environment variable is still M2_HOME A new environment variable may be used in the future (M3_HOME? MVN_HOME?), but if it's not set maven will fallback to using M2_HOME The user directory may change to .mvn in the future, but what happens if a .m2 directory already exists hasn't been decided yet. eric -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Eric, you can look at these: http://jira.codehaus.org/browse/MNG-4483 http://maven.40175.n5.nabble.com/Setting-goals-for-upcoming-releases- td2801569.html Paul On Thu, Oct 14, 2010 at 11:33 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- From: Wendy Smoak [mailto:wsm...@gmail.com] On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala na...@chikli.com wrote: Kind of a random thought -- now that Maven 3 is out, are all those M2 based names going to be changed to M3, or more preferably a non-version specific name? i.e. M2_HOME, m2eclipse, etc.? This was discussed on the dev list a while back, you can check the archives to see how it turned out. Ok, *where* on the dev list? I just spent 15 minutes looking for mention of this and the only thing I found that said anything about this was: http://www.mail-archive.com/d...@maven.apache.org/msg84980.html but hardly counts as being discussed. How about providing a link to what you're talking about? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote: As much fun as all this commentary is, unless Ken comes back and posts a reply, I feel like we're simply the victims of a drive-by trolling... As such, I recommend letting this thread die, at least until Ken comes back and adds something to the discussion... Ken??? Sure, happy to. I won't be quite as angry in this post as in the last one :-), but I still have a lot of complaints against the Maven way of doing things. I won't hit them all, here are a few random thoughts: 1) Maven is declarative vs. procedural. This is great, but Prolog has been that way for decades. Why build such a complex syntax when a much simpler one already existed. 2) Relates to 1). I still think this is important. AFAIK, XML was NEVER intended to be a syntax for direct editing by the user. It is needlessly verbose and redundant, and seriously obscures the actual intent of the code. As the simplest possible example, what is the point in writing someGenericOptionfalse/someGenericOption when what is really meant is the (IMHO) much easier to read someGenericOption = false. 3) Yes, I'm aware there is something called polyglot maven. (Haven't looked at it yet, as I don't want to add yet another layer of complexity to what I'm doing.) Doesn't the simple existence of this prove my point? There were never polyglot makefiles--in spite of all of their (numerous) problems, the syntax of makefiles was simple enough there was never a demand for them. 4) Maybe I'm missing something, but maven seems to be all about predefined maven tasks. (Not sure I'm using the right terminology). If there's something simple I can do from the command line, maven doesn't provide an obvious way for me to do it. 5) Maven is just too complex. The comment I've seen is, If users would just read a book..., but what if I don't have the time to read an entire book simply to figure out how to push my docs to github? With command-line access, I wouldn't need to do so. And if the project got so big that an ad hoc solution didn't suffice, _then_ I could come back and read the book. So those are just a few random thoughts. Make of them what you will. Thanks, Ken Wayne On Wed, Oct 13, 2010 at 5:13 PM, Rick Mangi rick.ma...@mtvn.com wrote: Flexible and elegant aren't necessarily the same thing... Any language that prides itself on its ability to be obfuscated can't be elegant ;-) That said, I do love it. As far as Maven goes, the elegance of maven is that it does 90% of what you need it to do with very little or no effort and the other 10% can be done without much hassle. On 10/13/10 10:48 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: It does. The rest of the language is rather ugly, though. -K On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote: I just enjoyed the bit about perl having elegant and concise data structures :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mavenicing bpel module
Two suggestions,
1) Use a more recent version of the antrun plugin. Version 1.1 is kind of out
dated. 1.6 was recently released.
2) Read the documentation on Using tasks not included in Ant's default jar [1]
[1]
http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html
Ron Gallagher
ATT
-Original Message-
From: José Vicente [mailto:jvia...@gmail.com]
Sent: Thursday, October 14, 2010 11:08 AM
To: users@maven.apache.org
Subject: mavenicing bpel module
Hi:
I'm mavenicing a BPEL Module but i has this error:
Embedded error: The following error occurred while executing this line:
C:\caps\NETBEA~1\EchoDeAfirma\BpelConexions\nbproject\build-impl.xml:79:
taskdef class
org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask
cannot be found
do you have any idea ?
pom.xml:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
artifactIdBpelConexions/artifactId
groupIdBpelConexions/groupId
packagingjar/packaging
version1.0-SNAPSHOT/version
build
plugins
!-- DISABLE COMPILER PLUGIN AS ANT RUN WOUDL COMPILE THE CODE
--
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
skiptrue/skip
source1.5/source
target1.5/target
excludes
exclude**/*.java/exclude
/excludes
/configuration
/plugin
!-- DISABLE the test code run as a junit test as this test is
integration test code.--
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.1.3/version
inheritedtrue/inherited
configuration
skiptrue/skip
excludes
exclude**/enginetest/*.java/exclude
/excludes
/configuration
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
idjbicomp-build-package/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
tasks
ant antfile=build.xml inheritAll=false
target=dist_se
/ant
copy overwrite=true file=dist/${
jbi.component.name}.jar
toFile=${project.build.directory}/${project.artifactId}-${project.version}.jar
/
!--
dist/EJBWSAfirma.jar
--
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
properties
jbi.component.name${project.artifactId}/jbi.component.name
/properties
/project
build-impl.xml :
?xml version=1.0 encoding=UTF-8?
!--
*** GENERATED FROM project.xml - DO NOT EDIT ***
*** EDIT ../build.xml INSTEAD ***
--
project name=BpelConexions-impl default=default basedir=..
target name=default depends=dist_se/
!--
INITIALIZATION SECTION
--
target name=pre-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-private depends=pre-init
property file=nbproject/private/private.properties/
/target
target name=init-userdir depends=pre-init,init-private
property name=user.properties.file
location=${netbeans.user}/build.properties/
/target
target name=init-user depends=pre-init,init-private,init-userdir
property file=${user.properties.file}/
/target
target name=init-project
depends=pre-init,init-private,init-userdir,init-user
property file=nbproject/project.properties/
/target
target name=do-init
depends=pre-init,init-private,init-userdir,init-user,init-project
available file=${src.dir}/../retrieved
property=retrieved.exists/
/target
target name=post-init
!-- Empty placeholder for easier customization. --
!-- You can override this target in the ../build.xml file. --
/target
target name=init-check
depends=pre-init,init-private,init-userdir,init-user,init-project,do-init
fail unless=src.dirMust set src.dir/fail
fail unless=build.dirMust set build.dir/fail
fail unless=dist.dirMust set dist.dir/fail
fail
War plugin renaming jars in WEB-INF/lib to jarname-RELEASE.jar
When I look in WEB-INF/lib dir of my exploded war I see that some (but not
all) of my jars are missing their version number. A jar that should be named
mybiglib-1.0.4.jar is named mybiglib-RELEASE.jar. It is the right jar but
the wrong name. I have seen some old bugs on the issue but they were closed
as “can’t repro” or “don’t care because it works”.
We do use the RELEASE keyword for versioning in some cases but not all
artifacts that use the RELEASE keyword have this issue. I played with the
outputFileNameMapping attribute and could successfully append “foo” to my
jar names but the RELEASE keyword remained.
outputFileNameMapping@{artifact...@-@{versi...@-foo.@{extension}@
/outputFileNameMapping
Yields mybiglib-RELEASE-foo.jar.
Should be mybiglib-1.0.4-foo.jar.
Is their any way to get consistent behavior in this regard? I would like my
jars in WEB-INF/lib to have version numbers in all cases.
Thanks,
L.K.
Re: maven is a swamp
On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:
As much fun as all this commentary is, unless Ken comes back and posts
a reply, I feel like we're simply the victims of a drive-by
trolling...
As such, I recommend letting this thread die, at least until Ken comes
back and adds something to the discussion... Ken???
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see the
comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an aha,
I understand what the major
and minor parts of the file are all about moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or the
convenience of the tools
that process it?
- Could someone well-versed in programming, but without an understanding of
maven, make at
least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no. In
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
So I guess my comment is, decent internals, horrible externals.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdykken.rex/groupId
artifactIdrex/artifactId
version0.5-SNAPSHOT/version
inceptionYear2010/inceptionYear
developers
developer
idkmcdonald/id
nameKenneth McDonald/name
emailykkenmcd [at] gmail com/email
/developer
/developers
licenses
license
nameLesser General Public License (LGPL)/name
urlhttp://www.gnu.org/copyleft/lesser.txt/url
distributionrepo/distribution
/license
/licenses
properties
scala.version2.8.0/scala.version
/properties
repositories
repository
idscala-tools.org/id
nameScala-Tools Maven2 Repository/name
urlhttp://scala-tools.org/repo-releases/url
/repository
/repositories
pluginRepositories
pluginRepository
idsnapshots.scala-tools.org/id
nameScala-Tools Maven2 Repository/name
urlhttp://scala-tools.org/repo-releases/url
/pluginRepository
/pluginRepositories
dependencies
dependency
groupIdorg.scala-lang/groupId
artifactIdscala-compiler/artifactId
version${scala.version}/version
/dependency
dependency
groupIdorg.scala-lang/groupId
artifactIdscala-library/artifactId
version${scala.version}/version
/dependency
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.scalatest/groupId
artifactIdscalatest/artifactId
version1.2/version
scopetest/scope
/dependency
/dependencies
build
sourceDirectorysrc/main/scala/sourceDirectory
testSourceDirectorysrc/test/scala/testSourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
/plugin
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.14.1/version
executions
execution
goals
goalcompile/goal
goaltestCompile/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
configuration
useManifestOnlyJarfalse/useManifestOnlyJar
includes
include**/*Test.*/include
include**/*Suite.*/include
/includes
/configuration
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.14.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
RE: maven is a swamp
To me, the answer is yes,yes, yes but then I don't see Maven as a
*programming* language.
To me I can quickly see what we are trying to do and what it needs to do
it.
In a world where Source + Tools = Product (where tools = tools +
libraries) I see documentation about the tools.
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-Original Message-
From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net]
Sent: Thursday, October 14, 2010 3:32 PM
To: Maven Users List
Subject: Re: maven is a swamp
On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:
As much fun as all this commentary is, unless Ken comes back and posts
a reply, I feel like we're simply the victims of a drive-by
trolling...
As such, I recommend letting this thread die, at least until Ken comes
back and adds something to the discussion... Ken???
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see
the comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an
aha, I understand what the major and minor parts of the file are all
about moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or
the convenience of the tools that process it?
- Could someone well-versed in programming, but without an understanding
of maven, make at least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no.
In terms of readability, this file (and all pom files I've seen) are
simply disasters. In terms of semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
So I guess my comment is, decent internals, horrible externals.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdykken.rex/groupId
artifactIdrex/artifactId
version0.5-SNAPSHOT/version
inceptionYear2010/inceptionYear
developers
developer
idkmcdonald/id
nameKenneth McDonald/name
emailykkenmcd [at] gmail com/email
/developer
/developers
licenses
license
nameLesser General Public License (LGPL)/name
urlhttp://www.gnu.org/copyleft/lesser.txt/url
distributionrepo/distribution
/license
/licenses
properties
scala.version2.8.0/scala.version
/properties
repositories
repository
idscala-tools.org/id
nameScala-Tools Maven2 Repository/name
urlhttp://scala-tools.org/repo-releases/url
/repository
/repositories
pluginRepositories
pluginRepository
idsnapshots.scala-tools.org/id
nameScala-Tools Maven2 Repository/name
urlhttp://scala-tools.org/repo-releases/url
/pluginRepository
/pluginRepositories
dependencies
dependency
groupIdorg.scala-lang/groupId
artifactIdscala-compiler/artifactId
version${scala.version}/version
/dependency
dependency
groupIdorg.scala-lang/groupId
artifactIdscala-library/artifactId
version${scala.version}/version
/dependency
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.scalatest/groupId
artifactIdscalatest/artifactId
version1.2/version
scopetest/scope
/dependency
/dependencies
build
sourceDirectorysrc/main/scala/sourceDirectory
testSourceDirectorysrc/test/scala/testSourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
/plugin
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.14.1/version
executions
execution
goals
goalcompile/goal
goaltestCompile/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
configuration
RE: Maven SQL plugin
Chris and Company i tried 12 ways from sunday and I could not get this plugin.xml to work for me debug statements display NPEs on any/all references to srcFiles I discovered the srcFiles array is not initted and not allocated Source file: org.codehaus.mojo.sql.SqlExecMojo parameter namesrcFiles/name typejava.io.File[]/type requiredfalse/required editabletrue/editable descriptionList of files containing SQL statements to load./description /parameter One solution is to refactor the array to use ArrayList and reconfig on pluginXml to implement java.util.ArrayListjava.io.File does work (at least for me) parameter namesrcFiles/name typejava.util.ArrayList/type requiredfalse/required editabletrue/editable descriptionList of files containing SQL statements to load./description /parameter this is more than a 1 line change and I have other things to do..i could do a fix but then theres the test-suite to worry about any possibility to get an official response from the author? Good Catch Chris! Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 14 Oct 2010 10:03:58 -0400 Subject: Re: Maven SQL plugin From: john.te...@gmail.com To: users@maven.apache.org Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Re: maven is a swamp
On 14/10/2010 3:32 PM, Kenneth McDonald wrote: On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote: As much fun as all this commentary is, unless Ken comes back and posts a reply, I feel like we're simply the victims of a drive-by trolling... As such, I recommend letting this thread die, at least until Ken comes back and adds something to the discussion... Ken??? Hi Wayne, I'll post one more response to your well-thought-out question. Here is the pom file I'm currently using: and just so you don't have to scroll all the way to the bottom to see the comments, I'll put them here :-) - Is there _anything_ in the structure of this file which leads me to an aha, I understand what the major and minor parts of the file are all about moment? - Does the file get across what it means both concisely and clearly? - Is the syntax of the file for the convenience of the programmer, or the convenience of the tools that process it? - Could someone well-versed in programming, but without an understanding of maven, make at least some sense of this file? IMHO, the answers are no, no, for the convenience of the tools, and no. In terms of readability, this file (and all pom files I've seen) are simply disasters. In terms of semantics--OK, pretty good. In terms of usability, what a piece of garbage! But why would you ever see this? Doesn't your IDE support Maven? There is no reason why any of my guys would ever look at this as XML. We use Eclipse/STS as an IDE and this simple POM would never require anyone to do anything in XML. Hand editing POMs is not a reasonable thing to do in 2010 unless you are debugging Maven and want to break a POM to see what Maven does. I will admit to occasionally cutting and pasting between XML files if I have a lot of duplicate sections but this is a once in a project thing that hardly ever happens I am more likely to copy the whole POM and use the editor to finish. You need to look at parent POMs to get rid of the clutter: This goes in the project parent POM so you don't put it in a POM that generates an artifact: developers developer idkmcdonald/id nameKenneth McDonald/name emailykkenmcd [at] gmail com/email /developer /developers licenses license nameLesser General Public License (LGPL)/name urlhttp://www.gnu.org/copyleft/lesser.txt/url distributionrepo/distribution /license /licenses All of this belongs in the parent as well since it will be the same for each module. plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.1/version /plugin plugin groupIdorg.scala-tools/groupId artifactIdmaven-scala-plugin/artifactId version2.14.1/version executions execution goals goalcompile/goal goaltestCompile/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.6/version configuration useManifestOnlyJarfalse/useManifestOnlyJar includes include**/*Test.*/include include**/*Suite.*/include /includes /configuration /plugin /plugins As does this: reporting plugins plugin groupIdorg.scala-tools/groupId artifactIdmaven-scala-plugin/artifactId version2.14.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.1/version /plugin /plugins /reporting Your POM gets pretty small and easy to edit using a POM editor once you move out the stuff that belongs elsewhere. Non of this stuff is going to trouble the Eclipse POM editor even if you do not do it the smart way. Ron So I guess my comment is, decent internals, horrible externals. project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdykken.rex/groupId artifactIdrex/artifactId version0.5-SNAPSHOT/version inceptionYear2010/inceptionYear developers developer idkmcdonald/id nameKenneth McDonald/name emailykkenmcd [at] gmail com/email
Re: Checkstyle/maven/parent POM
* In checkstyle plugin 2.6, it appears that the suppressionsLocation/ suppressionsFileExpression don't work. I spent a significant amount of time trying all manner of settings for those, but the exclusions file was never found. Did you check the source code for the plugin and maybe add some logging statements to see what's going on there? You may have found a bug. Plugins are (generally) super simple to figure out. Check it out and donate your patch back if you do find a bug. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven SQL plugin
Hi Chris, It has been my experience of ~2.5 years that the order is maintained with a srcFile list, though I see nothing in the plugin docs that specifically mentions this, nor have I had the time (or inclination) to read the source... We have a relatively small number of sql files, 4 in one place, 2 in another, so it is not too bad for us to list them all by name. FWIW, we are using version 1.4 of the plugin. Cheers, John On Thu, Oct 14, 2010 at 10:27 AM, Chris Odney chris.od...@gmail.com wrote: Hi John, I never noticed the option of srcFiles as against fileset My understanding is the list of files specified using srcFiles are executed in the order they are specified whereas it is not so in the case of fileset(this is when orderFile attribute is not specified). Am I wrong? Thanks for the reply, Chris. On Thu, Oct 14, 2010 at 7:33 PM, John Singleton john.te...@gmail.com wrote: Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Re: Maven SQL plugin
Hi gang, I can help with the plugin. There have been a few authors on it over the years, and there may be some gaps in coverage. Apologies for that. Would it be too difficult to get a small project in HSQL that demonstrates the issue? I don't use the plugin any more, but am happy to help out. It's probably due for a release as well. Cheers, Brian On Oct 14, 2010, at 3:44 PM, Martin Gainty wrote: Chris and Company i tried 12 ways from sunday and I could not get this plugin.xml to work for me debug statements display NPEs on any/all references to srcFiles I discovered the srcFiles array is not initted and not allocated Source file: org.codehaus.mojo.sql.SqlExecMojo parameter namesrcFiles/name typejava.io.File[]/type requiredfalse/required editabletrue/editable descriptionList of files containing SQL statements to load./description /parameter One solution is to refactor the array to use ArrayList and reconfig on pluginXml to implement java.util.ArrayListjava.io.File does work (at least for me) parameter namesrcFiles/name typejava.util.ArrayList/type requiredfalse/required editabletrue/editable descriptionList of files containing SQL statements to load./description /parameter this is more than a 1 line change and I have other things to do..i could do a fix but then theres the test-suite to worry about any possibility to get an official response from the author? Good Catch Chris! Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 14 Oct 2010 10:03:58 -0400 Subject: Re: Maven SQL plugin From: john.te...@gmail.com To: users@maven.apache.org Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Assemblies and filtering
Im trying to construct an assembly descriptor to replicate the output of our ant tasks. Ive run into a few issues with filtering 1) is there a way to do a mass rename on filter? the current setup gives a special *.vpp extention to files that need to be filtered with velocity. after filters have been applied, the .vpp extention is stripped off and the resulting xml, sh, dat, etc file is used in the distribution. Does maven support this? ive looked over the documentation and nothing seems to suggest it does. Specifying individual files is not workable because the number of files to be filtered is quite large, and developers are free to add files when needed. 2) During the filtering process - is there a way to throw an error and fail the build if one or more properties are not found? Ant does this quite nicely, but maven just ignores any missing properties. 3) When trying to use shared assembly descriptors, it seems componentDescriptors are not supported. When i try to use the shared assembly, i get an error: Error reading assemblies: Failed to locate component descriptor: src/assemblies/logfiles.xml the top of my shared assembly file looks like this: assembly idDist/id formats formatzip/format /formats componentDescriptors componentDescriptorsrc/assemblies/logfiles.xml/componentDescriptor /componentDescriptors includeBaseDirectoryfalse/includeBaseDirectory I made sure the file src/assemblies/logfiles.xml is included in the project used to install the shared descriptor -- but it doesnt seem to be called. Any ideas on how to fix this?
Re: maven is a swamp
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see the
comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an
aha, I understand what the major
and minor parts of the file are all about moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or the
convenience of the tools
that process it?
- Could someone well-versed in programming, but without an understanding of
maven, make at
least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no. In
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
But why would you ever see this?
Doesn't your IDE support Maven?
I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes me
look at the pom as xml. But
even that begs the question.
There is no reason why any of my guys would ever look at this as XML.
We use Eclipse/STS as an IDE and this simple POM would never require anyone
to do anything in XML.
Hand editing POMs is not a reasonable thing to do in 2010 unless you are
debugging Maven and want to break a POM to see what Maven does.
I agree. Hand editing POMs is not reasonable because POMs are not amenable to
hand editing. That's a problem
of the POM format, not of the concept of hand editing.
You need to look at parent POMs to get rid of the clutter:
This goes in the project parent POM so you don't put it in a POM that
generates an artifact:
That may be the case (and is something that is nonobvious from reading basic
maven docs), but...
developers
developer
idkmcdonald/id
nameKenneth McDonald/name
emailykkenmcd [at] gmail com/email
/developer
/developers
licenses
license
nameLesser General Public License (LGPL)/name
urlhttp://www.gnu.org/copyleft/lesser.txt/url
distributionrepo/distribution
/license
/licenses
developers = [{id: kmcdonald, name: Kenneth McDonald, email: ykkenmcd [at]
gmail com}]
licenses = [
{
name: Lesser General Public License (LGPL),
url: http://www.gnu.org/copyleft/lesser.txt;
distribution: repo
}
]
That's ten lines of code vs. fifteen, and the ten lines are _much_ more
readable. And I could've compressed those ten lines further without much
effort. C'mon, people, where's your sense of proportion? The syntax I've used
is pretty Pythonic (not sure if it's exactly that since I've used
Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_
time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the
problem with using a syntax that is:
a) easily parsed
b) easily read
c) easily written
Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that
things should be text _unless_ they are explicitly marked as not text. This
completely flies in the face of I don't know how many years of CS, and is
simply wrong. Most of most coding constructs is control logic. It follows that
it should be easy to write the control logic, a little bit more difficult to
write the literals. Now when HTML was being designed, that was different,
because they were designing to a format whose primary purpose was visual
represention on a page. Guess what, boys and girls--we're not doing that
anymore! XML is a control format, and should make it easy to write the control
parts of the statements, and a little tougher to write the literal parts. The
fact that it doesn't do this is evidence if its almost complete inadequacy to
serve as a control language.
...I've edited out a lot here below for brevity.
Cheers,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
Hi Kenneth !
Drawback of using a Python/YAML like solution is code completion.
I remember some discussion where Jason was planning to add XML namespaces
for plugins, allowing to define specific schemas for configuration tags.
We are OK, this is not done yet, but the perspective is interesting to my
mind (it would offer inline documentation while hand coding the pom...)
Using YAML would lose this possibility to my mind (since data won't be
strongly typed).
Frédéric
On Thu, Oct 14, 2010 at 11:56 PM, Kenneth McDonald
kenneth.m.mcdon...@sbcglobal.net wrote:
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see
the comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an
aha, I understand what the major
and minor parts of the file are all about moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or
the convenience of the tools
that process it?
- Could someone well-versed in programming, but without an understanding
of maven, make at
least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no.
In terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms
of semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
But why would you ever see this?
Doesn't your IDE support Maven?
I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it
makes me look at the pom as xml. But
even that begs the question.
There is no reason why any of my guys would ever look at this as XML.
We use Eclipse/STS as an IDE and this simple POM would never require
anyone to do anything in XML.
Hand editing POMs is not a reasonable thing to do in 2010 unless you are
debugging Maven and want to break a POM to see what Maven does.
I agree. Hand editing POMs is not reasonable because POMs are not amenable
to hand editing. That's a problem
of the POM format, not of the concept of hand editing.
You need to look at parent POMs to get rid of the clutter:
This goes in the project parent POM so you don't put it in a POM that
generates an artifact:
That may be the case (and is something that is nonobvious from reading
basic maven docs), but...
developers
developer
idkmcdonald/id
nameKenneth McDonald/name
emailykkenmcd [at] gmail com/email
/developer
/developers
licenses
license
nameLesser General Public License (LGPL)/name
urlhttp://www.gnu.org/copyleft/lesser.txt/url
distributionrepo/distribution
/license
/licenses
developers = [{id: kmcdonald, name: Kenneth McDonald, email: ykkenmcd
[at] gmail com}]
licenses = [
{
name: Lesser General Public License (LGPL),
url: http://www.gnu.org/copyleft/lesser.txt;
distribution: repo
}
]
That's ten lines of code vs. fifteen, and the ten lines are _much_ more
readable. And I could've compressed those ten lines further without much
effort. C'mon, people, where's your sense of proportion? The syntax I've
used is pretty Pythonic (not sure if it's exactly that since I've used
Perl/Python/JavaScript so interchangeably), but it's been around for a
_LONG_ time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT
is the problem with using a syntax that is:
a) easily parsed
b) easily read
c) easily written
Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea
that things should be text _unless_ they are explicitly marked as not text.
This completely flies in the face of I don't know how many years of CS, and
is simply wrong. Most of most coding constructs is control logic. It follows
that it should be easy to write the control logic, a little bit more
difficult to write the literals. Now when HTML was being designed, that was
different, because they were designing to a format whose primary purpose was
visual represention on a page. Guess what, boys and girls--we're not doing
that anymore! XML is a control format, and should make it easy to write the
control parts of the statements, and a little tougher to write the literal
parts. The fact that it doesn't do this is evidence if its almost complete
inadequacy to serve as a control language.
...I've edited out a lot here below for brevity.
Cheers,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On 14 October 2010 22:56, Kenneth McDonald
kenneth.m.mcdon...@sbcglobal.net wrote:
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see the
comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an
aha, I understand what the major
and minor parts of the file are all about moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or the
convenience of the tools
that process it?
- Could someone well-versed in programming, but without an understanding of
maven, make at
least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no. In
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
But why would you ever see this?
Doesn't your IDE support Maven?
I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes
me look at the pom as xml. But
even that begs the question.
IntelliJ kicks ass
There is no reason why any of my guys would ever look at this as XML.
We use Eclipse/STS as an IDE and this simple POM would never require anyone
to do anything in XML.
Hand editing POMs is not a reasonable thing to do in 2010 unless you are
debugging Maven and want to break a POM to see what Maven does.
I agree. Hand editing POMs is not reasonable because POMs are not amenable to
hand editing. That's a problem
of the POM format, not of the concept of hand editing.
I routinely edit my pom's by hand using vi, I do not feel any major
pain so doing, and I have some rather complex pom's at that... I have
one pom that starts two jetty, selenium, a derby database, some other
odds and sods and runs integration tests with failsafe... ok ok ok so
i'm a pmc, but still it's no big deal working with the pom as is
You need to look at parent POMs to get rid of the clutter:
This goes in the project parent POM so you don't put it in a POM that
generates an artifact:
That may be the case (and is something that is nonobvious from reading basic
maven docs), but...
developers
developer
idkmcdonald/id
nameKenneth McDonald/name
emailykkenmcd [at] gmail com/email
/developer
/developers
licenses
license
nameLesser General Public License (LGPL)/name
urlhttp://www.gnu.org/copyleft/lesser.txt/url
distributionrepo/distribution
/license
/licenses
developers = [{id: kmcdonald, name: Kenneth McDonald, email: ykkenmcd
[at] gmail com}]
licenses = [
{
name: Lesser General Public License (LGPL),
url: http://www.gnu.org/copyleft/lesser.txt;
distribution: repo
}
]
That's ten lines of code vs. fifteen, and the ten lines are _much_ more
readable. And I could've compressed those ten lines further without much
effort. C'mon, people, where's your sense of proportion? The syntax I've used
is pretty Pythonic (not sure if it's exactly that since I've used
Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_
time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the
problem with using a syntax that is:
a) easily parsed
b) easily read
c) easily written
Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that
things should be text _unless_ they are explicitly marked as not text. This
completely flies in the face of I don't know how many years of CS, and is
simply wrong. Most of most coding constructs is control logic. It follows
that it should be easy to write the control logic, a little bit more
difficult to write the literals. Now when HTML was being designed, that was
different, because they were designing to a format whose primary purpose was
visual represention on a page. Guess what, boys and girls--we're not doing
that anymore! XML is a control format, and should make it easy to write the
control parts of the statements, and a little tougher to write the literal
parts. The fact that it doesn't do this is evidence if its almost complete
inadequacy to serve as a control language.
...I've edited out a lot here below for brevity.
Cheers,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
Re: Maven SQL plugin
http://jira.codehaus.org/browse/MSQL-53 addresses exactly this issue... On Thu, Oct 14, 2010 at 5:12 PM, John Singleton john.te...@gmail.comwrote: Hi Chris, It has been my experience of ~2.5 years that the order is maintained with a srcFile list, though I see nothing in the plugin docs that specifically mentions this, nor have I had the time (or inclination) to read the source... We have a relatively small number of sql files, 4 in one place, 2 in another, so it is not too bad for us to list them all by name. FWIW, we are using version 1.4 of the plugin. Cheers, John On Thu, Oct 14, 2010 at 10:27 AM, Chris Odney chris.od...@gmail.comwrote: Hi John, I never noticed the option of srcFiles as against fileset My understanding is the list of files specified using srcFiles are executed in the order they are specified whereas it is not so in the case of fileset(this is when orderFile attribute is not specified). Am I wrong? Thanks for the reply, Chris. On Thu, Oct 14, 2010 at 7:33 PM, John Singleton john.te...@gmail.com wrote: Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: srcFiles srcFile[file1]/srcFile srcFile[file2}/srcFile ... /srcFiles HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney chris.od...@gmail.com wrote: Hi, I am facing some problem in ordering the sql execution. We have one sql script file for each table under one directory. Ex: There is user.sql and role.sql in the directory c:\SqlScripts. We are using the sql maven plugin to execute these sql files. The role table has a Foriegn key to the user table and the execution is failing because the plugin is trying to execute the role.sql before user.sql. I cannot use the orderfile attribute as we specify the fileset as c:\SqlScripts\*.sql. How do I overcome this problem? I see 2 solutions: 1) Merge all scripts into one file in the creation order, the script to create role comes after the script to create user. 2)Remove the * wildcard and specify each file in the filelist attribute in the order of execution. 3)Number the name of the files according to the execution order ex: 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure if this would work though, as the ordering may not be applied) Any more elegant solutions? Thank you, Chris.
Re: maven is a swamp
On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote: Hi Kenneth ! Drawback of using a Python/YAML like solution is code completion. But the payoff is you don't need code completion! You just put in a )/}/] or so, and your code is completed! Any yes, any competent text editor can check for braces mismatches etc. I recognize the concern, I just don't see it as valid. I've been programming in Python for twenty years now. I won't say it's always the case, but in a large number of cases, the terseness you gain in your code more than offsets things like code completion, static analysis, etc. And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. Just to let you know I'm not firmly entrenched in one camp, the static analysis that Scala supplies seems to me to overcome the inherit benefits of dynamic analysis. Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. It feels like your entire complaint about Maven boils down to the use of XML in the pom... You can't simply accept this as a trade-off for the other benefits offered by Maven, or offer up an alternative YAML/JSON-style pom file format (that you've developed) ala polyglot?? Yes, the XML is not hugely user-friendly. Yes, an alternative format that is more user-friendly would be nice. The existence of polyglot is sufficient evidence of these points. But I have never felt this alone was a huge barrier to Maven adoption nor to my own personal usage of Maven -- generally hand edited in vi or another similar tool, I don't use m2e often. And I'm not even a PMC member like Stephen. ;-) If Maven 4 moved to a YAML/JSON model, would that make you happy enough to use Maven and simultaneously solve world hunger, bring peace to the world, etc? Or would you just find more things to complain about? ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
I won't argue about closing tag, it's obvious a } is cleaner than a /myTag But I insist about code completion that is : - I'm in build section, I don't remember how my tag for target directory is named, I hit ctrl+space (under eclipse *cough*) and it provide me with all available tags in the build section ... - ... plus it provides, too, a documentation for all tags ! I don't know if with YAML, we can use an xml schema to describe the current document structure. If so, it will have all the benefits. If not, it will lose something important to my point of view. Frédéric On Fri, Oct 15, 2010 at 12:30 AM, Kenneth McDonald kenneth.m.mcdon...@sbcglobal.net wrote: On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote: Hi Kenneth ! Drawback of using a Python/YAML like solution is code completion. But the payoff is you don't need code completion! You just put in a )/}/] or so, and your code is completed! Any yes, any competent text editor can check for braces mismatches etc. I recognize the concern, I just don't see it as valid. I've been programming in Python for twenty years now. I won't say it's always the case, but in a large number of cases, the terseness you gain in your code more than offsets things like code completion, static analysis, etc. And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. Just to let you know I'm not firmly entrenched in one camp, the static analysis that Scala supplies seems to me to overcome the inherit benefits of dynamic analysis. Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
Step 1: even fairly straightforward POMs that need more than the default conventions rapidly get verbose and hard to read due to XML. Step 2: Hiding behind that, though, there are, I claim, areas of genuine confusion. For the simple cases, it's fine to say 'convention over configuration'. Lots of us can agree on the conventions for turning a heap of Java files into a Jar. However, for better or worse, many of us have to do things with builds for which there is no self-evident convention. The maven plugins for the job pick something, and then reality shows up and kicks us in the head. XML amplifies this, but there is an underlying problem there. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On Oct 14, 2010, at 6:30 PM, Kenneth McDonald wrote: On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote: Hi Kenneth ! Drawback of using a Python/YAML like solution is code completion. But the payoff is you don't need code completion! You just put in a )/}/] or so, and your code is completed! Any yes, any competent text editor can check for braces mismatches etc. I recognize the concern, I just don't see it as valid. I've been programming in Python for twenty years now. I won't say it's always the case, but in a large number of cases, the terseness you gain in your code more than offsets things like code completion, static analysis, etc. And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. http://github.com/sonatype/polyglot-maven/blob/master/pmaven-yaml/src/test/resources/pom.config.yml Already works with Maven's current core. Along with Scala, Clojure, and Ruby. A fact to note though is that I've asked over 2k people over the last two years at talks and in any average crowd the people who care to have a different format or DSL is around 3%. At any rate anything is possible with Maven 3. Just to let you know I'm not firmly entrenched in one camp, the static analysis that Scala supplies seems to me to overcome the inherit benefits of dynamic analysis. Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: maven is a swamp
On 14/10/2010 7:01 PM, Wayne Fay wrote: And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. It does not seem like anything to consider since IDE's can provide a nice GUI editor. It feels like your entire complaint about Maven boils down to the use of XML in the pom... You can't simply accept this as a trade-off for the other benefits offered by Maven, or offer up an alternative YAML/JSON-style pom file format (that you've developed) ala polyglot?? Yes, the XML is not hugely user-friendly. Yes, an alternative format that is more user-friendly would be nice. The existence of polyglot is sufficient evidence of these points. But I have never felt this alone was a huge barrier to Maven adoption nor to my own personal usage of Maven -- generally hand edited in vi or another similar tool, I don't use m2e often. And I'm not even a PMC member like Stephen. ;-) If Maven 4 moved to a YAML/JSON model, would that make you happy enough to use Maven and simultaneously solve world hunger, bring peace to the world, etc? Or would you just find more things to complain about? ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
