[jira] Created: (MAVENUPLOAD-1792) 4.1 Release of Dozer
4.1 Release of Dozer Key: MAVENUPLOAD-1792 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1792 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke Attachments: dozer-4.1-bundle.jar I have attached the bundle to this Jira Request. The source can be found at: http://sourceforge.net/project/showfiles.php?group_id=133517 -- 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-1443) Dozer Maven Upload Request
Dozer Maven Upload Request -- Key: MAVENUPLOAD-1443 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1443 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke http://dozer.sourceforge.net/dozer-3.1-bundle.jar http://dozer.sourceforge.net http://dozer.sourceforge.net/team-list.html Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types. -- 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-1443) Dozer Maven Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91081 ] Franz Garsombke commented on MAVENUPLOAD-1443: -- The problem is that we use some Sun jars for unit testing...(JAXB and javax jars). The only *official* repository I could find Sun jars on was: https://maven-repository.dev.java.net/ How can I work around this? Thanks, Franz > Dozer Maven Upload Request > -- > > Key: MAVENUPLOAD-1443 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1443 > Project: maven-upload-requests > Issue Type: Task >Reporter: Franz Garsombke > > http://dozer.sourceforge.net/dozer-3.1-bundle.jar > http://dozer.sourceforge.net > http://dozer.sourceforge.net/team-list.html > Dozer is a powerful, yet simple Java Bean to Java Bean mapper that > recursively copies data from one object to another. Typically, these Java > Beans will be of different complex types. -- 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-1512) Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another
Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another - Key: MAVENUPLOAD-1512 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1512 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke Attachments: dozer-3.3.1-bundle.jar Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types. Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level. Dozer not only supports mapping between attribute names, but also converting between types. Many conversion scenarios are supported out of the box, but Dozer also allows you to specify custom conversions via XML. The mapper is used any time you need to take one type of Java Bean and map it to another type of Java Bean. Most field mapping can be done automatically by Dozer using reflection, but any custom mapping can be predescribed in XML format. Mapping is bi-directional so only one relationship between classes needs defining. If any property names on both objects are the same you do not even need to do any explicit property mapping for these fields. -- 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-1622) Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another
Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another - Key: MAVENUPLOAD-1622 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1622 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke Attachments: dozer-3.4-bundle.jar Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types. Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level. Dozer not only supports mapping between attribute names, but also converting between types. Many conversion scenarios are supported out of the box, but Dozer also allows you to specify custom conversions via XML. The mapper is used any time you need to take one type of Java Bean and map it to another type of Java Bean. Most field mapping can be done automatically by Dozer using reflection, but any custom mapping can be predescribed in XML format. Mapping is bi-directional so only one relationship between classes needs defining. If any property names on both objects are the same you do not even need to do any explicit property mapping for these fields. -- 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-2363) does not work in a multi-project build
[ http://jira.codehaus.org/browse/MNG-2363?page=comments#action_83059 ]
Franz Garsombke commented on MNG-2363:
--
Same problem. I have a predefined ant plugin (in pluginmanagement) at the
aggregator level. I do not want all of the sub modules to inherit this ant
plugin since some of the sub modules need to define their own executions for
the ant plugin. Creating profiles at the aggregator level and then inheriting a
profile seemed like the right approach. The activation does not allow me
to work at the submodule level.
Thanks,
Franz
> does not work in a multi-project build
> ---
>
> Key: MNG-2363
> URL: http://jira.codehaus.org/browse/MNG-2363
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Reporter: David Boden
>Priority: Critical
> Fix For: 2.1
>
> Attachments: problemactivation.zip, screenshot-1.jpg
>
>
> I would expect each subproject to have the profile turned on or off depending
> on whether ${basedir}/file-to-check-for exists.
> Instead, during a multi-project build the profile is either on or off
> depending on whether the file exists relative to the *aggregator pom*. The
> decision is made once.
> Variable substitution doesn't work, so I can't explicitly use
> ${basedir}/file-to-check-for or any variation on this theme
> to workaround the bug.
> Some background to my particular problem. I have 10 modules to build. Some of
> them are GUI modules and contain a file called plugin.xml in the subproject
> directory. I want to package these up specially and sign them, ready for
> deployment to webstart. The other modules are shared and server code and I
> don't want these packaged in the same way. So, I've got a dependency in my
> *parent* pom file which activates a profile called "guibundle" if a
> plugin.xml file exists in the subproject directory.
--
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-91) Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging.
Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging. --- Key: MWAR-91 URL: http://jira.codehaus.org/browse/MWAR-91 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Mac OSX. Maven 2.0.4 Reporter: Franz Garsombke I have a dependency defined below: com.foo.ejb.server slm-ejb-server test-jar compile I would expect it in the WEB-INF/lib directory at time of packaging. Interestingly enough its transitive dependencies show up but not the actual test jar. The reason we need it in the WAR is for Cactus tests. I agree Cactus is evil but can not remove it in the short term. -- 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: (MASSEMBLY-183) assembly:attached does not work with filter- ERROR: Cannot override read-only parameter
assembly:attached does not work with filter- ERROR: Cannot override read-only parameter --- Key: MASSEMBLY-183 URL: http://jira.codehaus.org/browse/MASSEMBLY-183 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Maven 2.0.4 - Mac OSx - JDK 1.5 Reporter: Franz Garsombke Priority: Minor Filtering does not work when you use the attached goal on the assembly plugin. When you add a filters tag to the configuration and run assembly:attached the following error is generated: ERROR: Cannot override read-only parameter Sample configuration: maven-assembly-plugin src/assemble/dev.properties src/assemble/distribution.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: (MNG-2841) Ability to change plugins to 'aggregator' style on the fly
Ability to change plugins to 'aggregator' style on the fly -- Key: MNG-2841 URL: http://jira.codehaus.org/browse/MNG-2841 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.5 Environment: N/A Reporter: Franz Garsombke Priority: Minor We use a parent POM and sub-module POMs pretty heavily. It would be nice to be able to execute a plugin in the parent without having it execute in the children. Also, I do not want to create a profile for this feature. The only way I have seen to get around this problem is creating plugins as aggregator style. The plugin then only runs once at the parent level. I would like to have this feature available to all plugins. Thanks for your time. Franz -- 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
