[jira] Commented: (MAVEN-1509) Property "maven.home.local" doesn't get overriden
The following comment has been added to this issue:
Author: Ross Burnett
Created: Tue, 23 Nov 2004 7:24 PM
Body:
I'm not sure if the current behaviour is by accident or design, but I believe
that it is correct and should not be changed.
The project.properties file is for project-specific, not user-specific,
properties. Since ${maven.home.local} is about a user's own local environment,
it shouldn't be set in project.properties. Doing so could lead to build
failures if not all users have access to the specified path.
Or is there some valid use case that I've missed?
-
View this comment:
http://jira.codehaus.org/browse/MAVEN-1509?page=comments#action_27096
-
View the issue:
http://jira.codehaus.org/browse/MAVEN-1509
Here is an overview of the issue:
-
Key: MAVEN-1509
Summary: Property "maven.home.local" doesn't get overriden
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0.2
Versions:
1.0.1
Assignee:
Reporter: Ralf Quebbemann
Created: Thu, 18 Nov 2004 5:51 AM
Updated: Tue, 23 Nov 2004 7:24 PM
Environment: J:\programming\java\myprojects\jgig>maven -i
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.5.0
file.encoding=Cp1252
java.ext.dirs=E:\Programme\Java\jdk1.5.0\jre\lib\ext
java.class.path=E:\Programme\development\programming\maven-1.0.1\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=E:\Programme\development\programming\maven-1.0.1\lib\endorsed\xerces-2.4.0.jar;E
:\Programme\development\programming\maven-1.0.1\lib\endorsed\xml-apis-1.0.b2.jar;E:\Programme\Java\j
dk1.5.0\jre\lib\rt.jar;E:\Programme\Java\jdk1.5.0\jre\lib\i18n.jar;E:\Programme\Java\jdk1.5.0\jre\li
b\sunrsasign.jar;E:\Programme\Java\jdk1.5.0\jre\lib\jsse.jar;E:\Programme\Java\jdk1.5.0\jre\lib\jce.
jar;E:\Programme\Java\jdk1.5.0\jre\lib\charsets.jar;E:\Programme\Java\jdk1.5.0\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.1
maven-announcement-plugin-1.3
maven-ant-plugin-1.8.1
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4.1
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.2
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5.1
maven-checkstyle-plugin-2.5
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.5
maven-dashboard-plugin-1.5
maven-developer-activity-plugin-1.5.1
maven-dist-plugin-1.6.1
maven-docbook-plugin-1.2
maven-ear-plugin-1.5
maven-eclipse-plugin-1.9
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5.1
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.2
maven-html2xdoc-plugin-1.3.1
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5.1
maven-jalopy-plugin-1.3.1
maven-jar-plugin-1.6.1
maven-java-plugin-1.4
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.7
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.9
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3.1
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.2
maven-jnlp-plugin-1.4.1
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.2
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.3
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.2.1
maven-plugin-plugin-1.5.2
maven-pmd-plugin-1.6
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4.1
maven-repository-plugin-1.2
maven-scm-plugin-1.4.1
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.2
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6.1
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Exception reading build.properties: E:\Dokumente und
Einstellungen\peter\build.properties (Das Syste
m kann die angegebene Datei nicht finden)
Home Build properties: {}
Description:
The property "maven.home.local" doesn't get overidden
Re: [PROPOSAL] Ading a new tag to ?
On Tuesday 23 November 2004 14:19, Brett Porter wrote: > > Jason, you are absolutely correct - the requirement is *not* > > separate repositories. I think the fundamental requirement is > > the ability to classify artifacts and to select artifacts based > > on classification. > > I agree with Jason that this is getting too complicated, and what > I Was pushing towards was the same thing. > > You should be signifying these different things by version. > > > Here are my dependency use cases: > > 1) set artifact/group to released version of an artifact/group > > ok, 1.0 Agree > > > 2) set artifact/group to latest release of an artifact/group > > 1.0-SNAPSHOT Not quite. I deal with 20 odd products on an essentially monthly release cycle. 20 products with an average of 2 concurrent devstreams and 4 components per product => 160 POMs that I have to review and update monthly. It would be nice to be able to specify use the latest production release. With luck transitive dependencies will reduce the number of POMs that need to be reviewed to around 40 which is still a large number. (By the way, I've been arguing against the above complexity for years) I do consider this a nice to have and not a requirement. > > 3) set artifact/group to specific version released to QA > > 1.0-QA-1 ? Agree > > 4) set artifact/group to latest version released to QA > > 1.0-QA-SNAPSHOT, though Maven support isn't there for this yet - > you'd need to look it up, or have the JAR republished. See my > thoughts on the release cycle later. Agree. What is needed for maven to handle this? > > 5) set artifact/group to latest bleeding edge version > > 1.0-SNAPSHOT. This is no different to the above use case. Agree. The use case is different in that here someone in the developer role "asks maven to deploy a bleeding edge version" and in the above case someone in the CM role "asks maven to deploy a QA version" > As I said before, this is a release management issue, rather than > repository/pom issue. Except how do I prevent a developer from deploying a bleeding edge artifact as a QA artifact to the repository by accident? > going on to the next email in the thread: > > 1) One should not need to modify the POM in order to execute > > any of these use cases. In a team of 10 developers 9 will be > > executing use case #4 while only one may be executing use case > > 1. In other words I need to be able to specify the artifact > > using a property. > > maven.jar.override=on > maven.jar.foo=1.0-QA > > is this ok? They can even do that globally. Agree. > But also, why can't that developer edit their checkout of > project.xml and only commit the final version? Two reasons. With 75 different developers of various skills and technical proficiency I can't assume that all will grok a POM or how to modify it. This is especially true of web page developers who are not used to build systems in general and those who need to modify a POM on an irregular basis. Second, I need to disallow developers from checking in a POM at all. Why? With 20 odd products with interlocking dependencies and a monthly release cycle it is imperative that changes to dependencies not only de tracked, but made only after due deliberation and analysis. My experience indicates that unless the authority to modify dependencies is strictly controlled, then they will drift. Bottom line - a single repository using version identifiers will work so long as: 1) maven can distinguish between a release version, a QA version and a bleeding edge version based on the version tag 2) there is some mechanism to control deployment (so that a developer cannot deploy an artifact tagged as QA to the repository) -steve -- Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVENUPLOAD-264) eclipse jdtcore update
Message: The following issue has been reopened. Reopener: Torsten Curdt Date: Tue, 23 Nov 2004 5:30 PM Waiting for feedback how to resolve this. - View the issue: http://jira.codehaus.org/browse/MAVENUPLOAD-264 Here is an overview of the issue: - Key: MAVENUPLOAD-264 Summary: eclipse jdtcore update Type: Task Status: Reopened Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-upload-requests Assignee: Carlos Sanchez Reporter: Torsten Curdt Created: Sun, 21 Nov 2004 8:25 PM Updated: Tue, 23 Nov 2004 5:30 PM Description: http://eclipse.org Please update!! - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
> Jason, you are absolutely correct - the requirement is *not* > separate repositories. I think the fundamental requirement is the > ability to classify artifacts and to select artifacts based on > classification. I agree with Jason that this is getting too complicated, and what I Was pushing towards was the same thing. You should be signifying these different things by version. > Here are my dependency use cases: > 1) set artifact/group to released version of an artifact/group ok, 1.0 > 2) set artifact/group to latest release of an artifact/group 1.0-SNAPSHOT > 3) set artifact/group to specific version released to QA 1.0-QA-1 ? > 4) set artifact/group to latest version released to QA 1.0-QA-SNAPSHOT, though Maven support isn't there for this yet - you'd need to look it up, or have the JAR republished. See my thoughts on the release cycle later. > 5) set artifact/group to latest bleeding edge version 1.0-SNAPSHOT. This is no different to the above use case. As I said before, this is a release management issue, rather than repository/pom issue. going on to the next email in the thread: > 1) One should not need to modify the POM in order to execute any of > these use cases. In a team of 10 developers 9 will be executing use > case #4 while only one may be executing use case 1. In other words > I need to be able to specify the artifact using a property. maven.jar.override=on maven.jar.foo=1.0-QA is this ok? They can even do that globally. But also, why can't that developer edit their checkout of project.xml and only commit the final version? > 2) The repository remains standardized. In other words, a developer > working on project A who decides he needs bleeding edge artifacts > from the m2 effort of project B doesn't need to talk to a developer > in group B to determine groupIds or repository names, etc. The > developer can simply indicate they want bleeding edge of m2. I think the above covers this. Sticking to versions will keep it a lot simpler. Here is what I think the cycle should be: 1.0-SNAPSHOT 1.0-SNAPSHOT -> release 1.0-QA-1 (and as 1.0-QA-SNAPSHOT) 1.0-SNAPSHOT -> release 1.0-QA-2 (and as 1.0-QA-SNAPSHOT) 1.0-SNAPSHOT -> release 1.0 1.1-SNAPSHOT... Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: different repositories WAS: [PROPOSAL] Ading a new tag to ?
On Tuesday 23 November 2004 11:45, Brett Porter wrote: > I'm still not sure what you need here. When you use a SNAPSHOT, > it is not first wins, but newest - all are checked. > > But you talk about changing repositories per group - aren't the > repositories paritioned enough such that the set of groups > affected have their own? > I'm thinking you might be talking about a release management > issue more than this. If they are using one from 'bleeding edge' > and the rest from 'QA', maybe > QA should be somewhere where the version is incremented to a > pre-release, and they change their dependencies to that. > > If this is incorrect, can you spell out an example we can work > through? > > Cheers, > Brett As I mentioned in my response to Jason, here are my use cases: 1) set artifact/group to released version of an artifact/group 2) set artifact/group to latest released version of an artifact/group 3) set artifact/group to specific version released to QA 4) set artifact/group to latest version released to QA 5) set artifact/group to latest bleeding edge version There are a few requirements lurking in the background here as well. They include: 1) One should not need to modify the POM in order to execute any of these use cases. In a team of 10 developers 9 will be executing use case #4 while only one may be executing use case 1. In other words I need to be able to specify the artifact using a property. 2) The repository remains standardized. In other words, a developer working on project A who decides he needs bleeding edge artifacts from the m2 effort of project B doesn't need to talk to a developer in group B to determine groupIds or repository names, etc. The developer can simply indicate they want bleeding edge of m2. If you would like me to write up something formal as a summary, I'd be glad to do so. -steve -- Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
On Tuesday 23 November 2004 13:24, Jason van Zyl wrote: > On Tue, 2004-11-23 at 12:17, Stephen Nesbitt wrote: > > Not sure I follow here. Most of the time developers will work > > against the artifacts in the QA repository. > > I'm watching this conversation but I'll jump in here with a > question. Why do you need a separate repository for QA artifacts? > At the moment I'm doing some analysis in a development centre > that has your typical dev/QA/Production setup and I don't see a > need for a separate repository per se. > Why does it need to be so complicated. Sorry, I just find that > people tend to make things more complicated for themselves than > required. So you need to use artifacts produced by QA: it's > certainly not a technical requirement that they be in a separate > repository. Are you dealing with policy here? I'm just curious > because I have some of the same problems to deal with where I am > at the moment. Jason, you are absolutely correct - the requirement is *not* separate repositories. I think the fundamental requirement is the ability to classify artifacts and to select artifacts based on classification. As I understand it now, maven supports two "classifications" - released(has a version number) and snapshot (latest). That's not rich enough for our needs. (Indeed I'm not sure snapshot is truly a category, it's more a specifier within a classification). Here are my dependency use cases: 1) set artifact/group to released version of an artifact/group 2) set artifact/group to latest release of an artifact/group 3) set artifact/group to specific version released to QA 4) set artifact/group to latest version released to QA 5) set artifact/group to latest bleeding edge version How those versions are stored is really a design decision and, as you said, should be kept as simple as possible. Sorry for the long reply, but it's nice to have a chance to discuss issues I have been chewing on for years. -steve -- Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
On Tue, 2004-11-23 at 12:17, Stephen Nesbitt wrote: > Not sure I follow here. Most of the time developers will work > against the artifacts in the QA repository. I'm watching this conversation but I'll jump in here with a question. Why do you need a separate repository for QA artifacts? At the moment I'm doing some analysis in a development centre that has your typical dev/QA/Production setup and I don't see a need for a separate repository per se. > In some instances they > will want to work against QA artifacts except for those artifacts > associated with a specific group (or possibly a specific artifact). > Using a simple list of repositories with first one that matches > wins won't work(unless there is a way to tag an artifact with a > user specified identifier) Why does it need to be so complicated. Sorry, I just find that people tend to make things more complicated for themselves than required. So you need to use artifacts produced by QA: it's certainly not a technical requirement that they be in a separate repository. Are you dealing with policy here? I'm just curious because I have some of the same problems to deal with where I am at the moment. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPGENAPP-4) Make genapp pull templates from repository instead of being embedded in a plugin
The following comment has been added to this issue: Author: Miguel Griffa Created: Tue, 23 Nov 2004 4:08 PM Body: IMHO, genapp templates shuold be dependencies. This would solve lots of issues. Getting templates from repo would be great, but also to have dependencies automatically fetched when new is available (snapshots), or searched in a list (repo list). - View this comment: http://jira.codehaus.org/browse/MPGENAPP-4?page=comments#action_27092 - View the issue: http://jira.codehaus.org/browse/MPGENAPP-4 Here is an overview of the issue: - Key: MPGENAPP-4 Summary: Make genapp pull templates from repository instead of being embedded in a plugin Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-genapp-plugin Assignee: Arnaud HERITIER Reporter: Archimedes Trajano Created: Tue, 30 Dec 2003 3:28 AM Updated: Tue, 23 Nov 2004 4:08 PM Description: Perhaps we can provide a facility that would pull the template from the repository whether remote or local. We can also add the following targets: genapp:install = installs the template genapp:create-template = creates a template project based on an existing project genapp:test-template = tests the template by creating an instance of the template in the target directory, and runs the tests in generated instance. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPGENAPP-19) Add web-velocity application template
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPGENAPP-19 Here is an overview of the issue: - Key: MPGENAPP-19 Summary: Add web-velocity application template Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-genapp-plugin Assignee: Arnaud HERITIER Reporter: Miguel Griffa Created: Tue, 23 Nov 2004 4:02 PM Updated: Tue, 23 Nov 2004 4:02 PM Description: Attached a template for a simple web application that uses velocity for rendering. The generated app shuold work out of the box, of course. Patch follows - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPGENAPP-19) Add web-velocity application template
The following issue has been updated: Updater: Miguel Griffa (mailto:[EMAIL PROTECTED]) Date: Tue, 23 Nov 2004 4:02 PM Changes: Attachment changed to web-velocity-template.tar.gz - For a full history of the issue, see: http://jira.codehaus.org/browse/MPGENAPP-19?page=history - View the issue: http://jira.codehaus.org/browse/MPGENAPP-19 Here is an overview of the issue: - Key: MPGENAPP-19 Summary: Add web-velocity application template Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-genapp-plugin Assignee: Arnaud HERITIER Reporter: Miguel Griffa Created: Tue, 23 Nov 2004 4:02 PM Updated: Tue, 23 Nov 2004 4:02 PM Description: Attached a template for a simple web application that uses velocity for rendering. The generated app shuold work out of the box, of course. Patch follows - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jelly Core Tag "getStatic"
Hi Geeks I was looking for a way to retrieve a Constant value from a class in Maven and stumbled over core:getStatic tag but this is not in 1.0 nor in 1.0.1. Is there a reason why this is not in? And is there a way to retrieve a constant value from a class in Maven now? Thanx - Andy Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
Actually I was going to have a shot at creating a patch for this, but when I checked the CVS, I got lost with the fact that the code appears to be generated and I havent found time yet to figure out exactly how :-) -Corey On Tue, 23 Nov 2004 23:09:06 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > This has been discussed several times in the past. I must say, scope is > probably the best name I've seen for it so far. > > It will get resolved in some way in the near future. > > - Brett > > > > Corey Scott wrote: > > >While we are on the subject of adding tags to has a scope > >tag been considered? This would allow users to generate dep reports > >and so on that lead to a better understanding of where and why the > >dependancy exists. > > > >Examples: > >Runtime (default) runtime > >Test Only test > >Build Only build > >Dependancy of a Dependancy ?? > > > >I believe that this has been hinted at during previous discussions and > >bug reports and i think it is has merit. > > > >Comments? > > > >-Corey > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using maven while developing maven
Does this help? http://www.apache.org/~brett/site-2/developers/building-from-source.html#Building_Maven_with_Maven I have a development version that I continuously use and build over the top of (until I kill it and have to start from scratch :) - Brett Hardy Ferentschik wrote: Hi there, just wondering how you guys are dealing with this. I am using maven to build my java projects and have a installed version of maven 1.0.1. I also would like to develop/debug the maven. I can build maven using my installed version of maven, but how do I get a running version maven installed into a seperate directory for testing/debugging. I've tried to run org.apache.maven.cli.App via the debugger, but I got a ClassCastException, because a ForeheadClassLoader was expected. I guess the easiest would be to have to install maven into a seperate directory and launch it with remote debugging enabled. Is this possible? How are you solving this issue? Cheers Hardy - 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]
Patch: JNLP plugin option to not strip manifest attributes
The Maven JAR plugin nicely creates an Implementation-Version attribute in the JAR's manifest, looking like this: Implementation-Version: 0.5.4-SNAPSHOT It also adds a handful of other informational attributes. After spending a few hours writing code to get this version string and display it in the About Box of my Java Web Start application, I discovered that it didn't work when I actually launched the app via JWS. Turns out the maven-jnlp-plugin strips out all the attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I've submitted the patch here: http://jira.codehaus.org/browse/MPJNLP-20 Cheers, Sean -- --- M. Sean Gilligan: 831-466-9788 x11 vBlog Central : http://www.vblogcentral.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: different repositories WAS: [PROPOSAL] Ading a new tag to ?
Hi, Stephen Nesbitt wrote: I think this situation is best covered by publishing to different repositories for each, and then only utilising the remote repositories appropriate when building. IF you happen to specify more than one remote repository, you get the newest which should be correct. Not sure I follow here. Most of the time developers will work against the artifacts in the QA repository. In some instances they will want to work against QA artifacts except for those artifacts associated with a specific group (or possibly a specific artifact). Using a simple list of repositories with first one that matches wins won't work(unless there is a way to tag an artifact with a user specified identifier) I'm still not sure what you need here. When you use a SNAPSHOT, it is not first wins, but newest - all are checked. But you talk about changing repositories per group - aren't the repositories paritioned enough such that the set of groups affected have their own? I'm thinking you might be talking about a release management issue more than this. If they are using one from 'bleeding edge' and the rest from 'QA', maybe QA should be somewhere where the version is incremented to a pre-release, and they change their dependencies to that. If this is incorrect, can you spell out an example we can work through? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
On Tuesday 23 November 2004 04:46, Brett Porter wrote: Hi Brett. You suggested I dive in so I'm going to > > I think this situation is best covered by publishing to different > repositories for each, and then only utilising the remote > repositories appropriate when building. IF you happen to specify > more than one remote repository, you get the newest which should > be correct. Not sure I follow here. Most of the time developers will work against the artifacts in the QA repository. In some instances they will want to work against QA artifacts except for those artifacts associated with a specific group (or possibly a specific artifact). Using a simple list of repositories with first one that matches wins won't work(unless there is a way to tag an artifact with a user specified identifier) > > There are two things we are aiming highly to do: > - reduce clutter in the POM (by making sure it is both concise > and has sensible defaults) > - ensure dependency specifications match or are closely tied to > the project definition so that IDs can be matched. > > This is why model changes in general, but dependencies in > particular, get heavy scrutiny before inclusion. Absolutely concur. I did some initial work on a declaritive build system about a year ago that featured something very similar to the POM. The problem was always making sure the POM did not become as or more complex than the Ant files it replaced. Also, per our discussion previously I am beginning the process of determining Cobalt's attitude to more direct involvement on my part. We use open source in our products and the organization has expressd a willingness to contribute in the past. Initial indications are good. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPJNLP-20) 'Update Manifest' feature should be optional
The following issue has been updated: Updater: M. Sean Gilligan (mailto:[EMAIL PROTECTED]) Date: Tue, 23 Nov 2004 2:38 PM Comment: This is the patch that I've tested in three scenarios: 1) Using default true value of the maven.jnlp.update.manifest property, 2) Overriding with false in project.properties, 3) overriding with true in project.properties. They all work correctly on OS X 10.3, with Java 1.4.2. Changes: Attachment changed to maven-jnlp-plugin.diff - For a full history of the issue, see: http://jira.codehaus.org/browse/MPJNLP-20?page=history - View the issue: http://jira.codehaus.org/browse/MPJNLP-20 Here is an overview of the issue: - Key: MPJNLP-20 Summary: 'Update Manifest' feature should be optional Type: Improvement Status: Open Priority: Major Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven-jnlp-plugin Fix Fors: 1.4.1 Assignee: Emmanuel Venisse Reporter: M. Sean Gilligan Created: Tue, 23 Nov 2004 2:34 PM Updated: Tue, 23 Nov 2004 2:38 PM Environment: Mac OS X, Java 1.4.2 Description: The maven-jnlp-plugin strips out all JAR manifest attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I'm hoping someone will commit the patch and make a 1.4.2 release of the plugin... - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Signing jars
Hi, (IMMO) * signing a jar isjust an ant call, I don't know if making it a goal is really interessting (and all the task properties will produce much jelly code) * anyway as jnlp plugin objective is to generate a jnlp file, I'm not sure if the best place for a jar:sign goal would be there, perhaps the jar plugin (perhaps a bit too j2ee oriented) or the j2ee plugin would be a better idea ? hope it may help you Julien Carlos Sanchez wrote: Hi, I'd like to sign the generated jar and after taking a look to jnlp plugin seems that its purpose is other than just signing, should I use it or it'd be better adding a jar:sign goal? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPJNLP-20) 'Update Manifest' feature should be optional
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPJNLP-20 Here is an overview of the issue: - Key: MPJNLP-20 Summary: 'Update Manifest' feature should be optional Type: Improvement Status: Open Priority: Major Original Estimate: 1 hour Time Spent: Unknown Remaining: 1 hour Project: maven-jnlp-plugin Fix Fors: 1.4.1 Assignee: Emmanuel Venisse Reporter: M. Sean Gilligan Created: Tue, 23 Nov 2004 2:34 PM Updated: Tue, 23 Nov 2004 2:34 PM Environment: Mac OS X, Java 1.4.2 Description: The maven-jnlp-plugin strips out all JAR manifest attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I'm hoping someone will commit the patch and make a 1.4.2 release of the plugin... - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
Stephen Nesbitt wrote: should be visited. I am not sure that this is fine grained enough. I can imagine a use case in which a developer has dependecies on jar A & jar B both having the same groupId with a repository tied to say QA snapshots. For whatever reason the developer decides that he wants Jar A from the bleeding edge repository while leaving Jar B from the QA repository (maybe confirming a fix to a QA issue?) In any case having the repository assigned to the groupID won't meet this case. I'm not sure just how much of an edge case this is, but I do think it is important to have some sort of answer (even if it is a manual process of updating your local repo directly) I am sure that it can be addressed in some way. For example you can write your own plugin which will deploy some artifacts to QA repository or do somthing which is needed to match coorporate standards. I would't be expecting that maven will be out of the box supporting all possible artifact flows in every company. One thing which will be particulary good in m2 is that it is componetizied. We are not sure what we will be willing to expose to end users but there are componets like ArtifactDeployer, ArtifactInstaller, ArtifactDowloader etc and m2 will come with "default" implementation. of that componets which define our strategy for communicating with repositories. In case of highly no standart needs I imagine that implementation of that components can be extended or replaced to match those unusal needs. It will be probably very, very rare case - but still it will be possible to do so. Michal -- Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
On Tuesday 23 November 2004 07:23, Maczka Michal wrote: > > -Original Message- > I forgot to add that it would be possible to make a decsion which > repository should be hit > using the value provided in groupId tag of the dependency. > > so if it is foo/baa/xxx the repositry A and > only A should be vistied > if it is bazz/aa/xxx repositories B and C > should be visited. I am not sure that this is fine grained enough. I can imagine a use case in which a developer has dependecies on jar A & jar B both having the same groupId with a repository tied to say QA snapshots. For whatever reason the developer decides that he wants Jar A from the bleeding edge repository while leaving Jar B from the QA repository (maybe confirming a fix to a QA issue?) In any case having the repository assigned to the groupID won't meet this case. I'm not sure just how much of an edge case this is, but I do think it is important to have some sort of answer (even if it is a manual process of updating your local repo directly) -steve -- Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ant/src/plugin-test project.properties project.xml maven.xml
epugh 2004/11/23 09:14:26
Modified:ant/xdocs changes.xml
ant project.xml
ant/src/plugin-resources/templates build.jelly
ant/src/plugin-test project.xml maven.xml
Added: ant/src/plugin-test/lib activation-1.0.2.jar
ant/src/plugin-test project.properties
Log:
MPANT-7. Not obeying jar overrides. While this patch doesn't get every
case, it does
get the common one of using an included lib. I am using this succesfuly with
commons-email's
ant build.
Revision ChangesPath
1.30 +4 -0 maven-plugins/ant/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/maven-plugins/ant/xdocs/changes.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- changes.xml 20 Aug 2004 21:19:30 - 1.29
+++ changes.xml 23 Nov 2004 17:14:25 - 1.30
@@ -24,6 +24,10 @@
dIon Gillard
+
+
+ Obey jar override and
not attempt to download relative jars.
+
Use relative paths in
test resources filesets.
1.47 +1 -1 maven-plugins/ant/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven-plugins/ant/project.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- project.xml 20 Aug 2004 21:19:30 - 1.46
+++ project.xml 23 Nov 2004 17:14:25 - 1.47
@@ -23,7 +23,7 @@
3
maven-ant-plugin
Maven Ant Plugin
- 1.8.1
+ 1.9-SNAPSHOT
Generates ant build files from a maven project, so that plain
ant users can build your project
Generate Ant build file
http://maven.apache.org/reference/plugins/ant/
1.1
maven-plugins/ant/src/plugin-test/lib/activation-1.0.2.jar
<>
1.24 +15 -3
maven-plugins/ant/src/plugin-resources/templates/build.jelly
Index: build.jelly
===
RCS file:
/home/cvs/maven-plugins/ant/src/plugin-resources/templates/build.jelly,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- build.jelly 16 Aug 2004 10:50:26 - 1.23
+++ build.jelly 23 Nov 2004 17:14:26 - 1.24
@@ -349,14 +349,26 @@
proxyuser="${maven.proxy.username}"
proxypassword="${maven.proxy.password}"/>
-
-
+
+
+
+
+
+
+
+/>
+
+
+
+
+
+
+
1.7 +9 -0 maven-plugins/ant/src/plugin-test/project.xml
Index: project.xml
===
RCS file: /home/cvs/maven-plugins/ant/src/plugin-test/project.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- project.xml 16 Aug 2004 10:50:26 - 1.6
+++ project.xml 23 Nov 2004 17:14:26 - 1.7
@@ -53,6 +53,15 @@
+
+
+ activation
+ activation
+ 1.0.2
+ jar
+
+
+
junit
junit
1.11 +6 -0 maven-plugins/ant/src/plugin-test/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/maven-plugins/ant/src/plugin-test/maven.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- maven.xml 16 Aug 2004 10:50:26 - 1.10
+++ maven.xml 23 Nov 2004 17:14:26 - 1.11
@@ -47,6 +47,12 @@
+
+
+
+
+
+
[jira] Commented: (MPANT-7) ant-plugin not obeying jar override
The following comment has been added to this issue: Author: David Eric Pugh Created: Tue, 23 Nov 2004 12:20 PM Body: I have tweaked it so that included jar's that are used via jar override are resolved properly. Instead of a get, a copy is done instead. I am using this successfully to build commons-email's "build.xml" file. I tried to assign this to myself and got a jira exception. - View this comment: http://jira.codehaus.org/browse/MPANT-7?page=comments#action_27076 - View the issue: http://jira.codehaus.org/browse/MPANT-7 Here is an overview of the issue: - Key: MPANT-7 Summary: ant-plugin not obeying jar override Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ant-plugin Assignee: Arnaud HERITIER Reporter: Mike Bowler Created: Tue, 25 Mar 2003 12:16 PM Updated: Tue, 23 Nov 2004 12:20 PM Environment: Sun JDK1.3.1 on windows. Maven from cvs on March 24, 2003 Description: When using the ant-plugin to generate an ant build file, the generated tags do not obey the jar overrides specified in project.properties. All tags attempt to load the jars from ibiblio even though an override was specified that points to the local harddrive. Overrides are being used because the jar files in question are proprietary and cannot be uploaded to ibiblio. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-plugins/ant/src/plugin-test/lib - New directory
epugh 2004/11/23 09:14:16 maven-plugins/ant/src/plugin-test/lib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Ading a new tag to ?
> -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 23, 2004 3:49 PM > To: Maven Developers List > Subject: RE: [PROPOSAL] Ading a new tag to ? > > How does this help if your project relies on OSS and > proprietary artifacts? How can I configure Maven to look for > the proprietary artifacts (SNAPSHOT or not) only in the local > repo? I forgot to add that it would be possible to make a decsion which repository should be hit using the value provided in groupId tag of the dependency. so if it is foo/baa/xxx the repositry A and only A should be vistied if it is bazz/aa/xxx repositories B and C should be visited. It will be a question of ssing simple include/exclude regexp patterns per repository descriptor. But I think that at the moment we should try to stick to something simpler. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Ading a new tag to ?
> -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 23, 2004 3:49 PM > To: Maven Developers List > Subject: RE: [PROPOSAL] Ading a new tag to ? > > > Maczka Michal wrote on Tuesday, November 23, 2004 12:00 PM: > > >> -Original Message- > >> From: Stephen Nesbitt > [snip] > > > >> I noticed that Jörg Schaible's post kinda made the same point with > >> the suggestion of a tag in the dependency element. > >> > >> Hows does any of this fit into"in situ" artifacts? > > > > In situ artifact won't be that helpful in that case if it > > comes to speed of processing. > > > > Other m2 feature might be helpful - you can define a > > repositories per project basis. IT means that each pom can > > contain the location from which corresponding jar should be > > taken and you just need to push your poms to right repositoriy(ies) > > How does this help if your project relies on OSS and > proprietary artifacts? How can I configure Maven to look for > the proprietary artifacts (SNAPSHOT or not) only in the local > repo? The simplest solution which you can use now would be to use exclusivly the local intranet repo which must be be initially seeded in some way (e.g sychronized with ibiblio once per day/week) This should already make in some case the processing much faster as you will be never hitting ibiblio directly. So general idea is - you should possibly use single repository which is close to you and very fast. How this idea should be implemented it is a different story. Maven Proxy and such tools might be helpful. I bet it is even implementable in case of teams are geographically dispersed. In such case artifact repositories might be servers which are somehow activly synchronizing the content among them. But I believe that this is not releated to particular maven projects or poms - it is global configuration of maven and the question of organizing the repository system properly. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Ading a new tag to ?
Maczka Michal wrote on Tuesday, November 23, 2004 12:00 PM: >> -Original Message- >> From: Stephen Nesbitt [snip] > >> I noticed that Jörg Schaible's post kinda made the same point with >> the suggestion of a tag in the dependency element. >> >> Hows does any of this fit into"in situ" artifacts? > > In situ artifact won't be that helpful in that case if it > comes to speed of processing. > > Other m2 feature might be helpful - you can define a > repositories per project basis. IT means that each pom can > contain the location from which corresponding jar should be > taken and you just need to push your poms to right repositoriy(ies) How does this help if your project relies on OSS and proprietary artifacts? How can I configure Maven to look for the proprietary artifacts (SNAPSHOT or not) only in the local repo? The current approach seems to be "look in any repo and take the newest"... Additionally since the availability of ibiblio was mensioned .. how is it impacted currently on all those thousand users with properietary artifacts already? It would be interesting to see some statistics for http://www.ibiblio.or/maven with 404 response. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using maven while developing maven
Hi there, just wondering how you guys are dealing with this. I am using maven to build my java projects and have a installed version of maven 1.0.1. I also would like to develop/debug the maven. I can build maven using my installed version of maven, but how do I get a running version maven installed into a seperate directory for testing/debugging. I've tried to run org.apache.maven.cli.App via the debugger, but I got a ClassCastException, because a ForeheadClassLoader was expected. I guess the easiest would be to have to install maven into a seperate directory and launch it with remote debugging enabled. Is this possible? How are you solving this issue? Cheers Hardy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven site work
Hi brett, awesome, I like it. I think we should add a link to jira in the menu. It isn't enought visible in project info. And a link to Source Repository in Maven Developers. Emmanuel - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 22, 2004 1:22 PM Subject: maven site work > Hi folks, > > Rather than backing up with tarballs I've started to commit my work on > the Maven site. I had intended to do this on a branch, but I managed to > only branch the modified fields, and all the deletions/additions ended > up on HEAD which was pointless. Rather than fudge around with it, I've > put all the doco on HEAD and put a disabler into maven.xml to prevent > accidental publishing. For now, site publish can happen from > MAVEN-1_0-BRANCH if necessary. > > Here is a preview: http://www.apache.org/~brett/site-2/ > Obviously plenty of holes, but feedback on the content so far and layout > is welcome. I'm trying to keep the best practices and Maven theology > separate from the Maven 1.x nitty gritty so that it can be more easily > replaced over time, future proofing the site a little. > > I'll keep moving on this, hoping to finish this week and relaunch before > pushing out 1.0.2 and then moving on to 1.1 and beyond. > > Oh, and I apologise for using navigation.xml as my TODO workspace :) > > If anyone wants to volunteer to write a document, just let me know. > > Cheers, > Brett > > > > - > 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: [PROPOSAL] Ading a new tag to ?
Hi Stephen, I think this situation is best covered by publishing to different repositories for each, and then only utilising the remote repositories appropriate when building. IF you happen to specify more than one remote repository, you get the newest which should be correct. There are two things we are aiming highly to do: - reduce clutter in the POM (by making sure it is both concise and has sensible defaults) - ensure dependency specifications match or are closely tied to the project definition so that IDs can be matched. This is why model changes in general, but dependencies in particular, get heavy scrutiny before inclusion. Cheers, Brett Stephen Nesbitt wrote: On Sunday 21 November 2004 02:14, Vincent Massol wrote: Hi Maven devs, I think there's a need to allow specifying when some artifacts are only to be looked for in the local repository. For example, in a multiproject the local repository is used to share private artifacts between the subprojects. These private artifacts are not meant to be uploaded to a Maven remote repo. Perhaps this has already been discussed - if so I apologize. Beyond the performance aspects, I see a need for being able to specify a repository on an artifact basis. Here at Cobalt we deal with three fundamental types of artifacts - released to production, released to QA, and bleeding edge. 95% of the time dev will pick up a snapshot or a released version. But there is always the case where a dev needs a bleeding edge artifact from another team. (I can't assume that a dev will have access to the source of that other artifact) Snapshots and released artifacts cover our first two types - released to prod and QA. But I currently don't see a way to handle a third, or fourth, type with out being able to specify where to look for an artifact. I noticed that Jörg Schaible's post kinda made the same point with the suggestion of a tag in the dependency element. Hows does any of this fit into"in situ" artifacts? -steve Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVEN-1496) Exception during java:compile
Message:
The following issue has been closed.
Resolver: Brett Porter
Date: Tue, 23 Nov 2004 7:39 AM
this looks like the antlr JAR or the commons-jelly-tags-antlr JAR are corrupt -
try deleting them and running again online.
-
View the issue:
http://jira.codehaus.org/browse/MAVEN-1496
Here is an overview of the issue:
-
Key: MAVEN-1496
Summary: Exception during java:compile
Type: Bug
Status: Closed
Priority: Major
Resolution: CANNOT REPRODUCE
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Versions:
1.0
Assignee:
Reporter: wernsdoerfer
Created: Sun, 7 Nov 2004 5:15 AM
Updated: Tue, 23 Nov 2004 7:39 AM
Environment: __ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.5.0
file.encoding=Cp1252
java.ext.dirs=D:\java\jdk1.5.0\jre\lib\ext
java.class.path=D:\java\Maven-1.0\lib\forehead-1.0-beta-5.jar
os.name=Windows XP
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=D:\java\Maven-1.0\lib\endorsed\xerces-2.4.0.jar;D:\java\Maven-1.0\lib\endorsed\xml-apis-1.0.b2.jar;D:\java\jdk1.5.0\jre\lib\rt.jar;D:\java\jdk1.5.0\jre\lib\i18n.jar;D:\java\jdk1.5.0\jre\lib\sunrsasign.jar;D:\java\jdk1.5.0\jre\lib\jsse.jar;D:\java\jdk1.5.0\jre\lib\jce.jar;D:\java\jdk1.5.0\jre\lib\charsets.jar;D:\java\jdk1.5.0\jre\classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.0
maven-announcement-plugin-1.2
maven-ant-plugin-1.7
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.1.1
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5
maven-checkstyle-plugin-2.4.1
maven-clean-plugin-1.3
maven-clover-plugin-1.5
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.4
maven-dashboard-plugin-1.3
maven-developer-activity-plugin-1.5
maven-dist-plugin-1.6
maven-docbook-plugin-1.2
maven-ear-plugin-1.5
maven-eclipse-plugin-1.7
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.1
maven-html2xdoc-plugin-1.3
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5
maven-jalopy-plugin-1.3
maven-jar-plugin-1.6
maven-java-plugin-1.4
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.6.1
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.7
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.1
maven-jnlp-plugin-1.4
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.1
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.2
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.1
maven-plugin-plugin-1.5.1
maven-pmd-plugin-1.5
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4
maven-repository-plugin-1.2
maven-scm-plugin-1.4
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.1
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Exception reading build.properties: C:\Dokumente und
Einstellungen\thomas\build.properties (Das System kann die angegebene Datei
nicht finden)
Home Build properties: {}
Description:
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
Could not find the class: org.apache.commons.jelly.tags.antlr.AntlrTagLibrary
java.lang.ClassNotFoundException:
org.apache.commons.jelly.tags.antlr.AntlrTagLibrary
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:425)
at
org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171)
at
org.apache.commons.jelly.JellyCont
RE: [PROPOSAL] Ading a new tag to ?
> -Original Message- > From: Stephen Nesbitt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 23, 2004 1:14 AM > To: [EMAIL PROTECTED] > Cc: Vincent Massol > Subject: Re: [PROPOSAL] Ading a new tag to ? > > > On Sunday 21 November 2004 02:14, Vincent Massol wrote: > > Hi Maven devs, > > > > I think there's a need to allow specifying when some artifacts > > are only to be looked for in the local repository. For example, > > in a multiproject the local repository is used to share private > > artifacts between the subprojects. These private artifacts are > > not meant to be uploaded to a Maven remote repo. > > > [..] > I noticed that Jörg Schaible's post kinda made the same point with > the suggestion of a tag in the dependency element. > > Hows does any of this fit into"in situ" artifacts? In situ artifact won't be that helpful in that case if it comes to speed of processing. Other m2 feature might be helpful - you can define a repositories per project basis. IT means that each pom can contain the location from which corresponding jar should be taken and you just need to push your poms to right repositoriy(ies) In m2 we have limited the number of repositories into which you can deploy artifact to 1. That's is probaably something which we may can revisit in case it will be really needed as I also see a need of having distinct repositories for snapshots artifacts and released artifacts. We can probably search for solution here. But first we have to be ready with more fundental things as the processing model in m2 is bit different mainly due to introduction of transitive dependencies and it might be that we will find different bottlnecks and while we will be searching for the solution which will remove them also this problem will be gone. But such use cases like yours are definitly helpful for us as definitly large teams of devlopers are using maven differently then we do internally among maven devlopers. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Ading a new tag to ?
> -Original Message- > From: Corey Scott [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 23, 2004 5:11 AM > To: Maven Developers List > Subject: Re: [PROPOSAL] Ading a new tag to ? > > > While we are on the subject of adding tags to has a scope > tag been considered? Yes it is still considered and will be addressed soon. The final form of that functinality is not yet decided and the version similar to which you have shown is still a serious contender... Other options include among others tag whch will merge two concern: what you use as "type" now and the what you want to use as "scope". I am personally more supportive for the first option as imo it will be overall simpler. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
This has been discussed several times in the past. I must say, scope is probably the best name I've seen for it so far. It will get resolved in some way in the near future. - Brett Corey Scott wrote: While we are on the subject of adding tags to has a scope tag been considered? This would allow users to generate dep reports and so on that lead to a better understanding of where and why the dependancy exists. Examples: Runtime (default) runtime Test Only test Build Only build Dependancy of a Dependancy ?? I believe that this has been hinted at during previous discussions and bug reports and i think it is has merit. Comments? -Corey - 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: maven site work
Help on documentation is always welcome, and being a non-expert is fine because you probably see things that long-time users miss or assume. The best way to contribute is to pick something you think is not explained well enough, and write it down through your own experience. Polish it up as much as possible, and submit it. If possible, check with the list first to see if it would be useful, or if someone is already working on it. I've started putting together some principles (common terminology, style guidelines) that we might be able to discuss to give the whole set a more coherent feel, so keep an eye out for that too when I get it together for comments. - Brett Corey Scott wrote: I love the new menu, I think it will be great for first time users as it requires less interpretation. I am happy to help out with the docs (although I am by no means a Maven expert yet), just let me know what you would like done and if I can I will help out. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1507) Fails on IBM 1.3 JDK
The following comment has been added to this issue: Author: David J. M. Karlsen Created: Tue, 23 Nov 2004 5:31 AM Body: I can report the same problem: C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v5\java\bin>java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1) Classic VM (build 1.3.1, J2RE 1.3.1 IBM Windows 32 build cn131-20030711a (JIT enabled: jitc)) does not work (same error message). C:\j2sdk1.4.2_06\bin>java -version java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) maven.jar is not found in either of the JDK's, neither in external CLASSPATH or the likes. - View this comment: http://jira.codehaus.org/browse/MAVEN-1507?page=comments#action_27059 - View the issue: http://jira.codehaus.org/browse/MAVEN-1507 Here is an overview of the issue: - Key: MAVEN-1507 Summary: Fails on IBM 1.3 JDK Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: core Fix Fors: 1.0.2 Versions: 1.0.1 Assignee: Reporter: dion gillard Created: Tue, 16 Nov 2004 10:44 PM Updated: Tue, 23 Nov 2004 5:31 AM Environment: WinXP SP 2, IBM JDK: Description: Not sure what can be done about this, but felt it better to report it than let it slide. C:\source\wsad\workspace\Deployment>set JAVA_HOME=c:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v 5\java C:\source\wsad\workspace\Deployment>maven clean __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.1 java.lang.NoSuchFieldError: org.apache.maven.repository.AbstractArtifact: field OVERRIDE_NONE not found at org.apache.maven.repository.AbstractArtifact.(AbstractArtifact.java:53) at org.apache.maven.repository.GenericArtifact.(GenericArtifact.java:40) at org.apache.maven.repository.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:53) at org.apache.maven.ArtifactListBuilder.build(ArtifactListBuilder.java:59) at org.apache.maven.project.Project.buildArtifactList(Project.java:1407) at org.apache.maven.project.Project.initialize(Project.java:1341) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:148) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error running Maven. Please help us to correct this problem by following these simple steps: - read the Maven FAQ at http://maven.apache.org/faq.html - run the same command again with the '-e' parameter, eg maven -e jar - search the maven-user archives for the error at http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] - post the output of maven -e to JIRA at http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up first) - run 'maven --info' and post the output as the environment to the bug above Total time: 3 seconds Finished at: Wed Nov 17 14:06:21 EST 2004 C:\source\wsad\workspace\Deployment>"%JAVA_HOME%\bin\java" -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1) Classic VM (build 1.3.1, J2RE 1.3.1 IBM Windows 32 build cn131-20030711a (JIT enabled: jitc)) - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
