integrating with continuum
Hi there, I am new to Continuum and was wondering if it is possible to extend Continuum by adding new project types. I'd like to add my own Add XXX Project link on the Continuum page next to the other links for Maven, Maven2, Ant, and Shell projects. Or alternatively if I could use an API to add my projects programatically to the database. Is this already possible? TIA, Knut Wannheden
Re: integrating with continuum
You can't add an other type of project. What is your project type? We have a start of xmlrpc client in jira that can manage continuum, but it don't help you with new project type. Emmanuel Knut Wannheden a écrit : Hi there, I am new to Continuum and was wondering if it is possible to extend Continuum by adding new project types. I'd like to add my own Add XXX Project link on the Continuum page next to the other links for Maven, Maven2, Ant, and Shell projects. Or alternatively if I could use an API to add my projects programatically to the database. Is this already possible? TIA, Knut Wannheden
[jira] Commented: (CONTINUUM-385) run.sh on MacOS X fails with problem in wrapper
[ http://jira.codehaus.org/browse/CONTINUUM-385?page=comments#action_57523 ] Konstntin Polyzois commented on CONTINUUM-385: -- Any news on this one? run.sh on MacOS X fails with problem in wrapper --- Key: CONTINUUM-385 URL: http://jira.codehaus.org/browse/CONTINUUM-385 Project: Continuum Type: Bug Components: Core system Versions: 1.0 Environment: Mac OS X 10.4 Reporter: Mark Donszelmann Priority: Minor Fix For: 1.1 Hi running continuum 1.0 on MacOS X 10.4 gives me the following when started as: bin/macosx/runs.h start or bin/macosx/runs.h console -- Output Running continuum... Removed stale pid file: ./continuum.pid wrapper | -- Wrapper Started as Console dyld: lazy symbol binding failed: Symbol not found: _ftime Referenced from: /Users/duns/java/continuum-1.0/bin/macosx/wrapper Expected in: /usr/lib/libcrypto.0.9.7.dylib dyld: Symbol not found: _ftime Referenced from: /Users/duns/java/continuum-1.0/bin/macosx/wrapper Expected in: /usr/lib/libcrypto.0.9.7.dylib Trace/BPT trap -- while if I run bin/plexus.sh all works fine (but only interactively. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: integrating with continuum
Knut Wannheden a écrit : Emmanuel, On 2/1/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: You can't add an other type of project. What is your project type? In our development enviroment we have our own project file format (similar to Maven POM) and our own build tools on top of this. The reason we are not using any existing tools, like Maven, ist that we had some specific requirements which other tools could not handle at the time we implemented this. This development and build environment is developed in Java so I was hoping that it would be easy to integrate as some kind of extension to Continuum. I'd like to add projects with interdependencies to Continuum. Can I also use the shell project type for this? You can use the shell project type. You only need a command line to launch your build. Interdependencies between projects are available for now only for maven projects. We'll add this feature for ant and shell projects in 1.1 As we have very many projects, which also change over time, I'd like to use some kind of API to keep the project definitions in Continuum in sync. Thus I was wondering about adding new project types or an API to add projects. What sort of changes do you want to do? Can you see a viable solution to this? Or should I enter a feature request in JIRA? Look at CONTINUUM-544 for a xmlrpc client. I'll integrate it later in continuum. Regards, --knut
Re: integrating with continuum
Knut Wannheden a écrit : I'd like to add projects with interdependencies to Continuum. Can I also use the shell project type for this? You can use the shell project type. You only need a command line to launch your build. Interdependencies between projects are available for now only for maven projects. We'll add this feature for ant and shell projects in 1.1 OK. I think I remember reading somewhere that the shell project type is currently limited in that way. So I'm looking forward to the 1.1 release. As we have very many projects, which also change over time, I'd like to use some kind of API to keep the project definitions in Continuum in sync. Thus I was wondering about adding new project types or an API to add projects. What sort of changes do you want to do? I'm not sure I quite understand your question. But let me explain what I'd like to do. We have 100+ projects in our development environment and occasionally we add new projects and change the dependencies between existing projects. We also change the developer list for the projects. Obviously I'd like the definitions in Continuum to stay in sync without having to enter and verify that manually. I have my answer ;-) You'll can do it by xmlrpc client api. Can you see a viable solution to this? Or should I enter a feature request in JIRA? Look at CONTINUUM-544 for a xmlrpc client. I'll integrate it later in continuum. That certainly looks interesting. I see this is also scheduled for 1.1. Is there an estimated relases date for 1.1? It's perhaps in 1.0.3. alpha of 1.1 will probably release in 2006Q1 and final in 2006Q2 Emmanuel Regards, --knut
Re: integrating with continuum
Emmanuel, I'm not sure I quite understand your question. But let me explain what I'd like to do. We have 100+ projects in our development environment and occasionally we add new projects and change the dependencies between existing projects. We also change the developer list for the projects. Obviously I'd like the definitions in Continuum to stay in sync without having to enter and verify that manually. I have my answer ;-) You'll can do it by xmlrpc client api. Excellent! That certainly looks interesting. I see this is also scheduled for 1.1. Is there an estimated relases date for 1.1? It's perhaps in 1.0.3. alpha of 1.1 will probably release in 2006Q1 and final in 2006Q2 Sounds good. I'm looking forward for these enhancements! Cheers, --knut
[jira] Updated: (CONTINUUM-510) big year schedule 2099 prevents continuum from startup
[ http://jira.codehaus.org/browse/CONTINUUM-510?page=all ] John Casey updated CONTINUUM-510: - Fix Version: (was: 1.1-alpha-1) 1.0.3 big year schedule 2099 prevents continuum from startup Key: CONTINUUM-510 URL: http://jira.codehaus.org/browse/CONTINUUM-510 Project: Continuum Type: Bug Components: Web interface, Core system Versions: 1.0.2 Environment: xp,starteam Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 - Create a scheduler with year 2099 ( ex 0 15 10 * * ? 2100 ) Continuum does throw exception letting user know it will never got fired but still add it to dabase - Assign the newly create scheduler to a project - restart - Continuum webapp never get started The only solution i can think of is to remove database and start from scratch According to Evenisse, Quart does not allow year 2099 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-531) Add back the build now button on the view project page.
[ http://jira.codehaus.org/browse/CONTINUUM-531?page=all ] John Casey updated CONTINUUM-531: - Fix Version: (was: 1.1-alpha-1) 1.0.3 Add back the build now button on the view project page. --- Key: CONTINUUM-531 URL: http://jira.codehaus.org/browse/CONTINUUM-531 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Trygve Laugstol Assignee: nick gonzalez Fix For: 1.0.3 Attachments: CONTINUUM-531.patch -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-567) A build must be launched if we have changes since last build (for same build definition) and not only if we have detected changes when we run scm update commad
[ http://jira.codehaus.org/browse/CONTINUUM-567?page=all ] John Casey updated CONTINUUM-567: - Fix Version: (was: 1.1-alpha-1) 1.0.3 A build must be launched if we have changes since last build (for same build definition) and not only if we have detected changes when we run scm update commad --- Key: CONTINUUM-567 URL: http://jira.codehaus.org/browse/CONTINUUM-567 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.2 Reporter: Emmanuel Venisse Assignee: nick gonzalez Fix For: 1.0.3 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-354) Need a way to poll for new projects
[ http://jira.codehaus.org/browse/CONTINUUM-354?page=all ] John Casey updated CONTINUUM-354: - Fix Version: (was: 1.1-alpha-1) 1.0.3 Need a way to poll for new projects --- Key: CONTINUUM-354 URL: http://jira.codehaus.org/browse/CONTINUUM-354 Project: Continuum Type: Improvement Versions: 1.0-beta-1 Reporter: Matthew Beermann Assignee: nick gonzalez Fix For: 1.0.3 The feature where Continuum can populate its build list from a URL is wonderful; it'd be even more wonderful if it could remember that URL and poll it periodically. We have a master build list of all projects that we'll use to initially populate the build database; but ideally we could simply add a new project to that in CVS and have Continuum just pick it up. This is a feature that we've (somewhat painfully) managed to implement in CruiseControl, and it's a must-have if we're going to switch over... this might or might not depend on CONTINUUM-330. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-496) End Time contains junk value when I forced a build to run
[ http://jira.codehaus.org/browse/CONTINUUM-496?page=all ] John Casey updated CONTINUUM-496: - Fix Version: (was: 1.1-alpha-1) 1.0.3 End Time contains junk value when I forced a build to run - Key: CONTINUUM-496 URL: http://jira.codehaus.org/browse/CONTINUUM-496 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: John Sisson Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0.3 The following is from the build history when it was building. Note the end time on the first line: Dec 1, 2005 10:23:11 PM Dec 31, 1969 4:00:00 PM BuildingResult 22Dec 1, 2005 10:00:18 PM Dec 1, 2005 10:06:51 PM Success Result 21Dec 1, 2005 7:00:16 PM Dec 1, 2005 7:03:57 PM Success Result This occurred on http://ci.gbuild.org/continuum/servlet/continuum running a 1.1-SNAPSHOT. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-576) all builds stuck in in progress/scheduled state
all builds stuck in in progress/scheduled state - Key: CONTINUUM-576 URL: http://jira.codehaus.org/browse/CONTINUUM-576 Project: Continuum Type: Bug Components: Core system Reporter: Brett Porter Fix For: 1.0.3 ci.codehaus.org was stuck in this state for about 20 days and noone noticed :) I know we have corrective measures on startup - is that something that can be done when a build is triggered? Another option is to go all the way to detecting if the build process still exists, which would allow the ability to implement stop functionality as well. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-147) Add Bazaar provider documentation
Add Bazaar provider documentation - Key: SCM-147 URL: http://jira.codehaus.org/browse/SCM-147 Project: Maven SCM Type: New Feature Components: maven-scm-site Reporter: Torbjørn EIkli Smørgrav Priority: Minor -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: process of releasing plugins bug reports
jerome lacoste wrote: Sorry but it's not marked as such in Jira http://jira.codehaus.org/browse/MASSEMBLY-19 Component/s: None Affects Version/s:None Fix Version/s:None I know its a pain in the butt, but I will reiterate. We created the JIRA projects *after* the bugs were resolved. We didn't have enough information to go back and figure out which belonged to which version. Nothing wrong with the process, the past data was floored. Sorry, but I can't fix it now. And again, I need to point out the release of your issue has not been delayed. 2.0.1 wasn't originally planned. [snip part based on the assumption we reviewed all 60 assembly issues] I don't know what else I could do appart from notifying you that it wasn't included in the forthcoming release. I missed the vote mail (which maybe shouldn't be on the dev list?). Right. The proposed solution was already given. WRT to backport, I asked in another mail thread to backport it and make a 2.0.2. I replied here before reading that, sorry. I feelt that the longer you stay with this issue in the code, the more you have a chance to break existing user configurations who will do the upgrade. I think once its released, the time in between is irrelevant as people don't always upgrade as soon as there is a release. Reviewing the issue, I don't get it. I can see how its a breaking change, but I don't see how anyone would consider the previous behaviour anything but a bug (its ignoring outputDirectory, right?) I don't see this as urgent. We do need to prioritise the 2.1 release anyway. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSITE-72) new non reactor populateModules SiteMojo code assumes each POM declares its own URL
[ http://jira.codehaus.org/browse/MSITE-72?page=all ]
John Allen updated MSITE-72:
Attachment: SiteMojo.diff
new non reactor populateModules SiteMojo code assumes each POM declares its
own URL
---
Key: MSITE-72
URL: http://jira.codehaus.org/browse/MSITE-72
Project: Maven 2.x Site Plugin
Type: Bug
Reporter: John Allen
Fix For: 2.0
Attachments: SiteMojo.diff
In populateModules() :-
SiteMojo.java +523
File f = new File( project.getBasedir(), module +
/pom.xml );
if ( f.exists() )
{
MavenXpp3Reader reader = new MavenXpp3Reader();
FileReader fileReader = null;
try
{
fileReader = new FileReader( f );
model = reader.read( fileReader );
This code assumes that a modules POM declares a URL. All my modules rely upon
a parent in the ancestry to define their URL resulting in an empty modules
menu.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: integrating with continuum
Emmanuel, On 2/1/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: You can't add an other type of project. What is your project type? In our development enviroment we have our own project file format (similar to Maven POM) and our own build tools on top of this. The reason we are not using any existing tools, like Maven, ist that we had some specific requirements which other tools could not handle at the time we implemented this. This development and build environment is developed in Java so I was hoping that it would be easy to integrate as some kind of extension to Continuum. I'd like to add projects with interdependencies to Continuum. Can I also use the shell project type for this? As we have very many projects, which also change over time, I'd like to use some kind of API to keep the project definitions in Continuum in sync. Thus I was wondering about adding new project types or an API to add projects. Can you see a viable solution to this? Or should I enter a feature request in JIRA? Regards, --knut
Re: process of releasing plugins bug reports
On 2/1/06, Brett Porter [EMAIL PROTECTED] wrote: jerome lacoste wrote: Sorry but it's not marked as such in Jira http://jira.codehaus.org/browse/MASSEMBLY-19 Component/s: None Affects Version/s:None Fix Version/s:None I know its a pain in the butt, but I will reiterate. Note I am not trying to be a pain in the butt here. I am just saying that there was something that could have been done better and that I hope won't happen again. So the question is are we sure that this won't happen again? I am not convinced. We created the JIRA projects *after* the bugs were resolved. We didn't have enough information to go back and figure out which belonged to which version. OK Nothing wrong with the process, the past data was floored. Sorry, but I can't fix it now. And again, I need to point out the release of your issue has not been delayed. 2.0.1 wasn't originally planned. Didn't know that. OK. [snip part based on the assumption we reviewed all 60 assembly issues] Misunderstanding. I didn't assume you reviewed all issues. More on that below. I will try to summarize the problems I see: the only way for me to know about the fact that my issue wasn't fixed in the forthcoming release was to read the vote email on the developer list. I missed it. I also forgot to watch the issue in Jira (why isn't that automatic for the reporter?) My bad. Could there have been more things that made me able to not miss that? I believe so. - why the issue wasn't considered for the branch in the first place? It was marked as critical in Jira and was a one liner. Is there something we can do to Jira to mark them better? - if you cannot review all the issues, make sure we can help. Either add a message to all issues in Jira please help us triage these issues before the forthcoming branch. Jira has a bulk edit mode (I checked it and it works on the projects I have edit rights), so it still can be used there. I can't do it though. - of all the 60 assembly plugin issues, only 18 are marked today with no fix version but fixed in Jira. Of all these, only 4 are marked as critical or above. (funny part, all of these were reported by me...). All had a patch. The blocker one even had 2 votes (3 if you include me) and wasn't considered neither. The patch looks complex but is very very simple if you look at the issue comments. - since we only split out the JIRA projects recently, we didn't know which were in 2.0 and which were more recent. svn integration in Jira could have helped with that. Shouldn't this be implemented? - if you release a branch, make this information more prominent. Branch don't seem to be that usual in the current plugin release process. Maybe add the word branch in the vote title, maybe send the message in another channel (not just the dev list). If the effort is made to make a branch, backport patches, vote release, why not spend it to review some issues and make sure the community isn't surprised? - each plugin is released with its own version in a very loosed couple manner. I find it pretty hard to follow what's going on and how it's going to affect my builds (I've seen wrong dependencies in pom). I guess the process is going to become better later on, but my experience with other systems that handle dependencies let me think that issues in this area won't go away. People make mistakes. I don't know what else I could do appart from notifying you that it wasn't included in the forthcoming release. I missed the vote mail (which maybe shouldn't be on the dev list?). Right. The proposed solution was already given. WRT to backport, I asked in another mail thread to backport it and make a 2.0.2. I replied here before reading that, sorry. I feelt that the longer you stay with this issue in the code, the more you have a chance to break existing user configurations who will do the upgrade. I think once its released, the time in between is irrelevant as people don't always upgrade as soon as there is a release. Reviewing the issue, I don't get it. I can see how its a breaking change, but I don't see how anyone would consider the previous behaviour anything but a bug (its ignoring outputDirectory, right?) I don't see this as urgent. We do need to prioritise the 2.1 release anyway. Assembly plugin within a multi-project doesn't work for me right now. No more no less. For me that's a show stopper. And that seems to be a show stopped for at least 2 other persons. PS: I could have used a very small part of the time spent writing these mails to prepare and release 2.0.2. * I can't. Is there any interest in releasing a 2.0.2? If so how can I help? * if I send these mails it's in the hope that things will be better next time. If you think I am wasting your time, let me know (or ignore them, but I'd prefer to know...). Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For
[jira] Created: (MSITE-84) Refactor of site:stage and site:site required due to new site:site modules appraoch
Refactor of site:stage and site:site required due to new site:site modules appraoch --- Key: MSITE-84 URL: http://jira.codehaus.org/browse/MSITE-84 Project: Maven 2.x Site Plugin Type: Improvement Reporter: John Allen site:stage was designed to provide a means of normalising all the URLs involved in a reactor built site to be local filesystem based paths allowing a complete site to be built and tested without it being deployed to the target deployment location(s) - it did this by modifying all project URLs (parent/module/etc) to be prefixed with a file URL based upon their site Wagon URLs. The new site:site code is taken a more intrusive appraoch to determining module details (either reading module pom.xmls or with my patch, sourcing them from the repository) - this approach prevents the site:stage Mojo getting in there first and modifying the project URLs before the site:site Mojo processes them. A cooperative redesign is required to enable this new site:site module handling functionality and the existing site:stage functionality. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Specify multiple proxies
Brett Porter wrote: Thomas Recloux wrote: I see two solutions: - Keeping only one active proxy and add a way to specify multiple protocols by proxy. - Modify the Settings and DefaultMaven objects to add one active proxy server by protocol. What do you think of this? If you choose one of theses solutions, I can post the patch. I think they are both good solutions and maybe could be used together. I'd start with the second one as it doesn't requires model changes and can be included in Maven 2.0.3. I'd also special case https to use the http proxy if none is defined. Proxy setup in java is a real pain. Personally I'd like apps on my laptop to try and use a proxy if nslookup fails then skip it if not, but try explaining that to Java, even Java1.5. And don't even mention the autoproxy stuff in Java1.5 as it doesn't work. My laptop is clever enough to change IE's proxy settings as it roams (see http://www.hpl.hp.com/techreports/2001/HPL-2001-158.pdf ) , and yet the java 5 proxy stuff doesnt pick up even static things. My planned workaround for all this is to actually host a local proxy and route everything through there, with that separate program containing all the logic for proxy binding hosted there -it'd contain the intelligence to choose proxy based on WLAN ID, IP address c, and have a single override point. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-715) JUnit addon: jfcunit
JUnit addon: jfcunit Key: MAVENUPLOAD-715 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-715 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: jfcunit-2.0.8-bundle.jar jfcUnit enables developers to write test cases for Java Swing based applications. - I'm not the developer - checked it compiles with given dependencies -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1898) Plugin classpath broken from 2.0 to 2.0.1
[ http://jira.codehaus.org/browse/MNG-1898?page=comments#action_57528 ]
Brian Fox commented on MNG-1898:
Any progress on this issue? I would like to move forward with my plugins but
can't because of this. We are stuck maintaining a bunch of lame ant scripts in
the meantime.
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http://jira.codehaus.org/browse/MNG-1898
Project: Maven 2
Type: Bug
Environment: winxp
Reporter: Brian Fox
Assignee: John Casey
Priority: Blocker
Fix For: 2.0.3
Attachments: MNG-1898-coreit.tar.bz2, test-1.0.zip, test-case.zip
I'm working on a kodo plugin in the codehaus mojo sandbox. Using 2.0, it
works fine. In 2.1, it can't find xercesImpl, which is a transitive
dependency of the plugin. Did something change to cause new behavior (aka a
bug) related to this? Just eyeballing the info below, in 2.0, the instance of
classloader was org.codehaus.classworlds.RealmClassLoader but in 2.0.1 it is
org.codehaus.plexus.util.RealmDelegatingClassLoader
I tried specifying xercesImpl as a direct dependency and that didn't work
either so I'm not sure it's related to the transitivity.
Output from 2.0.1: (2.0 follows further below)
[DEBUG] org.codehaus.mojo:kodo-maven-plugin:maven-plugin:1.0-alpha-1-SNAPSHOT
(selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (setting version to: 3.3.3 from
range: [3.0,])
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (selected for runtime)
[DEBUG] com.solarmetric:kodo-wl81manage:jar:1.0 (selected for runtime)
[DEBUG] com.solarmetric:kodo-workbench:jar:1.0 (selected for runtime)
[DEBUG] org.hsqldb:jdbc-hsql:jar:1.7.0 (selected for runtime)
[DEBUG] sqlline:sqlline:jar:1.0 (selected for runtime)
[DEBUG] jcommon:jcommon:jar:0.9.1 (selected for runtime)
[DEBUG] javax.jdo:jdo:jar:1.0.2 (selected for runtime)
[DEBUG] xalan:xalan:jar:2.5.1 (selected for runtime)
[DEBUG] jfreechart:jfreechart:jar:0.9.16 (selected for runtime)
[DEBUG] com.solarmetric:kodo-jdo-runtime:jar:3.3.3 (selected for runtime)
[DEBUG] javax.sql:jdbc-stdext:jar:2.0 (selected for runtime)
[DEBUG] jline:jline:jar:0.9.1 (selected for runtime)
[DEBUG] mx4j:mx4j-jmx:jar:1.1.1 (selected for runtime)
[DEBUG] jta-spec:jta-spec:jar:1.0.1 (selected for runtime)
[WARNING] While downloading xml-apis:xml-apis:2.0.0
This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
[DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for runtime)
[DEBUG] xerces:xercesImpl:jar:2.5.0 (selected for runtime)
[DEBUG] jca:jca:jar:1.0.0 (selected for runtime)
[DEBUG] mx4j:mx4j-tools:jar:1.1.1 (selected for runtime)
[DEBUG] jndi:jndi:jar:1.2.1 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] log4j:log4j:jar:1.2.12 (setting version to: 1.2.12 from range:
[1.2.9,])
[DEBUG] log4j:log4j:jar:1.2.12 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0 (selected for runtime)
[DEBUG] Configuring mojo
'org.codehaus.mojo:kodo-maven-plugin:1.0-alpha-1-SNAPSHOT:enhance' --
[DEBUG] (f) classDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] (f) searchDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] -- end configuration --
[INFO] [kodo:enhance {execution: kodo-enhance}]
[info] Found
file:E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes\com\stchome\application\supplementalforms\persist\persist.jdo
[info] [EMAIL PROTECTED]
[debug] Added to Classpath:
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/src/main/resources/
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/target/classes/
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
[INFO]
[DEBUG] Trace
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:93)
at serp.xml.XMLFactory.checkSAXCache(XMLFactory.java:217)
at serp.xml.XMLFactory.getSAXParser(XMLFactory.java:66)
at
com.solarmetric.meta.XMLMetaDataParser.parseNew(XMLMetaDataParser.java:354)
at com.solarmetric.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:320)
at
[jira] Created: (MRESOURCES-10) Filtering should handle java.io.File values
Filtering should handle java.io.File values
---
Key: MRESOURCES-10
URL: http://jira.codehaus.org/browse/MRESOURCES-10
Project: Maven 2.x Resources Plugin
Type: Improvement
Reporter: Mike Perham
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and this
becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/${pom.artifactId};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
java.lang.ClassCastException: java.io.File
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:100)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
at
org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRESOURCES-10) Filtering should handle java.io.File values
[ http://jira.codehaus.org/browse/MRESOURCES-10?page=all ]
Mike Perham updated MRESOURCES-10:
--
Description:
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and this
becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/$\{pom.artifactId\};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
java.lang.ClassCastException: java.io.File
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:100)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
at
org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
was:
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and this
becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/${pom.artifactId};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
java.lang.ClassCastException: java.io.File
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:100)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
at
org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
Filtering should handle java.io.File values
---
Key: MRESOURCES-10
URL: http://jira.codehaus.org/browse/MRESOURCES-10
Project: Maven 2.x Resources Plugin
Type: Improvement
Reporter: Mike Perham
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and
this becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/$\{pom.artifactId\};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
[jira] Updated: (MRESOURCES-10) Filtering should handle java.io.File values
[ http://jira.codehaus.org/browse/MRESOURCES-10?page=all ]
Mike Perham updated MRESOURCES-10:
--
Description:
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and this
becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/${pom.artifactId};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
java.lang.ClassCastException: java.io.File
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:100)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
at
org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
was:
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and this
becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/$\{pom.artifactId\};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
java.lang.ClassCastException: java.io.File
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
at
org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
at java.io.Reader.read(Reader.java:100)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
at
org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
Filtering should handle java.io.File values
---
Key: MRESOURCES-10
URL: http://jira.codehaus.org/browse/MRESOURCES-10
Project: Maven 2.x Resources Plugin
Type: Improvement
Reporter: Mike Perham
I'm trying to use filters along with ${basedir} to setup my unit test Derby
database. Derby must have a unique directory to build its database in and
this becomes a problem in multi-module builds.
Currently I'm doing this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:target/test/testdb/${pom.artifactId};create=true/value/property
/bean
{code}
But I'd like to do this:
{code:xml}
bean id=wsf.storage.dataSource
class=org.apache.commons.dbcp.BasicDataSource
property
name=driverClassNamevalueorg.apache.derby.jdbc.EmbeddedDriver/value/property
property
name=urlvaluejdbc:derby:${basedir}/target/test/testdb;create=true/value/property
/bean
{code}
When I try to do the latter, I get this:
Re: [vote] [m1] plugin releases
Stephane Nicoll wrote: +1 for All except Jira-plugin +0 ; Dependency on Jira 3.3+ might be a big issue. Had anyone sent a mail to the user list about it? I don't think this is a big issue. The restriction to Jira 3.3+ was necessary because of an API change in Jira itself, see http://jira.codehaus.org/browse/MPJIRA-17. I don't know exactly what will happen if you use an older version of Jira, I dont have one to test, but AFAICT, it should work overall, only the filtering (by resolution, priority or status) will not be correct. That's why I said on the web page 'needs at least JIRA 3.3 to work properly' and not 'needs at least JIRA 3.3 to work'. I don't know if it's necessary to send a mail to the user list, or just document it in more detail? -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPPLUGIN-35) plugin:install fails if maven.jar.final.name is set
[ http://jira.codehaus.org/browse/MPPLUGIN-35?page=all ]
Lukas Theussl closed MPPLUGIN-35:
-
Resolution: Fixed
Now using ${maven.final.name}.jar everywhere. Plugins need standard names so
they can be uninstalled properly.
plugin:install fails if maven.jar.final.name is set
Key: MPPLUGIN-35
URL: http://jira.codehaus.org/browse/MPPLUGIN-35
Project: maven-plugin-plugin
Type: Bug
Versions: 1.7
Environment: m11b3
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.7.1
The plugin:plugin goal uses ${maven.jar.final.name} as build artifact, but
all other goals (install, deploy...) use ${maven.final.name}.jar. This
should have been fixed with the patch attached to MPJAVA-8, but it hasn't.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MJAR-27) jar:sign doesn't check if project prouces an artifact
jar:sign doesn't check if project prouces an artifact - Key: MJAR-27 URL: http://jira.codehaus.org/browse/MJAR-27 Project: Maven 2.x Jar Plugin Type: Bug Environment: Maven 2.0.2 Latest Jar checkout Reporter: Michael Böckling Attachments: jarsign-patch.txt jar:sign does not skip projects that don't produce an artifact (=pom packaging). Attached patch to detect this situation and handle it gracefully. Since similar issues showed up in the Javadoc and Cobertura plugin, too, I was wondering if an additional mojo annotation like @requireLanguage (project must have e.e. java as its language) or @requireArtifact (don't execute if this project does not create an artifact, e.g. has pom packaging) would make sense. Stuff like this makes it much harder to establish a company-wide standardized build process, since there are always pom projects in the inheritance hierarchy... -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-715) JUnit addon: jfcunit
[ http://jira.codehaus.org/browse/MAVENUPLOAD-715?page=comments#action_57550 ] Carlos Sanchez commented on MAVENUPLOAD-715: Version of the project is 2.08 not 2.0.8 JUnit addon: jfcunit Key: MAVENUPLOAD-715 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-715 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: jfcunit-2.0.8-bundle.jar jfcUnit enables developers to write test cases for Java Swing based applications. - I'm not the developer - checked it compiles with given dependencies -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-686) Please, upload JXTA 2.3.6 to the ibiblio repository.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-686?page=comments#action_57551 ] Carlos Sanchez commented on MAVENUPLOAD-686: As stated in the documentation for uploads, I won't upload this to jxta - wrong groupIds, now we use fully qualified org.jxta - I don't see any proof that they control the whole jxta.org is the same as if I want to upload something to net.souceforge just because I have a project hosted there I haven't looked at the sources, and I won't Please, upload JXTA 2.3.6 to the ibiblio repository. Key: MAVENUPLOAD-686 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-686 Project: maven-upload-requests Type: Task Reporter: Loic Lefevre http://lolosav.free.fr/dev/jxta-2.3.6-bundle.jar JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-708) Hibernate Annotations 3.1 beta 8 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-708?page=all ] Carlos Sanchez closed MAVENUPLOAD-708: -- Assign To: Carlos Sanchez Resolution: Fixed Hibernate Annotations 3.1 beta 8 upload request --- Key: MAVENUPLOAD-708 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-708 Project: maven-upload-requests Type: Task Reporter: Nathan Hamblen Assignee: Carlos Sanchez Please upload. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-712) Upload hibernate-tools-3.1.0.beta4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-712?page=all ] Carlos Sanchez closed MAVENUPLOAD-712: -- Assign To: Carlos Sanchez Resolution: Fixed Upload hibernate-tools-3.1.0.beta4 -- Key: MAVENUPLOAD-712 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-712 Project: maven-upload-requests Type: Bug Reporter: Tomislav Stojcevich Assignee: Carlos Sanchez Attachments: hibernate-tools-3.1.0.beta4-bundle.jar, hibernate-tools-3.1.0.beta4-bundle.jar, jtidy-r8-21122004-bundle.jar, jtidy-r8-21122004-bundle.jar Upload new version. Also attached is special version of jtidy that is distributed with the package, the groupid is set to org.hibernate.hibernate-tools for this version as suggested in MAVENUPOLAD-690 which was created for MAVENUPLOAD-691. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-715) JUnit addon: jfcunit
[ http://jira.codehaus.org/browse/MAVENUPLOAD-715?page=all ] Michael Böckling updated MAVENUPLOAD-715: - Attachment: jfcunit-2.08-bundle.jar JUnit addon: jfcunit Key: MAVENUPLOAD-715 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-715 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: jfcunit-2.0.8-bundle.jar, jfcunit-2.08-bundle.jar jfcUnit enables developers to write test cases for Java Swing based applications. - I'm not the developer - checked it compiles with given dependencies -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJAVA-8) Consistent properties for jar, war, ejb and ear
[ http://jira.codehaus.org/browse/MPJAVA-8?page=all ]
Lukas Theussl closed MPJAVA-8:
--
Resolution: Fixed
Closing now that MPPLUGIN-35 is fixed, I don't see any other place where this
is still an issue. The war case won't be fixed for backwards compatibility
reasons, see http://tinyurl.com/ayefj .
Consistent properties for jar, war, ejb and ear
---
Key: MPJAVA-8
URL: http://jira.codehaus.org/browse/MPJAVA-8
Project: maven-java-plugin
Type: Improvement
Reporter: Aslak Hellesoy
Attachments: MPJAVA-8-new1.patch, patch.diff
Time Spent: 30 minutes
Remaining: 0 minutes
The current naming conventions for properties defining the names of jar, ejb,
war and ear are somewhat inconsistent.
This patch introduces 4 new properties:
# defined in the java plugin's plugin.properties
maven.jar.final.name = ${maven.final.name}.jar
# defined in the war plugin's plugin.properties
maven.war.final.name = ${maven.final.name}.war
# defined in the ejb plugin's plugin.properties
maven.ejb.final.name = ${maven.final.name}.jar
# defined in the ear plugin's plugin.properties
maven.ear.final.name = ${maven.final.name}.ear
This patch solves the following problems:
1) It removes the risk of name clashes for projects that produce both plain
jar files and ejb jar files, since the maven.ejb.final.name property can be
overridden.
2) When packaging wars and ejbs inside ears, it is sometimes desirable to
have different names for ejbs and wars, like foo-ejb-1.0.jar and
foo-war-1.0.war. This is necessary when the contents of an ear file is to be
deployed on different weblogic servers with weblogic.deploy. This can now be
achieved by overriding maven.ejb.final.name and/or maven.war.final.name.
This patch should not change any of the current functionality, and the
documentation has been updated too.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPPLUGIN-30) Plugins on a per-user basis
[ http://jira.codehaus.org/browse/MPPLUGIN-30?page=all ]
Lukas Theussl updated MPPLUGIN-30:
--
Fix Version: 1.7.1
Can't we simply add a property to choose whether plugins get installed in
maven.plugin.dir or maven.plugin.user.dir?
Plugins on a per-user basis
---
Key: MPPLUGIN-30
URL: http://jira.codehaus.org/browse/MPPLUGIN-30
Project: maven-plugin-plugin
Type: Bug
Versions: 1.5
Environment: Linux (Debian), Maven 1.1
Reporter: Rodrigo S. de Castro
Fix For: 1.7.1
Attachments: maven-plugin-plugin-installation.patch
Problem:
When I try to compile Geronimo, it fails when trying to install its plugin
into the $MAVEN_HOME directory, since it is a shared installation in
/usr/local/maven-1.1. It does not install the plugins on a per-user basis to
my maven local directory (~/.maven). Is this the intended behaviour?
Analysis:
In the org.apache.maven.plugin.PluginManager class, which is called for
plugin:install-now, the plugin is installed in the user plugins dir, as we
may check through the following code:
if ( cache )
{
FileUtils.copyFileToDirectory( file, userPluginsDir );
cacheManager.registerPlugin( pluginName, housing );
housing.parse( cacheManager );
cacheManager.saveCache( unpackedPluginsDir );
}
Since I am not sure if the behaviour was intentional, I would like to know
your opinion about that.
From the point of view that there is an inconsistent behaviour, I will attach
a patch that changes plugin:install to do the same as plugin:install-now:
install in the user directory. With this patch, current repository version of
Apache Geronimo works properly.
Concerning plugin removal, the code already check both directories (global
and user), as you may check here (plugin/plugin.jelly):
define:tag name=uninstall
ant:delete verbose=false failonerror=false
ant:fileset dir=${maven.plugin.dir}
ant:include name=${name}-*.jar /
/ant:fileset
ant:fileset dir=${maven.plugin.user.dir}
ant:include name=${name}-*.jar /
/ant:fileset
/ant:delete
Thank you!
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (ARCHETYPE-23) Possibility to create real multiple modules with Java sources
[ http://jira.codehaus.org/browse/ARCHETYPE-23?page=comments#action_57555 ]
John Didion commented on ARCHETYPE-23:
--
I've modified archetype-core and archetype-plugin to provide this functionality
for our projects. I'll attache the code I modified to get this to work. Here's
an example of a multi-module archetype.xml:
{noformat}
?xml version=1.0?
archetype xmlns=http://maven.apache.org/Archetype/1.0.0;
idarchetype-webservice/id
modules
module
dirapi/dir
sources
sourcesrc/main/java/readme.txt/source
/sources
/module
module
dirimpl/dir
sources
sourcesrc/main/java/readme.txt/source
/sources
resources
resourcesrc/main/resources/readme.txt/resource
resourcesrc/main/resources/META-INF/PropertyMetadata.xml/resource
resourcesrc/main/sql/readme.txt/resource
/resources
testSources
testSourcesrc/test/java/readme.txt/testSource
/testSources
testResources
testResourcesrc/test/resources/readme.txt/testResource
testResourcesrc/test/sql/readme.txt/testResource
/testResources
siteResources
siteResourcesrc/site/site.xml/siteResource
siteResourcesrc/site/apt/index.apt/siteResource
/siteResources
/module
module
dirclient/dir
/module
module
dirwebapp/dir
resources
resourcesrc/main/resources/log4j.xml/resource
resourcesrc/main/webapp/WEB-INF/web.xml/resource
/resources
testSources
testSourcesrc/test/java/readme.txt/testSource
/testSources
/module
/modules
/archetype
{noformat}
Possibility to create real multiple modules with Java sources
-
Key: ARCHETYPE-23
URL: http://jira.codehaus.org/browse/ARCHETYPE-23
Project: Maven Archetype
Type: Improvement
Components: maven-archetype-plugin
Reporter: Johannes Carlén
Assignee: Jason van Zyl
I'm lacking the possibility to be able to generate a real multimodule
application i.e. an ear containing both a web module and an ejb module with
java sources.
I know it is possible to list all classes as a resource, however when doing
so I can't get the packageName to automatically be prepended to the java
files path (src/main/java/package/.../App.java).
What it means is that I'd like to be able to mark the java files as source
files also when doing multiple modules generations.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (ARCHETYPE-23) Possibility to create real multiple modules with Java sources
[ http://jira.codehaus.org/browse/ARCHETYPE-23?page=all ] John Didion updated ARCHETYPE-23: - Attachment: MavenArchetypeMojo.java archetype.mdo DefaultArchetype.java Possibility to create real multiple modules with Java sources - Key: ARCHETYPE-23 URL: http://jira.codehaus.org/browse/ARCHETYPE-23 Project: Maven Archetype Type: Improvement Components: maven-archetype-plugin Reporter: Johannes Carlén Assignee: Jason van Zyl Attachments: DefaultArchetype.java, MavenArchetypeMojo.java, archetype.mdo I'm lacking the possibility to be able to generate a real multimodule application i.e. an ear containing both a web module and an ejb module with java sources. I know it is possible to list all classes as a resource, however when doing so I can't get the packageName to automatically be prepended to the java files path (src/main/java/package/.../App.java). What it means is that I'd like to be able to mark the java files as source files also when doing multiple modules generations. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-707) Glazedlists 1.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-707?page=all ] Geoffrey De Smet updated MAVENUPLOAD-707: - Attachment: pom.xml Glazedlists 1.5.0 - Key: MAVENUPLOAD-707 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-707 Project: maven-upload-requests Type: Task Reporter: Geoffrey De Smet Attachments: pom.xml JTable with sorting filtering, used in spring-rich and many Swing applications. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: process of releasing plugins bug reports
jerome lacoste wrote: Note I am not trying to be a pain in the butt here. :) I meant I know the fact that the issue could have been moved up to 2.0.1 was the pain, not you. I am just saying that there was something that could have been done better and that I hope won't happen again. I'm aware of that, but I'm trying to remind you to differentiate between could have been done better and being done worse. Yes, the change could have been included, but it not being so didn't delay it's original timeline. So the question is are we sure that this won't happen again? I am not convinced. Why? Nothing below in your response indicates it would be a recurring problem. No process is foolproof, mistakes will be made. I can guarantee one will happen again. But I'm pretty sure I've sufficiently explained that our process, now that it's set up, covers this case. I will try to summarize the problems I see: the only way for me to know about the fact that my issue wasn't fixed in the forthcoming release was to read the vote email on the developer list. I missed it. I also forgot to watch the issue in Jira (why isn't that automatic for the reporter?) My bad. It is automatic - we didn't change, or look at, the original issue. FWIW, we might well have if JIRA let you edit closed issues. I'll go and look into requesting that on their site. - why the issue wasn't considered for the branch in the first place? It was marked as critical in Jira and was a one liner. Is there something we can do to Jira to mark them better? The problem was it was closed. - if you cannot review all the issues, make sure we can help. Either add a message to all issues in Jira please help us triage these issues before the forthcoming branch. Jira has a bulk edit mode (I checked it and it works on the projects I have edit rights), so it still can be used there. I can't do it though. It doesn't work on closed issues. - of all the 60 assembly plugin issues, only 18 are marked today with no fix version but fixed in Jira. Of all these, only 4 are marked as critical or above. (funny part, all of these were reported by me...). All had a patch. The blocker one even had 2 votes (3 if you include me) and wasn't considered neither. The patch looks complex but is very very simple if you look at the issue comments. Ok, so we were scared off from something that could have been simple. Lesson learned if we do this on any other plugins (which is unlikely). - since we only split out the JIRA projects recently, we didn't know which were in 2.0 and which were more recent. svn integration in Jira could have helped with that. Shouldn't this be implemented? It is implemented, but it only matches by keys, not by date. It would still require reopening all the the issues, one by one. - if you release a branch, make this information more prominent. Branch don't seem to be that usual in the current plugin release process. Maybe add the word branch in the vote title, maybe send the message in another channel (not just the dev list). If the effort is made to make a branch, backport patches, vote release, why not spend it to review some issues and make sure the community isn't surprised? I think we already tried to do this, and noted that it needs to be more prominent. Really what should have happened was a mail to the dev list when work started on the branch to say what was happening. That probably would have been noticed. - each plugin is released with its own version in a very loosed couple manner. I find it pretty hard to follow what's going on and how it's going to affect my builds (I've seen wrong dependencies in pom). I guess the process is going to become better later on, but my experience with other systems that handle dependencies let me think that issues in this area won't go away. People make mistakes. This doesn't seem to have any suggestion attached to it :) What was your point? Assembly plugin within a multi-project doesn't work for me right now. No more no less. For me that's a show stopper. And that seems to be a show stopped for at least 2 other persons. I couldn't grok that anywhere from the description of comments originally. PS: I could have used a very small part of the time spent writing these mails to prepare and release 2.0.2. * I can't. Is there any interest in releasing a 2.0.2? If so how can I help? sure you can! - reopen the issue and attach a patch against the branch. - more patches against 2.1 issues to get that out faster (obviously preferred) * if I send these mails it's in the hope that things will be better next time. If you think I am wasting your time, let me know (or ignore them, but I'd prefer to know...). Calling us on mistakes is good, otherwise it probably would happen again. But some feedback: - you've been pretty verbose. I think a lot of questions were repeated and facts introduced to prove your point, often after your point was proven and accepted. I've judged
Re: [vote] [m1] plugin releases
On 2/1/06, Lukas Theussl [EMAIL PROTECTED] wrote: Stephane Nicoll wrote: +1 for All except Jira-plugin +0 ; Dependency on Jira 3.3+ might be a big issue. Had anyone sent a mail to the user list about it? That's why I said on the web page 'needs at least JIRA 3.3 to work properly' and not 'needs at least JIRA 3.3 to work'. Yep, I read the mail too fast :) I don't know if it's necessary to send a mail to the user list, or just document it in more detail? This should be clearly stated in the announcement mail, I would say Thanks, Stéphane -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
editing closed JIRA issues
I found this: http://confluence.atlassian.com/pages/viewpage.action?pageId=121422 Vincent, could you help us set this up in our workflow? Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] [m1] plugin releases
IMO, Just document it, and maybe which plugin version works with 3.3. - Brett Lukas Theussl wrote: Stephane Nicoll wrote: +1 for All except Jira-plugin +0 ; Dependency on Jira 3.3+ might be a big issue. Had anyone sent a mail to the user list about it? I don't think this is a big issue. The restriction to Jira 3.3+ was necessary because of an API change in Jira itself, see http://jira.codehaus.org/browse/MPJIRA-17. I don't know exactly what will happen if you use an older version of Jira, I dont have one to test, but AFAICT, it should work overall, only the filtering (by resolution, priority or status) will not be correct. That's why I said on the web page 'needs at least JIRA 3.3 to work properly' and not 'needs at least JIRA 3.3 to work'. I don't know if it's necessary to send a mail to the user list, or just document it in more detail? -Lukas - 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] Created: (MANTRUN-41) Easy access to dependency jars
Easy access to dependency jars
--
Key: MANTRUN-41
URL: http://jira.codehaus.org/browse/MANTRUN-41
Project: Maven 2.x Antrun Plugin
Type: New Feature
Versions: 1.1
Reporter: Patrick Lightbody
Fix For: 1.2
It would be nice to have an easy access to the dependency jars located in
~/.m2. A couple ideas tossed around in #maven were:
${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
OR
a new Ant task:
maven:dep artifactId=... property=jarpath/
Where you could then reference ${jarpath}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MANTRUN-41) Easy access to dependency jars
[ http://jira.codehaus.org/browse/MANTRUN-41?page=all ]
Kenney Westerhof closed MANTRUN-41:
---
Resolution: Fixed
Fixed in revision 374150. I chose to define properties:
maven.dependency.groupId.artifactId.type.path,
so for instance:
maven.dependency.log4j.log4j.jar.path.
Easy access to dependency jars
--
Key: MANTRUN-41
URL: http://jira.codehaus.org/browse/MANTRUN-41
Project: Maven 2.x Antrun Plugin
Type: New Feature
Versions: 1.1
Reporter: Patrick Lightbody
Assignee: Kenney Westerhof
Fix For: 1.2
It would be nice to have an easy access to the dependency jars located in
~/.m2. A couple ideas tossed around in #maven were:
${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
OR
a new Ant task:
maven:dep artifactId=... property=jarpath/
Where you could then reference ${jarpath}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MANTRUN-35) mvn debug level not passed to ant
[ http://jira.codehaus.org/browse/MANTRUN-35?page=all ] Kenney Westerhof closed MANTRUN-35: --- Assign To: Kenney Westerhof (was: Jason van Zyl) Resolution: Fixed Fixed in revision 374152: when -X is specified, the loglevel is set to 'debug'. If this solution is not satisfactory, please reopen. mvn debug level not passed to ant - Key: MANTRUN-35 URL: http://jira.codehaus.org/browse/MANTRUN-35 Project: Maven 2.x Antrun Plugin Type: Improvement Versions: 1.1 Environment: Any Reporter: M. van der Plas Assignee: Kenney Westerhof Priority: Minor Fix For: 1.2 Ant task like echo have a property level which can be set to trigger activation based on the loglevel. Maven mvn has the commandline option to activate the debug log level. Currently it is not possible to set the ant task log level. The mvn log level should be passed to ant so it can be used in log level aware ant tasks. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CONTINUUM-519) scheduler not calling scm's update command at scheduled time
[ http://jira.codehaus.org/browse/CONTINUUM-519?page=all ] John Casey reopened CONTINUUM-519: -- scheduler not calling scm's update command at scheduled time Key: CONTINUUM-519 URL: http://jira.codehaus.org/browse/CONTINUUM-519 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: xp, starteam Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: CONTINUUM-519.patch The log shows the timer fires correctly but no attempt to call scm's update command to detect changes 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - Continuum 1.0.2 started! 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ ^__^ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ (oo)\___ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - (__)\ )\/\ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - ||w | 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - || || 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.initialization.ContinuumInitializer - Continuum initializer running ... 4985 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Activating schedules ... 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Mon Dec 19 05:00:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Tue Dec 20 00:01:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Thu Jan 01 10:15:00 PST 2099 5016 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,build-project] 5344 [WrapperSimpleAppMain] ERROR org.codehaus.plexus.velocity.VelocityComponent - ResourceManager.getResource() parse exception: org.apache.velocity.exception.ParseErrorException: Lexical error: org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 121, column 17. Encountered: EOF after : 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - The from mailbox is not configured, will use the nag email address from the project. 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - From name: Continuum 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - Build host name: uscus-build2 5563 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.RecipientSource - To override address is not configured, will use the nag email address from the project. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Starting task executor, thread name 'build-project'. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,check-out-project] 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:check-out-project - Starting task executor, thread name 'check-out-project'. 2151003 [scheduler1_Worker-8] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 2151112 [scheduler1_Worker-8] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 16550995 [scheduler1_Worker-8] INFO
[jira] Updated: (CONTINUUM-519) scheduler not calling scm's update command at scheduled time
[ http://jira.codehaus.org/browse/CONTINUUM-519?page=all ] John Casey updated CONTINUUM-519: - Fix Version: (was: 1.1-alpha-1) 1.0.3 scheduler not calling scm's update command at scheduled time Key: CONTINUUM-519 URL: http://jira.codehaus.org/browse/CONTINUUM-519 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: xp, starteam Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: CONTINUUM-519.patch The log shows the timer fires correctly but no attempt to call scm's update command to detect changes 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - Continuum 1.0.2 started! 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ ^__^ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ (oo)\___ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - (__)\ )\/\ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - ||w | 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - || || 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.initialization.ContinuumInitializer - Continuum initializer running ... 4985 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Activating schedules ... 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Mon Dec 19 05:00:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Tue Dec 20 00:01:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Thu Jan 01 10:15:00 PST 2099 5016 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,build-project] 5344 [WrapperSimpleAppMain] ERROR org.codehaus.plexus.velocity.VelocityComponent - ResourceManager.getResource() parse exception: org.apache.velocity.exception.ParseErrorException: Lexical error: org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 121, column 17. Encountered: EOF after : 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - The from mailbox is not configured, will use the nag email address from the project. 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - From name: Continuum 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - Build host name: uscus-build2 5563 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.RecipientSource - To override address is not configured, will use the nag email address from the project. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Starting task executor, thread name 'build-project'. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,check-out-project] 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:check-out-project - Starting task executor, thread name 'check-out-project'. 2151003 [scheduler1_Worker-8] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 2151112 [scheduler1_Worker-8] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 16550995 [scheduler1_Worker-8] INFO
[jira] Closed: (CONTINUUM-519) scheduler not calling scm's update command at scheduled time
[ http://jira.codehaus.org/browse/CONTINUUM-519?page=all ] John Casey closed CONTINUUM-519: Resolution: Fixed scheduler not calling scm's update command at scheduled time Key: CONTINUUM-519 URL: http://jira.codehaus.org/browse/CONTINUUM-519 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: xp, starteam Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: CONTINUUM-519.patch The log shows the timer fires correctly but no attempt to call scm's update command to detect changes 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - Continuum 1.0.2 started! 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ ^__^ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - \ (oo)\___ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - (__)\ )\/\ 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - ||w | 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - || || 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.Continuum - 4641 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.initialization.ContinuumInitializer - Continuum initializer running ... 4985 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Activating schedules ... 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Mon Dec 19 05:00:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Tue Dec 20 00:01:00 PST 2005 5016 [WrapperSimpleAppMain] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Thu Jan 01 10:15:00 PST 2099 5016 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,build-project] 5344 [WrapperSimpleAppMain] ERROR org.codehaus.plexus.velocity.VelocityComponent - ResourceManager.getResource() parse exception: org.apache.velocity.exception.ParseErrorException: Lexical error: org.apache.velocity.runtime.parser.TokenMgrError: Lexical error at line 121, column 17. Encountered: EOF after : 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - The from mailbox is not configured, will use the nag email address from the project. 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - From name: Continuum 5438 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - Build host name: uscus-build2 5563 [WrapperSimpleAppMain] INFO org.codehaus.plexus.notification.RecipientSource - To override address is not configured, will use the nag email address from the project. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Starting task executor, thread name 'build-project'. 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,check-out-project] 5578 [WrapperSimpleAppMain] INFO org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:check-out-project - Starting task executor, thread name 'check-out-project'. 2151003 [scheduler1_Worker-8] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 2151112 [scheduler1_Worker-8] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 5750995 [scheduler1_Worker-7] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 9351007 [scheduler1_Worker-13] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.build.settings.SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... 12950997 [scheduler1_Worker-11] INFO org.apache.maven.continuum.store.ContinuumStore:jdo - nb result : 3 16550995 [scheduler1_Worker-8] INFO
[jira] Reopened: (CONTINUUM-507) detect and repair svn problems by running svn cleanup
[ http://jira.codehaus.org/browse/CONTINUUM-507?page=all ] John Casey reopened CONTINUUM-507: -- detect and repair svn problems by running svn cleanup - Key: CONTINUUM-507 URL: http://jira.codehaus.org/browse/CONTINUUM-507 Project: Continuum Type: Bug Components: Core system Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0.3 builds fail when svn needs a cleanup - the error can be used to detect this, and run svn cleanup. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-535) Trigger a build if change set doesn't contains only files with unknown status
[ http://jira.codehaus.org/browse/CONTINUUM-535?page=all ] John Casey reopened CONTINUUM-535: -- Trigger a build if change set doesn't contains only files with unknown status - Key: CONTINUUM-535 URL: http://jira.codehaus.org/browse/CONTINUUM-535 Project: Continuum Type: Bug Components: Core system Reporter: Emmanuel Venisse Assignee: nick gonzalez Fix For: 1.0.3 Attachments: CONTINUUM-535.patch -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-507) detect and repair svn problems by running svn cleanup
[ http://jira.codehaus.org/browse/CONTINUUM-507?page=all ] John Casey closed CONTINUUM-507: Resolution: Fixed Fix Version: (was: 1.1-alpha-1) 1.0.3 detect and repair svn problems by running svn cleanup - Key: CONTINUUM-507 URL: http://jira.codehaus.org/browse/CONTINUUM-507 Project: Continuum Type: Bug Components: Core system Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0.3 builds fail when svn needs a cleanup - the error can be used to detect this, and run svn cleanup. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-535) Trigger a build if change set doesn't contains only files with unknown status
[ http://jira.codehaus.org/browse/CONTINUUM-535?page=all ] John Casey closed CONTINUUM-535: Resolution: Fixed Fix Version: (was: 1.1-alpha-1) 1.0.3 Trigger a build if change set doesn't contains only files with unknown status - Key: CONTINUUM-535 URL: http://jira.codehaus.org/browse/CONTINUUM-535 Project: Continuum Type: Bug Components: Core system Reporter: Emmanuel Venisse Assignee: nick gonzalez Fix For: 1.0.3 Attachments: CONTINUUM-535.patch -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-514) Consistency in layout of Continuum download page to the Maven 2.0 download page
[ http://jira.codehaus.org/browse/CONTINUUM-514?page=all ] John Casey reopened CONTINUUM-514: -- Consistency in layout of Continuum download page to the Maven 2.0 download page --- Key: CONTINUUM-514 URL: http://jira.codehaus.org/browse/CONTINUUM-514 Project: Continuum Type: Task Components: Documentation Versions: 1.0.2 Reporter: Natalie Burdick Assignee: Emmanuel Venisse Fix For: 1.0.3 Please update the http://maven.apache.org/continuum/download.html page to match the http://maven.apache.org/download.html? page -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-514) Consistency in layout of Continuum download page to the Maven 2.0 download page
[ http://jira.codehaus.org/browse/CONTINUUM-514?page=all ] John Casey closed CONTINUUM-514: Resolution: Fixed Fix Version: (was: 1.1-alpha-1) 1.0.3 Consistency in layout of Continuum download page to the Maven 2.0 download page --- Key: CONTINUUM-514 URL: http://jira.codehaus.org/browse/CONTINUUM-514 Project: Continuum Type: Task Components: Documentation Versions: 1.0.2 Reporter: Natalie Burdick Assignee: Emmanuel Venisse Fix For: 1.0.3 Please update the http://maven.apache.org/continuum/download.html page to match the http://maven.apache.org/download.html? page -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-527) Getting Started Documentation omits JAVA_HOME requirement
[ http://jira.codehaus.org/browse/CONTINUUM-527?page=all ] John Casey updated CONTINUUM-527: - Fix Version: 1.0.3 Getting Started Documentation omits JAVA_HOME requirement - Key: CONTINUUM-527 URL: http://jira.codehaus.org/browse/CONTINUUM-527 Project: Continuum Type: Improvement Components: Documentation Versions: 1.0.2 Environment: RedHat 9, Sun JDK 1.4.2_01, java in PATH Reporter: Jamie Flournoy Fix For: 1.0.3 The documentation says you can just unpack the tarball and execute run.sh but this is not accurate. I had to define JAVA_HOME. ./bin/linux/run.sh failed with a not very descriptive error message: Running continuum... wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... wrapper | Unable to start a JVM jvm 1| wrapper | Unable to start JVM: No such file or directory (2) jvm 1| wrapper | Critical error: wait for JVM process failed (No child processes) wrapper | -- Wrapper Stopped So either run.sh should check for whether JAVA_HOME is defined, or the docs should say it's required, or (even better!) both. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-532) Add ability to move from a particular build to the build list for a project.
[ http://jira.codehaus.org/browse/CONTINUUM-532?page=all ] John Casey reopened CONTINUUM-532: -- Add ability to move from a particular build to the build list for a project. Key: CONTINUUM-532 URL: http://jira.codehaus.org/browse/CONTINUUM-532 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Trygve Laugstol Assignee: Emmanuel Venisse Fix For: 1.0.3 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-532) Add ability to move from a particular build to the build list for a project.
[ http://jira.codehaus.org/browse/CONTINUUM-532?page=all ] John Casey closed CONTINUUM-532: Resolution: Fixed Fix Version: (was: 1.1-alpha-1) 1.0.3 Add ability to move from a particular build to the build list for a project. Key: CONTINUUM-532 URL: http://jira.codehaus.org/browse/CONTINUUM-532 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Trygve Laugstol Assignee: Emmanuel Venisse Fix For: 1.0.3 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-543) please add reference to netbeans continuum integration from the the continuum site
[ http://jira.codehaus.org/browse/CONTINUUM-543?page=all ] John Casey updated CONTINUUM-543: - Fix Version: 1.0.3 please add reference to netbeans continuum integration from the the continuum site -- Key: CONTINUUM-543 URL: http://jira.codehaus.org/browse/CONTINUUM-543 Project: Continuum Type: Bug Components: Documentation Reporter: Milos Kleint Fix For: 1.0.3 Attachments: continuum-site.patch, continuum-site.patch see subject patch attached. Thanks a lot. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[maven2 build trunk - SUCCESS - update] Wed Feb 1 20:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060201.21.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060201.21.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MANTRUN-32) ant tasks don't use correct environment in antrun plugin
[ http://jira.codehaus.org/browse/MANTRUN-32?page=all ]
Kenney Westerhof closed MANTRUN-32:
---
Assign To: Kenney Westerhof
Resolution: Fixed
Fixed in revision 374157. Added missing call to Project.init().
ant tasks don't use correct environment in antrun plugin
Key: MANTRUN-32
URL: http://jira.codehaus.org/browse/MANTRUN-32
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Reporter: Brett Porter
Assignee: Kenney Westerhof
Fix For: 1.2
Attachments: antTargetConverterPatch.patch
eg, ${user.home} does not resolve to the java system property as it would
when you execute it standalone
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-555) Continuum only executes default build-definition
[ http://jira.codehaus.org/browse/CONTINUUM-555?page=all ] John Casey updated CONTINUUM-555: - Fix Version: (was: 1.1) 1.0.3 Continuum only executes default build-definition Key: CONTINUUM-555 URL: http://jira.codehaus.org/browse/CONTINUUM-555 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Dave Brown Fix For: 1.0.3 Attachments: Picture 1.png Can't find any documentation to state to the contrary, but my understanding is that Continuum should execute all build-definitions on each scheduled build (only the default is executed on a Build Now) Attached is a screen shot of my build definitions. On the latest build, continuum only build the default. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-449) title bar says Jabber when creating an MSN notifier
[ http://jira.codehaus.org/browse/CONTINUUM-449?page=all ] John Casey closed CONTINUUM-449: Resolution: Fixed Fix Version: (was: 1.1) 1.0.3 title bar says Jabber when creating an MSN notifier - Key: CONTINUUM-449 URL: http://jira.codehaus.org/browse/CONTINUUM-449 Project: Continuum Type: Bug Reporter: Brett Porter Assignee: Emmanuel Venisse Priority: Trivial Fix For: 1.0.3 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-449) title bar says Jabber when creating an MSN notifier
[ http://jira.codehaus.org/browse/CONTINUUM-449?page=all ] John Casey reopened CONTINUUM-449: -- title bar says Jabber when creating an MSN notifier - Key: CONTINUUM-449 URL: http://jira.codehaus.org/browse/CONTINUUM-449 Project: Continuum Type: Bug Reporter: Brett Porter Assignee: Emmanuel Venisse Priority: Trivial Fix For: 1.1 -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-27) checktyle:check does not use custom checkstyle xml files when used in a multiproject mode with a build-tools project passed as a plugin dependency
[ http://jira.codehaus.org/browse/MCHECKSTYLE-27?page=comments#action_57564 ] Vincent Massol commented on MCHECKSTYLE-27: --- I just wanted to say that I have tried it again with checkstyle plugin v2.0 and it's not working any better checktyle:check does not use custom checkstyle xml files when used in a multiproject mode with a build-tools project passed as a plugin dependency -- Key: MCHECKSTYLE-27 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-27 Project: Maven 2.x Checkstyle Plugin Type: Bug Reporter: Vincent Massol Here's the config I have: build plugins plugin artifactIdmaven-checkstyle-plugin/artifactId dependencies dependency groupIdorg.codehaus.cargo/groupId artifactIdcargo-build-tools/artifactId version0.8-SNAPSHOT/version /dependency /dependencies executions execution configuration configLocationbuild-tools/checkstyle.xml/configLocation headerLocationbuild-tools/checkstyle.license/headerLocation suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation /configuration goals goalcheck/goal /goals /execution /executions /plugin /plugins /build When i run the project I get lots of checkstyle errors due to the fact that checkstyle is using the default rules and not my projcect's. Note that I have created a build-tools project as defined in tips.apt. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-544) there is no xmlrpc client code for contacting the server.
[ http://jira.codehaus.org/browse/CONTINUUM-544?page=all ] John Casey updated CONTINUUM-544: - Fix Version: (was: 1.1) 1.0.3 there is no xmlrpc client code for contacting the server. - Key: CONTINUUM-544 URL: http://jira.codehaus.org/browse/CONTINUUM-544 Project: Continuum Type: New Feature Components: XMLRPC Interface Reporter: Milos Kleint Fix For: 1.0.3 Attachments: ProjectsReader.java, continuum-rpc-client.zip sibmitting a simple library for client code interaction, currently used at mevenide -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r374150 - in /maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun: AbstractAntMojo.java AntPropertyHelper.java
some thoughts: - This omits classifier, in the case it differs from type - isn't this verbose if you have to give jar all the time, when most dependencies are? - does this handle dotted group IDs? (I assume it does) I thought it might be better to do a taskdef (which I assume the antrun plugin can introduce), so the script could contain: set-dependency-property property=... groupId=... artifactId=... [type=... classifier=...] / WDYT? - Brett [EMAIL PROTECTED] wrote: Author: kenney Date: Wed Feb 1 11:58:44 2006 New Revision: 374150 URL: http://svn.apache.org/viewcvs?rev=374150view=rev Log: PR: MANTRUN-41 Added 'maven.dependency.groupId.artifactId.type.path' properties for all dependencies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-537) Guests cannot see totals
[ http://jira.codehaus.org/browse/CONTINUUM-537?page=all ] John Casey updated CONTINUUM-537: - Fix Version: (was: 1.1) 1.0.3 Guests cannot see totals Key: CONTINUUM-537 URL: http://jira.codehaus.org/browse/CONTINUUM-537 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Henri Yandell Fix For: 1.0.3 If you remove the ability for guests to initiate builds, they cannot see the totals at the bottom of the show reports screen. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-518) Top directory files in project (ie: pom.xml) not updated from CVS on subsequent builds.
[ http://jira.codehaus.org/browse/CONTINUUM-518?page=all ] John Casey updated CONTINUUM-518: - Fix Version: 1.0.3 Top directory files in project (ie: pom.xml) not updated from CVS on subsequent builds. --- Key: CONTINUUM-518 URL: http://jira.codehaus.org/browse/CONTINUUM-518 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Continuum 1.0.2 Maven 2.0 Solaris 5.8SP4 Reporter: Alex Mayorga Adame Fix For: 1.0.3 Files in top level folder of the project CVS doesn't get updated when builds are trigged. I've issolated this to the /working-directory working copies folders. Here you can see the cvs update of a sample project in /tmp/sampleProject bash-2.03$ cvs update cvs server: Updating . cvs server: Updating src cvs server: Updating src/main cvs server: Updating src/main/java cvs server: Updating src/main/java/com cvs server: Updating src/main/java/com/citigroup cvs server: Updating src/main/java/com/citigroup/sampleapp cvs server: Updating src/main/webapp cvs server: Updating src/main/webapp/WEB-INF cvs server: Updating src/main/webapp/html-jsp cvs server: Updating src/site cvs server: Updating src/site/apt but when the cvs update is issued in the /working-directory/7 that contains the same sampleProject this is the output bash-2.03$ cvs update cvs server: Updating src cvs server: Updating src/main cvs server: Updating src/main/java cvs server: Updating src/main/java/com cvs server: Updating src/main/java/com/citigroup cvs server: Updating src/main/java/com/citigroup/sampleapp cvs server: Updating src/main/webapp cvs server: Updating src/main/webapp/WEB-INF cvs server: Updating src/main/webapp/html-jsp cvs server: Updating src/site cvs server: Updating src/site/apt Some how the top level folder . is being ignored in the projects checked out by Continuum. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-40) Properties defined in pom properties do not propagate to the antrun environment
[ http://jira.codehaus.org/browse/MANTRUN-40?page=comments#action_57565 ]
Kenney Westerhof commented on MANTRUN-40:
-
It's impossible to propagate all properties to the called ant buildfile, since
only listed properties
are propagated. Most properties are calculated runtime using reflection.
We could make an exception for the properties tag for called buildfiles and
iterate over
them, but that doesn't solve it ${project.*} properties.
However, properties do work for ant tasks embedded in the pom, so the title
of this issue is not correct.
A nice workaround might be to override the ant task, or to ask the ant folks to
fix
their Ant task so the PropertyHelper linked to the project is also propagated to
the new project instantiated by the Ant task, when inheritAll=true. It should
inherit
ALL properties, wheter they're calculated or not - the script doesn't know
that.. :)
Properties defined in pom properties do not propagate to the antrun
environment
-
Key: MANTRUN-40
URL: http://jira.codehaus.org/browse/MANTRUN-40
Project: Maven 2.x Antrun Plugin
Type: Improvement
Reporter: Jason Dillon
Priority: Critical
Properties defined in pom properties do not propagate to the antrun
environment.
For example:
{code}
properties
my.propertyfoo/my.property
/properties
{code}
Does *not* get propagate to Ant. While properties defined within the pom
will resolve, the properties are not available as an Ant property. So from
antrun:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo/
{code}
And then the Ant build.xml:
{code}
project
target name=foo
echo${my.property}/echo
/target
project
{code}
The output will be:
{noformat}
[echo] ${my.property}
{noformat}
Instead of what it *should be*:
{noformat}
[echo] foo
{noformat}
The workaround is to delegate to a build.xml file with the ant task and
redefine each property that is needed:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo
property name=my.property value=${my.property}/
/ant
{code}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCHECKSTYLE-27) checktyle:check does not use custom checkstyle xml files when used in a multiproject mode with a build-tools project passed as a plugin dependency
[ http://jira.codehaus.org/browse/MCHECKSTYLE-27?page=all ]
Vincent Massol updated MCHECKSTYLE-27:
--
Description:
Here's the config I have:
{code:xml}
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code:xml}
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
was:
Here's the config I have:
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
checktyle:check does not use custom checkstyle xml files when used in a
multiproject mode with a build-tools project passed as a plugin dependency
--
Key: MCHECKSTYLE-27
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-27
Project: Maven 2.x Checkstyle Plugin
Type: Bug
Reporter: Vincent Massol
Here's the config I have:
{code:xml}
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code:xml}
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MANTRUN-40) Properties defined in pom properties do not propagate to the antrun environment
[ http://jira.codehaus.org/browse/MANTRUN-40?page=comments#action_57566 ]
Brett Porter commented on MANTRUN-40:
-
what about if the plugin depended on the maven-artifact-ant antlib (the thin
jar + transitive deps, not the fat one), and registered that antlib with the
project being used (if possible), and the project's pom with the antlib (which
is possible)? This would mean they can use those tasks from the script.
Properties defined in pom properties do not propagate to the antrun
environment
-
Key: MANTRUN-40
URL: http://jira.codehaus.org/browse/MANTRUN-40
Project: Maven 2.x Antrun Plugin
Type: Improvement
Reporter: Jason Dillon
Priority: Critical
Properties defined in pom properties do not propagate to the antrun
environment.
For example:
{code}
properties
my.propertyfoo/my.property
/properties
{code}
Does *not* get propagate to Ant. While properties defined within the pom
will resolve, the properties are not available as an Ant property. So from
antrun:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo/
{code}
And then the Ant build.xml:
{code}
project
target name=foo
echo${my.property}/echo
/target
project
{code}
The output will be:
{noformat}
[echo] ${my.property}
{noformat}
Instead of what it *should be*:
{noformat}
[echo] foo
{noformat}
The workaround is to delegate to a build.xml file with the ant task and
redefine each property that is needed:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo
property name=my.property value=${my.property}/
/ant
{code}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCHECKSTYLE-27) checktyle:check does not use custom checkstyle xml files when used in a multiproject mode with a build-tools project passed as a plugin dependency
[ http://jira.codehaus.org/browse/MCHECKSTYLE-27?page=all ]
Vincent Massol updated MCHECKSTYLE-27:
--
Description:
Here's the config I have:
{code:xml}
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code}
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
was:
Here's the config I have:
{code:xml}
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code:xml}
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
checktyle:check does not use custom checkstyle xml files when used in a
multiproject mode with a build-tools project passed as a plugin dependency
--
Key: MCHECKSTYLE-27
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-27
Project: Maven 2.x Checkstyle Plugin
Type: Bug
Reporter: Vincent Massol
Here's the config I have:
{code:xml}
build
plugins
plugin
artifactIdmaven-checkstyle-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-build-tools/artifactId
version0.8-SNAPSHOT/version
/dependency
/dependencies
executions
execution
configuration
configLocationbuild-tools/checkstyle.xml/configLocation
headerLocationbuild-tools/checkstyle.license/headerLocation
suppressionsLocationbuild-tools/checkstyle-suppressions.xml/suppressionsLocation
/configuration
goals
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code}
When i run the project I get lots of checkstyle errors due to the fact that
checkstyle is using the default rules and not my projcect's.
Note that I have created a build-tools project as defined in tips.apt.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_57567 ]
Kenney Westerhof commented on MANTRUN-37:
-
I see two different problems here. Mike; if you purge
~/.m2/repository/org/apache/maven/plugins/ do you still have
problems? It seems like a core bug, not an antrun bug. Is the issue fixed in
2.0.2?
Paul Zeeman: I can't reproduce this. It almost looks as if your ant-1.6.5.jar
is incomplete/corrupt.
Any chance you can make a mini-project that reproduces the problem?
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Priority: Critical
Fix For: 1.2
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Feb 1 20:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060201.201500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060201.201500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r374150 - in /maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun: AbstractAntMojo.java AntPropertyHelper.java
On Thu, 2 Feb 2006, Brett Porter wrote: some thoughts: - This omits classifier, in the case it differs from type Right, will fix. - isn't this verbose if you have to give jar all the time, when most dependencies are? I don't think those 4 characters are going to bother the users as much as the 'maven.dependency' prefix :) And what do yo propose, leaving it off if the type == jar classifier != type ? Might come off as a bit inconsistent, I think? - does this handle dotted group IDs? (I assume it does) Yes, I was thinking about maybe using a colon as the group/artifact separator, but then that might give problems. For now it's the original groupId + artifactId, so 'org.apache.maven.something.artifactId', which is unique AFAIK. I thought it might be better to do a taskdef (which I assume the antrun plugin can introduce), so the script could contain: set-dependency-property property=... groupId=... artifactId=... [type=... classifier=...] / That was my proposal too, but then I figured that maven-artifact-ant already provides that. And users will mostly use that task (i personally thought of maven:dependency) to set a property they'll use later on in another task. The committed solution eliminates that extra step. But it can be provided if needs be. WDYT? idem.. :) -- Kenney - Brett [EMAIL PROTECTED] wrote: Author: kenney Date: Wed Feb 1 11:58:44 2006 New Revision: 374150 URL: http://svn.apache.org/viewcvs?rev=374150view=rev Log: PR: MANTRUN-41 Added 'maven.dependency.groupId.artifactId.type.path' properties for all dependencies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-54) XML test reports are not well-formed when failure message contains quotes.
XML test reports are not well-formed when failure message contains quotes. -- Key: MSUREFIRE-54 URL: http://jira.codehaus.org/browse/MSUREFIRE-54 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.2 Environment: n/a Reporter: Mike Whittemore Attachments: TEST-bad.xml, TEST-good.xml, unittests.xsl When a test fails, and the error message contains quotes, the surefire XML report is not well-formed. The error message gets placed in the failure element's 'message' attribute, which causes nested quotes if the message contains any quotes. Error message quotes should be escaped I believe. This may apply to other elements in the XML report. I am using surefire plugin version 2.1.2 but it may affect other versions as well. Test Case: It's not junit, but it may be helpful. I've attached two faked XML reports that resemble real Maven2 XML surefire reports. The 'bad' one has a message with quotes, the 'good' one does not. I used Xalan and an XSLT found in my CruiseControl install to transform each one. The 'bad' one cannot be parsed. The 'good' well-formed one can be parsed and successfully transformed. I've also attached the XSLT. The commands to run the transforms follow: java -cp path to xalan jar org.apache.xalan.xslt.Process -IN TEST-good.xml -XSL unittests.xsl java -cp path to xalan jar org.apache.xalan.xslt.Process -IN TEST-bad.xml -XSL unitests.xsl -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MANTRUN-41) Easy access to dependency jars
[ http://jira.codehaus.org/browse/MANTRUN-41?page=all ]
Carlos Sanchez reopened MANTRUN-41:
---
Some comments:
- you're breaking api compatability with previous version changing constructor
arguments
- you've added a new feature with no documentation
- and please don't use tabs
I'm not sure either if adding custom strings to resolve different things is the
solution, next time will we add again a if to check if the property starts with
xxx and do some other thing?
Easy access to dependency jars
--
Key: MANTRUN-41
URL: http://jira.codehaus.org/browse/MANTRUN-41
Project: Maven 2.x Antrun Plugin
Type: New Feature
Versions: 1.1
Reporter: Patrick Lightbody
Assignee: Kenney Westerhof
Fix For: 1.2
It would be nice to have an easy access to the dependency jars located in
~/.m2. A couple ideas tossed around in #maven were:
${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
OR
a new Ant task:
maven:dep artifactId=... property=jarpath/
Where you could then reference ${jarpath}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Wed Feb 1 20:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060201.203001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060201.203001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MANTRUN-32) ant tasks don't use correct environment in antrun plugin
[ http://jira.codehaus.org/browse/MANTRUN-32?page=all ]
Carlos Sanchez reopened MANTRUN-32:
---
Again breaking api, you should deprecate methods instead of removing.
ant tasks don't use correct environment in antrun plugin
Key: MANTRUN-32
URL: http://jira.codehaus.org/browse/MANTRUN-32
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Reporter: Brett Porter
Assignee: Kenney Westerhof
Fix For: 1.2
Attachments: antTargetConverterPatch.patch
eg, ${user.home} does not resolve to the java system property as it would
when you execute it standalone
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: editing closed JIRA issues
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: mercredi 1 février 2006 20:57 To: Maven Developers List Subject: editing closed JIRA issues I found this: http://confluence.atlassian.com/pages/viewpage.action?pageId=121422 Vincent, could you help us set this up in our workflow? I've created a new workflow called Maven New which allows edits even if the issue is closed. I've associated the MNG JIRA project to it. Now we need magic Jason to run his scripts to associate all the Maven family projects to it automatically. Thanks -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MANTRUN-40) Properties defined in pom properties do not propagate to the antrun environment
[ http://jira.codehaus.org/browse/MANTRUN-40?page=comments#action_57570 ]
Jason Dillon commented on MANTRUN-40:
-
Sorry Kenny, but properties *do not* actually make it into the ant's execution
environment. Properties are only resolved in the pom (tasks embedded in the
pom as you noted). BUT, if one of those tasks needs to access a property that
*was not* explicitly passed to it, like what is done with {{antproperty
name= .../}} which would then use the pom's property resolution mechanism,
then that task will *not see* the value of the property. So the title of the
issue is correct.
Properties defined in pom properties do not propagate to the antrun
environment
-
Key: MANTRUN-40
URL: http://jira.codehaus.org/browse/MANTRUN-40
Project: Maven 2.x Antrun Plugin
Type: Improvement
Reporter: Jason Dillon
Priority: Critical
Properties defined in pom properties do not propagate to the antrun
environment.
For example:
{code}
properties
my.propertyfoo/my.property
/properties
{code}
Does *not* get propagate to Ant. While properties defined within the pom
will resolve, the properties are not available as an Ant property. So from
antrun:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo/
{code}
And then the Ant build.xml:
{code}
project
target name=foo
echo${my.property}/echo
/target
project
{code}
The output will be:
{noformat}
[echo] ${my.property}
{noformat}
Instead of what it *should be*:
{noformat}
[echo] foo
{noformat}
The workaround is to delegate to a build.xml file with the ant task and
redefine each property that is needed:
{code}
ant antfile=${pom.basedir}/src/ant/build.xml dir=${pom.basedir}
inheritAll=true inheritRefs=true target=foo
property name=my.property value=${my.property}/
/ant
{code}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MANTRUN-41) Easy access to dependency jars
[ http://jira.codehaus.org/browse/MANTRUN-41?page=comments#action_57571 ]
Kenney Westerhof commented on MANTRUN-41:
-
- about the AntPropertyHelper: it's supposed to be a package private class, not
part of any public API.
But I'll add the original constructor if you want, but I already don't agree
with having 2 constructors
that result in different behavior.
- I could say that about lots of other features. It's documented in JIRA and in
SVN. I'll document it
in the site too (the classpath PATH variables were not documented for long
after they were committed, btw.)
- was I using tabs? sorry about that. fixed.
Anyway, the issue is fixed. Do you want me to unfix it since you opened it
again?
Easy access to dependency jars
--
Key: MANTRUN-41
URL: http://jira.codehaus.org/browse/MANTRUN-41
Project: Maven 2.x Antrun Plugin
Type: New Feature
Versions: 1.1
Reporter: Patrick Lightbody
Assignee: Kenney Westerhof
Fix For: 1.2
It would be nice to have an easy access to the dependency jars located in
~/.m2. A couple ideas tossed around in #maven were:
${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
OR
a new Ant task:
maven:dep artifactId=... property=jarpath/
Where you could then reference ${jarpath}
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MANTRUN-32) ant tasks don't use correct environment in antrun plugin
[ http://jira.codehaus.org/browse/MANTRUN-32?page=all ]
Kenney Westerhof closed MANTRUN-32:
---
Resolution: Fixed
sorry! committed @ rev 374173
ant tasks don't use correct environment in antrun plugin
Key: MANTRUN-32
URL: http://jira.codehaus.org/browse/MANTRUN-32
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Reporter: Brett Porter
Assignee: Kenney Westerhof
Fix For: 1.2
Attachments: antTargetConverterPatch.patch
eg, ${user.home} does not resolve to the java system property as it would
when you execute it standalone
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSITE-84) Refactor of site:stage and site:site required due to new site:site modules appraoch
[ http://jira.codehaus.org/browse/MSITE-84?page=all ] Brett Porter updated MSITE-84: -- Fix Version: 2.0 hmm, ok. I hadn't thought this was what site:stage was doing. Refactor of site:stage and site:site required due to new site:site modules appraoch --- Key: MSITE-84 URL: http://jira.codehaus.org/browse/MSITE-84 Project: Maven 2.x Site Plugin Type: Improvement Reporter: John Allen Fix For: 2.0 site:stage was designed to provide a means of normalising all the URLs involved in a reactor built site to be local filesystem based paths allowing a complete site to be built and tested without it being deployed to the target deployment location(s) - it did this by modifying all project URLs (parent/module/etc) to be prefixed with a file URL based upon their site Wagon URLs. The new site:site code is taken a more intrusive appraoch to determining module details (either reading module pom.xmls or with my patch, sourcing them from the repository) - this approach prevents the site:stage Mojo getting in there first and modifying the project URLs before the site:site Mojo processes them. A cooperative redesign is required to enable this new site:site module handling functionality and the existing site:stage functionality. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Wed Feb 1 21:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060201.21.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060201.21.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r374170 - /maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
um, not quite :)
1) the equals check is redundant
2) type + classifier is valid
I think its just a simple append of .${classifier} if it is not null.
[EMAIL PROTECTED] wrote:
Author: kenney
Date: Wed Feb 1 12:56:07 2006
New Revision: 374170
URL: http://svn.apache.org/viewcvs?rev=374170view=rev
Log:
As per Brett's request, added a check for the classifier. If it's different
from the artifact type, the classifier will be used in the property name.
Modified:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
Modified:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
URL:
http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java?rev=374170r1=374169r2=374170view=diff
==
---
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
(original)
+++
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
Wed Feb 1 12:56:07 2006
@@ -64,11 +64,14 @@
for ( Iterator it = artifacts.iterator(); it.hasNext(); )
{
Artifact artifact = (Artifact) it.next();
- log.debug( Storing: maven.dependency. + artifact.getGroupId() +
. +
-artifact.getArtifactId() + . + artifact.getType() +
.path= + artifact.getFile().getPath() );
-artifactMap.put( maven.dependency. + artifact.getGroupId() +
. +
-artifact.getArtifactId() + . + artifact.getType() +
.path, artifact.getFile().getPath() );
+String key = maven.dependency. + artifact.getGroupId() + . +
artifact.getArtifactId() + . +
+( artifact.getClassifier() == null ||
artifact.getType().equals( artifact.getClassifier() ) ?
+ artifact.getType() : artifact.getClassifier() ) + .path;
+
+log.debug( Storing: + key + = +
artifact.getFile().getPath() );
+
+artifactMap.put( key, artifact.getFile().getPath() );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-686) Please, upload JXTA 2.3.6 to the ibiblio repository.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-686?page=comments#action_57575 ] Loic Lefevre commented on MAVENUPLOAD-686: -- Okay, after some brainstorming on the dev mailing list, the following groupId has been chosen for this artifact: org.jxta.platform The bundle is up to date. Regards, Loïc Please, upload JXTA 2.3.6 to the ibiblio repository. Key: MAVENUPLOAD-686 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-686 Project: maven-upload-requests Type: Task Reporter: Loic Lefevre http://lolosav.free.fr/dev/jxta-2.3.6-bundle.jar JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Feb 1 21:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060201.211500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060201.211500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: editing closed JIRA issues
It's not possible to replace the existing Maven workflow? Vincent Massol wrote: -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: mercredi 1 février 2006 20:57 To: Maven Developers List Subject: editing closed JIRA issues I found this: http://confluence.atlassian.com/pages/viewpage.action?pageId=121422 Vincent, could you help us set this up in our workflow? I've created a new workflow called Maven New which allows edits even if the issue is closed. I've associated the MNG JIRA project to it. Now we need magic Jason to run his scripts to associate all the Maven family projects to it automatically. Thanks -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: editing closed JIRA issues
Brett Porter wrote: It's not possible to replace the existing Maven workflow? I can certainly flip them but it would be easier to just edit the existing workflow. Vincent Massol wrote: -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: mercredi 1 février 2006 20:57 To: Maven Developers List Subject: editing closed JIRA issues I found this: http://confluence.atlassian.com/pages/viewpage.action?pageId=121422 Vincent, could you help us set this up in our workflow? I've created a new workflow called Maven New which allows edits even if the issue is closed. I've associated the MNG JIRA project to it. Now we need magic Jason to run his scripts to associate all the Maven family projects to it automatically. Thanks -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-320) Hibernate 3.1.x POMs pull in Sun jars
Hibernate 3.1.x POMs pull in Sun jars - Key: MEV-320 URL: http://jira.codehaus.org/browse/MEV-320 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mike Perham jta and jacc need to be scoped as provided as they are J2EE specs and should be provided by the container. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-320) Hibernate 3.1.x POMs pull in Sun jars
[ http://jira.codehaus.org/browse/MEV-320?page=comments#action_57584 ] Carlos Sanchez commented on MEV-320: I don't know about using hibernate in a full app server but what happens if you want to use jta transactions in a web container like tomcat? Hibernate 3.1.x POMs pull in Sun jars - Key: MEV-320 URL: http://jira.codehaus.org/browse/MEV-320 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mike Perham jta and jacc need to be scoped as provided as they are J2EE specs and should be provided by the container. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Build Error from SRC
To Whom it may concern: M2_ HOME is set to E:\JUtils\maven-2.0.1-frmSrc and I'm getting the following error //-- ERROR: M2_HOME is set to an invalid directory. M2_HOME = E:\JUtils\MAVEN2~1.1_S\COMPON~1\BOOTST~1\target\INSTAL~1\bin\mvn.bat\.. Please set the M2_HOME variable in your environment to match the location of the Maven installation Installing Maven in E:\JUtils\maven-2.0.1-SNAPSHOT\..\maven-2.1-SNAPSHOT Exception in thread main java.lang.Exception: Maven was not installed in E:\JUtils\maven-2.0.1-SNAPSHOT\..\maven-2.1-SNAPSHOT at org.apache.maven.bootstrap.installer.BootstrapInstaller.run(BootstrapIns taller.java:151) at org.apache.maven.bootstrap.installer.BootstrapInstaller.main(BootstrapIn staller.java:93) Using settings from C:\Documents and Settings\wford\.m2\settings.xml Using the following for your local repository: C:/Documents and Settings/wford/.m2/repository Using the following for your remote repository: [http://repo1.maven.org/maven2, http://snapshots.maven.codehaus.org/maven2/] Analysing dependencies ... Building project in E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier -- Cleaning E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target... Compiling sources ... Compiling 11 source files to E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target\classe s Packaging resources ... Packaging E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target\maven- core-it-verifier.jar ... -- Total time: 1 seconds Finished at: Wed Feb 01 17:45:57 EST 2006 ECHO is off. --- Running integration tests --- Using default local repository: C:\Documents and Settings\wford\.m2\repository it0089... FAILED - Standard Out - Removing file: C:\Documents and Settings\wford\.m2\repository/org/apache/maven/plugins/maven-core-it-plu gin/1.0-SNAPSHOT/maven-cor e-it-plugin-1.0-SNAPSHOT.jar Command: E:\JUtils\maven-2.0.1-SNAPSHOT\bin\mvn -e --no-plugin-registry --batch-mode -Dmaven.repo.local=C:\Documents and Settings \wford\.m2\repository clean:clean install - Standard Error - Exit code: 1 Error Stacktrace: org.apache.maven.it.VerificationException at org.apache.maven.it.Verifier.executeGoals(Verifier.java:676) at org.apache.maven.it.Verifier.main(Verifier.java:856) Error Stacktrace Log file contents: The system cannot find the path specified. . . .etc The system cannot find the path specified. 0/89 passed Failed tests: [it0089, it0088, it0087, it0086, it0085, it0084, it0083, it0082, it0081, it0080, it0079, it0078, it0077, it0076, it0 075, it0074, it0073, it0072, it0071, it0070, it0069, it0068, it0067, it0066, it0065, it0064, it0063, it0062, it0061, it0060, it005 9, it0058, it0057, it0056, it0055, it0054, it0053, it0052, it0051, it0050, it0049, it0048, it0047, it0046, it0045, it0044, it0043, it0042, it0041, it0040, it0039, it0038, it0037, it0036, it0035, it0034, it0033, it0032, it0031, it0030, it0029, it0028, it0027, i t0026, it0025, it0024, it0023, it0022, it0021, it0020, it0019, it0018, it0017, it0016, it0014, it0013, it0012, it0011, it0010, it0 009, it0008, it0007, it0006, it0005, it0004, it0003, it0002, it0001, it] E:\JUtils\maven2.0.1_src\components
Re: Maven Build Error from SRC
Why don't you try with the last version 2.0.2 On 2/1/06, Waldo Ford [EMAIL PROTECTED] wrote: To Whom it may concern: M2_ HOME is set to E:\JUtils\maven-2.0.1-frmSrc and I'm getting the following error //-- ERROR: M2_HOME is set to an invalid directory. M2_HOME = E:\JUtils\MAVEN2~1.1_S\COMPON~1\BOOTST~1\target\INSTAL~1\bin\mvn.bat\.. Please set the M2_HOME variable in your environment to match the location of the Maven installation Installing Maven in E:\JUtils\maven-2.0.1-SNAPSHOT\..\maven-2.1-SNAPSHOT Exception in thread main java.lang.Exception: Maven was not installed in E:\JUtils\maven-2.0.1-SNAPSHOT\..\maven-2.1-SNAPSHOT at org.apache.maven.bootstrap.installer.BootstrapInstaller.run(BootstrapIns taller.java:151) at org.apache.maven.bootstrap.installer.BootstrapInstaller.main(BootstrapIn staller.java:93) Using settings from C:\Documents and Settings\wford\.m2\settings.xml Using the following for your local repository: C:/Documents and Settings/wford/.m2/repository Using the following for your remote repository: [http://repo1.maven.org/maven2, http://snapshots.maven.codehaus.org/maven2/] Analysing dependencies ... Building project in E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier -- Cleaning E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target... Compiling sources ... Compiling 11 source files to E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target\classe s Packaging resources ... Packaging E:\JUtils\maven2.0.1_src\components\maven-core-it-verifier\target\maven- core-it-verifier.jar ... -- Total time: 1 seconds Finished at: Wed Feb 01 17:45:57 EST 2006 ECHO is off. --- Running integration tests --- Using default local repository: C:\Documents and Settings\wford\.m2\repository it0089... FAILED - Standard Out - Removing file: C:\Documents and Settings\wford\.m2\repository/org/apache/maven/plugins/maven-core-it-plu gin/1.0-SNAPSHOT/maven-cor e-it-plugin-1.0-SNAPSHOT.jar Command: E:\JUtils\maven-2.0.1-SNAPSHOT\bin\mvn -e --no-plugin-registry --batch-mode -Dmaven.repo.local=C:\Documents and Settings \wford\.m2\repository clean:clean install - Standard Error - Exit code: 1 Error Stacktrace: org.apache.maven.it.VerificationException at org.apache.maven.it.Verifier.executeGoals(Verifier.java:676) at org.apache.maven.it.Verifier.main(Verifier.java:856) Error Stacktrace Log file contents: The system cannot find the path specified. . . .etc The system cannot find the path specified. 0/89 passed Failed tests: [it0089, it0088, it0087, it0086, it0085, it0084, it0083, it0082, it0081, it0080, it0079, it0078, it0077, it0076, it0 075, it0074, it0073, it0072, it0071, it0070, it0069, it0068, it0067, it0066, it0065, it0064, it0063, it0062, it0061, it0060, it005 9, it0058, it0057, it0056, it0055, it0054, it0053, it0052, it0051, it0050, it0049, it0048, it0047, it0046, it0045, it0044, it0043, it0042, it0041, it0040, it0039, it0038, it0037, it0036, it0035, it0034, it0033, it0032, it0031, it0030, it0029, it0028, it0027, i t0026, it0025, it0024, it0023, it0022, it0021, it0020, it0019, it0018, it0017, it0016, it0014, it0013, it0012, it0011, it0010, it0 009, it0008, it0007, it0006, it0005, it0004, it0003, it0002, it0001, it] E:\JUtils\maven2.0.1_src\components - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-320) Hibernate 3.1.x POMs pull in Sun jars
[ http://jira.codehaus.org/browse/MEV-320?page=comments#action_57585 ] Mike Perham commented on MEV-320: - I would think you would need to pull in an XA engine like JOTM too so this wouldn't be a showstopper. Perhaps it should be marked as optional? Hibernate 3.1.x POMs pull in Sun jars - Key: MEV-320 URL: http://jira.codehaus.org/browse/MEV-320 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Mike Perham jta and jacc need to be scoped as provided as they are J2EE specs and should be provided by the container. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2030) Make -X show maven version as first thing
Make -X show maven version as first thing - Key: MNG-2030 URL: http://jira.codehaus.org/browse/MNG-2030 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.2 Reporter: Carlos Sanchez Priority: Critical output of mvn -X needs to include the version number so when an user posts the output we should be able to identify which version is he running against -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2030) Make -X show maven version as first thing
[ http://jira.codehaus.org/browse/MNG-2030?page=all ] Carlos Sanchez updated MNG-2030: Fix Version: 2.0.3 Make -X show maven version as first thing - Key: MNG-2030 URL: http://jira.codehaus.org/browse/MNG-2030 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.2 Reporter: Carlos Sanchez Priority: Critical Fix For: 2.0.3 output of mvn -X needs to include the version number so when an user posts the output we should be able to identify which version is he running against -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Thu Feb 2 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060202.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060202.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPSCM-76) Make scm plugin independent of release
[ http://jira.codehaus.org/browse/MPSCM-76?page=all ] Lukas Theussl closed MPSCM-76: -- Resolution: Fixed Make scm plugin independent of release -- Key: MPSCM-76 URL: http://jira.codehaus.org/browse/MPSCM-76 Project: maven-scm-plugin Type: Task Reporter: Lukas Theussl Fix For: 1.6 Move all used classes and tags to scm as release will be demoted -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - checkout] Thu Feb 2 00:30:01 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060202.003002.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-55) Validate the configuration
Validate the configuration --- Key: MSUREFIRE-55 URL: http://jira.codehaus.org/browse/MSUREFIRE-55 Project: Maven 2.x Surefire Plugin Type: Improvement Versions: 2.1.2 Reporter: Jason van Zyl Fix For: 2.1.3 Currently someone can enter an incorrect value for the forkMode which yields incorrect results. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
