[jira] Created: (MENFORCER-61) Add rule to check versions of reporting plugins
Add rule to check versions of reporting plugins Key: MENFORCER-61 URL: http://jira.codehaus.org/browse/MENFORCER-61 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Reporter: Wouter Hermeling There is no rule that checks for snapshots of reporting plugins. The requirePluginVersions rule does not check this. -- 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: (MENFORCER-62) requirePluginVesions: avoid checking commandline-invoked mojos
requirePluginVesions: avoid checking commandline-invoked mojos
--
Key: MENFORCER-62
URL: http://jira.codehaus.org/browse/MENFORCER-62
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-alpha-4
Environment: Maven 2.0.8, 2.0.9
Linux,Windows
Reporter: Petr Kozelka
Locking plugin versions affects also mojos invoked from commandline, which is
typically undesired.
Besides that, such mojos cannot be even invoked with fully qualified name.
I am using following configuration in our corporate pom, to enforce that all
plugin versions are explicitly declared so that builds are reproducible:
{noformat}
...
messageERROR: Please always define plugin
versions./message
banLatesttrue/banLatest
banReleasetrue/banRelease
banSnapshotsfalse/banSnapshots
banTimestampsfalse/banTimestamps
phasesclean,deploy,install/phases
...
{noformat}
With this config, I cannot use commandline mojos that are not mentioned with
exact version.
One such case is {{mvn idea:idea}} which ends with enforcer failure.
*Even worse*: in this case I have {color:red}no chance to invoke{color} that
mojo even with full qualifier - it fails as if I didn't specify version (maybe
this part is a bug in different component):
{noformat}
mvn org.apache.maven.plugins:maven-idea-plugin:2.2:idea
{noformat}
I can theoretically add something like this to the corporate pom, and it really
helps:
{noformat}
...
unCheckedPlugins
unCheckedPluginorg.apache.maven.plugins:maven-idea-plugin/unCheckedPlugin
/unCheckedPlugins
...
{noformat}
However, this approach is generally unusable, as it requires re-releasing of
all modules descending from that pom - which is never desired and rarely
possible.
h3. A semi-solution idea:
This might be difficult to fix - but if the list of unchecked plugins was
somehow externalizable, it would solve my urgent need.
For instance, add option {{unCheckedPluginList}} containing comma separated
items - then I can reference a property defined in {{settings.xml}} from there.
That would work for me, because settings are not subject to releasing:
{noformat}
...
unCheckedPluginList${my.unchecked.plugins}/unCheckedPluginList
...
{noformat}
--
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: (MERCURY-86) remote repository presumes GAV metadata to contain versions/ for all snapshots
[ http://jira.codehaus.org/browse/MERCURY-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-86. --- Resolution: Fixed fixed to process snapshot correctly; it's now used to calculate available TS together with versions remote repository presumes GAV metadata to contain versions/ for all snapshots Key: MERCURY-86 URL: http://jira.codehaus.org/browse/MERCURY-86 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 This assumption is only valid for mercury-created metadata. Make it understand snapshot/ -- 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-4022) Incorrect merge behavior using profile driven plugin configuration
Incorrect merge behavior using profile driven plugin configuration -- Key: MNG-4022 URL: http://jira.codehaus.org/browse/MNG-4022 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.9 Environment: Fedora 10 x86_64, not a factor Reporter: John McNair Attachments: maven-plugin-merge.zip Plugin configurations are not merged correctly when contained inside a profile. The attached example demonstrates a failure where the parent contains the configuration, and the child contains the execution. There is no configuration whatsoever in the child. The circumstances required to trigger this are: - Configuration contains a list of at least 2 complex elements. - Configuration is inside a profile. This does not happen outside the profile - The first element in the list contains parameters that the last element does not contain, e.g.: foos foo namefirst/name /foo foo / foo / /foos In this example, there should be a list of three Foo elements. The first should have name=first and the last two should have name=null. In reality, the second element will have name=null, but the third will have name=first. This behavior holds for all parameters in the first element that do not exist in the last element. The attached example includes a test plugin with an Element object that demonstrates this behavior. I have traced down the cause and have some high level ideas about the fix, but I have not coded a patch. I think there are two bugs that meet under these circumstances to cause the configuration corruption. Certainly there are multiple opportunities to make this pom configuration work as expected. First, there is no configuration in the child. Why should maven even attempt a merge? I ran maven through the debugger to get a better understanding of the sequence of events. Maven sources the parent pom and the child pom. When the child pom is sourced, it contains the full configuration exactly as it exists in the parent. Then an attempt is made to merge these identical configurations. Maven has the chance to avoid this issue by recognizing that the configuration element does not exist at all in the child and simply inheriting that as is from the parent. The other bug is not in Maven. It is in Xpp3Dom (http://fisheye.codehaus.org/browse/plexus/plexus-utils/tags/plexus-utils-1.5.1/src/main/java/org/codehaus/plexus/util/xml/Xpp3Dom.java?r=4475#l346). Notice that it iterates over the list of recessive children (from the parent pom) linearly and attempts to do a map-based lookup for the corresponding element in the dominant children (from the child pom). This works fine when you have a composition of several complex types, but it fails when there is a sequence of the identical types. From a bit more abstract perspective, if Xpp3Dom is attempting to merge two identical Xpp3Doms, I would expect the result to be the identity rather than data corruption. I have not done the research to understand why profile plugins go through this path inside Xpp3Dom but non-profile plugins apparently don't. There may also be other situations which are affected. I have not tried using a pluginManagement element for instance. Lastly, there is something of a workaround. You can tell Xpp3Dom not to merge by setting the self.combine attribute: configuration self.combine=override This tells Xpp3Dom to ignore the recessive Xpp3Dom (parent) and just use the dominant (child) which seems odd given that there is no child configuration. However, it will work if you don't have any real merging needs. -- 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-3375) Repository entries with same id are ignored
[
http://jira.codehaus.org/browse/MNG-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3375:
---
Attachment: MNG-3375-maven-project.patch
With this patch, Maven will throw an {{InvalidRepositoryException}} if a
repository's ID is not unique and the build will fail. I opted for the build to
fail (instead of just issuing a warning) because running a build against a
completely different repository can be a source of unnecessary build problems.
A simple warning could easily be missed.
Repository entries with same id are ignored
---
Key: MNG-3375
URL: http://jira.codehaus.org/browse/MNG-3375
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Carlos Sanchez
Priority: Critical
Fix For: 2.0.11
Attachments: MNG-3375-maven-project.patch
If two repository entries have the same id one of them is ignored with no
warning or error.
IIRC this worked with previous versions of maven, giving the same id allowed
you to share the configuration in the settings.xml file (it may have been for
deployment only though)
--
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-3375) Repository entries with same id are ignored
[
http://jira.codehaus.org/browse/MNG-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164131#action_164131
]
Torben S. Giesselmann commented on MNG-3375:
BTW: I didn't really manage to write a test, because testing the function
involved would require a fully configured / working {{PlexusContainer}} and,
quite frankly, I ran into some problems. ;-) Someone more experienced than me
should be able to construct a working test. Here's what my current test would
look like, maybe someone can make some use of it:
{code}
public void testShouldNotAllowDuplicateRepositoryIds()
{
Repository repo1 = new Repository();
repo1.setId( first );
repo1.setUrl(non-empty-url);
repo1.setLayout(default);
Repository repo2 = new Repository();
repo2.setId( second );
repo2.setUrl(non-empty-url);
repo2.setLayout(default);
Repository dupeRepo = new Repository();
dupeRepo.setId( second );
dupeRepo.setUrl(non-empty-url);
dupeRepo.setLayout(default);
List repoList = new ArrayList();
repoList.add(repo1);
repoList.add(repo2);
DefaultPlexusContainer container = null;
try
{
// TODO: initialize a working PlexusContainer ...
// String basedir = System.getProperty( basedir );
// InputStream configurationStream =
this.getClass().getClassLoader().getResourceAsStream( PlexusContainerTest.xml
);
// container = new DefaultPlexusContainer();
// container.addContextValue( basedir, basedir );
// container.addContextValue( plexus.home, basedir +
/target/plexus-home );
// container.setConfigurationResource( ReaderFactory.newXmlReader(
configurationStream ) );
// container.initialize();
// container.start();
ProjectUtils.buildArtifactRepositories( repoList, new
DefaultArtifactRepositoryFactory(), container );
}
catch ( InvalidRepositoryException e )
{
fail( e.getMessage() );
}
// MNG-3375: exception should be thrown if two repository IDs
are equal
repoList.add(dupeRepo);
try
{
ProjectUtils.buildArtifactRepositories( repoList, new
DefaultArtifactRepositoryFactory(), container );
fail();
}
catch ( InvalidRepositoryException e ) {
// exception should be thrown
}
}
{code}
Repository entries with same id are ignored
---
Key: MNG-3375
URL: http://jira.codehaus.org/browse/MNG-3375
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Carlos Sanchez
Priority: Critical
Fix For: 2.0.11
Attachments: MNG-3375-maven-project.patch
If two repository entries have the same id one of them is ignored with no
warning or error.
IIRC this worked with previous versions of maven, giving the same id allowed
you to share the configuration in the settings.xml file (it may have been for
deployment only though)
--
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: (MERCURY-83) repository metadata should be excluded from signature generation and checks
[ http://jira.codehaus.org/browse/MERCURY-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164135#action_164135 ] Oleg Gusakov commented on MERCURY-83: - added exempt from verification flag to the transport layer repository metadata should be excluded from signature generation and checks --- Key: MERCURY-83 URL: http://jira.codehaus.org/browse/MERCURY-83 Project: Mercury Issue Type: Bug Components: Transport Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 -- 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-2352) typica-1.5-bundle.jar
typica-1.5-bundle.jar - Key: MAVENUPLOAD-2352 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2352 Project: Maven Upload Requests Issue Type: Wish Reporter: David Kavanagh Attachments: typica-1.5-bundle.jar http://code.google.com/p/typica/ I've attached the bundle since I don't have it posted in maven bundle format for regular download. I'm the project owner and would like to submit this new release. -- 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-4009) [regression] Effects of active profiles from parent are not inherited by children.
[
http://jira.codehaus.org/browse/MNG-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-4009:
--
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
[regression] Effects of active profiles from parent are not inherited by
children.
--
Key: MNG-4009
URL: http://jira.codehaus.org/browse/MNG-4009
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Shane Isbell
Fix For: 3.0-alpha-3
Parent POM snippet:
{code:xml}
profiles
profile
idparent-profile/id
properties
!-- our children should see this, too --
parentProfilePropertyPASSED/parentProfileProperty
/properties
/profile
/profiles
{code}
The effective child POM is missing the property parentProfileProperty
although the profile parent-profile has been activated from 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] Closed: (MNG-4009) [regression] Effects of active profiles from parent are not inherited by children.
[
http://jira.codehaus.org/browse/MNG-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-4009.
-
Resolution: Fixed
[regression] Effects of active profiles from parent are not inherited by
children.
--
Key: MNG-4009
URL: http://jira.codehaus.org/browse/MNG-4009
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Shane Isbell
Fix For: 3.0-alpha-3
Parent POM snippet:
{code:xml}
profiles
profile
idparent-profile/id
properties
!-- our children should see this, too --
parentProfilePropertyPASSED/parentProfileProperty
/properties
/profile
/profiles
{code}
The effective child POM is missing the property parentProfileProperty
although the profile parent-profile has been activated from 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] Updated: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Navarro updated MAVENUPLOAD-2346: --- Attachment: appframework-1.03-bundle.jar This is the new bundle with the missing dependency on swing worker and with source et javadoc jar inside. Thanks in advance. Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, upload! -- 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-2342) please upload Glazed Lists 1.8.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164149#action_164149 ] Alexandre Navarro commented on MAVENUPLOAD-2342: A cool lib, thanks in advance to upload. Alexandre Navarro please upload Glazed Lists 1.8.0 Key: MAVENUPLOAD-2342 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2342 Project: Maven Upload Requests Issue Type: Task Reporter: Holger Brands official 1.8 release of Glazed Lists supporting Java JREs = 1.5 -- 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-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164151#action_164151 ] Jason Chaffee commented on MNG-2426: I just ran into this same issue with maven-2.0.9 Artifact copied to local repository with wrong file extension when using jboss-packaging plugin --- Key: MNG-2426 URL: http://jira.codehaus.org/browse/MNG-2426 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) Reporter: Fredrik Vraalsen Fix For: 2.0.x When using the jboss-packaging plugin and setting packaging to jboss-sar in my pom, the artifact is copied into the local repository with the wrong file extension (.jboss-sar instead of .sar). The jboss-packaging components.xml has extension set to sar. The file in the build target directory has the correct .sar extension. Here's the relevant excerpt from my pom.xml: packagingjboss-sar/packaging ... build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.0-SNAPSHOT/version extensionstrue/extensions ... -- 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-2845) Unwanted creation of repository directories
[
http://jira.codehaus.org/browse/MNG-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164152#action_164152
]
Torben S. Giesselmann commented on MNG-2845:
I can't reproduce the issue, neither with 2.0.9 nor 2.0.11-SNAPSHOT.
Here's my environment:
{quote}
$ mvn -v
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: mac os x version: 10.5.6 arch: i386 Family: unix
{quote}
Eclipse plugin used: {{maven-eclipse-plugin-2.5.1}}
Here's what I added to the pom:
{code}
repositories
repository
idlocalrepo/id
namelocal module directory/name
urlfile://lib/url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
/repository
/repositories
{code}
Could this be environment-specific? Could you provide a sample project showing
the effect?
Unwanted creation of repository directories
---
Key: MNG-2845
URL: http://jira.codehaus.org/browse/MNG-2845
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.5
Environment: Windows XP, JDK 1.4
Reporter: Holger Hoffstätte
Fix For: 2.0.11
My pom contain a convenience repo:
repository
idlocal (Maven 1)/id
nameLocal module repository (lib)/name
urlfile://lib/url
..etc..
Running mvn eclipse:eclipse with maven 2.0.5 will create that directory in
the filesystem; maven 2.0.4 will not. IMHO creating directories without
explicit instruction is a no-no.
Discussion:
http://www.nabble.com/New-%22feature%22-in-2.0.5%3A-maven-creates-repo-directories-%21-tf3261881s177.html
--
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-3553) cannot resolve dependency with scope import
[
http://jira.codehaus.org/browse/MNG-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164156#action_164156
]
Jacques Morel commented on MNG-3553:
Can we get movement on this bug?
When is 2.0.10 supposed to be out? Do we have really to wait for that release
to be out before this bug becomes active?
We invested significant time migrating our large ant based project into several
multi-module projects heavily using import scope to provide encapsulated set of
dependencies. While migrating our build seemed randomly flaky but since only a
few were working on it they really didn't hit that much having installed all
modules locally. So ironically, now that we are ready to roll it out to our
larger audience, we realize the magnitude of this bug makes it impossible.
cannot resolve dependency with scope import
---
Key: MNG-3553
URL: http://jira.codehaus.org/browse/MNG-3553
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Thomas Diesler
Fix For: 2.0.11
Attachments: mng-3553.zip
This pom when added as a dependency of another project does not see
repository http://snapshots.jboss.org/maven2
!-- DependencyManagement --
dependencyManagement
dependencies
dependency
groupIdorg.jboss.jbossas/groupId
artifactIdjboss-as-component-matrix/artifactId
version${jboss.version}/version
typepom/type
scopeimport/scope
/dependency
/dependencies
/dependencyManagement
with effective settings
[tdies...@tddell trunk]$ mvn help:effective-settings
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] JBoss Web Services - Stack CXF
[INFO] JBoss Web Services - Stack CXF Management
[INFO] JBoss Web Services - Stack CXF Runtime Server
[INFO] JBoss Web Services - Stack CXF Runtime Client
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building JBoss Web Services - Stack CXF
[INFO]task-segment: [help:effective-settings] (aggregator-style)
[INFO]
[INFO] [help:effective-settings]
[INFO]
Effective settings:
?xml version=1.0?settings
localRepository/home/tdiesler/.m2/repository/localRepository
profiles
profile
activation
property
name!jboss.repository.off/name
/property
/activation
repositories
repository
snapshots /
idsnapshots.jboss.org/id
urlhttp://snapshots.jboss.org/maven2/url
/repository
repository
snapshots
enabledfalse/enabled
/snapshots
idrepository.jboss.org/id
urlhttp://repository.jboss.org/maven2/url
/repository
/repositories
idjboss.repository/id
/profile
/profiles
activeProfiles
activeProfileuser-profile/activeProfile
/activeProfiles
pluginGroups
pluginGrouporg.jboss.maven.plugins/pluginGroup
/pluginGroups
/settings
--
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-3553) cannot resolve dependency with scope import
[
http://jira.codehaus.org/browse/MNG-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164167#action_164167
]
Jason van Zyl commented on MNG-3553:
No one has provided a sample project that Ralph can reproduce the problem. As
Ralph has said he would be happy to help resolve the problem back in September.
If you provide a complete example we can use an an integration test and we can
help you. I know that Ralph uses this feature extensive with a large team so
for our particular use we know that it works. If you want us to expand the
parameters of expected or known use then please provide us with a complete test
and/or integration tests.
cannot resolve dependency with scope import
---
Key: MNG-3553
URL: http://jira.codehaus.org/browse/MNG-3553
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Thomas Diesler
Fix For: 2.0.11
Attachments: mng-3553.zip
This pom when added as a dependency of another project does not see
repository http://snapshots.jboss.org/maven2
!-- DependencyManagement --
dependencyManagement
dependencies
dependency
groupIdorg.jboss.jbossas/groupId
artifactIdjboss-as-component-matrix/artifactId
version${jboss.version}/version
typepom/type
scopeimport/scope
/dependency
/dependencies
/dependencyManagement
with effective settings
[tdies...@tddell trunk]$ mvn help:effective-settings
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] JBoss Web Services - Stack CXF
[INFO] JBoss Web Services - Stack CXF Management
[INFO] JBoss Web Services - Stack CXF Runtime Server
[INFO] JBoss Web Services - Stack CXF Runtime Client
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building JBoss Web Services - Stack CXF
[INFO]task-segment: [help:effective-settings] (aggregator-style)
[INFO]
[INFO] [help:effective-settings]
[INFO]
Effective settings:
?xml version=1.0?settings
localRepository/home/tdiesler/.m2/repository/localRepository
profiles
profile
activation
property
name!jboss.repository.off/name
/property
/activation
repositories
repository
snapshots /
idsnapshots.jboss.org/id
urlhttp://snapshots.jboss.org/maven2/url
/repository
repository
snapshots
enabledfalse/enabled
/snapshots
idrepository.jboss.org/id
urlhttp://repository.jboss.org/maven2/url
/repository
/repositories
idjboss.repository/id
/profile
/profiles
activeProfiles
activeProfileuser-profile/activeProfile
/activeProfiles
pluginGroups
pluginGrouporg.jboss.maven.plugins/pluginGroup
/pluginGroups
/settings
--
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: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164171#action_164171 ] James Kato commented on SUREFIRE-377: - Well, I've found a work around which is not too painful, just a little awkward. Because it is the TestNG dependency that triggers surefire to use the TestNG runner to execute JUnit tests, I've moved this dependency out of the main project scope. In order to compile and run all JUnit tests, I exclude the TestNG tests from the compiler and surefire plugins. Then in a profile, I add my TestNG dependency and adjust the compiler and surefire plugins to include the TestNG tests and the test suite file. To run JUnit tests I use: mvn test To run testNG tests I use: mvn test -P testng-profile Simple when you know how. Any better solutions appreciated since I see problems with this as my number of tests increases. James When JUnit and TestNG tests are in same project, only one set gets run -- Key: SUREFIRE-377 URL: http://jira.codehaus.org/browse/SUREFIRE-377 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4 Reporter: Dan Fabulich Fix For: 2.4 Attachments: surefire377.patch, testng-junit-together.zip The attached Maven project has two tests: one JUnit test and one TestNG test. According to the documentation, in this case TestNG should run both tests. Run mvn test. Only the TestNG test will run. If you modify the pom to set the property junit=true, only the JUnit test will run. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4-SNAPSHOT/version configuration properties property namejunit/name valuetrue/value /property /properties /plugin -- 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: (MERCURY-88) enable reading virtual artifacts across repositories
enable reading virtual artifacts across repositories Key: MERCURY-88 URL: http://jira.codehaus.org/browse/MERCURY-88 Project: Mercury Issue Type: Improvement Reporter: Oleg Gusakov Assignee: Oleg Gusakov The first design was that Artifact is kept in one repository, reality dictates that they could spread across multiple -- 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: (MERCURY-88) enable reading virtual artifacts across repositories
[ http://jira.codehaus.org/browse/MERCURY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-88. --- Resolution: Fixed Fix Version/s: 1.0-alpha-5 committed to trunk enable reading virtual artifacts across repositories Key: MERCURY-88 URL: http://jira.codehaus.org/browse/MERCURY-88 Project: Mercury Issue Type: Improvement Components: Repository Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 The first design was that Artifact is kept in one repository, reality dictates that they could spread across multiple -- 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: (MERCURY-88) enable reading virtual artifacts across repositories
[ http://jira.codehaus.org/browse/MERCURY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-88: Component/s: Repository enable reading virtual artifacts across repositories Key: MERCURY-88 URL: http://jira.codehaus.org/browse/MERCURY-88 Project: Mercury Issue Type: Improvement Components: Repository Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 The first design was that Artifact is kept in one repository, reality dictates that they could spread across multiple -- 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: (MERCURY-89) local repository does not utilize full speed of the file system
[ http://jira.codehaus.org/browse/MERCURY-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-89: Fix Version/s: 1.0-alpha-5 local repository does not utilize full speed of the file system --- Key: MERCURY-89 URL: http://jira.codehaus.org/browse/MERCURY-89 Project: Mercury Issue Type: Improvement Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 switch to File APIs -- 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: (MERCURY-89) local repository does not utilize full speed of the file system
local repository does not utilize full speed of the file system --- Key: MERCURY-89 URL: http://jira.codehaus.org/browse/MERCURY-89 Project: Mercury Issue Type: Improvement Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 switch to File APIs -- 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: (MERCURY-89) local repository does not utilize full speed of the file system
[ http://jira.codehaus.org/browse/MERCURY-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-89. --- Resolution: Fixed switched local repository does not utilize full speed of the file system --- Key: MERCURY-89 URL: http://jira.codehaus.org/browse/MERCURY-89 Project: Mercury Issue Type: Improvement Components: Repository Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov Fix For: 1.0-alpha-5 switch to File APIs -- 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
