[jira] Closed: (MIDEA-124) adapt to new idea project files version (8.x or 9.x)
[ http://jira.codehaus.org/browse/MIDEA-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manuel aldana closed MIDEA-124. --- Resolution: Won't Fix i reviewed latest eap intellij 9 and upgrade now works normal and makes no problems the only thing i miss is, that project files do not have information that it is a maven project. but maybe the cost/benefit effort is too high (upgrading/maintaining all intellij releases). but lets hope intellij is always down-compatible to project files of intellij 6 (afaik idea-plugin is generating files for this release). ticket can be closed, for maven-project-knowledge i created differet ticket MIDEA-125. > adapt to new idea project files version (8.x or 9.x) > > > Key: MIDEA-124 > URL: http://jira.codehaus.org/browse/MIDEA-124 > Project: Maven 2.x IDEA Plugin > Issue Type: Improvement >Reporter: manuel aldana > > currently after generating project files starting idea 8 or 9 there always > needs to be an upgrade done by idea. > it would be cool to be better compatible with latest idea versions. maybe by > also passing a plugin property which target-idea-project file version should > be used. -- 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-125) Generate maven-aware project-files
Generate maven-aware project-files -- Key: MIDEA-125 URL: http://jira.codehaus.org/browse/MIDEA-125 Project: Maven 2.x IDEA Plugin Issue Type: New Feature Reporter: manuel aldana Generate project files, which have the information that it is a maven project. Currently I have to click on 'reimport maven project'. While I do many clean checkouts this is cumbersome and sometimes I forget it and wonder why nothing works. This is not a major issue, but should be included when idea-plugin is touched next time. -- 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-124) adapt to new idea project files version (8.x or 9.x)
adapt to new idea project files version (8.x or 9.x) Key: MIDEA-124 URL: http://jira.codehaus.org/browse/MIDEA-124 Project: Maven 2.x IDEA Plugin Issue Type: Improvement Reporter: manuel aldana currently after generating project files starting idea 8 or 9 there always needs to be an upgrade done by idea. it would be cool to be better compatible with latest idea versions. maybe by also passing a plugin property which target-idea-project file version should be used. -- 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: (SUREFIRE-554) Offer excludes/includes setting of -Denv.vars passthrough of forked test-runner
Offer excludes/includes setting of -Denv.vars passthrough of forked test-runner --- Key: SUREFIRE-554 URL: http://jira.codehaus.org/browse/SUREFIRE-554 Project: Maven Surefire Issue Type: Improvement Components: process forking Affects Versions: 2.4.3 Reporter: manuel aldana Offer a possiblity to passthrough env-setting from maven CLI to the forked test-runner. To avoid a passthrough of all -D parameters enable default and configurable excludes. It will avoid a lot of confusion and maven trouble when using CLI params to pass them to the test runner. For discussion see also http://www.nabble.com/passing-through--D-params-from-CLI-to-other-plugins-td24188981.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-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[
http://jira.codehaus.org/browse/MNG-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134770#action_134770
]
manuel aldana commented on MNG-2456:
i got same problem. for the start i workarounded this by setting
false in distribution management for snapshots.
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: 2.0.x
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-3573) Customization of jar-name pattern of classpath-entries inside MANIFEST.MF
Customization of jar-name pattern of classpath-entries inside MANIFEST.MF - Key: MNG-3573 URL: http://jira.codehaus.org/browse/MNG-3573 Project: Maven 2 Issue Type: New Feature Components: maven-archiver Affects Versions: 2.0.8 Reporter: manuel aldana Priority: Critical i followed manifest-customation as explained in: http://maven.apache.org/shared/maven-archiver/index.html what i really miss, is to configure the classpath pattern of the dependency jar-names. the only customization of classpath entries is possible by setting the classpath prefix () and (). unfortunately it is not possible to set the jar-name pattern itself. to avoid library name-clashes we got pattern $groupId-$artifactId-$version for jars which are put besides the main-jar. by default maven-archiver only sets $artifactId-$version. so it would be nice to have a possible configuration like or similar inside maven archive-configuration . -- 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-3564) alternative and higher level configuration option to
alternative and higher level configuration option to Key: MNG-3564 URL: http://jira.codehaus.org/browse/MNG-3564 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.9 Reporter: manuel aldana maven provides scope (test, runtime etc.) to filter certain dependencies. never the less sometimes it is quite helpful to have a another configuration option, where you decide what to include transitively or what kind of dependency-set is relevant to your current project. using configuration to accomplish this is often very verbose, non-standard and is difficult to read (it is often not obvious what is meant with all these exclusions). as an example ivy includes such configuration meta-info approach (see http://ant.apache.org/ivy/m2comparison.html). this feature would be nice because when building releases one is more flexible. -- 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-3472) configuration possibilities to limit size of local repository
configuration possibilities to limit size of local repository - Key: MNG-3472 URL: http://jira.codehaus.org/browse/MNG-3472 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.8 Reporter: manuel aldana it would be great to make repository-size configurable, for instance by setting the maximum number of downloads of a snapshot-version to be kept. thus the explosion of local repository size can be reduced. especially when you are working with many in-house multi-module projects which are marked as snapshots before released , can increase repository size significantly. see mailing-list discussion: http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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] Created: (SUREFIRE-458) alternative test-class scanner (by type filter)
alternative test-class scanner (by type filter)
Key: SUREFIRE-458
URL: http://jira.codehaus.org/browse/SUREFIRE-458
Project: Maven Surefire
Issue Type: Improvement
Components: plugin
Affects Versions: 2.4.1
Reporter: manuel aldana
hi,
currently test filtering is done by using the directive, which
includes test-classes by file name pattern. this approach is sometimes a bit
annoying for namings of classes are unreliable. test data classes are sometimes
named like TestDataForXXX or XXXDataForTest so they are included to testsuite
too.
a better approach would be to scan test classes by the type. currently we are
using gsbase-test-suite scanner to accomplish this. it would be cool if this
kind of scanner would be included in surefire-plugin, so it is not neccessary
to implement such a collector for each project.
following code as example (scans for test-classes which are concrete):
{code:java title=Test-class Scanner}
import java.lang.reflect.Modifier;
import com.gargoylesoftware.base.testing.RecursiveTestSuite;
import com.gargoylesoftware.base.testing.TestFilter;
import junit.framework.Test;
/** @author manuel aldana, [EMAIL PROTECTED] */
public class TestCaseCollector {
/** @return Testsuite, which returns all concrete Test-classes */
public static Test suite() throws Exception {
return new RecursiveTestSuite("target/test-classes", new
TestFilter() {
public boolean accept(Class clazz) {
if (isConcreteTestCase(clazz))
return true;
return false;
}
});
}
private static boolean isConcreteTestCase(Class clazz) {
if (isAbstractClass(clazz))
// it is assumed, that abstract classes have no
superclasses which are concrete test classes
return false;
if (clazz.getSuperclass().getName().equals("java.lang.Object"))
return false;
if
(clazz.getSuperclass().getName().equals("junit.framework.TestCase"))
return true;
// recurse to parents
return isConcreteTestCase(clazz.getSuperclass());
}
private static boolean isAbstractClass(Class clazz) {
if (Modifier.isAbstract(clazz.getModifiers()))
return true;
return false;
}
}
{code}
--
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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111384 ] manuel aldana commented on MNG-3252: it is a complete miracle. after downloading and installing a fresh maven-2.0.7.bin.zip it worked. still my not working maven installation with 'mvn -version' showed version 2.0.7. just weird! indeed the contents of my not working maven showed a different checksum, maybe transimission errors or similar, though i assumed that file corruptions are already handled by the unpack programm through checksums... > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip, pomProjectA.xml, > pomProjectB.xml, settings.xml > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > 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] Commented: (MNG-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111289 ] manuel aldana commented on MNG-3252: this bug has somewhere already been fixed: i tried version of release candiate 2.0.8 (see http://www.nabble.com/2.0.8-Release-Candidate-tf4681576s177.html) and with this snapshot downloading works. > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: pomProjectA.xml, pomProjectB.xml, settings.xml > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > 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: (MNG-3252) SNAPSHOTS: updatePolicy always gets ignored
SNAPSHOTS: updatePolicy always gets ignored --- Key: MNG-3252 URL: http://jira.codehaus.org/browse/MNG-3252 Project: Maven 2 Issue Type: Bug Components: General, POM, Settings Affects Versions: 2.0.7 Reporter: manuel aldana Priority: Blocker Attachments: pomProjectA.xml, pomProjectB.xml, settings.xml i am working with snapshots and therefore i am setting the always of internal repository. This is not working and basically makes working with SNAPSHOTS impossible, which is highly severe in many maven development processes. for details see attached files. the setting is that project A is depending on project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn compile' of project A gets executed, maven does not look up for a fresh version of project B. in my view it ignores the always snapshot setting and uses the default daily flag. the reason for this assumption is that the day after executing 'mvn compile', it checked for a new version. please advice what i can do to have this issue fixed (this is a total blocker with working with maven in our development). if this cannot be fixed for 2.0.7 quickly, please tell which version i can use, maybe it has been fixed already (though could not find a matching bug report). when trying to reproduce with attached files watch out, that the url of internal repository needs to be adjusted. 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: (MASSEMBLY-242) transitive dependencies do not get included
transitive dependencies do not get included --- Key: MASSEMBLY-242 URL: http://jira.codehaus.org/browse/MASSEMBLY-242 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: maven 2.0.7 Reporter: manuel aldana Priority: Blocker i am using assembly plugin with standard descriptor jar-with-dependencies. problem is that transitive dependencies do not get included. pom.xml from project A: ... a a 1.0 tran dep 1.0 ... pom.xml from project B: ... b b 1.0 ... enabling assembly-plugin with jar-with-dependencies... a a 1.0 ... i am doing assembly:assembly on b:b. now tran:dep does not get included though it is defined in a:a. that means: if i open the assembled jar-file (from b:b) i cannot see any artifacts from tran:dep. for earlier discussion on mailingslist see http://www.nabble.com/assembly-plugin%3A-transitive-dependencies-do-not-get-included-tf4317601s177.html#a12308820 -- 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: (MECLIPSE-321) aborts build when pom.xml in version 3 is hit
aborts build when pom.xml in version 3 is hit - Key: MECLIPSE-321 URL: http://jira.codehaus.org/browse/MECLIPSE-321 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: m2eclipse snapshot 0.0.11.20070603-1200 Reporter: manuel aldana when building a warning is given that resolved pom is of version 3. after that build crashes with message: "Unable to read model from /Bla/pom.xml " it should behave like command client mvn. provide warning message but proceed with the build. pom example, which reproduces failure (-> streambuffer references org.jvnet.staxex:stax-ex:1.0 , which is of pom version 3): http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 Bla Bla 0.0.1 javax.xml.stream streambuffer 0.3 true -- 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
