[jira] Commented: (MSITE-577) generateReports still copies css and images folders
[ http://jira.codehaus.org/browse/MSITE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262346#action_262346 ] Lukas Theussl commented on MSITE-577: - You should run the site:deploy goal instead of the site-deploy phase then, see [Deploying a Site|http://maven.apache.org/plugins/maven-site-plugin/usage.html]. > generateReports still copies css and images folders > --- > > Key: MSITE-577 > URL: http://jira.codehaus.org/browse/MSITE-577 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-3 >Reporter: Aristedes Maniatis > > With this config: > > false > > all the reports are stopped, but the css and images folders are still copied. > These should not be copied over since there is no html for which they are > relevant. Not having these folders in place is very useful if we are using > the site phase for documentation generated by other means (and we still want > to take advantage of things like the site-deploy). -- 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: (MSITE-577) generateReports still copies css and images folders
[ http://jira.codehaus.org/browse/MSITE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262347#action_262347 ] Aristedes Maniatis commented on MSITE-577: -- Sure (and I don't want to turn this bug tracker into a maven support forum). But I'm using site:site as the convenient goal for hooking in the docbook generation plugin (and other resource generation stuff I have). Ideally I'd extend the maven goals by adding in site:docbook, but I don't believe it is possible to add goals in this way without hacking at the core of maven. I guess there are other ways to solve this problem, and for now I've added in an ant plugin to delete the images/css files added by maven-site. But this isn't very robust since those files are liable to change with an upgrade of maven-site. Let me phrase this bug report in a different way. If you don't want to use the default skin. Can you make the default images/css go away? I can see ways to override the files one by one. But that's not what I had in mind. > generateReports still copies css and images folders > --- > > Key: MSITE-577 > URL: http://jira.codehaus.org/browse/MSITE-577 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-3 >Reporter: Aristedes Maniatis > > With this config: > > false > > all the reports are stopped, but the css and images folders are still copied. > These should not be copied over since there is no html for which they are > relevant. Not having these folders in place is very useful if we are using > the site phase for documentation generated by other means (and we still want > to take advantage of things like the site-deploy). -- 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: (MSITE-577) generateReports still copies css and images folders
[ http://jira.codehaus.org/browse/MSITE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262359#action_262359 ] Lukas Theussl commented on MSITE-577: - What about using a trivial custom skin without any css or images? In any case, I don't quite understand what you are doing, it sounds like you shouldn't rely on the site plugin at all since you are using your own 'docbook generation plugin', and you shouldn't have to hack maven core either. Also I don't see why this is actually a problem apart from copying unused resources. If your custom plugin uses the same resources you have to override them anyway and if they are not used, they don't get in your way, so why bother? > generateReports still copies css and images folders > --- > > Key: MSITE-577 > URL: http://jira.codehaus.org/browse/MSITE-577 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-3 >Reporter: Aristedes Maniatis > > With this config: > > false > > all the reports are stopped, but the css and images folders are still copied. > These should not be copied over since there is no html for which they are > relevant. Not having these folders in place is very useful if we are using > the site phase for documentation generated by other means (and we still want > to take advantage of things like the site-deploy). -- 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: (MEAR-137) Support for JEE Application Clients
[ http://jira.codehaus.org/browse/MEAR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-137. Resolution: Fixed Added ITs and documentation. Also fixed a bug where the defaultBundleDir was affecting the location of the artifact. > Support for JEE Application Clients > --- > > Key: MEAR-137 > URL: http://jira.codehaus.org/browse/MEAR-137 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature > Environment: any >Reporter: Pablo Rodriguez >Assignee: Stephane Nicoll > Fix For: 2.6 > > Attachments: maven-ear-plugin > > > Currently the maven ear plugin only supports JEE application clients by > defining them as jarmodules with true. This > is a bit to hacky as Applicaiton client modules are first class EAR citizens > as ejb, war and rar modules. > The patch provided here is half of my attempt to upgrade this application > client modules to be maven ear first citizens. > I have created a maven-car-plugin defining a packaging type 'car' (in same > manner as war, ejb or rar). > http://code.google.com/p/maven-car-plugin/ > The patch provided here, adds support to maven-ear-plugin to recognize the > 'car' packaging type, include the artifact in the root of the ear and adds > the corresponding entry to application.xml > Note that i would like this to be temporary and would prefer to see the car > packaging type, the maven-car-plugin be core maven plugins with gorupid > org.maven.plugins as there is no reason for application clients not having > same support as war, ejb or rar modules. > I feel this extra module, packaging type and plugin are needed as confusion > has been arising around application clients > http://jira.codehaus.org/browse/MEAR-46 > http://jira.codehaus.org/browse/MEAR-40 > Pablo -- 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: (MEAR-40) Autodetect "Client Application" modules and "EJB3" modules.
[ http://jira.codehaus.org/browse/MEAR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-40. --- Resolution: Duplicate Fixed with MEAR-137 > Autodetect "Client Application" modules and "EJB3" modules. > --- > > Key: MEAR-40 > URL: http://jira.codehaus.org/browse/MEAR-40 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Markus KARG >Assignee: Stephane Nicoll > Fix For: 2.6 > > > The J2EE 1.4 specification know the modules type "EJB", "WEB", "RAR" and > "Client Application". > The EAR plugin currently supports the autodetection of "EJB", "WEB" and "RAR". > As a result, the EAR plugin automatically creates an application.xml file > containing entries using the corresponding type, without the need to > add entries to the pom. > Unfortunately this is not working with "Client Application" modules and > "EJB3" modules. > To have a client module's corresponding tag get added to the > application.xml file, the developer has to add it to the pom.xml manually, > what is not nice. Actually it would be easy for the EAR plugin to do that > automatically: It just needs to check whether each of the dependencies named > in the pom.xml file has a ".jar" extension AND contains a file called > "/META-INF/client-application.xml" (check J2EE 1.4 specification chapter 9 on > details). If such a file is found, the dependency is a "Client Application" > and in turn the EAR plugin has to add a "" tag to the application.xml > file. > Also, the support of "EJB3" modules is not working, since they do not > necessarily have a "/META-INF/ejb-jar.xml" file contained, which would be > needed to discriminate "utility JARs" from "EJB3 JARs" (as the distinction of > "utility JARs" from "Client Application JARs" can be done as described above > using the existence of the "/META-INF/client-application.xml" file). > Nevertheless, there should be a means of automatic detection of EJB3 modules > for automatic generation of entries in application.xml. A possible > way to solve that could be to analyze the content of each file with a .jar > extension: As soon as at least one class is contained that is annotated as > @Stateful, @Stateless, @Entity or @MessageDriven, or as soon as a file named > "/META-INF/ejb-jar.xml" is found in the jar, the definitively is an EJB > module and in turn the EAR module has to add a tag to the > application.xml file. Actually this will slow down detection of module types, > but on the other hand the user decided to use the automation instead of > manually adding entries, so he will accept the performance penalty. -- 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: (MEAR-120) does not work in multi module project
[
http://jira.codehaus.org/browse/MEAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-120.
Resolution: Cannot Reproduce
No response from user
> does not work in multi module project
> -
>
> Key: MEAR-120
> URL: http://jira.codehaus.org/browse/MEAR-120
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: OS name: "linux" version: "2.6.5-7.244-smp" arch: "i386"
> Family: "unix"
>Reporter: Deepak Chavan
>
> I have given finalName for my projects but it is not working for some
> modules. Following tag has been added in root pom.xml of my project:
> so-${pom.artifactId}-${pom.version}
> .
> .
> .
> According to this it should append prefix "so-" for all modules but it is not
> working as expected.
> maven-ear-plugin version : 2.3.1
> maven : maven 2.0.8
> Thanks,
> Deepak
--
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: (MEAR-65) Support MAR archives
[ http://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262374#action_262374 ] Stephane Nicoll commented on MEAR-65: - How is this bundled? I guess that .mar is not detected as a standard jar file so you should place it somewhere special where Axis can discover it right? Can you confirm this is still a valid use case? This seems to be quite old and I see more refs on 'aar' than 'mar' actually. > Support MAR archives > > > Key: MEAR-65 > URL: http://jira.codehaus.org/browse/MEAR-65 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Stephane Nicoll >Priority: Trivial > Fix For: 2.6 > > > Add support for adding MARs to the archive (mar), like the axis2 > addressing module @: > http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/ -- 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: (MEAR-48) Remove resourceDir deprecated feature
[ http://jira.codehaus.org/browse/MEAR-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-48: Fix Version/s: (was: 2.6) 2.7 > Remove resourceDir deprecated feature > - > > Key: MEAR-48 > URL: http://jira.codehaus.org/browse/MEAR-48 > Project: Maven 2.x Ear Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Stephane Nicoll >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.7 > > > resourceDir is deprecated for a while now so it should be removed. -- 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: (MEAR-65) Support MAR archives
[ http://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-65: Fix Version/s: (was: 2.6) 2.7 > Support MAR archives > > > Key: MEAR-65 > URL: http://jira.codehaus.org/browse/MEAR-65 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Stephane Nicoll >Priority: Trivial > Fix For: 2.7 > > > Add support for adding MARs to the archive (mar), like the axis2 > addressing module @: > http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/ -- 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: (MEAR-113) The default contextRoot should match the default bundleFileName
[ http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-113: - Fix Version/s: (was: 2.6) 2.7 > The default contextRoot should match the default bundleFileName > --- > > Key: MEAR-113 > URL: http://jira.codehaus.org/browse/MEAR-113 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Michael Semb Wever > Fix For: 2.7 > > Attachments: MEAR-113.patch, MEAR-113.patch > > > In a webModule the contextRoot defaults to > "/" + a.getArtifactId() > There is no way AFAIK to have a contextRoot that honours the webModule > artifact's finalName, necessary if it was dynamically set via profiles. > (The only way i see here is to duplicate all the profile information and put > the maven-ear-plugin configuration into each profile, just to insert the > various contextRoot values). > By making the contextRoot instead default to > "/" + getBundleFileName() > this scenario is solved. > The webModule's contextRoot defaults to the build name of the artifact if it > were customised. If that artifact's finalName was not customised then it > defaults back to the artifactId therefore maintaining today's behavior and > not breaking any compatibility. > Patch attached. -- 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: (MEAR-71) please support outputFilename here, same as in war plugin
[ http://jira.codehaus.org/browse/MEAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-71: Fix Version/s: (was: 2.6) 2.7 > please support outputFilename here, same as in war plugin > - > > Key: MEAR-71 > URL: http://jira.codehaus.org/browse/MEAR-71 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Reporter: Joakim Verona >Assignee: Stephane Nicoll > Fix For: 2.7 > > -- 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: (MEAR-87) Allow exclusion of artifacts when building the ear file.
[ http://jira.codehaus.org/browse/MEAR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-87: Fix Version/s: (was: 2.6) 2.7 > Allow exclusion of artifacts when building the ear file. > > > Key: MEAR-87 > URL: http://jira.codehaus.org/browse/MEAR-87 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.3.1 >Reporter: Dieter Houthooft >Priority: Minor > Fix For: 2.7 > > Attachments: maven-ear-plugin-excludes-fixed.patch, > maven-ear-plugin-excludes.patch > > > What is included in the .ear file is determined by the module list and the > dependency list and its transitive dependencies. We are often confronted with > changing demands about what to include in our ear files. It is quite hard to > change our dependency management (scopes) every time without side-effects on > other distributable artifacts. So I created an exclude configuration option > which allows to exclude artifacts from the ear file based on regular > expressions (java.util.regex) matching artifactIds and groupIds. > Use it like this: > > > > be.nondistributable.* > > > -- 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: (MRELEASE-671) release tag for maven-release-2.1 does not have src to match released jar
release tag for maven-release-2.1 does not have src to match released jar - Key: MRELEASE-671 URL: http://jira.codehaus.org/browse/MRELEASE-671 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: any Reporter: Simon Massey If you checkout the maven-release-2.1 code as per anon access svn url on the project page here: http://maven.apache.org/plugins/maven-release-plugin/source-repository.html Then the code does not compile as it is missing source. If you take a look at this folder: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.1/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ it does not contain ReleaseDescriptor.java yet that class is included in the maven-release-manager-2.1-sources.jar and maven-release-manager-2.1.jar on central and is required to compile the projects as checked out from that 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: (MRELEASE-671) release tag for maven-release-2.1 does not have src to match released jar
[ http://jira.codehaus.org/browse/MRELEASE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRELEASE-671. - Resolution: Not A Bug Assignee: Brett Porter that source file is generated at build time. I presume by "doesn't compile", you mean that you opened it in an IDE that doesn't recognise the Maven project, so the generate sources phase has not been executed? > release tag for maven-release-2.1 does not have src to match released jar > - > > Key: MRELEASE-671 > URL: http://jira.codehaus.org/browse/MRELEASE-671 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: any >Reporter: Simon Massey >Assignee: Brett Porter > > If you checkout the maven-release-2.1 code as per anon access svn url on the > project page here: > http://maven.apache.org/plugins/maven-release-plugin/source-repository.html > Then the code does not compile as it is missing source. If you take a look at > this folder: > http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.1/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ > it does not contain ReleaseDescriptor.java yet that class is included in the > maven-release-manager-2.1-sources.jar and maven-release-manager-2.1.jar on > central and is required to compile the projects as checked out from that 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
