[jira] Closed: (DOXIA-319) Improve toc macro for CSS
[
http://jira.codehaus.org/browse/DOXIA-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-319.
---
Resolution: Fixed
Fix Version/s: 1.1.1
> Improve toc macro for CSS
> -
>
> Key: DOXIA-319
> URL: http://jira.codehaus.org/browse/DOXIA-319
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.1
> Environment: any
>Reporter: Albert Kurucz
>Assignee: Lukas Theussl
>Priority: Minor
> Fix For: 1.1.1
>
>
> The toc macro in APT works great!
> example: %{toc|section=0}
> But.
> It would be nice to make it CSS friendly with an divId= and/or divClass=
> parameter.
> example: %{toc|section=0|divID=myTOC}
> If divId or div/Class parameter exists, the toc macro should change the
> enclosing accordingly.
> If there is no enclosing , then create an additional
> around the generated structure, which has the id/class as
> specified.
--
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: (MSHARED-41) Ability to list Class-Path: elements individually
[ http://jira.codehaus.org/browse/MSHARED-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176226#action_176226 ] Romain Gossé commented on MSHARED-41: - Maybe I should create a separate issue: I Like the classpath + classpath prefix feature, but I'd like it to be a bit flexible. For example, being able to append a custom entry to a generated classpath (it is somehow related tothis request) like the "." folder which can be useful for an executable jar looking for external resources (log4j file, velocity template etc.) Also, being able to limit the dependency transitivity, so that I don't have classpath entries I don't need at runtime...just a thought. > Ability to list Class-Path: elements individually > - > > Key: MSHARED-41 > URL: http://jira.codehaus.org/browse/MSHARED-41 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-archiver > Environment: All >Reporter: Robert Egan >Priority: Minor > > I'd like a method to list my classpath elements in a manner other than in one > long string. For example, one of my production jars contains the following > entry > Class-Path: plugins/framework plugins/checkservices plugins/transferse > rvices plugins/alerts plugins/pr plugins/pr/achapps plugins/pr/wireap > ps securityUtil-hotfix.jar securityUtil.jar wcmCache-hotfix.jar wcmCa > che.jar wcmPrincipals-hotfix.jar wcmPrincipals.jar lib/gnu/gnu-crypt > o.jar lib/oracle/jdbc-10.2.0.1.0/ojdbc14.jar lib/oracle/jdbc-10.2.0.1 > .0/jdbc_rowset_tiger1.0.1mrel-ri/rowset.jar lib/jdom/jdom-1.0/jdom.ja > r lib/emory.edu/backport-util-concurrent-2.2/backport-util-concurrent > .jar lib/apache/jakarta-commons/commons-cli-1.0.jar lib/apache/jakart > a-commons/commons-collections-3.1.jar lib/apache/jakarta-commons/comm > ons-dbcp-1.2.1.jar lib/apache/jakarta-commons/commons-lang-2.1.jar li > b/apache/jakarta-commons/commons-pool-1.2.jar lib/apache/jakarta-comm > ons/commons-logging-1.0.4/commons-logging.jar lib/rsa/authapi.jar lib > /apache/log4j/log4j-1.2.8.jar lib/jradius/jradius.jar lib/jradius/jra > dius-dictionary.jar lib/httpclient/commons-codec-1.3.jar lib/httpclie > nt/commons-httpclient-3.0.jar lib/apache/JCS/jcs-1.2.6.8.jar lib/oswe > go.edu/util-concurrent-1.3.4.jar > And it sure would be nice to have something like > > plugins/framework > plugins/checkservices > plugins/transferservices > ...etc > -- 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: (MASSEMBLY-224) Support Signing assembled jars
[ http://jira.codehaus.org/browse/MASSEMBLY-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176232#action_176232 ] Eric Reboisson commented on MASSEMBLY-224: -- hi all, Is there a forecasted date to resolve this issue ? Thx > Support Signing assembled jars > -- > > Key: MASSEMBLY-224 > URL: http://jira.codehaus.org/browse/MASSEMBLY-224 > Project: Maven 2.x Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-1 >Reporter: Florian Domino >Priority: Minor > Fix For: 2.2 > > > The Configuration Tag does not include the "signing parts" of the jar plugin > you can set alias and storepassword but it is ignored/never called > Fix: delegate the signing configuration tags to the jar plugin -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-261: -- Attachment: MRELEASE-261.patch Attaching MRELEASE-261.patch.. The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin. I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance.. > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176241#action_176241 ] Olivier Lamy commented on MRELEASE-261: --- Any chance you create an it test for that ? > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (SCM-358) maven-scm isn't reporting updated files
[
http://jira.codehaus.org/browse/SCM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176242#action_176242
]
Mark Struberg commented on SCM-358:
---
> and checked into perforce
so I assume this is more likely a maven-scm-provider-perforce issue than a
general maven-scm one?
> maven-scm isn't reporting updated files
>
>
> Key: SCM-358
> URL: http://jira.codehaus.org/browse/SCM-358
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.0-beta-3, 1.0
>Reporter: Spencer White
>
> BuildController does not see changes and therefore does not do a build. Here
> is how I tested:
> 1. cd /project/dir
> 2. find ./ -type f -exec md5sum {} \; > 2.old
> 3. check in changes to perforce from another client
> 4. wait for Continuum to do run it's scheduled task to update code
> 5. Continuum:
> 346298228 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default -
> "Merging SCM results
> 346298254 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - The
> project was not built because no changes were detected in sources since the
> last build.
> 346298255 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - No
> changes, not building
> 6. find ./ -type f -exec md5sum {} \; > 2.new
> 7. diff 2.old 2.new
>
> --begin--
> 28c27
> < d408dc1aab6914b85e3bd2e1ae609368
> ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> ---
> > 79dfa098c212744ffec226a8126bb3f5
> > ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> --end--
> IPhoneyClientProtocolHandler.java was the file that I had changed and checked
> into perforce. I check the file and the changes were updated in Continuum's
> working directory.
> Should I attach the POM.xml?
> Thanks.
--
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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176245#action_176245 ] Maria Odea Ching commented on MRELEASE-261: --- Just unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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] Issue Comment Edited: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176245#action_176245 ] Maria Odea Ching edited comment on MRELEASE-261 at 5/13/09 6:01 AM: I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. was (Author: oching): Just unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (DOXIA-38) Independent row parsing
[
http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-38.
Resolution: Fixed
Really fixed in [r774282|http://svn.apache.org/viewvc?rev=774282&view=rev],
snapshot deployed
> Independent row parsing
> ---
>
> Key: DOXIA-38
> URL: http://jira.codehaus.org/browse/DOXIA-38
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Anuerin Diaz
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 1.1.1
>
>
> Currently the table rendered formats each column depending on the definition
> of the first row. This is a problem when the text justification of the header
> row is different from the rest of the table (e.g. the header row is centered,
> but the rest of the table rows are left-aligned). Take this example fo
> instance:
> {noformat}
> *---*--*
> |<> |<>
> |
> *---+--+
> |generate-sources |generate any source code for inclusion in compilation.
>|
> *---+--+
> |generate-resources |generate resources for inclusion in the package.
>|
> *---+--+
> |compile |compile the source code of the project.
> |
> *---+--+
> |test |run tests using a suitable unit testing framework.
> These tests|
> | |should not require the code be packaged or deployed.
> |
> *---+--+
> |package |take the compiled code and package it in its
> distributable format,|
> | |such as JAR.
> |
> *---+--+
> |install |install the package into the local repository, for use
> as a |
> | |dependency in other projects locally.
> |
> *---+--+
> {noformat}
>
--
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: (SUREFIRE-550) Per-test or test group system properties
Per-test or test group system properties Key: SUREFIRE-550 URL: http://jira.codehaus.org/browse/SUREFIRE-550 Project: Maven Surefire Issue Type: Improvement Components: process forking Affects Versions: 2.4.3 Reporter: benson margulies As a user of surefire, I want to be able to specify different system properties for different tests, so that I don't have to make extra projects just to organize these tests. For example, if I need to run a particular test with -Dfile.encoding set to a non-default value, I currently appear to need to create an entire maven project to contain this. -- 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-3314) offline build not running, when having SNAPSHOT dependencies
[ http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176255#action_176255 ] Josh Brown commented on MNG-3314: - This is not fixed for me in maven 2.0.10. > offline build not running, when having SNAPSHOT dependencies > > > Key: MNG-3314 > URL: http://jira.codehaus.org/browse/MNG-3314 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.7 >Reporter: Matthias Weßendorf >Assignee: John Casey >Priority: Critical > Fix For: 2.0.10, 2.1.0 > > Attachments: maven-offline-snapshot-failure.log, > maven-offline-snapshot-problem.tar, offline-snapshots.patch > > > am having troubles with > mvn ... -o > (with maven 2.0.7) > says not able to download (but, really, the file is in my local repo) > The dependency is a -SNAPSHOT (for what's worth) > Luckily, when traveling by train, I had maven 2.0.4 on my box as well. > A change to use 2.0.4 works fine. > So, is this an already know bug in 2.0.7 ? > To my understanding it is a bug, since offline just shouldn't try to get a > newer > SNAPSHOT, perhaps I am wrong. > I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect > just not checking for new stuff. > and... for some reasons, sometimes, > it just downloads a new SNAPSHOT. > That is a pain, when you are "maintaining" the same snapshot on your > box, but the build just goes ahead and actually downloads a version. -- 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: (DOXIASITETOOLS-20) Add new meta Date-Revision and Date-Creation in the default-site.vm
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-20.
---
Resolution: Fixed
Closing for release.
> Add new meta Date-Revision and Date-Creation in the default-site.vm
> ---
>
> Key: DOXIASITETOOLS-20
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-20
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> Should be nice to add the creation and revision dates in the renderer, i.e.:
> {noformat}
>
>
> {noformat}
--
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: (MJAVADOC-224) CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[ http://jira.codehaus.org/browse/MJAVADOC-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176266#action_176266 ] rt15 commented on MJAVADOC-224: --- Taking exactly the same issue... (Project with multiple modules and a plugin, agregate with javadoc in version 2.5 -> goal already exists) Maybe more info later. > CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin > module > --- > > Key: MJAVADOC-224 > URL: http://jira.codehaus.org/browse/MJAVADOC-224 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Christian Schulte >Priority: Critical > Fix For: 2.4 > > > If your project contains a Maven plugin, then it is impossible to build > aggregated Javadoc. > As the output (attached) shows, Maven seems to recusively build (what's with > all those "skipping" messages?). When it reaches the plugin: > [INFO] Error during page generation > Embedded error: Error rendering Maven report: Error extracting plugin > descriptor: 'Goal: component-report already exists in the plugin descriptor > for prefix: tapestry-component-report > Existing implementation is: org.apache.tapestry.mojo.ComponentReport > Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport' > I can get by this with the -fn (fail never) option. -- 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: (MJAVADOC-224) CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[ http://jira.codehaus.org/browse/MJAVADOC-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176272#action_176272 ] rt15 commented on MJAVADOC-224: --- org.apache.maven.plugins:maven-javadoc-plugin:2.5:aggregate -> error org.apache.maven.plugins:maven-javadoc-plugin:2.2:javadoc -> works fine Other topics on the subject : http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200709.mbox/%3c46e37cce.5080...@apache.org%3e http://jira.codehaus.org/browse/MJAVADOC-145 http://www.nabble.com/%22Goal:-clean-already-exists-in-the-plugin-descriptor-for-prefix:-...%22-td23127658.html > CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin > module > --- > > Key: MJAVADOC-224 > URL: http://jira.codehaus.org/browse/MJAVADOC-224 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Christian Schulte >Priority: Critical > Fix For: 2.4 > > > If your project contains a Maven plugin, then it is impossible to build > aggregated Javadoc. > As the output (attached) shows, Maven seems to recusively build (what's with > all those "skipping" messages?). When it reaches the plugin: > [INFO] Error during page generation > Embedded error: Error rendering Maven report: Error extracting plugin > descriptor: 'Goal: component-report already exists in the plugin descriptor > for prefix: tapestry-component-report > Existing implementation is: org.apache.tapestry.mojo.ComponentReport > Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport' > I can get by this with the -fn (fail never) option. -- 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-109) Credentials ignored when provided in configLocation URL
[ http://jira.codehaus.org/browse/MCHECKSTYLE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176292#action_176292 ] nicolas de loof commented on MCHECKSTYLE-109: - checkstyle plugin uses org.codehaus.plexus.resource.ResourceManager to convert configLocation to a File. > Credentials ignored when provided in configLocation URL > --- > > Key: MCHECKSTYLE-109 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-109 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: maven 2.1.0 >Reporter: Stevo Slavic > > If configLocation URL contains username and password, e.g. > https://username:password/acme.org/checkstyle_checks.xml, those should be > used when obtaining checkstyle configuration xml. Currently, plugin fails to > obtain resource from such URL. -- 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: (MCHECKSTYLE-108) If I use the default maven checkstyle config, I can't use my own license header
[ http://jira.codehaus.org/browse/MCHECKSTYLE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof closed MCHECKSTYLE-108. --- Assignee: nicolas de loof Resolution: Won't Fix Fix Version/s: 2.3 As described in MCHECKSTYLE-48, the maven_checks + LICENSE.txt combination is largelly used by maven for internal use, and to avoid regression we had to force the LICENSTE.txt to point to the default, common maven licence header. Simply changing your Licence file name / location to anything BUT "LICENSE.txt" will fix this. Beeing case sensitive, you could just rename it to "License.txt", or maybe LICENSE without "txt" extension > If I use the default maven checkstyle config, I can't use my own license > header > --- > > Key: MCHECKSTYLE-108 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-108 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Paul Gier >Assignee: nicolas de loof > Fix For: 2.3 > > > I'm working on a plugin that follows the maven code conventions, but uses the > MIT license instead of apache. If I set the configLocation to > "config/maven_checks.xml" then the plugin ignores the LICENSE.txt file that I > put into the root directory of my project even if I set the headerLocation. -- 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: (MCHECKSTYLE-101) Skip should skip everything including the Velocity initialization
[
http://jira.codehaus.org/browse/MCHECKSTYLE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nicolas de loof closed MCHECKSTYLE-101.
---
Assignee: nicolas de loof
Resolution: Won't Fix
Fix Version/s: 2.3
As the Velocity context is created from a plexus @component VelocityComponent,
we cannot check for skip parameter befor it get initialized.
> Skip should skip everything including the Velocity initialization
> -
>
> Key: MCHECKSTYLE-101
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-101
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Steve Gilbert
>Assignee: nicolas de loof
> Fix For: 2.3
>
>
> The "skip" configuration property prevents the check from happening, however,
> Velocity still gets initialized. For a small project, this takes the build
> time from 5 seconds without checkstyle in the pom to 13 seconds with it in
> and skip=true. While 8 seconds does not seem like much, it adds up over the
> course of days and weeks. Note that we have checkstyle hooked in at the
> verify/check phase/goal to cause the build to fail on a checkstyle violation
> during a typical developer's compilation they do all the time.
> Build output with skip=true:
> [INFO] Preparing checkstyle:check
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO] [checkstyle:checkstyle]
> [INFO] [checkstyle:check {execution: default}]
> See also MCHECKSTYLE-71.
--
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: (MCHECKSTYLE-106) Unstable builds
[ http://jira.codehaus.org/browse/MCHECKSTYLE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof closed MCHECKSTYLE-106. --- Resolution: Duplicate > Unstable builds > --- > > Key: MCHECKSTYLE-106 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-106 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Maven 2.0.9, Jdk 1.6.0_04, jdk 1.6.0_10, Linux (Centos4 > and Kubuntu 8.04) >Reporter: Johan Vogelzang > > Set up: > - Multimodule structure (one parent-pom and three submodules, one containing > our checkstyle configuration: smartjava_checks.xml) > - Checkstyle configuration as described in > http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html > - Command: mvn clean install site > The strange thing is that when run the exact same sources with the exact same > build goals multiple times, the build fails for about 50% of the times. When > the build fails it shows: > Embedded error: Error rendering Maven report: Unable to find configuration > file at location smartjava_checks.xml. > I have seen earlier issues about classloading problems related to this error, > but not this unstable behaviour. > Workaround: When you run the Maven command without "install" the build runs > successful. > mvn clean site -- 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: (MWAR-194) Warn when inconsistent jar versions are detected during overlay
Warn when inconsistent jar versions are detected during overlay --- Key: MWAR-194 URL: http://jira.codehaus.org/browse/MWAR-194 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1-beta-1 Reporter: Brad Harper Suggest improving the plugin's overlay behavior by causing it to warn when inconsistent versions of jars are detected. When the base war and the overlay war contain differing versions of a jar file, it's possible to generate a war artifact that contains multiple jars for the same dependency -- but with differing versions. Results using the resulting war artifact are indeterminate and unpredictable. It can be difficult to identify the cause. Conflicts of this nature could be detected while the overlay is being performed. -- 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-101) Skip should skip everything including the Velocity initialization
[
http://jira.codehaus.org/browse/MCHECKSTYLE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176301#action_176301
]
Steve Gilbert commented on MCHECKSTYLE-101:
---
Perhaps not using an annotation can be considered.
> Skip should skip everything including the Velocity initialization
> -
>
> Key: MCHECKSTYLE-101
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-101
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Steve Gilbert
>Assignee: nicolas de loof
> Fix For: 2.3
>
>
> The "skip" configuration property prevents the check from happening, however,
> Velocity still gets initialized. For a small project, this takes the build
> time from 5 seconds without checkstyle in the pom to 13 seconds with it in
> and skip=true. While 8 seconds does not seem like much, it adds up over the
> course of days and weeks. Note that we have checkstyle hooked in at the
> verify/check phase/goal to cause the build to fail on a checkstyle violation
> during a typical developer's compilation they do all the time.
> Build output with skip=true:
> [INFO] Preparing checkstyle:check
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO] [checkstyle:checkstyle]
> [INFO] [checkstyle:check {execution: default}]
> See also MCHECKSTYLE-71.
--
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-101) Skip should skip everything including the Velocity initialization
[
http://jira.codehaus.org/browse/MCHECKSTYLE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176305#action_176305
]
nicolas de loof commented on MCHECKSTYLE-101:
-
we use a shared plexus component that is dependency-injected by plexus
container.
What's wrong with this component beeing initialized ? only some undesirable
logs ?
> Skip should skip everything including the Velocity initialization
> -
>
> Key: MCHECKSTYLE-101
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-101
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Steve Gilbert
>Assignee: nicolas de loof
> Fix For: 2.3
>
>
> The "skip" configuration property prevents the check from happening, however,
> Velocity still gets initialized. For a small project, this takes the build
> time from 5 seconds without checkstyle in the pom to 13 seconds with it in
> and skip=true. While 8 seconds does not seem like much, it adds up over the
> course of days and weeks. Note that we have checkstyle hooked in at the
> verify/check phase/goal to cause the build to fail on a checkstyle violation
> during a typical developer's compilation they do all the time.
> Build output with skip=true:
> [INFO] Preparing checkstyle:check
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO] [checkstyle:checkstyle]
> [INFO] [checkstyle:check {execution: default}]
> See also MCHECKSTYLE-71.
--
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-101) Skip should skip everything including the Velocity initialization
[
http://jira.codehaus.org/browse/MCHECKSTYLE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176306#action_176306
]
Steve Gilbert commented on MCHECKSTYLE-101:
---
The logs are not the problem. It's time. The point of skipping checkstyle is
to save individual developer build time. When Velocity initializes, it takes a
lot of time, as much time as it does for checkstyle to do the checking. In our
environment we have checkstyle hooked into the install goal so the time lost
accumulates over many iterations and is significant.
> Skip should skip everything including the Velocity initialization
> -
>
> Key: MCHECKSTYLE-101
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-101
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Steve Gilbert
>Assignee: nicolas de loof
> Fix For: 2.3
>
>
> The "skip" configuration property prevents the check from happening, however,
> Velocity still gets initialized. For a small project, this takes the build
> time from 5 seconds without checkstyle in the pom to 13 seconds with it in
> and skip=true. While 8 seconds does not seem like much, it adds up over the
> course of days and weeks. Note that we have checkstyle hooked in at the
> verify/check phase/goal to cause the build to fail on a checkstyle violation
> during a typical developer's compilation they do all the time.
> Build output with skip=true:
> [INFO] Preparing checkstyle:check
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO] [checkstyle:checkstyle]
> [INFO] [checkstyle:check {execution: default}]
> See also MCHECKSTYLE-71.
--
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-2562) expose current time as a property for POM interpolation
[
http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176331#action_176331
]
Wendy Smoak commented on MNG-2562:
--
A user asked about this on irc:
benson0: I'm lost in the maze of MNG-3718. Can someone just tell me the ${} to
access a readable build date in 2.1.0? None of the syntaxes mentioned in the
jiras seem to be right.
jason: ${build.timestamp}
I can't find it anywhere in the site, however grep does turn up a mention in
maven-project-spec.tex as well as the code/tests.
> expose current time as a property for POM interpolation
> ---
>
> Key: MNG-2562
> URL: http://jira.codehaus.org/browse/MNG-2562
> Project: Maven 2
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> it is useful to have the current time, for example to write out a manifest
> entry for the build time or to filter into another file.
> I'm not sure of the best way to make the format of the time configurable -
> perhaps another POM element/property.
> See the related issue for a current example of how this can be done, but it
> would be nice to have a built-in.
--
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: (MNGSITE-87) Document the build timestamp feature
Document the build timestamp feature
Key: MNGSITE-87
URL: http://jira.codehaus.org/browse/MNGSITE-87
Project: Maven 2 Project Web Site
Issue Type: Task
Reporter: Wendy Smoak
The new ${build.timestamp} feature does not appear to be documented
See http://jira.codehaus.org/browse/MNG-2562 and the maze of linked issues...
--
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-562) Configuration of additional source folders
Configuration of additional source folders
--
Key: MECLIPSE-562
URL: http://jira.codehaus.org/browse/MECLIPSE-562
Project: Maven 2.x Eclipse Plugin
Issue Type: Wish
Components: M2Eclipse support
Affects Versions: 2.6
Environment: M2 2.0.10
Reporter: Bruno Marti
Priority: Minor
I need to define some additional source folders in classpath (.classpath) like
Please, could you add an additional parameter to the m2eclipse goal, or perhaps
in plugins general configuration:
${project.build.directory}/generated-sources/mySources
--
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
