[jira] Created: (ARCHETYPE-360) Wrong assignment in loop results in wrong debug log output
Wrong assignment in loop results in wrong debug log output
--
Key: ARCHETYPE-360
URL: http://jira.codehaus.org/browse/ARCHETYPE-360
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0
Reporter: Marc Wirth
Priority: Trivial
Attachments: wrong_assignment.patch
The artifactId parameter in the processFilesetModule() method is reassigned
in the while loop iterating over submodules, but the parameter is not used in
the loop.
The only consequence of that is that the artifact ID logged by the {{
getLogger().debug( Processed + artifactId );}} line at the end of the method
does not match the artifact ID logged at the start of the method
{{getLogger().debug( Processing module + artifactId );}} if there are
submodules.
Proposal: Just delete the line, see attached patch 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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-361) String.replace() used in an inconsistent (and unnecessary) way
String.replace() used in an inconsistent (and unnecessary) way
--
Key: ARCHETYPE-361
URL: http://jira.codehaus.org/browse/ARCHETYPE-361
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0
Reporter: Marc Wirth
Priority: Minor
Attachments: unnecessary_stringreplace.patch
See attached patch. Sorry, no specific test case, but the existing testcases do
not complain if this change is applied.
First one:
{code}
processFilesetProject( archetypeDescriptor,
StringUtils.replace( artifactId,
${rootArtifactId}, rootArtifactId ),
archetypeResources, pom,
archetypeZipFile, moduleOffset, context, packageName,
outputDirectoryFile, basedirPom );
{code}
replaced with:
{code}
processFilesetProject( archetypeDescriptor,
artifactId,
archetypeResources, pom,
archetypeZipFile, moduleOffset, context, packageName,
outputDirectoryFile, basedirPom );
{code}
On the first call to the method the artifactId is the id from the request, so
it cannot really contain $\{rootArtifactId\} unless somebody typed that on
the console. If there are modules and the method recurses the parameter is
replaced with {{StringUtils.replace( project.getDir(), __rootArtifactId__,
rootArtifactId )}} and the ModuleDescriptor dir uses the underscores for
escaping, not the dollar and the braces, so I assume this replacement is not
necessary at all. (None of the existing tests breaks).
Second one:
{code}
processFilesetModule( rootArtifactId,
StringUtils.replace(
project.getDir(), __rootArtifactId__, rootArtifactId ),
archetypeResources,
new File( moduleOutputDirectoryFile,
Constants.ARCHETYPE_POM ), archetypeZipFile,
( StringUtils.isEmpty( moduleOffset )
? : ( moduleOffset + / ) )
+ StringUtils.replace(
project.getDir(), ${rootArtifactId}, rootArtifactId ),
pom, moduleOutputDirectoryFile,
packageName, project, context );
{code}
replaced with:
{code}
processFilesetModule( rootArtifactId,
StringUtils.replace(
project.getDir(), __rootArtifactId__, rootArtifactId ),
archetypeResources,
new File( moduleOutputDirectoryFile,
Constants.ARCHETYPE_POM ), archetypeZipFile,
( StringUtils.isEmpty( moduleOffset )
? : ( moduleOffset + / ) )
+ project.getDir(),
pom, moduleOutputDirectoryFile,
packageName, project, context );
{code}
The dir of the Module descriptor uses underscores, not dollar plus braces for
escaping. At least that's the way it is also created in
org.apache.maven.archetype.creator.FilesetArchetypeCreator#createModule. Thus
replacing a {{$\{...\}}} expression in ModuleDescriptor#getDir() should never
actually do anything.
Is that analysis correct?
--
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: (ARCHETYPE-350) Proposal for making (sub-)module handling more flexible with regards to folder names
Proposal for making (sub-)module handling more flexible with regards to folder
names
Key: ARCHETYPE-350
URL: http://jira.codehaus.org/browse/ARCHETYPE-350
Project: Maven Archetype
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Marc Wirth
Attachments: module_name.patch
We have a use-case where we want modules to use the artifact ID of the parent
as prefix, but the modules folder should only use the suffix to keep overall
paths short (without becoming too redundant.)
To make configuration more flexible I've changed the implementation so that the
name of a module is used to define the output folder where the module is
created and that it is run through velocity so that arbitrary properties can be
defined. Please check the attached patch file.
For example with this patch we could use a archetype-metadata definition like:
{code}
requiredProperty key=subArtifactId
...
module id=${rootArtifactId}.${subArtifactId} dir=__rootArtifactId__.sub
name=${subArtifactId}
{code}
to generate the module (from {{__rootArtifactId__.sub}} in the archetype-zip)
into a folder that only consists of the module name, but having the
rootArtifact ID plus the module name as its artifactId.
I don't have a testcase specifically for this, but at least it doesn't break
the existing fileset-archetype tests.
While looking through the relevant code I've tried to clean up a few other
oddities (artifactId is reset so log output would print a potentially wrong id,
what looked like a mixup of replacements in Strings with ${x} or __x__
delimiters to me).
Also,
http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
says The attributes name, id and dir of the module are used to determine the
directory where to generate that module's files, they also are used to
determine the artifactId of the Maven project corresponding to this module.
but actually the name attribute was never used during generation (only set
during creation, same value as the id). To distinguish the source location
within the archetype, i.e. the dir-attribute, from the destination I used the
name attribute to define the output directory name.
What do you think about that?
--
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-4714) legacy repositories are silently treated as default repositories?
legacy repositories are silently treated as default repositories?
-
Key: MNG-4714
URL: http://jira.codehaus.org/browse/MNG-4714
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-beta-1
Reporter: Marc Wirth
Priority: Minor
Attachments: pom.xml
Support for legacy repositories was removed for
http://jira.codehaus.org/browse/MNG-4204 but if you now try to build something
were an artifact exists only on a legacy repository the build will warn:
[WARNING] 'repositories.repository.layout' for maven-repository.dev.java.net
uses the deprecated value 'legacy'. @
...
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects
but then the build just fails with a missing artifact message.
Class org.apache.maven.repository.legacy.LegacyRepositorySystem has explicitly:
public ArtifactRepository createArtifactRepository( String repositoryId,
String url, ArtifactRepositoryLayout repositoryLayout, ArtifactRepositoryPolicy
snapshots, ArtifactRepositoryPolicy releases )
{
if ( repositoryLayout == null )
{
repositoryLayout = layouts.get( default );
}
...
}
So while the LegacyRepositoryLayout does not exist anymore, Maven will treat
the repository as Default-Repository and of course fail to find something.
From my point of view the Warning at the beginning should rather be an error.
The reference to future versions is also quite misleading as the support was
already removed in the current version (-
org.apache.maven.model.validation.DefaultModelValidator#validateRepository
reports that violation).
What's the intended behaviour here?
--
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: (MNG-4714) legacy repositories are silently treated as default repositories?
[
http://jira.codehaus.org/browse/MNG-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Wirth updated MNG-4714:
Attachment: pom.xml
Example pom.xml to demonstrate
legacy repositories are silently treated as default repositories?
-
Key: MNG-4714
URL: http://jira.codehaus.org/browse/MNG-4714
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-beta-1
Reporter: Marc Wirth
Priority: Minor
Attachments: pom.xml
Support for legacy repositories was removed for
http://jira.codehaus.org/browse/MNG-4204 but if you now try to build
something were an artifact exists only on a legacy repository the build
will warn:
[WARNING] 'repositories.repository.layout' for maven-repository.dev.java.net
uses the deprecated value 'legacy'. @
...
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects
but then the build just fails with a missing artifact message.
Class org.apache.maven.repository.legacy.LegacyRepositorySystem has
explicitly:
public ArtifactRepository createArtifactRepository( String repositoryId,
String url, ArtifactRepositoryLayout repositoryLayout,
ArtifactRepositoryPolicy snapshots, ArtifactRepositoryPolicy releases )
{
if ( repositoryLayout == null )
{
repositoryLayout = layouts.get( default );
}
...
}
So while the LegacyRepositoryLayout does not exist anymore, Maven will treat
the repository as Default-Repository and of course fail to find something.
From my point of view the Warning at the beginning should rather be an error.
The reference to future versions is also quite misleading as the support
was already removed in the current version (-
org.apache.maven.model.validation.DefaultModelValidator#validateRepository
reports that violation).
What's the intended behaviour here?
--
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-4592) Snapshot artifacts that could not be downloaded due to communication problems are blacklisted for a day by default.
Snapshot artifacts that could not be downloaded due to communication problems are blacklisted for a day by default. - Key: MNG-4592 URL: http://jira.codehaus.org/browse/MNG-4592 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-7 Reporter: Marc Wirth If an artifact could not be downloaded because of communication problems with the server Maven should not use the update check intervall before rechecking. The fix for http://jira.codehaus.org/browse/MNG-3421 introduced a behaviour that has cost us some time to find a solution. We're facing network problems with one of our nexus servers and this results by default in a 24 hour blacklisting of that artifact. For a continuous integration scenario this is rather painful (build stays red for a whole day) and using a different policy increases the network overhead because then all snapshots are checked. For now we have a very ugly workaround that simply deletes all *.lastUpdated files from the local repository. A better solution from our point of view would be to only write the lastUpdated file if the resource really doesn't exist (DefaultWagonManager#getRemoteFile() threw ResourceDoesNotExistException?), but not if the wagon reported a communication problem (TransferFailedException?). That way the solution to MNG-3421 should still be valid, but without blocking CI in our case. It would also be rather helpful if the real cause for such delayed lookups would be reported by default (Failure to resolve ... was cached in the local repository. Resolution will not be reattempted until ...). In our case we only had the standard error message in the log that the artifact could not be resolved from any repository and it took us a while to figure out that this was really because of the lastUpdated-check. -- 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-4593) Alpha 7 requires parent pom of artifact referenced for compilation
Alpha 7 requires parent pom of artifact referenced for compilation -- Key: MNG-4593 URL: http://jira.codehaus.org/browse/MNG-4593 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-7 Reporter: Marc Wirth While evaluating the latest alpha release for our environment we found that alpha-7 suddenly requires the availability of the parent pom of an artifact. The pom in question references an artifact as normal dependency without explicit scope (plain GAV). The pom of that artifact references a parent that really does not exist in any repository. With alpha-7 the build fails complaining about that parent. With alpha-6 the build works fine. Looking at the changes for alpha-7 I don't see any indication that this was intentionally done, so I rather consider this to be a bug. (Increases number of lookups required and I don't see any necessity for the availability of the parent, but maybe I'm missing something here). -- 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-4478) deploy plugin altDeploymentRepository does not use authorization credentials
deploy plugin altDeploymentRepository does not use authorization credentials Key: MNG-4478 URL: http://jira.codehaus.org/browse/MNG-4478 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 3.0-alpha-5, 3.0-alpha-4 Reporter: Marc Wirth Attachments: maven-deploy-plugin-1.patch When using the altDeploymentRepository of the deploy plugin (2.4 or 2.5-SNAPSHOT) the (Default)ArtifactRepository will have no Authorization object set, thus deployment will fail if the repository requires authorization. My expectation was that authorization credentials are picked up if a server with matching ID is configured in the settings.xml. The attached patch fixes this the hard way in the deploy plugin, but the change requires building the deploy plugin against maven 3.0-alpha. I think this should rather be fixed in Maven itself if possible, but I don't know how to do that. -- 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
