Re: JDK 1.5 is out, and it breaks Maven
Jörg Schaible wrote: Hi Berin, Jörg Schaible wrote on Wednesday, March 03, 2004 9:08 AM: Berin Loritsch wrote on Tuesday, March 02, 2004 10:52 PM: Thanks to the new JDK 1.5 installer, the default location to install both the runtime and the developer kit is within the %PROGRAM_FILES% directory. That means a space is in the path to the java command no matter how you slice it. The current maven script for Cygwin compatibility does not properly handle this arrangement--because it never had to until now. The proper way to solve the issue is to add surrounding quotes to the $JAVACMD that starts up maven. Enclosed is a script that works. Berin, can you raise an issue for the cli component: http://jira.codehaus.org/secure/BrowseProject.jspa?id= 10030 just saw that there is already an issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1179 can you attach the file there? Thank you. I created a new entry, and then I saw this message, so I attached the fix in both places. I also created a new entry for the maven-java-plugin module to fix the compilation defaults issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDK 1.5 is out, and it breaks Maven
Thanks to the new JDK 1.5 installer, the default location to install both the
runtime and the developer kit is within the %PROGRAM_FILES% directory. That
means a space is in the path to the java command no matter how you slice it.
The current maven script for Cygwin compatibility does not properly handle
this arrangement--because it never had to until now. The proper way to solve
the issue is to add surrounding quotes to the $JAVACMD that starts up maven.
Enclosed is a script that works.
Also a problem is that the defaults on the javac compiler are different, and
the fact that we set the -target option without specifying the -source
option means that all compilation will fail with the following message:
javac: source release 1.4 requires target release 1.4
The default -source option is 1.4 for JDK 1.5, which means you need a
-target of 1.4. Actually, unless you intend to have Java 1.1 compatible
binaries, the -target option should never be set.
As a temperary workaround, how do we override the -source property in
Maven?
#!/bin/sh
# Copyright (c) 2001-2002 The Apache Software Foundation. All rights
# reserved.
FOREHEAD_VERSION=1.0-beta-5
if [ -z $MAVEN_OPTS ] ; then
MAVEN_OPTS=-Xmx256m
fi
if [ -f $HOME/.mavenrc ] ; then
. $HOME/.mavenrc
fi
# OS specific support. $var _must_ be set to either true or false.
cygwin=false;
darwin=false;
case `uname` in
CYGWIN*) cygwin=true ;;
Darwin*) darwin=true ;;
esac
if [ -z $MAVEN_HOME ] ; then
# try to find MAVEN
if [ -d /opt/maven ] ; then
MAVEN_HOME=/opt/maven
fi
if [ -d ${HOME}/maven ] ; then
MAVEN_HOME=${HOME}/maven
fi
## resolve links - $0 may be a link to maven's home
PRG=$0
progname=`basename $0`
saveddir=`pwd`
# need this for relative symlinks
cd `dirname $PRG`
while [ -h $PRG ] ; do
ls=`ls -ld $PRG`
link=`expr $ls : '.*- \(.*\)$'`
if expr $link : '.*/.*' /dev/null; then
PRG=$link
else
PRG=`dirname $PRG`/$link
fi
done
MAVEN_HOME=`dirname $PRG`/..
# make it fully qualified
MAVEN_HOME=`cd $MAVEN_HOME pwd`
cd $saveddir
fi
# For Cygwin, ensure paths are in UNIX format before anything is touched
if $cygwin ; then
[ -n $MAVEN_HOME ]
MAVEN_HOME=`cygpath --unix $MAVEN_HOME`
[ -n $MAVEN_HOME_LOCAL ]
MAVEN_HOME_LOCAL=`cygpath --unix $MAVEN_HOME_LOCAL`
[ -n $JAVA_HOME ]
JAVA_HOME=`cygpath --unix $JAVA_HOME`
[ -n $CLASSPATH ]
CLASSPATH=`cygpath --path --unix $CLASSPATH`
fi
if [ -z $JAVACMD ] ; then
if [ -n $JAVA_HOME ] ; then
if [ -x $JAVA_HOME/jre/sh/java ] ; then
# IBM's JDK on AIX uses strange locations for the executables
JAVACMD=$JAVA_HOME/jre/sh/java
else
JAVACMD=$JAVA_HOME/bin/java
fi
else
JAVACMD=java
fi
fi
if [ ! -x $JAVACMD ] ; then
echo Error: JAVA_HOME is not defined correctly.
echo We cannot execute $JAVACMD
exit
fi
if [ -z $JAVA_HOME ] ; then
echo Warning: JAVA_HOME environment variable is not set.
echo If build fails because sun.* classes could not be found
echo you will need to set the JAVA_HOME environment variable
echo to the installation directory of java.
fi
MAVEN_ENDORSED==${JAVA_HOME}/lib/endorsed:${MAVEN_HOME}/lib/endorsed
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
[ -n $MAVEN_HOME ]
MAVEN_HOME=`cygpath --path --windows $MAVEN_HOME`
[ -n $MAVEN_HOME_LOCAL ]
MAVEN_HOME_LOCAL=`cygpath --path --windows $MAVEN_HOME_LOCAL`
[ -n $JAVA_HOME ]
JAVA_HOME=`cygpath --path --windows $JAVA_HOME`
[ -n $MAVEN_ENDORSED ]
MAVEN_ENDORSED=`cygpath --path --windows $MAVEN_ENDORSED`
fi
# For Darwin, use classes.jar for TOOLS_JAR
TOOLS_JAR=${JAVA_HOME}/lib/tools.jar
if $darwin; then
TOOLS_JAR=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Classes/classes.jar
fi
MAIN_CLASS=com.werken.forehead.Forehead
if [ -n $MAVEN_HOME_LOCAL ]; then
$JAVACMD \
$MAVEN_OPTS \
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
\
-Djava.endorsed.dirs=${MAVEN_ENDORSED} \
-classpath ${MAVEN_HOME}/lib/forehead-${FOREHEAD_VERSION}.jar \
-Dforehead.conf.file=${MAVEN_HOME}/bin/forehead.conf \
-Dtools.jar=$TOOLS_JAR \
-Dmaven.home=${MAVEN_HOME} \
-Dmaven.home.local=${MAVEN_HOME_LOCAL} \
$MAIN_CLASS $@
fi
if [ ! -n $MAVEN_HOME_LOCAL ]; then
$JAVACMD \
$MAVEN_OPTS \
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
\
-Djava.endorsed.dirs=${MAVEN_ENDORSED} \
-classpath ${MAVEN_HOME}/lib/forehead-${FOREHEAD_VERSION}.jar \
-Dforehead.conf.file=${MAVEN_HOME}/bin/forehead.conf \
-Dtools.jar=$TOOLS_JAR \
-Dmaven.home=${MAVEN_HOME} \
$MAIN_CLASS $@
fi
setting up Maven on Linux
I want to set up Maven 1.0rc1 on my linux laptop for all users, but I am running into problems because all new plugins need to be installed by root, which makes the process of installing and debugging plugins a real problem. I have set the plugins directory with the following settings: chgrp -R users plugins chmod -R g+w plugins I still can't let users update and add plugins at this location. Also, how many others are using Maven with a real operating system (Windows doesn't count)? The issues are completely with permissions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting up Maven on Linux
__matthewHawthorne wrote: I think you have the right idea. But I've never been able to get a shared plugin directory working. I allow them to be unpacked in the default dir ~/.maven/plugins. I have been able to set up my local repository in the way that you're suggesting though. Try doing chgrp and chmod with the -v (verbose) option to make sure that all files are being affected. The problem is the way the plugin:install goal works. It modifies the installation plugin directory, as well as the ~/.maven/plugins. Normally this isn't a problem--until you try to do plugin development. Berin Loritsch wrote: I want to set up Maven 1.0rc1 on my linux laptop for all users, but I am running into problems because all new plugins need to be installed by root, which makes the process of installing and debugging plugins a real problem. I have set the plugins directory with the following settings: chgrp -R users plugins chmod -R g+w plugins I still can't let users update and add plugins at this location. Also, how many others are using Maven with a real operating system (Windows doesn't count)? The issues are completely with permissions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting up Maven on Linux
[EMAIL PROTECTED] wrote: Hi, I'm using Maven on a SuSE 9.0 (before that, 8.1 and 8.2). I use following setup: in /usr, I've created a directory called java. Below that directory, I install all my java stuff such as ant, maven, jdk's etc. I've executed the commands: chgrp -R users /usr/java chmod -R g+w /usr/java I know, that this gives any user access to modify anything below the /usr/java directory, but on my machine, the only user is me. Hmm. I have done this, or something like it. I still can't get access. I originally did not have me in my users group, but even with that fix I can't seem to have write access to the plugins directory. You would need to give the users access to write into the repository directory too, if you wish to use a single repository and not one pr. user. I've been quite happy with Linux/maven, I've used maven for quite a while. br, /Sverre Quoting Berin Loritsch [EMAIL PROTECTED]: I want to set up Maven 1.0rc1 on my linux laptop for all users, but I am running into problems because all new plugins need to be installed by root, which makes the process of installing and debugging plugins a real problem. I have set the plugins directory with the following settings: chgrp -R users plugins chmod -R g+w plugins I still can't let users update and add plugins at this location. Also, how many others are using Maven with a real operating system (Windows doesn't count)? The issues are completely with permissions. - 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: Source code analyzer for unused method detection?
Siegfried Goeschl wrote: Oops, considering dynamic class loading and reflection it is actually impossible ... Cheers, Siegfried Goeschl I can second that--but I can go one further. Due to the type of design and true separation of implementation/interface with Avalon style components, each component appears to be completely separate. So, while we might be able to tell if an interface method is called, it will almost always be by something that no tool can directly trace. The only way to tell in systems like that is to perform a certain type of profiling. There are three types of profiling, and most people are only familiar with performance profiling. The other types are memory profiling and coverage profiling. Profiling requires that the application be run through a JVM with profiling extensions added, and output the results of the run to some output file (unless you have a commercial tool that give you a GUI at runtime). The normal extensions included with the sun JVM will allow you to examine the garbage collection and performance aspects, but memory fails me if it can do coverage testing. Adding an extension requires some C/C++ development, which is platform dependant. However, you will even be able to test for orphan private methods. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source code analyzer for unused method detection?
Paul Libbrecht wrote: Nooo... I think users of such a tool would accept to write by hand the methods that should be considered as entry-points to the package! I am not advocating that this project build such an animal. All I am saying is that when you have every piece as truly isolated as possible, you can't authoritatively tell what is used and not used unless you run it in the application. You can manually define certain interfaces to be the entry-points for a set of components, but what if one of the methods on the interface is never called once in the system? There is no ideal solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jxr-plugin fails if '_' in packagename
Kumar, Vaidhyanatha K. wrote: Matthias, Did that fix help you. I tried your suggestion and I still have the summary and other frames generated incorrectly. Vaidhy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 3:13 AM To: [EMAIL PROTECTED] Subject: RE: jxr-plugin fails if '_' in packagename Oooh. That would affect me too. Since I can't use a '-' in package names, I substitute the '_' for that character. That way my d-haven.org url becomes an org.d_haven package. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More constructive criticism
With ANT 1.6 on the horrizon, it appears that there are some new issues to worry about. For instance, the general impression that Maven is good to you if you are good to Maven: http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168 My question comes in this form: How much difference is there between a Maven 1.0 and the next generation Maven that fixes a bunch of the issues we already have? I mean, will the existing plugins work? Is the repository compatible? If so, then I highly recommend the NG Maven sooner than later. If not, what can be done to make the plugins compatible? What work needs to be done in that respect? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More constructive criticism
[EMAIL PROTECTED] wrote: snip/ Also, getting started--esp. if you have several smaller projects that make up one larger project is not very easy. For instance I have my GUIApp project using Maven. It works great, and the reactor (once I got it working)does its job. Unfortunately, getting the parent project to create a distribution with the proper documentation and packaging isn't set up. I'm somewhat at a loss how to do this. Have you looked at how Maven produces it's installation/distribution? :) Remember, I am playing devil's advocate here. I will look at it, but the point is that I *shouldn't* have to. Conversely, with ANT, while it can be painful, it is obvious how to get things done. It's also DEAD easy to write Maven plugins. My experience is a bit different in this matter. The chief accomplice to this issue is the lack of any meaningful documentation on Jelly. You sort of have to discover how it is used and what is legal syntax. The thing is that with the pre/post goal operations, I can easily enhance existing behavior, but certain things required me to change an existing plugin--which should be happily part of the Maven RC1 by now. Remember that it depends on *what* you want to do. Easy things are easy, but hard things are seemingly impossible. In fact, the pre/post goal thing is part of the reason for the emergent behavior that I described. You see, if I call guiapp:install-snapshot, the JARs created with my GUIApp plugin will have the meta-info I wanted. If I call the jar:install-snapshot, I won't get the meta-info I wanted, even though I provide a preGoal name=jar:install-snapshot/ entry. It took me a while to figure this out. Also, how do you keep certain plugins from interacting with the build if you don't want them to? I imagine that eventually we will have some plugins that conflict with one another. I think the best thing that describes developing a Maven plugin, and trying to make it work the way you want it to is emergent behavior. In [snip] You mean something like http://wiki.codehaus.org/maven/HowToCreateYourFirstPlugIn2 is emergent behaviour? You and I have very different opinions on that one. How many plugins are that braindead? Any plugin that defines pre/post goals that modify the behavior of an installed plugin in some way classifies as emergent behavior. It's not a dig, but it is reality. As it is, Maven is very usable, and I like it alot. I also think it can be improved to provide some level of predictability. Speak to me in words I can use to create issues :-) :) Some of it comes from the need for strategy docs. The simple case is documented, but what about the more complex sub-project style projects? There is little to help in that regard. Some of it comes from using a scripting language that has no meaningful documentation so unless you have been initiated you are in the dark. Other issues come from the loose pre/post goal type of issues. Its a hard balance to walk. On one hand a rigid definition of build stages will help to provide standard interfaces for making parts of the build happen in very predictable manners. On the other hand, defining that rigid set of interfaces is not easy, and doesn't allow for some truly flexible solutions we can do now. I really have no advice on this. All I can do is play devil's advocate, or explain the points of difficulty I have had. To be fair, this community has been very helpful to me, and it is home to a group of top notch folks. It's alot easier to manage my projects with Maven than plain ANT, and have a level of consistency with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More constructive criticism
[EMAIL PROTECTED] wrote: news [EMAIL PROTECTED] wrote on 01/10/2003 01:18:56 AM: [EMAIL PROTECTED] wrote: [snip] Have you looked at how Maven produces it's installation/distribution? :) Remember, I am playing devil's advocate here. I will look at it, but the point is that I *shouldn't* have to. Oh, I get it, Maven is the tool you use without any other samples. I see the point overall. Make the hard things easier. It would really help if someone would help out on Jelly and Jexl. Yep. And as a neophyte to the whole Jelly/Jexl world, I just don't know enough to help out here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can Maven auto-add XML dependencies?
[EMAIL PROTECTED] wrote: What about people that want to use different XML parsers etc than those supplied with the JVM? And should we do the same for other stuff like XSL? :) All I wanted is for my build to continue to build even if the XML dependencies are not there. If there is something that satisfies it for me, then cool. Really all that is needed for a build to continue working under JDK 1.3.1 is the xml-utils.jar file as it has all the JAXP code. As long as your project (and all mine comply with this) interacts with parsers and transformers through JAXP, all is well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can Maven auto-add XML dependencies?
Sometimes what happens in a project is that folks get used to working with JDK 1.4, and forget to add the XML dependencies because JDK 1.4 already has them. It would be really nice if Maven could determine the version number of the JVM (System.getProperty(java.runtime.version)), and if it is lower than 1.4 automatically add the XML dependencies. It would make *my* life easier. Don't know about anyone else's though ;P - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to download Maven RC1?
All the docs are updated on the website referring to Maven-1.0-RC1. The only binaries that I can find to download are for Maven-1.0-beta10. Has RC1 been released yet? Also, is Maven planning on using Apache's mirroring infrastructure to distribute it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Usability issues general ranting
Michal Maczka wrote: The original author does need to learn that open source coding is not created out of some desire to 'sell' a product to lots and lots of people, but to satisfy the itch of the people involved. There is some truth here. However, an open-source project's success is just as much judged by its audience as any other project. And a top level apache project would have more ambition than this I thought. Yeah are right. Our vision should be dropped and we should implement every single stupid feature then is requested and do this even if those features are in mutual contradiction. And the most frequent request is: you guys should be like ant. This is not hard thing to do. We will simply remove files from our CVS repository and import files from Ant repository replacing every occurrence of word ant with maven. If this is what will make people happy we should listen to them! Don't we? Michal, this isn't helpful. I understand your point, but there are better ways of stating it. It is important though to learn the strengths and weaknesses of what you are being compared to so that you can set up and maintain an appologetics page. Appologetics is the study of defending your position. What do you recognize as the strengths of ANT? What are its weaknesses? How does Maven leverage the strengths and minimize the weaknesses? That type of thing can be set up and merely maintained. Then when you receive a request for you guys should be like ant you can tell them to RTFM. It shows you did your homework--and that you recognize the good and the bad from that de-facto standard build tool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
Laird Nelson wrote: Andy Jefferson wrote: You could take it further and think of the whole issue of dependencies and the fact that there are basically 3 'types' ... build, test, and runtime. Or: each plugin has dependencies, and the java:compile one fills its dependency list from the POM, the test:* one fills its dependency list from some other location in the POM, etc. Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Saying that each plugin can have a dependency but that that dependency list can come from anywhere (like the POM, i.e. it doesn't need to be hardcoded) allows for more flexibility in the future. L But can Maven be altered so that the dependency won't be resolved unless it is really needed? For example, why with the clean target do all the project dependencies (which don't differentiate as to use) need to be resolved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the time?
[EMAIL PROTECTED] wrote: Yes, resolving dependencies all the time is a PITA. What's your suggested alternative? Do plugins declare whether they need the dependencies? Some other method of us guessing? If the project dependencies list had a clue as to which type of dependency they are, then they can be resolved occordingly. As one person rightfully pointed out, there are runtime, build time, and test time dependencies. There may be more, (possibly a packaging time?), but for the sake of simplicity/ discussion that should be enough. The java:compile and test:compile would resolve all the dependencies necessary for it at that time. That can either be done by having different dependencies sections like this: buildDependencies/ testDependencies/ runtimeDependencies/ Or it can be done something like this: dependencies dependency depTypebuild/depType !-- ... -- /dependency /dependencies Either way, the project specific dependencies would not need to be resolved until the proper plugin needed them. The **:compile plugins would grab the build dependencies plus whatever else it needed (like test dependencies for the test:compile). In the end, it is (conceptually speaking) not difficult. Not having messed with much of the code, I cannot vouch for the technical aspects of it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there any reason we have to resolve dependencies all the t ime?
Laird Nelson wrote: Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Yes, that's my point. We're in agreement. :) It appears that there is a post 1.0 fix for the whole mess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updating properties listed in online guide
There are a couple properties that I found useful to use in my own plugin. I have a plugin that I want to generate meta information for all classes compiled. I conveniently added postGoal entries for test:compile and java:compile. The properties I needed to leverage were: maven.compile.src.set - the set of Java Source directories maven.build.dest - already documented maven.test.compile.src.set - the set of Java Test Source directories maven.test.dest - the destination where test classes go As you can see--only one of those properties is documented in the online guide. It would be beneficial to at *least* have the maven.test.dest directory spelled out. If there are preferred ways of specifying the Java source directory and the Java test source directories over what I dug up, I would be very happy to know what they are (there were none documented. The maven.build.src is the root of all the source folders, not just the src/java folder.). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating properties listed in online guide
[EMAIL PROTECTED] wrote: Documentation: 1) maven.compile.src.set - documented as part of the java plugin @ http://maven.apache.org/reference/plugins/java/properties.html 2) core property documented in the users guide 3) maven.test.compile.src.set - is NOT documented as part of the test plugin @ http://maven.apache.org/reference/plugins/test/properties.html 4) maven.test.dest - is documented as part of the test plugin @ http://maven.apache.org/reference/plugins/test/properties.html Looks like only 3 is missing to me, right? I guess so. You know, it is pretty difficult trying to keep track of what does what and where to find the correct property. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating properties listed in online guide
[EMAIL PROTECTED] wrote: I suppose so, but there are essentially two places: a) maven core properties (as per the user guide), or b) the plugin that provides that functionality. Would a page like this http://maven.apache.org/reference/plugins/index.html help if there were more detail, or are you after fundamentally different details? Its a step in the right direction. Perhaps what would be most beneficial is something that would map the property names to the plugin--or at least just have a global list of all the properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extending normal Manifest entries
Is there currently any way to simply add new manifest entries to all the ones that Maven generates for you? I have a special packaging requirement that needs to add up to four attributes--but I don't want to have to choose between Maven generated and personally generated manifests. I would like to simply add attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending normal Manifest entries
Erik Husby wrote: I had a need to do this as well. In maven.xml, I added: project xmlns:ant=jelly:ant xmlns:j=jelly:core xmlns:deploy=deploy pregoal name=jar:jar ant:manifest file=MANIFEST.MF ant:attribute name=Class-Path value=j2ee-1.4.1_02.jar jdom-b9.jar jhall-1.1.3.jar js-1.5R4-RC3.jar junit-3.8.1.jar profiler-1.0.jar/ /ant:manifest /pregoal /project And then in project.properties, one adds maven.jar.manifest=MANIFEST.MF SO it does merge... I just spent some time changing the plugin to add to the manifest using properties. Example snippet below: maven.jar.manifest.attributes.list = GUIApp-Conf,GUIApp-Instrument,GUIApp-Log maven.jar.manifest.attribute.GUIApp-Conf = org/d_haven/demoapp/DemoApp.xconf maven.jar.manifest.attribute.GUIApp-Instrument = org/d_haven/demoapp/DemoApp.instruments maven.jar.manifest.attribute.GUIApp-Log = org/d_haven/demoapp/DemoApp.xlog maven.jar.manifest.groups.list = DemoAppConstants,ValidateQuitApplication maven.jar.manifest.DemoAppConstants.name=org/d_haven/demoapp/DemoAppConstants.class maven.jar.manifest.DemoAppConstants.attributes.list=Description,Foo maven.jar.manifest.DemoAppConstants.attribute.Description=It's ok maven.jar.manifest.DemoAppConstants.attribute.Foo=bar maven.jar.manifest.ValidateQuitApplication.name=org/d_haven/demoapp/screens/ValidateQuitApplication.class maven.jar.manifest.ValidateQuitApplication.attributes.list=Description maven.jar.manifest.ValidateQuitApplication.attribute.Description=We are rockin' This will add to the Maven generated Manifest like this: skip maven generated content GUIApp-Conf: org/d_haven/demoapp/DemoApp.xconf GUIApp-Instrument: org/d_haven/demoapp/DemoApp.instruments GUIApp-Log: org/d_haven/demoapp/DemoApp.xlog Name: org/d_haven/demoapp/DemoAppConstants.class Description: It's ok Foo: bar Name: org/d_haven/demoapp/screens/ValidateQuitApplication.class Description: We are rockin' It seems to work pretty decently, and I am getting ready to send a patch in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding functionality to maven-jar-plugin
The attached patch to the plugin.jelly script for the maven-jar-plugin will
allow you to add arbitrary values to the manifest--complete with sections
which will make the sealing of classes/packages possible. The new values
are added like this:
maven.jar.manifest.attributes.list = GUIApp-Conf,GUIApp-Instrument,GUIApp-Log
maven.jar.manifest.attribute.GUIApp-Conf = org/d_haven/demoapp/DemoApp.xconf
maven.jar.manifest.attribute.GUIApp-Instrument =
org/d_haven/demoapp/DemoApp.instruments
maven.jar.manifest.attribute.GUIApp-Log = org/d_haven/demoapp/DemoApp.xlog
maven.jar.manifest.groups.list = DemoAppConstants,ValidateQuitApplication
maven.jar.manifest.DemoAppConstants.name=org/d_haven/demoapp/DemoAppConstants.class
maven.jar.manifest.DemoAppConstants.attributes.list=Description,Foo
maven.jar.manifest.DemoAppConstants.attribute.Description=It's ok
maven.jar.manifest.DemoAppConstants.attribute.Foo=bar
maven.jar.manifest.ValidateQuitApplication.name=org/d_haven/demoapp/screens/ValidateQuitApplication.class
maven.jar.manifest.ValidateQuitApplication.attributes.list=Description
maven.jar.manifest.ValidateQuitApplication.attribute.Description=We are rockin'
This will add to the Maven generated Manifest like this:
skip maven generated content
GUIApp-Conf: org/d_haven/demoapp/DemoApp.xconf
GUIApp-Instrument: org/d_haven/demoapp/DemoApp.instruments
GUIApp-Log: org/d_haven/demoapp/DemoApp.xlog
Name: org/d_haven/demoapp/DemoAppConstants.class
Description: It's ok
Foo: bar
Name: org/d_haven/demoapp/screens/ValidateQuitApplication.class
Description: We are rockin'
Please note that all the existing functionality has been preserved. We are
only adding the ability to add sections and attributes of our own design.
I personally don't like having to specify these things in property format,
but I don't know much about extending the POM so I can't propose a nicer
format. Anyway, this makes it easy for plugins to add new attributes, etc.
--- plugin.jelly.old2003-07-14 17:36:46.0 -0400
+++ plugin.jelly2003-09-04 16:44:33.0 -0400
@@ -9,7 +9,8 @@
xmlns:resources=resources
xmlns:util=jelly:util
xmlns:doc=doc
- xmlns:m=maven
+ xmlns:m=maven
+ xmlns:log=jelly:log
!-- == --
!-- J A R --
@@ -71,7 +72,6 @@
ant:attribute name=Extension-List value=${extensionList}/
/j:if
-
j:forEach var=artifact items=${pom.artifacts}
j:set var=dep value=${artifact.dependency}/
ant:attribute name=${dep.artifactId}-Extension-Name
value=${dep.artifactId}/
@@ -79,6 +79,36 @@
ant:attribute name=${dep.artifactId}-Implementation-URL
value=http://www.ibiblio.org/maven${artifact.urlPath}/
/j:forEach
/j:if
+
+j:if test=${context.getVariable('maven.jar.manifest.attributes.list') !=
null}
+util:tokenize var=attributeList delim=,
trim=true${maven.jar.manifest.attributes.list}/util:tokenize
+j:forEach var=attribute items=${attributeList}
+j:set var=name value=maven.jar.manifest.attribute.${attribute}/
+j:set var=value value=${context.findVariable(name)}/
+log:debug[user attribute] ${attribute}: ${value}/log:debug
+ant:attribute name=${attribute} value=${value}/
+/j:forEach
+/j:if
+
+j:if test=${context.getVariable('maven.jar.manifest.groups.list') != null}
+util:tokenize var=groupList delim=,
trim=true${maven.jar.manifest.groups.list}/util:tokenize
+j:forEach var=group items=${groupList}
+j:set var=nameVar value=maven.jar.manifest.${group}.name/
+j:set var=groupName value=${context.findVariable(nameVar)}/
+j:set var=attributeListVar
value=maven.jar.manifest.${group}.attributes.list/
+j:set var=groupAttributes
value=${context.findVariable(attributeListVar)}/
+util:tokenize var=attributeList delim=,
trim=true${groupAttributes}/util:tokenize
+log:debug[group] Name: ${groupName}/log:debug
+ant:section name=${groupName}
+j:forEach var=attribute items=${attributeList}
+j:set var=name
value=maven.jar.manifest.${group}.attribute.${attribute}/
+j:set var=value value=${context.findVariable(name)}/
+log:debug[attribute] ${attribute}: ${value}/log:debug
+ant:attribute name=${attribute} value=${value}/
+/j:forEach
+/ant:section
+/j:forEach
+/j:if
/ant:manifest
/ant:jar
/goal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including remote properties
Jason van Zyl wrote: On Tue, 2003-09-02 at 15:46, Berin Loritsch wrote: The Avalon team would like to use their distribution heirarchy as a Maven remote repository. The only problem is the traffic it forces on the Apache servers. We would like to incorporate support from the mirrors redirection program to get things to work properly. I can (and did) easily create a genereated properties file that is run as a CGI script on the server to point to the preferred mirror. The file has the entry maven.repo.remote=[preferred]/avalon, Sorry I don't quite understand the generated properties file that is run as a CGI script. How is a generated properties file a CGI script? Can you not just point the maven.repo.remote value at the normal apache cgi mirror script? No, that's the problem. The generated properties file is from a CGI script hosted by Apache infrastructure that points to what it believes is the nearest mirror to you. I would like to leverage that, and have the builds pull from the mirrors. The snag I ran into has to do with declaring the properties files. Maven has the property element you can put in the maven.xml file, Do you mean the properties/ element in project.xml, or using the ant property/ tag in the maven.xml file? I mean the property/ tag in the maven.xml file. but the only options to specify the properties files are file, resource, and env. That means that I cannot use that to get the remote properties file. I'm still not exactly sure what you're trying to do but the Jelly util tag library has a properties tag that takes a URI. I am really new to jelly, and I'm kinda shooting in the dark here. What is available to help me out here? Is there any workaround I can use? Is there a plugin that exists to take care of this type of functionality? You are just trying to point your maven builds at the mirror cgi script? Yep. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Distinguishing between runtime and compile time dependencies
Is there a magic flag to identify a runtime dependency from a compile
time dependency? For example, Xerces and Xalan may be needed to compile
some aspects of a project (some people use it to generate java source
code), but never needed at run time.
This will allow a number of things:
* The extensions attributes can be generated ONLY for runtime dependencies
* The GUMP descriptor will be able to reflect that information so that
the other GUMP descriptors can propogate those dependencies for unit tests
* I can develop my plugin to gather the dependencies into a distributable
I personally have a need to generate a work directory like this:
/${root}
loader.jar
/lib
***.jar
/docs
***.html
***.pdf
The thing is that I want to be able to collect all of the runtime
dependencies for this special distribution format and place them in the
lib directory. Currently, the best I can do is grab *all* the dependencies,
regardless of runtime or compile time.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distinguishing between runtime and compile time dependencies
Jason van Zyl wrote: On Wed, 2003-09-03 at 10:07, Berin Loritsch wrote: Is there a magic flag to identify a runtime dependency from a compile time dependency? For example, Xerces and Xalan may be needed to compile some aspects of a project (some people use it to generate java source code), but never needed at run time. There is no facility yet. But we've talked about it for a long time and we do have working code for it in experimental versions of Maven but the real crux of the problem is collecting POMs in the repositories so we can build the necessary graphs. In this way you would only have to state the compile time dependencies and the runtime dependencies would be calculated. Not something that is going to make it into 1.0. :( I don't mind so much requiring the user to include all dependencies in the dependency declaration, and some of those dependencies are constant with what I am setting up. The big thing is being able to distinguish between the ones that are needed at runtime so that I can only copy those and ignore the others. While recursive runtime dependency tracking would be *nice*, it won't be necessary. In 9 out of 10 cases, your runtime dependencies are required for compilation anyway so they would need to be included in the dependencies list. Are you trying to assemble a container runtime? yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including remote properties
Jason van Zyl wrote: On Wed, 2003-09-03 at 09:58, Berin Loritsch wrote: Jason van Zyl wrote: You are just trying to point your maven builds at the mirror cgi script? Where's the source for this little puppy and I'll take a look and maybe I can get a better grasp on the problem. If you log into www.apache.org, the script for the CGI portion is here: /www/avalon.apache.org/maven.cgi /www/avalon.apache.org/maven.properties (It uses the same script for the download pages) The snippet from my maven.xml was like this: properties file=http://avalon.apache.org/maven.cgi/ Someone suggested using an ANT get before trying to use the properties. However, if something like this can be made into a plugin--that would be fantastic! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any pointers for plugin development?
The old how to write a plugin in the WIKI is not enough to go by. I have a plugin I am developing as part of a larger application, and I want to ensure that it is built and installed. Unfortunately, the project.xml that it is used to define the project is not doubled to be where the plugin JAR assembly expects it. How should I arrange my parent and plugin project.xml files, and how should I set up the plugin directory structure. I'm shooting in the dark, and missing my target. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distinguishing between runtime and compile time dependencies
Paul Libbrecht wrote:
j:forEach var=artifact items=${pom.artifacts}
j:set var=dependency value=${artifact.dependency}/
j:if test=${dependency.getProperty('runtime') == 'true'}
ant:echoProcessing dependency: ${dependency.id}/ant:echo
ant:mkdir dir=${aggregate.dir}/lib/
ant:copy todir=${aggregate.dir}/lib
file=${artifact.path}/
/j:if
/j:forEach
Quick question:
if there is a specific artifact we want to copy and we know the group/artifactId
is there a shortcut instead of iterating over the list of dependencies? I only
need one artifact for this one tool
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Including remote properties
The Avalon team would like to use their distribution heirarchy as a Maven remote repository. The only problem is the traffic it forces on the Apache servers. We would like to incorporate support from the mirrors redirection program to get things to work properly. I can (and did) easily create a genereated properties file that is run as a CGI script on the server to point to the preferred mirror. The file has the entry maven.repo.remote=[preferred]/avalon, which expands to the desired value. The snag I ran into has to do with declaring the properties files. Maven has the property element you can put in the maven.xml file, but the only options to specify the properties files are file, resource, and env. That means that I cannot use that to get the remote properties file. Is there any workaround I can use? Is there a plugin that exists to take care of this type of functionality? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including remote properties
Lester Ward wrote: Maven has the property element you can put in the maven.xml file, but the only options to specify the properties files are file, resource, and env. That means that I cannot use that to get the remote properties file. Couldn't you just use Ant's Get task to download the properties to a local file, then point the property element at that file? :) That is a possibility. The problem is that hacking the maven.xml file for a group of projects can be a bit messy. The best solution would be a plugin. Anyhoo, I will start with that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
