[jira] Commented: (DOXIA-59) Doxia creates files with inconsistent new lines
[ http://jira.codehaus.org/browse/DOXIA-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105129 ] Vincent Siveton commented on DOXIA-59: -- Lukas created a standard testing parser (DOXIA-101). Actually, we need to add unix style line.separator as system property to be able to run correctly tests on windows (r567231). > Doxia creates files with inconsistent new lines > --- > > Key: DOXIA-59 > URL: http://jira.codehaus.org/browse/DOXIA-59 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Carlos Sanchez > Fix For: 1.0 > > Attachments: DOXIA-59-nramirez.patch > > > It uses \n instead of System.getProperty( line.separator ); -- 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-131) HtmlTools.encodeId makes id lower case
[ http://jira.codehaus.org/browse/DOXIA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed DOXIA-131. - Resolution: Fixed > HtmlTools.encodeId makes id lower case > -- > > Key: DOXIA-131 > URL: http://jira.codehaus.org/browse/DOXIA-131 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl >Assignee: Dennis Lundberg > Fix For: 1.0-alpha-9 > > > HtmlTools.encodeId uses Character.toLowerCase to convert its argument to > lower case. I don't see the reason for that since upper case characters are > legal in id's (see http://www.w3.org/TR/html4/types.html#type-name ). In > particular, it's a problem with anchors/links in the xhtml sink (see DOXIA-47 > ), especially if we want to create anchors from section names, to maintain > backward compatibility with m1. Is there a special reason for the toLowerCase > or can we remove it? -- 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: (MIDEA-104) web.iml file generated correctly on Windows but not on Linux
[ http://jira.codehaus.org/browse/MIDEA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105103 ] Anthony Yeracaris commented on MIDEA-104: - The attachments were uploaded in the opposite order. Attachment 1 is "good", attachment 2 is "bad". > web.iml file generated correctly on Windows but not on Linux > > > Key: MIDEA-104 > URL: http://jira.codehaus.org/browse/MIDEA-104 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Both platforms: > java version 1.5.0_12 > Maven version 2.0.6 > IntelliJ version 6.0.5 (build 6180) >Reporter: Anthony Yeracaris > Attachments: web.iml, web.iml > > > In the failing case, in the web module settings of IntelliJ, modules are > listed as being packaged by path name (from the .m2 directory tree) instead > of by library (the library references are present but are all listed as "Do > not package"). > In the working case, no path names are mentioned, and the library references > are copied. > Some analysis has determined the following: > In the working iml, a containerElement with a name attribute is generated. In > the failing iml, the same containerElement is generated, but without a name > attribute. > The attachments are , . -- 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: (MIDEA-104) web.iml file generated correctly on Windows but not on Linux
web.iml file generated correctly on Windows but not on Linux Key: MIDEA-104 URL: http://jira.codehaus.org/browse/MIDEA-104 Project: Maven 2.x IDEA Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Both platforms: java version 1.5.0_12 Maven version 2.0.6 IntelliJ version 6.0.5 (build 6180) Reporter: Anthony Yeracaris Attachments: web.iml, web.iml In the failing case, in the web module settings of IntelliJ, modules are listed as being packaged by path name (from the .m2 directory tree) instead of by library (the library references are present but are all listed as "Do not package"). In the working case, no path names are mentioned, and the library references are copied. Some analysis has determined the following: In the working iml, a containerElement with a name attribute is generated. In the failing iml, the same containerElement is generated, but without a name attribute. The attachments are , . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-293) javaee-api artifact version issue (EE5)
[ http://jira.codehaus.org/browse/MECLIPSE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105101 ] Ernst Lindoorn commented on MECLIPSE-293: - What is the reasoning behind looking through the project dependencies for specifically named artifacts, to resolve versions of java ee / ejb and such? Wouldn't it be preferable to have versions definable/overridable in the pom? i.e. There is no documentation on which dependencies are necessary to get i.e. a jsf.ejb version 3; It turns out you need either an artifact named ejb, geronimo-spec-ejb or geronimo-ejb_3.0_spec with the proper version or if none of those exist you see if javaee-api, j2ee or geronimo-spec-j2ee is version 5.0. The above mechanism doesn't seem very robust. You noticed that the version of javaee-api is 5 instead of 5.0, what happens if someone releases 5.1? Or when a user creates a conflicting artifact? Ernst > javaee-api artifact version issue (EE5) > --- > > Key: MECLIPSE-293 > URL: http://jira.codehaus.org/browse/MECLIPSE-293 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.4 >Reporter: Thierry Levieux >Assignee: Arnaud Heritier > > The javaee-api artifact version is 5 (See > http://weblogs.java.net/blog/ludo/archive/2007/01/java_ee_5_apis.html), > whereas eclipse/wtp and maven eclipse only recognizes 5.0 as a valid version. > I think the pom version is not consistent (for instance, glassfish V3 build > project uses 5.0 as artifact version), > but WE NEED a way/workaround to resolve correctly that library version. > I plan to contact Ludovic Champenois (project-owner) and check if he's > confortable with the javaee-api version... > Thanks > Thierry -- 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-230) not filtering resources, but does filter
not filtering resources, but does filter
--
Key: MASSEMBLY-230
URL: http://jira.codehaus.org/browse/MASSEMBLY-230
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Environment: Windows XP Maven 2.0.5
Reporter: Mick Knutson
In my assembly descriptor, this does not filter my resources:
${basedir}/src/main/resources/deploy
true
true
/
*.sh
*.bat
0544
But this DOES filter the same resources just fine:
${basedir}/src/main/resources/deploy/deploy.sh.txt
deploy
test.sh
true
unix
0554
I have tried 2.2-beta-1 and 2.1 of the plugin and it acts the same way.
A workaround is to just specify each file individually, but I have dozens of
files and the descriptor is going to get quite cluttered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out
[ http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105100 ] Teodoro Cue Jr. commented on CONTINUUM-1387: That's what I've tried to do. Just put it in the build queue even if isInCheckoutQueue returns true. But the build process would build the project anyway. Source downloaded or not. This is the reason why I discovered that the build process would download the project if the working directory does not exist. With this, would it be better to make another queue? If isInCheckoutQueue returns true, put the project in the new queue instead of the build queue. The new queue would implement an observer pattern listening to the checkout queue. When a project has been checkout completely, trigger the build by calling DefaultContinuum.buildProject(). > Can't initiate a build of a new project in continuum until all modules have > been checked out > > > Key: CONTINUUM-1387 > URL: http://jira.codehaus.org/browse/CONTINUUM-1387 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Wendy Smoak > > When a multi-module project is added to continuum, a working copy of each > module is extracted from subversion. > Typically after adding a project I want to kick off a build. > If I initiate the build before all the modules are extracted, the ones that > have not yet been fully extracted will not be queued for build. Only those > already fully extracted will be built. -- 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: (MWAR-89) filtering ${something.url} ignores my property value and writes http://maven.apache.org/something
[
http://jira.codehaus.org/browse/MWAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105095
]
Marat Radchenko commented on MWAR-89:
-
I've encountered this error too. It is easy to workaround but very annoying :(
To reproduce:
mvn archetype:create -DgroupId=sample.group.id -DartifactId=sample-artifact-id
-DarchetypeArtifactId=maven-archetype-webapp && cd sample-artifact-id && echo
'test=${test.url}' > src/main/resources/test.properties
then manually add this to into pom.xml:
{code:xml}
maven-war-plugin
src/main/resources
test.properties
WEB-INF
true
{code}
And then run
mvn war:exploded && cat target/sample-artifact-id/WEB-INF/test.properties
you'll see test=http://maven.apache.org which is absolutely incorrect.
> filtering ${something.url} ignores my property value and writes
> http://maven.apache.org/something
> -
>
> Key: MWAR-89
> URL: http://jira.codehaus.org/browse/MWAR-89
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Paul Jungwirth
>Assignee: Stephane Nicoll
>Priority: Minor
>
> I have a multimodule build, and one of the modules is a war. That module has
> an artifactId of "aardvark." This is aardvark's pom:
>
> ...
>
> http://anywhere.com/
> whatever
>
> ...
>
>
>
> maven-war-plugin
>
>
>
>${basedir}/src/main/resources
>true
>
>
>
>
>
>
>
> Inside src/main/resources, I have a file that includes both ${something.url}
> and ${another.property}. But when I run maven, ${another.property} is
> filtered correctly, while ${something.url} becomes
> "http://maven.apache.org/aardvark."; It ignores my value and writes a URL to
> apache.org instead, appending the artifactId. Weird, huh? This seems to
> happen with any property that ends in ".url." Is this supposed to be a
> feature? I've never seen it documented anywhere.
> Thanks,
> Paul
--
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-3155) Add a link to Artifactory to the "Introduction to Repositories" guide
Add a link to Artifactory to the "Introduction to Repositories" guide - Key: MNG-3155 URL: http://jira.codehaus.org/browse/MNG-3155 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 2.0.7 Reporter: Yoav Landman Could you please add Artifactory (http://artifactory.sourceforge.net/) to the list of solutions under the "Setting up the Internal Repository" section? 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] Created: (WAGONFTP-22) Error deploying artifact: Unable to create directory
Error deploying artifact: Unable to create directory Key: WAGONFTP-22 URL: http://jira.codehaus.org/browse/WAGONFTP-22 Project: wagon-ftp Issue Type: Bug Affects Versions: 1.0-alpha-6 Environment: maven-2.0.6 Windows XP SP2 Reporter: troy ronning I'm trying to deploy a project and receiving error below. . [INFO] [deploy:deploy] altDeploymentRepository = test.ftp::default::ftp:// [INFO] Using alternate deployment repository test.ftp::default::ftp:// [INFO] Retrieving previous build number from test.ftp [DEBUG] repository metadata for: 'snapshot org.test:foo:1.0-SNAPSHOT' could not be found on repository: test.ftp Uploading: ftp:///org/test/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unable to create directory org [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Unable to create directory org at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifact: Unable to create directory org at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:174) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Unable to create directory org at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Unable to create directory org at org.apache.maven.wagon.providers.ftp.FtpWagon.fillOutputData(FtpWagon.java:264) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:133) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) ... 19 more I have wagon-ftp set as a build extension. org.apache.maven.wagon wagon-ftp 1.0-alpha-6 I can execute 'mkd' successfully from ftp CLI. -- 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: (MCOMPILER-57) State default source (1.3) and target (1.1) in the documentation
[
http://jira.codehaus.org/browse/MCOMPILER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105093
]
Wayne Fay commented on MCOMPILER-57:
Maven has a strong preference for "convention over configuration" which means
that requiring the source and target entries in the pom is not really
reasonable IMO. Instead, the defaults should be documented better, and perhaps
the error message could be adjusted to point to a FAQ entry that explains
things for new users.
> State default source (1.3) and target (1.1) in the documentation
>
>
> Key: MCOMPILER-57
> URL: http://jira.codehaus.org/browse/MCOMPILER-57
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Gisbert Amm
>Priority: Trivial
>
> The documentation does currently say nothing about the compiler defaults,
> especially source and target version, which is 1.3 and 1.1 (byte code 45.3).
> It would be helpful to add this information to the docs to make the defaults
> obvious.
> Respective mailing list content:
> This has been discussed several times on this list.
> IMO, the default compilation target being 1.1 (or another hard-defined
> version) meets the rule of least surprise. You can argue that you
> don't like 1.1 and you'd prefer 1.3 or even 1.5 but that is another
> discussion.
> In contrast, the rule of most surprise would be "my build changes when
> I change my JDK" or "my build changes when I build things on different
> machines". This is the absolute worst thing you can run into when
> trying to standardize and control your build process.
> If you want to target a specific JDK, then simply add the compiler
> configuration in your poms. If you feel this has not been documented
> sufficiently, then post a RFE in Jira and someone will add some text
> to the proper page(s) on the site.
> Wayne
> On 8/15/07, Gisbert Amm <[EMAIL PROTECTED]> wrote:
> >> Searching for version issues, I had a closer look at the *.class files
> >> generated by Maven2 with the default compiler settings and found that
> >> the first bytes of them are "cafe babe 0003 002D ...", which is byte
> >> code version 45.3 = Java 1.1.
> >>
> >> First I was believing that I had this (target 1.1) configured somewhere
> >> by accident. However, I didn't find any such configuration, therefore I
> >> dug into the plexus-compiler source and found the following in
> >> plexus-site/plexus-components/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java:
> >>
> >> // TODO: this could be much improved
> >> if ( StringUtils.isEmpty( config.getTargetVersion() ) )
> >> {
> >> // Required, or it defaults to the target of your JDK (eg 1.5)
> >> args.add( "-target" );
> >> args.add( "1.1" );
> >> }
> >> else
> >> {
> >> args.add( "-target" );
> >> args.add( config.getTargetVersion() );
> >> }
> >>
> >> if ( !suppressSource( config ) && StringUtils.isEmpty(
> >> config.getSourceVersion() ) )
> >> {
> >> // If omitted, later JDKs complain about a 1.1 target
> >> args.add( "-source" );
> >> args.add( "1.3" );
> >> }
> >>
> >> Is there any particular reason why target is set to 1.1 here? IMHO, it
> >> breaks the rule of least surprise for I am certainly expecting that the
> >> generated byte code by default has the version of the JDK I'm using the
> >> compiler of. The comment "Required, or it defaults to the target of your
> >> JDK" doesn't give any reason. Does anybody know, why this default is set?
> >>
> >> At least it should be mentioned on
> >> http://maven.apache.org/plugins/maven-compiler-plugin/howto.html to make
> >> it obvious to users. Otherwise people might have problems and need a
> >> long time to find out what's going on (see
> >> http://www.nabble.com/Odd-Compilation-Issue-tf1566644s177.html#a4287495
> >> for an example).
> >>
> >> Regards,
> >> Gisbert
--
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-1676) HtmlUnit 1.13 upload request
HtmlUnit 1.13 upload request Key: MAVENUPLOAD-1676 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1676 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot http://htmlunit.sourceforge.net/htmlunit-1.13-bundle.jar Team members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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-100) The iText module should not be coupled to the apt and xdoc modules
[ http://jira.codehaus.org/browse/DOXIA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-100. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: (was: 1.0-beta-1) 1.0-alpha-9 > The iText module should not be coupled to the apt and xdoc modules > -- > > Key: DOXIA-100 > URL: http://jira.codehaus.org/browse/DOXIA-100 > Project: Maven Doxia > Issue Type: Task > Components: Module - Itext >Reporter: Jason van Zyl >Assignee: Lukas Theussl > Fix For: 1.0-alpha-9 > > > We need a test source for rendering documents and not use the other modules' > parsers to generate events for anothe module's sink. -- 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: (MCOMPILER-57) State default source (1.3) and target (1.1) in the documentation
[
http://jira.codehaus.org/browse/MCOMPILER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105090
]
Gisbert Amm commented on MCOMPILER-57:
--
Instead of documenting the defaults it might be even better if the source and
target entries in the pom.xml would be mandatory and Maven would refuse to
compile at all when they were not set. That would at least make obvious which
source and target version the project is supposed to meet.
> State default source (1.3) and target (1.1) in the documentation
>
>
> Key: MCOMPILER-57
> URL: http://jira.codehaus.org/browse/MCOMPILER-57
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Gisbert Amm
>Priority: Trivial
>
> The documentation does currently say nothing about the compiler defaults,
> especially source and target version, which is 1.3 and 1.1 (byte code 45.3).
> It would be helpful to add this information to the docs to make the defaults
> obvious.
> Respective mailing list content:
> This has been discussed several times on this list.
> IMO, the default compilation target being 1.1 (or another hard-defined
> version) meets the rule of least surprise. You can argue that you
> don't like 1.1 and you'd prefer 1.3 or even 1.5 but that is another
> discussion.
> In contrast, the rule of most surprise would be "my build changes when
> I change my JDK" or "my build changes when I build things on different
> machines". This is the absolute worst thing you can run into when
> trying to standardize and control your build process.
> If you want to target a specific JDK, then simply add the compiler
> configuration in your poms. If you feel this has not been documented
> sufficiently, then post a RFE in Jira and someone will add some text
> to the proper page(s) on the site.
> Wayne
> On 8/15/07, Gisbert Amm <[EMAIL PROTECTED]> wrote:
> >> Searching for version issues, I had a closer look at the *.class files
> >> generated by Maven2 with the default compiler settings and found that
> >> the first bytes of them are "cafe babe 0003 002D ...", which is byte
> >> code version 45.3 = Java 1.1.
> >>
> >> First I was believing that I had this (target 1.1) configured somewhere
> >> by accident. However, I didn't find any such configuration, therefore I
> >> dug into the plexus-compiler source and found the following in
> >> plexus-site/plexus-components/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java:
> >>
> >> // TODO: this could be much improved
> >> if ( StringUtils.isEmpty( config.getTargetVersion() ) )
> >> {
> >> // Required, or it defaults to the target of your JDK (eg 1.5)
> >> args.add( "-target" );
> >> args.add( "1.1" );
> >> }
> >> else
> >> {
> >> args.add( "-target" );
> >> args.add( config.getTargetVersion() );
> >> }
> >>
> >> if ( !suppressSource( config ) && StringUtils.isEmpty(
> >> config.getSourceVersion() ) )
> >> {
> >> // If omitted, later JDKs complain about a 1.1 target
> >> args.add( "-source" );
> >> args.add( "1.3" );
> >> }
> >>
> >> Is there any particular reason why target is set to 1.1 here? IMHO, it
> >> breaks the rule of least surprise for I am certainly expecting that the
> >> generated byte code by default has the version of the JDK I'm using the
> >> compiler of. The comment "Required, or it defaults to the target of your
> >> JDK" doesn't give any reason. Does anybody know, why this default is set?
> >>
> >> At least it should be mentioned on
> >> http://maven.apache.org/plugins/maven-compiler-plugin/howto.html to make
> >> it obvious to users. Otherwise people might have problems and need a
> >> long time to find out what's going on (see
> >> http://www.nabble.com/Odd-Compilation-Issue-tf1566644s177.html#a4287495
> >> for an example).
> >>
> >> Regards,
> >> Gisbert
--
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-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[
http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105088
]
Vincent Siveton commented on MNG-2970:
--
I propose to add script parameters to activate hook scripts. For instance,
{noformat}
mvn ... --pre --post
{noformat}
will do the following sequence:
{noformat}
$M2_HOME/bin/mavenrc_pre
java call
$M2_HOME/bin/mavenrc_post
{noformat}
We could also specify file parameter, i.e. --pre /path/to/pre.sh and --post
/path/to/post.sh
WDYT?
> Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
>
>
> Key: MNG-2970
> URL: http://jira.codehaus.org/browse/MNG-2970
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.0.6
>Reporter: Vincent Siveton
> Fix For: Reviewed Pending Version Assignment
>
>
> CI builds need specific settings like environment or specific OS tasks.
> Some ideas to improve the mvn script:
> * add a setenv script before calling maven
> * add a pre/post hook scripts between maven call
--
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: (MSITE-249) Internationalization: Adapt generated directory layout to best practices
Internationalization: Adapt generated directory layout to best practices Key: MSITE-249 URL: http://jira.codehaus.org/browse/MSITE-249 Project: Maven 2.x Site Plugin Issue Type: Improvement Reporter: Alexander Hars The current directory layout is based on the assumption of a privileged 'default' language. Localized content for this language is placed into the root directory. All other language-specific content is placed into locale-specific subdirectories. However, in internationalization, current best practice is to place ALL localized content into subdirectories named after the 2 digit locale abbreviation. Even the default language. (This, of course, is how the Maven structures its site source tree, too). Having all localized content using the same structure has many advantages (including that relative links are the same in all languages, it is easy to switch from one language to the next, etc.). In addition, it cleanly separates the localized content from the content that is necessary to inform a user who arrives the first time and who is not automatically redirected to the right language section that he needs to choose the language/preferred country etc. In the current layout, the site/index.html has both the task of serving the welcome page content in the default language as well as helping users to make a choice about their preferred language. In the clean structure where all localized content is in subdirectories, the root index.html would only need to help the user make the change between available languages, the index.html in the subdirectories would serve as the localized welcome page. They can easily be translated, there would be no special requirement for the default language's welcome page. (of course all pages would have some menu for switching languages, but it would not be prominent). It would be quite simple to make this change. For backward compatibility, one could add a property that preserves the old structure. I know that the privileged default language approach by Maven was intended as a feature. But it certainly is not a best practice and has significant drawbacks. We should change it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out
[ http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105087 ] Brett Porter commented on CONTINUUM-1387: - I don't think the build process should download the source (as incheckoutqueue probably also checks for one *in progress*). is it possible to requeue the build in the build queue if isincheckoutqueue is true instead of just abandoning the build? > Can't initiate a build of a new project in continuum until all modules have > been checked out > > > Key: CONTINUUM-1387 > URL: http://jira.codehaus.org/browse/CONTINUUM-1387 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Wendy Smoak > > When a multi-module project is added to continuum, a working copy of each > module is extracted from subversion. > Typically after adding a project I want to kick off a build. > If I initiate the build before all the modules are extracted, the ones that > have not yet been fully extracted will not be queued for build. Only those > already fully extracted will be built. -- 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: (MSITE-248) Internationalization: Do not duplicate css files and image resources.
Internationalization: Do not duplicate css files and image resources. -- Key: MSITE-248 URL: http://jira.codehaus.org/browse/MSITE-248 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Reporter: Alexander Hars Currently, Maven copies the skin's css files and image resources into each locale directory. This leads to redundancy and has serious drawbacks when the developer adds their own .css files (which most developers will do). If the .css files are not packaged into a skin, then the developer has to copy each change to the .css file into teach locale. (And we should not expect a developer to create skin for a single project.). Redundant resources also additional drawbacks. For example, if the localized files are distributed as help files for a Java application we unnecessarily increase the size of our distribution. It would be much better to use a single location for all css files and image resource (Of course, this does not prevent the developer from adding localized css files or image resources, should they be needed). The solution is simple: save the css files and resources only once below the root directory. Then use relative links that point from the localized pages to the root. This can easily be done if the maven template could distinguish between the localized directory for the default locale and the other locales (would require another property to be passed to Velocity). It would even be simpler if the directory structure treated all locales as equals, as is best practice for internationalized applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out
[ http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105085 ] Teodoro Cue Jr. commented on CONTINUUM-1387: After investigating this for a few hours, I've found out that we can actually do a build even when the project is not yet downloaded. Removing isInCheckoutQueue( project.getId() ) from buildProject() under DefaultContinuum does just that. The adverse effect is that some projects are built without sources. I'm trying to find out how to fix this for now. DefaultBuildController actually checks if the project is downloaded already or not. It then downloads the code if it does not exist. My other concern is the existence of the same project under the checkout queue. I'm not familiar with the inner workings of the build procedure. Would this actually download the same source twice if the build procedure downloaded the source first then the checkout process encounters the same project in the queue? > Can't initiate a build of a new project in continuum until all modules have > been checked out > > > Key: CONTINUUM-1387 > URL: http://jira.codehaus.org/browse/CONTINUUM-1387 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Wendy Smoak > > When a multi-module project is added to continuum, a working copy of each > module is extracted from subversion. > Typically after adding a project I want to kick off a build. > If I initiate the build before all the modules are extracted, the ones that > have not yet been fully extracted will not be queued for build. Only those > already fully extracted will be built. -- 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-222) 2.2-beta-1 regression in assembly descriptor interpolation
[
http://jira.codehaus.org/browse/MASSEMBLY-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105083
]
Max Bowsher commented on MASSEMBLY-222:
---
Regarding ${pom.foo} - aren't other parts of Maven preferring ${project.foo}
with ${pom.foo} as a deprecated alternative?
> 2.2-beta-1 regression in assembly descriptor interpolation
> --
>
> Key: MASSEMBLY-222
> URL: http://jira.codehaus.org/browse/MASSEMBLY-222
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> I have found a significant change in behaviour between 2.1 and 2.2-beta-1,
> using the following assembly descriptor:
> {code:xml}
>
> dist
>
> tar.gz
>
> no
>
>
> /foobar-${version}
>
> README.txt
> changelog.txt
> java.policy
>
>
>
> target
> /foobar-${version}/jars
>
> foobar-${version}.jar
>
>
>
> src/main/scripts
> /foobar-${version}/bin
> 0755
>
>
>
>
> /foobar-${version}/jars
> false
>
>
>
> {code}
> Using 2.1, ${version} interpolates with the version of the project being
> assembled.
> Using 2.2-beta-1, the ${version} in the interpolates with the
> version of each individual dependency, leading to the being
> scattered across many directories.
--
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: (MCOMPILER-57) State default source (1.3) and target (1.1) in the documentation
[
http://jira.codehaus.org/browse/MCOMPILER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105082
]
Gisbert Amm commented on MCOMPILER-57:
--
Another baffled user:
http://www.nabble.com/annotations-are-not-supported-in--source-1.3-tf4281106s177.html#a12186976
> State default source (1.3) and target (1.1) in the documentation
>
>
> Key: MCOMPILER-57
> URL: http://jira.codehaus.org/browse/MCOMPILER-57
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Gisbert Amm
>Priority: Trivial
>
> The documentation does currently say nothing about the compiler defaults,
> especially source and target version, which is 1.3 and 1.1 (byte code 45.3).
> It would be helpful to add this information to the docs to make the defaults
> obvious.
> Respective mailing list content:
> This has been discussed several times on this list.
> IMO, the default compilation target being 1.1 (or another hard-defined
> version) meets the rule of least surprise. You can argue that you
> don't like 1.1 and you'd prefer 1.3 or even 1.5 but that is another
> discussion.
> In contrast, the rule of most surprise would be "my build changes when
> I change my JDK" or "my build changes when I build things on different
> machines". This is the absolute worst thing you can run into when
> trying to standardize and control your build process.
> If you want to target a specific JDK, then simply add the compiler
> configuration in your poms. If you feel this has not been documented
> sufficiently, then post a RFE in Jira and someone will add some text
> to the proper page(s) on the site.
> Wayne
> On 8/15/07, Gisbert Amm <[EMAIL PROTECTED]> wrote:
> >> Searching for version issues, I had a closer look at the *.class files
> >> generated by Maven2 with the default compiler settings and found that
> >> the first bytes of them are "cafe babe 0003 002D ...", which is byte
> >> code version 45.3 = Java 1.1.
> >>
> >> First I was believing that I had this (target 1.1) configured somewhere
> >> by accident. However, I didn't find any such configuration, therefore I
> >> dug into the plexus-compiler source and found the following in
> >> plexus-site/plexus-components/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java:
> >>
> >> // TODO: this could be much improved
> >> if ( StringUtils.isEmpty( config.getTargetVersion() ) )
> >> {
> >> // Required, or it defaults to the target of your JDK (eg 1.5)
> >> args.add( "-target" );
> >> args.add( "1.1" );
> >> }
> >> else
> >> {
> >> args.add( "-target" );
> >> args.add( config.getTargetVersion() );
> >> }
> >>
> >> if ( !suppressSource( config ) && StringUtils.isEmpty(
> >> config.getSourceVersion() ) )
> >> {
> >> // If omitted, later JDKs complain about a 1.1 target
> >> args.add( "-source" );
> >> args.add( "1.3" );
> >> }
> >>
> >> Is there any particular reason why target is set to 1.1 here? IMHO, it
> >> breaks the rule of least surprise for I am certainly expecting that the
> >> generated byte code by default has the version of the JDK I'm using the
> >> compiler of. The comment "Required, or it defaults to the target of your
> >> JDK" doesn't give any reason. Does anybody know, why this default is set?
> >>
> >> At least it should be mentioned on
> >> http://maven.apache.org/plugins/maven-compiler-plugin/howto.html to make
> >> it obvious to users. Otherwise people might have problems and need a
> >> long time to find out what's going on (see
> >> http://www.nabble.com/Odd-Compilation-Issue-tf1566644s177.html#a4287495
> >> for an example).
> >>
> >> Regards,
> >> Gisbert
--
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: (DOXIA-148) FmlParser emits HTML specific events
[ http://jira.codehaus.org/browse/DOXIA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105081 ] Lukas Theussl commented on DOXIA-148: - In addition, toplinks and elements are emitted directly via rawText as html elements. > FmlParser emits HTML specific events > > > Key: DOXIA-148 > URL: http://jira.codehaus.org/browse/DOXIA-148 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Fml >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl >Priority: Minor > > Questions/answers in an fml document may contain (almost) arbitrary html tags > (eg lists, paragraphs) but the question/answer in the Faq model is defined as > a simple String and questions/answers are emitted as rawText by the parser. > That means that FmlParser events can only be consumed correctly by the > XhtmlSink (or XmlSink). -- 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: (MRM-462) separate configuration of managed repositories from remote repositories
[ http://jira.codehaus.org/browse/MRM-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105077 ] Brett Porter commented on MRM-462: -- consensus seemed to be around the original plan, but with the added condition that id's may not be duplicated between different repository types > separate configuration of managed repositories from remote repositories > --- > > Key: MRM-462 > URL: http://jira.codehaus.org/browse/MRM-462 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-2 > > > the fancy footwork to make a managed repository use all the same > configuration screens as a remote repository is causing both subtle bugs > (particularly in the URL handling), and a confusing user experience (settings > appearing that are irrelevant to remote repositories in the edit form). > 1) separate the forms/actions (or at least exclude the fields that are not > relevant when editing the remote repos) > 2) treat the URL (remote) as a URL and the location (managed) as a path. > Don't munge anything. > 3) I think we should consider separating them into different lists in the > configuration again. -- 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] Work started: (MRM-462) separate configuration of managed repositories from remote repositories
[ http://jira.codehaus.org/browse/MRM-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-462 started by Brett Porter. > separate configuration of managed repositories from remote repositories > --- > > Key: MRM-462 > URL: http://jira.codehaus.org/browse/MRM-462 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-2 > > > the fancy footwork to make a managed repository use all the same > configuration screens as a remote repository is causing both subtle bugs > (particularly in the URL handling), and a confusing user experience (settings > appearing that are irrelevant to remote repositories in the edit form). > 1) separate the forms/actions (or at least exclude the fields that are not > relevant when editing the remote repos) > 2) treat the URL (remote) as a URL and the location (managed) as a path. > Don't munge anything. > 3) I think we should consider separating them into different lists in the > configuration again. -- 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: (MRM-436) incorrect default cron expression for snapshots repository
[ http://jira.codehaus.org/browse/MRM-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-436. Resolution: Fixed Fixed in -r566945 Fix: - Added '\' for the snapshots cron expression in default-archiva.xml to escape the ',' - (DefaultArchivaConfiguration) Added method for adding '\' to the cron expression if ',' exists before saving the configuration and method for removing '\' after the configuration is read from the configuration file > incorrect default cron expression for snapshots repository > -- > > Key: MRM-436 > URL: http://jira.codehaus.org/browse/MRM-436 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-2 > > > it is '0 0' which is not a valid value - it should probably be the same as > for releases -- 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] Work started: (MRM-393) Can't delete blacklist/whitelist pattern
[ http://jira.codehaus.org/browse/MRM-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-393 started by Maria Odea Ching. > Can't delete blacklist/whitelist pattern > > > Key: MRM-393 > URL: http://jira.codehaus.org/browse/MRM-393 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-2 > > > not sure if this only occurs when the form isn't complete - haven't tested > other scenarios > 1) add a proxy connector > 2) don't fill in fields > 3) add a blacklist pattern "foo" > 4) attempt to delete "foo" from blacklist pattern > EXPECTED: delete the blacklist pattern > ACTUAL: nothing happens > Same applies to whitelist -- 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
