[jira] Created: (MNG-940) assembly:unpack should support more archive types
assembly:unpack should support more archive types -- Key: MNG-940 URL: http://jira.codehaus.org/browse/MNG-940 Project: Maven 2 Type: New Feature Components: maven-assembly-plugin Reporter: Michal Maczka assembly:unpack should support more types of archives. In particular I need to assembly zips and wars togethter. Other feature which is missing (should I add another issue for this) is a possiblility of deciding per artifact basis where given archive should be unpacked. Implementation hint: I don't think that it is really necessery to make any distiniction between jars, zips wars, ears etc. They can be all threted as zips. So implementation can be in fact simplified and support for more type added very easly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-691) Ability to assign a report to choosen navigation menu
Ability to assign a report to choosen navigation menu -- Key: MNG-691 URL: http://jira.codehaus.org/browse/MNG-691 Project: Maven 2 Type: Wish Reporter: Michal Maczka It will be nice to have a possibiliy of deciding per report basis where (in which menu) given report will appear in the left side navigation instead of putting all reports into one bag (reports menu). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-521) Version inheritance from the parent pom
[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42869 ] Michal Maczka commented on MNG-521: --- If I can add my two cents: It is not really required "to have single place that will have global version number, which then used for submodules." I belive that the correctly stated requirment should be: It's important that common version number for multiple modules can be easily changed. And the strategy of having the version in a single place is just the one of the implementation of that requirement which can exist. What if there were gui tool or maven plugin which will do the job for you? say you will do something like: m2 project:upgrade-version -Dversion=1.2 and maven will recursively upgrade the current version and parent's version in multiple POMs. Wouldn't it be simple enough? > Version inheritance from the parent pom > --- > > Key: MNG-521 > URL: http://jira.codehaus.org/browse/MNG-521 > Project: Maven 2 > Type: Improvement > Components: design > Reporter: Eugene Kuleshov > Assignee: John Casey > Fix For: 2.0-beta-1 > > > Currently m2 pom require to have explicit version of the parent pom in all > submodules. This should work fine for "standalone" artifacts. However there > is different type of projects (e.g. EAR) that is usually stored in version > control as a whole thing and may contain multiple modules (ejb jars, rar, > war, etc) that are build with the same version as entire EAR. So, EAR > application released with a single global version for all submodules. In m1 > this was possible to specify relative path to parent pom and use version > substitution in child modules and deployer goal was substituting values for > version numbers upon deployment. > For this kind of modules it is very important to have single palce that will > have global version number, which then used for submodules. It is also make > sense to kee optional relative path (that can be also removed/replaced with > concrete parent id/version upon deployment) to support local build. I believe > this is very important for J2EE builds as well as any other projects that are > releasing multiple artifacts/jars under the same version (e.g. ASM, XDoclet). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-415) allow exclusion of certain dependencies from inclusion in an archive
[ http://jira.codehaus.org/browse/MNG-415?page=comments#action_39285 ] Michal Maczka commented on MNG-415: --- I understood how the scopes work and that why I am proposing is to change it as this seems to be the simplest solution for this problem. Really what you want to bundle in wars, ears and such artifacts are only runtime dependecies. servletapi is compile time only dependency but __it is not__ a runtime dependecy so it should not be bundled in wars. This seems to be natural for me and apparently for some other people. Look at the subject of the thread: "how to exclude compile time only jars from .war?" > allow exclusion of certain dependencies from inclusion in an archive > > > Key: MNG-415 > URL: http://jira.codehaus.org/browse/MNG-415 > Project: m2 > Type: Improvement > Components: maven-plugins, maven-archiver > Versions: 2.0-alpha-2 > Reporter: Brett Porter > Fix For: 2.0-alpha-3 > > > this has been requested for WAR, but it should apply to all archives that > include dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-415) allow exclusion of certain dependencies from inclusion in an archive
[ http://jira.codehaus.org/browse/MNG-415?page=comments#action_39283 ] Michal Maczka commented on MNG-415: --- EAR is a different case then WAR as not only you must decide what will be included in the archive but also attach some information to some dependencies (e.g. context roots for wars) The decison of what gets included and what not can be based on artifact's type and scope. For wars in particular only all runtime dependecies should be included and nothing else (compile and test dependecies should be skipped). So one of the possible solutons would be to enable to enumerate dependency scopes rather then assume that all compile time dependecies are also runtime dependecies. To give an example runtime (will be included in the war) runtime (will be included in the war) compile compile (will not be included in the war) test (will not be included in the war) This approch seems to be the most natural and simple one and covers in a generic way all the cases I can think of. Note the artifact scope given at the top level affects also dependencies of dependencies. > allow exclusion of certain dependencies from inclusion in an archive > > > Key: MNG-415 > URL: http://jira.codehaus.org/browse/MNG-415 > Project: m2 > Type: Improvement > Components: maven-plugins, maven-archiver > Versions: 2.0-alpha-2 > Reporter: Brett Porter > Fix For: 2.0-alpha-3 > > > this has been requested for WAR, but it should apply to all archives that > include dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-271) exported pom.xml should contain full pom information
[ http://jira.codehaus.org/browse/MNG-271?page=comments#action_31727 ] Michal Maczka commented on MNG-271: --- I also think that this is a way to go. Say we have parent project P1 and child project P2. There are two possible sources of errors here: a) P2 pom is deployed to repository and P1 pom is missing there (from my experience this happens very often). b) P1 and P2 are both in the snapshot state. P1 and P2 poms are deployed to repository, then P1 pom is changed (e.g. some dependencies are upgraded) and then re-deployed to the repository. After that operation P2 pom in the repository will be also indirectly changed. It is questionable if this is a desired thing. Taking into the consideration the fact that we have multilevel inheritance it can easily lead to the problems which are difficult to detect and it can break builds which would work if "expanded" poms were deployed to the repository. Other reasons why this is a good idea: - It should be easy to write a tool which reuses m2 repository metadata. Project inheritance in m2 is very complex and is mostly irrelevant for such tools. So this will help to widespread the acceptance of poms as the artifact repository metadata. - Process of resolving transitive dependencies should be fast. So it would be better if less operations for building "full poms" were needed. This can be addressed in m2 in a different way (e.g. local database of POMs can be build) but again such thing for efficiency must be reimplemented by any other tools. > exported pom.xml should contain full pom information > > > Key: MNG-271 > URL: http://jira.codehaus.org/browse/MNG-271 > Project: m2 > Type: Wish > Versions: 2.0-alpha-1 > Reporter: Vincent Massol > > > When you install a module in the local repo the pom.xml file is copied (it's > also included in jars). That's very good. However if my project is a module > (i.e it depends on some parent(s)), the pom.xml that is dumped only contains > partial information (it does not contain inherited information). > Thus it can be used standalone and does not offer all the information there > is about the module. > As the pom is fully constructed in memory, it would be nice to dump it from > memory instead of copying the pom.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
