[jira] Updated: (CONTINUUM-1023) The cancel button of both login and registration page does not work
[ http://jira.codehaus.org/browse/CONTINUUM-1023?page=all ] Franz Allan Valencia See updated CONTINUUM-1023: Attachment: CONTINUUM-1023-continuum-webapp.patch complementary to PLX-303, CONTINUUM-1023-continuum-webapp.patch redirects the user to the project groups page (groupSummary) when cancel is pressed instead of to the login page. > The cancel button of both login and registration page does not work > --- > > Key: CONTINUUM-1023 > URL: http://jira.codehaus.org/browse/CONTINUUM-1023 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Reporter: Franz Allan Valencia See >Priority: Minor > Attachments: CONTINUUM-1023-continuum-webapp.patch > > > The other pages rely on the submitCancel tag of continuum, but since the > login and registration are taken from plexus-security, they cannot use the > submitCancel tag. -- 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: (MNG-2340) Incorrect dependency version downloaded
[ http://jira.codehaus.org/browse/MNG-2340?page=comments#action_81469 ]
Andreas Guther commented on MNG-2340:
-
I was not aware that this is also a problem in the mvn site generating plug-in.
Does an entry for this problem exist for the maven site plug-in as well?
> Incorrect dependency version downloaded
> ---
>
> Key: MNG-2340
> URL: http://jira.codehaus.org/browse/MNG-2340
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.0.4
>Reporter: Adrian
>Priority: Critical
> Fix For: 2.1
>
> Attachments: MNGECLIPSE-131.zip
>
>
> I have a parent pom with a dependency management section specifying the
> version of an artifact to use. In the child project, I override this version.
> The maven plugin ignores the overriding version and downloads the version
> specified by the parent pom.
> For example, in the parent pom
> {code}
>
> lucene
> lucene
> 1.4.3
>
> {code}
> in the project pom, inheriting the parent pom
> {code}
>
> lucene
> lucene
> 2.0
>
> {code}
> The maven eclipse plugin downloads version 1.4.3 for my project
--
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: (MECLIPSE-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=comments#action_81468 ] Andreas Guther commented on MECLIPSE-107: - Managed dependencies need to be taken into account, but they need to be overwritten by the component pom in those cases where the component pom needs to specify the version against the definition in the parent pom. This is the behavior in Maven and must be the same in the Eclipse plugin. I have the scenario where we manage our version in a parent pom with the dependencyManagement section. Usually our components do not specify the version which then is taken as specified in the parent pom. Just today I had the situation where I needed to overwrite the version in only one component for test reasons. Getting the fix is highly appreciated. > Dependency Version Incorrectly Taken from DependencyManagement > -- > > Key: MECLIPSE-107 > URL: http://jira.codehaus.org/browse/MECLIPSE-107 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.2 >Reporter: Stephen Duncan Jr >Priority: Critical > Attachments: dmtest.zip > > > The version used when generating .classpath is taken from > dependencyManagement even though the child pom sets the dependency version, > which should override what is in dependencyManagement. This is a regression > from the correct behaviour in 2.1. > The attached project demonstrates the problem. The .classpath file generated > for the "child" project should specify log4j-1.2.13, but instead specifies > 1.28. -- 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: (MNG-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_81461 ] Brian Fox commented on MNG-2546: This is exactly what the dependency plugin needs to handle defacto dependencies defined in the config for copy and unpack that may be in the same reactor. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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: (MNG-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ http://jira.codehaus.org/browse/MNG-2553?page=comments#action_81460 ] Chandra Patni commented on MNG-2553: We also have a same repository for all projects. However, we don't want to specify URL in pom.xml. For instance we have some users on Apple/Linux who use file server using a different method. myrepository file://X:/ > Maven Local Settings Model should allow configuration of distributions > (distributionManagement) > --- > > Key: MNG-2553 > URL: http://jira.codehaus.org/browse/MNG-2553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > > There is a good use case where this would be very useful. > E.g. I develop a plugin in mojo-sandbox and want to test it in an environment > other than the one that I developed it on (e.g. a computer at work). I check > out the plugin to this, build and then want to deploy to another repository > (e..g a company's internal repository). I don't want to fiddle with the > pom.xml of the plugin, just refer to a profile in settings.xml. -- 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: (MAVENUPLOAD-1257) Please upload EZMorph-0.9.1
Please upload EZMorph-0.9.1 --- Key: MAVENUPLOAD-1257 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1257 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray EZMorph is simple java library for transforming an Object to another Object. This release includes a minor bugfix that is in high demand for the next release of json-lib. -- 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: (MSUREFIRE-57) Forking documentation improvement to help with class loader constrainst issues
[ http://jira.codehaus.org/browse/MSUREFIRE-57?page=comments#action_81455 ] Tanver Afzal commented on MSUREFIRE-57: --- Hi I am still confused where to set the forking. on the server side or in Eclipse some where. I appreciate your help. Regards Tanver > Forking documentation improvement to help with class loader constrainst issues > -- > > Key: MSUREFIRE-57 > URL: http://jira.codehaus.org/browse/MSUREFIRE-57 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.1.3 > Environment: maven 2.0.2 >Reporter: Ben Gidley > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.2 > > Attachments: maven-surefire-plugin-374325.patch > > > With (for example) JAXB2 forking surefire causes a > java.lang.LinkageError: loader constraints violated when linking > javax/xml/namespace/QName class > This is because by default when forking an Isolated class loader is used. > this can be resovled by turning child delegation on. > The documentation does not mention this and should be improved. -- 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: (MPJDIFF-10) jdiff doclet fails with jdk 1.4
[ http://jira.codehaus.org/browse/MPJDIFF-10?page=all ]
Arnaud Heritier updated MPJDIFF-10:
---
Attachment: MPJDIFF-10.patch
add the xml-apis which is required in the jdk 1.4
> jdiff doclet fails with jdk 1.4
> ---
>
> Key: MPJDIFF-10
> URL: http://jira.codehaus.org/browse/MPJDIFF-10
> Project: maven-jdiff-plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Lukas Theussl
> Fix For: 1.5.1
>
> Attachments: MPJDIFF-10.patch
>
>
> Running jdiff with jdk 1.4.2_10 gives the following exception:
> {noformat}
> [javadoc] JDiff: doclet started ...
> [javadoc] javadoc: In doclet class jdiff.JDiff, method start has thrown
> an exception java.lang.reflect.InvocationTargetException
> [javadoc] java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2
> {noformat}
> The build succeeds but there are no files generated. Note that it only
> happens with the current svn version of the plugin, it works when downgrading
> to the released maven-jdiff-plugin-1.5 . It also works with java 5 since the
> missing class is contained in the rt.jar. I fixed it by adding a dependency
> to xml-apis, but I think that should not be necessary?
--
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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=all ] Carlos Sanchez closed MAVENUPLOAD-1256. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload the library statsvn-0.2.0 to the repo > --- > > Key: MAVENUPLOAD-1256 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 > Project: maven-upload-requests > Issue Type: Task >Reporter: Benoit Xhenseval > Assigned To: Carlos Sanchez > Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar > > > Hi > This is a pure library (not a plugin) so I believe that this mechanism is the > correct one to have it uploaded on M1 and M2 repository? > We're working on an m2 repo " SF for qalab and the rest but in the meantime > could you upload this? > Many thanks > Benoit -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81431 ] Dennis Lundberg commented on MCHANGES-58: - Damien, The purpose of my comment was to set your expectations at a reasonable level. If it came across in any other way I apologize. The knowledge of Bugzilla among the Maven devs is probably lower than it is for JIRA, so we would probably need help from the some Bugilla power-users in the community to pull this off. The comparison to Maven SCM is both a good and a bad one. Maven SCM does have the abstraction layer that is need for this to work in a smooth way, and that Mark talks about. The discussions about this on the dev-list sort of ended in, well not much. If the effort to create such an interface is pushed through I would certainly be interested in using it in this plugin. However the issue tracking system is used for reporting only in Maven, while SCM is used for releasing stuff. So it has, and should have, a higher priority. Reporting won't do you much good if you can't build or release your project. > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=all ] Benoit Xhenseval updated MAVENUPLOAD-1256: -- Attachment: statsvn-0.2.0-bundle.jar Please ignore the other one. > Please upload the library statsvn-0.2.0 to the repo > --- > > Key: MAVENUPLOAD-1256 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 > Project: maven-upload-requests > Issue Type: Task >Reporter: Benoit Xhenseval > Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar > > > Hi > This is a pure library (not a plugin) so I believe that this mechanism is the > correct one to have it uploaded on M1 and M2 repository? > We're working on an m2 repo " SF for qalab and the rest but in the meantime > could you upload this? > Many thanks > Benoit -- 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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=comments#action_81429 ] Benoit Xhenseval commented on MAVENUPLOAD-1256: --- Ooops, thanks to you, we realised that our project.xml did not contain any groupId and it seems to be picked up from the package name somehow. This is now correctec Thanks for pointing this to us. Benoit > Please upload the library statsvn-0.2.0 to the repo > --- > > Key: MAVENUPLOAD-1256 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 > Project: maven-upload-requests > Issue Type: Task >Reporter: Benoit Xhenseval > Attachments: statsvn-0.2.0-bundle.jar, statsvn-0.2.0-bundle.jar > > > Hi > This is a pure library (not a plugin) so I believe that this mechanism is the > correct one to have it uploaded on M1 and M2 repository? > We're working on an m2 repo " SF for qalab and the rest but in the meantime > could you upload this? > Many thanks > Benoit -- 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: (MAVENUPLOAD-1256) Please upload the library statsvn-0.2.0 to the repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1256?page=comments#action_81423 ] Carlos Sanchez commented on MAVENUPLOAD-1256: - You can use org.statsvn or net.sf.statsvn, but not just statsvn > Please upload the library statsvn-0.2.0 to the repo > --- > > Key: MAVENUPLOAD-1256 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1256 > Project: maven-upload-requests > Issue Type: Task >Reporter: Benoit Xhenseval > Attachments: statsvn-0.2.0-bundle.jar > > > Hi > This is a pure library (not a plugin) so I believe that this mechanism is the > correct one to have it uploaded on M1 and M2 repository? > We're working on an m2 repo " SF for qalab and the rest but in the meantime > could you upload this? > Many thanks > Benoit -- 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: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[ http://jira.codehaus.org/browse/MRESOURCES-20?page=all ]
Erik Post updated MRESOURCES-20:
Attachment: MRESOURCES-20.patch
I've attached a patch that fixes the problem for me. In
ReflectionProperties.java, the call to ReflectionValueExtractor.evaluate now
includes a third parameter with value false so that the first component of the
key is not stripped. All unit tests pass.
> Filtering ${foo.file} evaluates to in full path to pom.xml
> --
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
>Reporter: Martin Onis
>Priority: Minor
> Attachments: MRESOURCES-20.patch
>
>
> If an unresolved variable is encountered, the plugin simply does not replace
> the variable in the target file.
> If this unresolved variable however ends in ".file}" it will evaluate to a
> file object that targets the current pom. This results in the replacement
> being the complete path to that pom (in the 2.1 version of the plugin this
> results in a ClassCastException).
> The workaround is, of course, not to filter the affected files.
> Though this will not work if other variables in the affected files do need to
> be replaced.
--
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: (MNG-2682) Global Settings are ignored
Global Settings are ignored
---
Key: MNG-2682
URL: http://jira.codehaus.org/browse/MNG-2682
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 2.0.4
Environment: Win XP, JDK1.6rc, m2eclipse 0.0.10 (trunk), eclipse 3.2.1
Reporter: Ralf Stoffels
With the CLI both the global settings in $M2_HOME/conf/settings.xml and the
user settings in ${user.dir}/.m2/settings.xml are used.
With the Embedder used by M2Eclipse only the user settings are used.
So this issue is different from MNG-1884
I hope this is fixed in 2.0.5 (-> MNG-1069).
--
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: (MNG-2344) Support for functional/integration tests is *way* too limited
[ http://jira.codehaus.org/browse/MNG-2344?page=comments#action_81405 ]
David Svanberg commented on MNG-2344:
-
Sorry this was a comment for #2433 ... Silly me.
> Support for functional/integration tests is *way* too limited
> -
>
> Key: MNG-2344
> URL: http://jira.codehaus.org/browse/MNG-2344
> Project: Maven 2
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices
>Affects Versions: 2.0.4
>Reporter: Craig McClanahan
> Assigned To: Brett Porter
>
> I am a recent convert to Maven2 ... after listening to advice from many
> people I respect (including Wendy Smoak and Brett Porter) we are in the midst
> of migrating the build environment for the Shale Framework (part of the
> http://struts.apache.org community) over to Maven2. For the most part, this
> has been all goodness ... the dependency management, and the hierarchical
> dependency resolution, make for a dramatic simplification in the overall
> environment.
> That being said, there is one major area where I'm really disappointed ...
> and it's almost enough to tip my personal scale back towards hand crafted Ant
> builds. It relates to support for testing of web applications. My plan is
> to leverage the Maven2 "archetype" capability to make it very easy to build
> "starter" web applications that are already set up to use Shale. To
> encourage best practices, I want to set up "out of the box" testing for the
> application to be developed.
> As we all know, this kind of testing can be divided into at least two major
> categories ... unit tests of the individual server side classes, and
> functiona/integration tests that want to deploy the application first, then
> interact with it (using a framework such as HttpUnit or HtmlUnit) to verify
> that the rendered results match expectations. In my previous Ant-based build
> world, I had two different targets ("test" and "systest") that could exercise
> the two different kinds of tests. Much to my surprise, it seems to be
> difficult-to-impossible to set up a similar sceanrio (two kinds of tests) in
> the same project when you're using Maven2.
> I could live with this (although I'd still grumble a lot) if it was just an
> issue of the sample apps that we ship with Shale. I can teach committers to
> run integration tests from a separate module before doing SVN commits. But
> that is *not* what I want to present to potential developers that will build
> webapps based on a Shale-provided archtetype. And it shouldn't be what *you*
> want for Maven2 users in general either ... support for both unit tests and
> integration tests seems like a mission critical feature that is not
> adequately supported at present.
--
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: (MNG-2433) Maven looks for snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2433?page=comments#action_81404 ] David Svanberg commented on MNG-2433: - Does fail also when offline set to true in settings.xml (which is kind of critical for us behind firewalls...): [INFO] artifact org.apache.maven.plugins:maven-scm-plugin: checking for updates from central [WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-scm-plugin' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted > Maven looks for snapshots in offline mode > - > > Key: MNG-2433 > URL: http://jira.codehaus.org/browse/MNG-2433 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Carsten Ziegeler >Priority: Critical > Fix For: 2.0.6 > > > It seems that sometimes Maven2 is looking for snapshots in offline mode (this > happens for example in the Cocoon project). here is an output that might help: > :\dev\workspace\cocoon-2.2\core\cocoon-webapp>mvn -o -Dmaven.test.skip=true > coc > oon:deploy > [INFO] > NOTE: Maven is executing in offline mode. Any artifacts not already in your > loca > l > repository will be inaccessible. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'cocoon'. > [INFO] org.apache.maven.plugins: checking for updates from snapshots > [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo > [INFO] org.codehaus.mojo: checking for updates from snapshots > [INFO] org.codehaus.mojo: checking for updates from mortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from snapshots > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from mortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from central > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from apache.snapshot > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from apache-cvs > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from apache.snapshots > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from snapshots > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from mortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from central > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from apache.snapshot > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from apache-cvs > [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for > updat > es from apache.snapshots > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from snapshots > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from mortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from central > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from apache.snapshot > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from apache-cvs > [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking > for > updates from apache.snapshots > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from s > napshots > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from m > ortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from c > entral > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from a > pache.snapshot > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from a > pache-cvs > [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates > from a > pache.snapshots -- 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: (MNG-2344) Support for functional/integration tests is *way* too limited
[ http://jira.codehaus.org/browse/MNG-2344?page=comments#action_81402 ]
David Svanberg commented on MNG-2344:
-
Even when offline set to true in settings.xml:
[INFO] artifact org.apache.maven.plugins:maven-scm-plugin: checking for updates
from central
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-scm-plugin' could not be retrieved from
repository: central due to an error: Error transferring file
[INFO] Repository 'central' will be blacklisted
> Support for functional/integration tests is *way* too limited
> -
>
> Key: MNG-2344
> URL: http://jira.codehaus.org/browse/MNG-2344
> Project: Maven 2
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices
>Affects Versions: 2.0.4
>Reporter: Craig McClanahan
> Assigned To: Brett Porter
>
> I am a recent convert to Maven2 ... after listening to advice from many
> people I respect (including Wendy Smoak and Brett Porter) we are in the midst
> of migrating the build environment for the Shale Framework (part of the
> http://struts.apache.org community) over to Maven2. For the most part, this
> has been all goodness ... the dependency management, and the hierarchical
> dependency resolution, make for a dramatic simplification in the overall
> environment.
> That being said, there is one major area where I'm really disappointed ...
> and it's almost enough to tip my personal scale back towards hand crafted Ant
> builds. It relates to support for testing of web applications. My plan is
> to leverage the Maven2 "archetype" capability to make it very easy to build
> "starter" web applications that are already set up to use Shale. To
> encourage best practices, I want to set up "out of the box" testing for the
> application to be developed.
> As we all know, this kind of testing can be divided into at least two major
> categories ... unit tests of the individual server side classes, and
> functiona/integration tests that want to deploy the application first, then
> interact with it (using a framework such as HttpUnit or HtmlUnit) to verify
> that the rendered results match expectations. In my previous Ant-based build
> world, I had two different targets ("test" and "systest") that could exercise
> the two different kinds of tests. Much to my surprise, it seems to be
> difficult-to-impossible to set up a similar sceanrio (two kinds of tests) in
> the same project when you're using Maven2.
> I could live with this (although I'd still grumble a lot) if it was just an
> issue of the sample apps that we ship with Shale. I can teach committers to
> run integration tests from a separate module before doing SVN commits. But
> that is *not* what I want to present to potential developers that will build
> webapps based on a Shale-provided archtetype. And it shouldn't be what *you*
> want for Maven2 users in general either ... support for both unit tests and
> integration tests seems like a mission critical feature that is not
> adequately supported at present.
--
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: (MNG-2056) Exception when starting new page with AbstractMavenMultiPageReport
[ http://jira.codehaus.org/browse/MNG-2056?page=comments#action_81401 ] David vicente commented on MNG-2056: I have the same problem. When do you schedule a release for this bug ? Thanks > Exception when starting new page with AbstractMavenMultiPageReport > -- > > Key: MNG-2056 > URL: http://jira.codehaus.org/browse/MNG-2056 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.2 > Environment: OS X 10.3.4. running JDK 1.5 (1.5.0_06-93) >Reporter: Adam Winer > Fix For: 2.0.6 > > > Attempts to call AbstractMavenMultiPageReport.startPage() from a custom > report result in the following exception: > Caused by: java.io.EOFException: input contained no data > at > org.codehaus.plexus.util.xml.pull.MXParser.fillBuf(MXParser.java:2979) > at org.codehaus.plexus.util.xml.pull.MXParser.more(MXParser.java:3022) > at > org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1407) > at > org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1392) > at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1090) > at > org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:172) > at > org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:83) > at > org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:48) > at > org.codehaus.doxia.module.xhtml.decoration.model.DecorationModelReader.createNavigation(DecorationModelReader.java:30) > at > org.codehaus.doxia.site.renderer.DefaultSiteRenderer.createSink(DefaultSiteRenderer.java:244) > at > org.apache.maven.reporting.sink.SinkFactory.getSink(SinkFactory.java:76) > at > org.apache.maven.reporting.AbstractMavenMultiPageReport.getSink(AbstractMavenMultiPageReport.java:79) > at > org.apache.maven.reporting.AbstractMavenMultiPageReport.startPage(AbstractMavenMultiPageReport.java:85) > FYI, I'm creating the SinkFactory for the multipage report using: > SinkFactory factory = new SinkFactory(); > factory.setSiteRenderer(getSiteRenderer()); > factory.setSiteDirectory(getOutputDirectory()); > setSinkFactory(factory); > Without this code, you just get a NullPointerException in > AbstractMavenMultiPageReport.getSink(). -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81397 ] Mark Hobson commented on MCHANGES-58: - Finally got around to it ;) https://bugs.eclipse.org/bugs/show_bug.cgi?id=166203 > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MAVENUPLOAD-1250) Upload org.hibernate:hibernate:jar:3.2.1.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1250?page=comments#action_81393 ] Felipe Leme commented on MAVENUPLOAD-1250: -- If you don't fix the POM, they won't upload it. > Upload org.hibernate:hibernate:jar:3.2.1.ga to ibiblio > -- > > Key: MAVENUPLOAD-1250 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1250 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/hibernate-3.2.1.ga-bundle.jar > http://www.hibernate.org/ > Hibernate is a powerful, high performance object/relational persistence and > query service. -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81392 ] Mark Hobson commented on MCHANGES-58: - The abstract issue API to use would be Mylar's, since a lot of work has been put into that and it's various implementations - check the Mylar CVS. I seem to remember the above thread ending with requirement to build Mylar with Maven, so it's artifacts can be used by Maven components. I meant to raise an issue with Mylar as Mik suggested.. > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81391 ] Damien Lecan commented on MCHANGES-58: -- Very interesting ! Starting point : http://mail-archives.apache.org/mod_mbox//maven-dev/200607.mbox/[EMAIL PROTECTED] What is the status of this new API ? Is it available somewhere ? If yes, does this plugin plans to migrate ? I have seen that another request was done for Trac instead of JIRA too ([MCHANGES-59|http://jira.codehaus.org/browse/MCHANGES-59]). > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81385 ] Mark Hobson commented on MCHANGES-58: - There was a thread a while ago on maven-dev regarding sharing Bugzilla communication code with the Eclipse Mylar project, which would make this a lot easier. > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=all ] Napoleon Esmundo C. Ramirez updated CONTINUUM-1022: --- Comment: was deleted > Validaiton Email not working > > > Key: CONTINUUM-1022 > URL: http://jira.codehaus.org/browse/CONTINUUM-1022 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Franz Allan Valencia See > > The validation email sent when you register is not working. -- 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: (CONTINUUM-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=comments#action_81382
]
Napoleon Esmundo C. Ramirez commented on CONTINUUM-1022:
The validation mail now uses JNDI to locate the mail service. However the
codes at the trunk isn't configured yet to make jetty:run work.
To configure continuum to use the JNDI mail resource, I added the following in
continuum-webapp/src/jetty-env.xml:
mail/Session
username
password
smtp.host.org
[EMAIL PROTECTED]
Continuum
true
I also added the following in continuum-webapp/src/main/webapp/WEB-INF/web.xml:
mail/Session
javax.mail.Session
Container
Which led me to another problem described by the following stack trace:
DEBUG: JavaMail version 1.4ea
DEBUG: java.io.FileNotFoundException:
/usr/share/jdk1.5.0_06/jre/lib/javamail.providers (No such file or directory)
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.providers
DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
DEBUG: Tables of loaded providers
DEBUG: Providers Listed By Class Name:
{com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun
Microsystems, Inc],
com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun
Microsystems, Inc],
com.sun.mail.imap.IMAPSSLStore=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun
Microsystems, Inc],
com.sun.mail.pop3.POP3SSLStore=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun
Microsystems, Inc],
com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc],
com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun
Microsystems, Inc]}
DEBUG: Providers Listed By Protocol:
{imaps=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun
Microsystems, Inc],
imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun
Microsystems, Inc],
smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun
Microsystems, Inc],
pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun
Microsystems, Inc],
pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun
Microsystems, Inc],
smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun
Microsystems, Inc]}
DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
DEBUG: !anyLoaded
DEBUG: not loading resource: /META-INF/javamail.address.map
DEBUG: java.io.FileNotFoundException:
/usr/share/jdk1.5.0_06/jre/lib/javamail.address.map (No such file or directory)
2006-11-29 16:26:29,745 [btpool0-4] ERROR Mailer -
Unable to generate email for template
'org/codehaus/plexus/security/ui/web/mail/template/newAccountValidationEmail.vm':
javax.mail.Session
java.lang.ClassCastException: javax.mail.Session
at
org.codehaus.plexus.mailsender.javamail.JndiJavamailMailSender.getSession(JndiJavamailMailSender.java:52)
at
org.codehaus.plexus.mailsender.javamail.AbstractJavamailMailSender.send(AbstractJavamailMailSender.java:62)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendMessage(Mailer.java:237)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendVelocityEmail(Mailer.java:165)
at
org.codehaus.plexus.security.ui.web.mail.Mailer.sendAccountValidationEmail(Mailer.java:108)
at
org.codehaus.plexus.security.ui.web.action.RegisterAction.register(RegisterAction.java:183)
Any ideas about this? Or did I miss on some configuration?
> Validaiton Email not working
>
>
> Key: CONTINUUM-1022
> URL: http://jira.codehaus.org/browse/CONTINUUM-1022
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Reporter: Franz Allan Valencia See
>
> The validation email sent when you register is not working.
--
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: (MDOAP-5) doap plugin not in central, but listed on the "plugins by category" page
doap plugin not in central, but listed on the "plugins by category" page Key: MDOAP-5 URL: http://jira.codehaus.org/browse/MDOAP-5 Project: Maven 2.x DOAP Plugin Issue Type: Bug Environment: Maven 2 Reporter: Jan Dockx Priority: Blocker [EMAIL PROTECTED]:helloWorld>mvn -N doap:generate [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'doap'. [INFO] artifact org.apache.maven.plugins:maven-doap-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-doap-plugin' does not exist or no valid version could be found [INFO] The plugin is listed on the Maven 2 "Plugins by category" page, but cannot be found in central -- 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: (CONTINUUM-1022) Validaiton Email not working
[ http://jira.codehaus.org/browse/CONTINUUM-1022?page=comments#action_81381 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-1022: The validation mail now uses JNDI to locate the mail service. However the codes at the trunk isn't configured yet to make jetty:run work. > Validaiton Email not working > > > Key: CONTINUUM-1022 > URL: http://jira.codehaus.org/browse/CONTINUUM-1022 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Franz Allan Valencia See > > The validation email sent when you register is not working. -- 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-1023) The cancel button of both login and registration page does not work
The cancel button of both login and registration page does not work --- Key: CONTINUUM-1023 URL: http://jira.codehaus.org/browse/CONTINUUM-1023 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See Priority: Minor The other pages rely on the submitCancel tag of continuum, but since the login and registration are taken from plexus-security, they cannot use the submitCancel tag. -- 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: (MCHANGES-47) Add support for multiple and tags in changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-47?page=all ] Julien HENRY updated MCHANGES-47: - Attachment: maven-change-multiple-issue.patch This patch simply add suport for multiple issues (comma separated). > Add support for multiple and tags in changes.xml > - > > Key: MCHANGES-47 > URL: http://jira.codehaus.org/browse/MCHANGES-47 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Dennis Lundberg > Attachments: maven-change-multiple-issue.patch, > MCHANGES-47-maven-changes-plugin.patch > > > This is to improve the compatibility with changes.xml files used by the Maven > 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for more info. -- 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-1022) Validaiton Email not working
Validaiton Email not working Key: CONTINUUM-1022 URL: http://jira.codehaus.org/browse/CONTINUUM-1022 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Franz Allan Valencia See The validation email sent when you register is not working. -- 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: (MECLIPSE-199) patch for incorrect documentation
patch for incorrect documentation - Key: MECLIPSE-199 URL: http://jira.codehaus.org/browse/MECLIPSE-199 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Andreas Wuest Attachments: patch.txt patch for a documentation typo (missing "/" in a closing xml tag) -- 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: (MCHANGES-58) Add ability to manage Bugzilla instead of JIRA
[ http://jira.codehaus.org/browse/MCHANGES-58?page=comments#action_81378 ] Damien Lecan commented on MCHANGES-58: -- ? As I see that Maven SCM project manages a lot of SCM's, may I conclude that Maven project uses CVS, Subversion, Perforce, Clearcase and VSS all together ? I understand your point of view, but I am a disappointed by a such answer. Building a patch for this feature is a huge work, especilly because many business rules could be shared between Jira and BZ implementations (many of AbstractJiraDownloader methods could be used for BZ too). It is not possible to do refactoring with patch, they are too hard to maintain. > Add ability to manage Bugzilla instead of JIRA > -- > > Key: MCHANGES-58 > URL: http://jira.codehaus.org/browse/MCHANGES-58 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Damien Lecan > > It would be very nice if this plugin can manage Bugzilla as it does for JIRA -- 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
