[jira] Commented: (MECLIPSE-407) EclipsePlugin parameter to skip dependency resolution
[
http://jira.codehaus.org/browse/MECLIPSE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132572#action_132572
]
Yuri Schimke commented on MECLIPSE-407:
---
Because we want PDE dependencies in the Eclipse, we have the above change.
However we also want our products to deploy with either
- built JAR files i.e. valid OSGi bundles built by maven
- With project open in Eclipse workspace so we can make code changes etc
To get the second to work, you also need a build.properties file, so we have
ended up with the following
public class BaclipsePlugin extends EclipsePlugin {
protected void setupExtras() throws MojoExecutionException {
if (isPdeProject()) {
// disable normal dependency resolution
setResolveDependencies(false);
}
}
protected void writeOsgiManifest(EclipseWriterConfig config) throws
MojoExecutionException {
}
protected void writeBuildProperties(EclipseWriterConfig config) throws
MojoExecutionException {
File projectRelativeFile = new File(getEclipseProjectDir(),
"build.properties");
StringBuilder content = new StringBuilder();
String sourceDirectories = getSourceDirectoriesString(config);
content.append("source.. = " + sourceDirectories + "\n");
String outputDirectories = getOutputDirectoriesString(config);
content.append("output.. = " + outputDirectories + "\n");
String binIncludes = getIncludesString(config);
content.append("bin.includes = " + binIncludes + "\n");
try {
FileUtils.fileWrite(projectRelativeFile.getAbsolutePath(),
content.toString());
} catch (IOException e) {
throw new
MojoExecutionException(Messages.getString("EclipsePlugin.cantwritetofile",
//$NON-NLS-1$
projectRelativeFile.getAbsolutePath()));
}
}
private String getIncludesString(EclipseWriterConfig config) {
return "META-INF/";
}
private String getSourceDirectoriesString(EclipseWriterConfig config) {
StringBuilder string = new StringBuilder();
EclipseSourceDir[] sourceDirs = config.getSourceDirs();
for (int i = 0; i < sourceDirs.length; i++) {
if (i > 0) {
string.append(",");
}
string.append(sourceDirs[i].getPath());
}
return string.toString();
}
private String getOutputDirectoriesString(EclipseWriterConfig config) throws
MojoExecutionException {
Set paths = new HashSet();
StringBuilder string = new StringBuilder();
EclipseSourceDir[] sourceDirs = config.getSourceDirs();
for (int i = 0; i < sourceDirs.length; i++) {
String outputDir = sourceDirs[i].getOutput();
if (outputDir == null) {
outputDir =
IdeUtils.toRelativeAndFixSeparator( config.getProjectBaseDir(),
config.getBuildOutputDirectory(), false );
}
if (paths.add(outputDir)) {
if (string.length() > 0) {
string.append(",");
}
string.append(outputDir);
}
}
return string.toString();
}
}
> EclipsePlugin parameter to skip dependency resolution
> -
>
> Key: MECLIPSE-407
> URL: http://jira.codehaus.org/browse/MECLIPSE-407
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: PDE support
>Affects Versions: 2.5
>Reporter: Yuri Schimke
>
> Because all our projects are PDE projects, we don't need want all the JARs
> copied locally and added to the classpath.
> Because there is no option to stop them being added to .classpath apart from
> adding a lot of excludes, we have a subclass of EclipsePlugin that does a
> similar tihng to the M2EclipsePlugin
> protected void setupExtras() throws MojoExecutionException {
> if (isPdeProject()) {
> // disable normal dependency resolution
> setResolveDependencies(false);
> }
> }
> However, it we could set a flag to stop dependency resolution, we would not
> need to maintain our own plugin. i.e. add the parameter javadoc.
> /**
> * Flag for mojo implementations to control whether normal maven
> dependencies should be resolved. Default value is
> * true.
> *
> * @parameter expression="${eclipse.resolveDependencies}"
> default-value="true"
> */
> private boolean resolveDependencies = 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
[jira] Commented: (MSHADE-30) duplicate entry error
[ http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132574#action_132574 ] Michael Mattox commented on MSHADE-30: -- For me a clean doesn't make it work. :( I'm now using assembly. > duplicate entry error > - > > Key: MSHADE-30 > URL: http://jira.codehaus.org/browse/MSHADE-30 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0.1 >Reporter: Michael Mattox > > I receive this error: > Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class > It started with a javax.xml.namespace class. So I started putting excludes, > and then I kept getting one new class after another. If I exclude everything > then I doubt my application is going to work. > I really don't understand this error. I have never seen this type of error > with the fatjar eclipse plugin. I understand it's complaining about having > the same class twice, but if it's not a problem for my eclipse project or the > maven build, why is it a problem for shade? > I feel the shade plugin should be able to handle this gracefully. -- 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
thanks in advance -- > issue running maven site
Iam trying to run maven site from my local windows vista machine iam getting the following error [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org/apache/commons/beanutils/Converter at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle (CheckstyleReport.java:786) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(Che ckstyleReport.java:582) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMaven Report.java:98) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(R eportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule( DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(Defaul tSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129 ) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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) [INFO] [INFO] Total time: 18 seconds [INFO] Finished at: Fri Apr 25 12:00:13 IST 2008 [INFO] Final Memory: 32M/57M [INFO] Please help me on this Thanks in advance sangeeth j - Bring your gang together. Do your thing. Find your favourite Yahoo! Group.
[jira] Updated: (SCM-364) NPE in StarteamChangeLogCommand
[ http://jira.codehaus.org/browse/SCM-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SCM-364: - Fix Version/s: (was: 1.x) 1.1 > NPE in StarteamChangeLogCommand > --- > > Key: SCM-364 > URL: http://jira.codehaus.org/browse/SCM-364 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-starteam >Affects Versions: 1.0 >Reporter: Olivier Lamy >Assignee: Dan Tran > Fix For: 1.1 > > > look CONTINUUM-1521 -- 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-612) implement conflict resolution techniques
[ http://jira.codehaus.org/browse/MNG-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132584#action_132584 ] Mark Hobson commented on MNG-612: - The maven-artifact changes from this patch have been committed to maven-artifact 3.x. Only Maven 2.1 is using this version, see MNG-3205 for switching Maven 2.0.x over. The rest of the patch outside of maven-artifact still needs to be applied to 2.0.x and 2.1. > implement conflict resolution techniques > > > Key: MNG-612 > URL: http://jira.codehaus.org/browse/MNG-612 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories, Design, Patterns & Best > Practices >Reporter: Brett Porter >Assignee: Mark Hobson >Priority: Critical > Fix For: 2.1 > > Attachments: MNG-612-2.patch, MNG-612-3.patch, MNG-612.patch > > Original Estimate: 8 hours > Remaining Estimate: 8 hours > > currently, the collector only: > - selects nearest "suggested" version in a valid range > - latest version from the valid ranges if none suggested > - fails if ranges are over-constrained > This needs to be configurable: > - select newest, even if there is a nearer suggestion > - select oldest, even if there is a nearer suggestion > - fail if all suggestions don't equate or a range results instead of a single > version > - ignore over constrained ranges and fallback to some other algorithm > - select snapshots even if they weren't explicitly specified -- 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: (SCM-182) git provider
[
http://jira.codehaus.org/browse/SCM-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SCM-182:
-
Fix Version/s: (was: future)
1.1
> git provider
>
>
> Key: SCM-182
> URL: http://jira.codehaus.org/browse/SCM-182
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-git
> Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
>Reporter: Dominik Winter
>Assignee: Jason van Zyl
> Fix For: 1.1
>
> Attachments: git.patch, git.tar.bz2, SCM-182.patch, update1.patch.bz2
>
>
> Please find the git provider as attachment.
> Usefulness:
> I used the git provider together with
> [http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
> it works fine for that use case.
> Open issues:
> - the JUnit tests are "proprietary", not yet TCK. I'll fix that.
> If you want to run the tests, you must have git installed and it must be in
> your {{PATH}}.
> To run git:
> - on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
> openssh, openssl, rsync, curl
> than you are able to compile and install git
> - on Linux: there are packages somewhere
> - on Mac OS X: use the [DarwinPorts|http://www.darwinports.org/]
--
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-3507) ANSI Color logging for improved output visibility.
[ http://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132597#action_132597 ] David Bernhard commented on MNG-3507: - Yes. It's possible - I've made a maven project that does it. The only catch is that under windows, while it works perfectly in cygwin xterms the native CMD.exe does not support it. I'll attach a zip in a minute. > ANSI Color logging for improved output visibility. > -- > > Key: MNG-3507 > URL: http://jira.codehaus.org/browse/MNG-3507 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur > > Is it possible for Maven to use ANSI color logging? IMO it would make Maven > logs much easier to read and increase the visibility of items that the user > want to see at any given point in time. > I think Andrew Williams did some work under Plexus sandbox to enable color > logging. There also a color logger available in Ant. > http://ant.apache.org/manual/listeners.html#AnsiColorLogger -- 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-3507) ANSI Color logging for improved output visibility.
[
http://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bernhard updated MNG-3507:
Attachment: maven-colorlogger.zip
To install, make the project and put the jar in {{$M2_HOME/lib}}.
Then, patch the plexus file in the maven uberjar:
In {{lib/}}, execute
{{jar xf maven-2.0.9-uber.jar org/codehaus/plexus/plexus-bootstrap.xml}}
In the unzipped file, edit the entry
{{org.codehaus.plexus.logging.console.ConsoleLoggerManager}}
to
{{ch.elca.el4j.maven.logging.FormattedLoggerManager}}
add it to the uberjar with (again in lib/)
{{jar uf maven-2.0.9-uber.jar org/codehaus/plexus/plexus-bootstrap.xml}}
and delete the org/ directory.
Ansi color is output only when you call maven with the option
*{{-Dplexus.logger.type=ansi}}*.
> ANSI Color logging for improved output visibility.
> --
>
> Key: MNG-3507
> URL: http://jira.codehaus.org/browse/MNG-3507
> Project: Maven 2
> Issue Type: Improvement
>Reporter: Rahul Thakur
> Attachments: maven-colorlogger.zip
>
>
> Is it possible for Maven to use ANSI color logging? IMO it would make Maven
> logs much easier to read and increase the visibility of items that the user
> want to see at any given point in time.
> I think Andrew Williams did some work under Plexus sandbox to enable color
> logging. There also a color logger available in Ant.
> http://ant.apache.org/manual/listeners.html#AnsiColorLogger
--
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-3491) JAR hell detection
[ http://jira.codehaus.org/browse/MNG-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132599#action_132599 ] David Bernhard commented on MNG-3491: - I have written a plugin to do almost exactly this. It inspects all class files and warns or fails if a class is twice on the classpath. There's also an optional gui that shows a tree of all loaded classes and which jar they come from. Bytewise comparison isn't there yet but wouldn't be hard to add. At the moment it's part of the maven utilities in our EL4J framework [http://el4j.sourceforge.net], as it was created to help build el4j (with maven, of course). I can see about releasing it without any dependencies on el4j core if you're interested. > JAR hell detection > -- > > Key: MNG-3491 > URL: http://jira.codehaus.org/browse/MNG-3491 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Andreas Krüger > > When your dependency tree contains the same class twice in two different > versions, you are in JAR hell. > I want Maven to detect whether that's where I am. So Maven should: > * Open all JARs it has added to a dependency tree. > * Check what classes are in each JAR (package name and class name). > * If the same class is found twice in two different JARs, I want Maven to > ** compare the two instances > ** fail the build unless they turn out to be bytewise identical. > All of these things should happen automatically, with every individual > dependency tree. > Unless the user specifically requests. E.g., if the user knows a particular > set of classes is officially in the dependency tree (e.g., of a test), but > never actually loaded, it should be possible to accept different versions of > these classes (some wild card pattern). > Regards, and thank you for providing fine software, > Andreas -- 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-3548) [maven-dependency-tree] Managed information lost when artifact previously encountered
[maven-dependency-tree] Managed information lost when artifact previously
encountered
-
Key: MNG-3548
URL: http://jira.codehaus.org/browse/MNG-3548
Project: Maven 2
Issue Type: Bug
Components: Shared
Affects Versions: Shared Components
Reporter: Mark Hobson
The scenario:
{noformat}
(managed: g:c:t:2)
g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- g:c:t:1
\- g:c:t:1{noformat}
Should result in:
{noformat}g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
\- g:c:t:2 (version managed from 1){noformat}
But becomes:
{noformat}g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
\- g:c:t:2{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] Created: (MNG-3547) Profiling patch to display times of individual project/goal executions.
Profiling patch to display times of individual project/goal executions. --- Key: MNG-3547 URL: http://jira.codehaus.org/browse/MNG-3547 Project: Maven 2 Issue Type: Improvement Components: Performance Affects Versions: 2.0.9 Environment: Maven 2.0.9 Reporter: David Bernhard Priority: Minor Attachments: maven-profiler.patch We have a maven project that takes about 10 minutes to build from the root pom. To analyze which parts of the build are the most time-intensive, I wrote a small profiling patch to maven 2.0.9. Running "mvn --profile" outputs information for each project and each goal of a plugin. It would be nice to have such an option available by default in maven. -- 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] Issue Comment Edited: (MNG-3548) [maven-dependency-tree] Managed information lost when artifact previously encountered
[
http://jira.codehaus.org/browse/MNG-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132600#action_132600
]
mihobson edited comment on MNG-3548 at 4/25/08 6:56 AM:
---
Added commented-out
{{testProjectWithManagedTransitiveDependencyVersionAndDuplicate}} to reproduce
the problem.
was (Author: mihobson):
Added commented-out
testProjectWithManagedTransitiveDependencyVersionAndDuplicate to reproduce the
problem.
> [maven-dependency-tree] Managed information lost when artifact previously
> encountered
> -
>
> Key: MNG-3548
> URL: http://jira.codehaus.org/browse/MNG-3548
> Project: Maven 2
> Issue Type: Bug
> Components: Shared
>Affects Versions: Shared Components
>Reporter: Mark Hobson
>
> The scenario:
> {noformat}
> (managed: g:c:t:2)
> g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- g:c:t:1
>\- g:c:t:1{noformat}
> Should result in:
> {noformat}g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
>\- g:c:t:2 (version managed from 1){noformat}
> But becomes:
> {noformat}g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
>\- g:c:t:2{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] Commented: (MNG-3548) [maven-dependency-tree] Managed information lost when artifact previously encountered
[
http://jira.codehaus.org/browse/MNG-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132600#action_132600
]
Mark Hobson commented on MNG-3548:
--
Added commented-out
testProjectWithManagedTransitiveDependencyVersionAndDuplicate to reproduce the
problem.
> [maven-dependency-tree] Managed information lost when artifact previously
> encountered
> -
>
> Key: MNG-3548
> URL: http://jira.codehaus.org/browse/MNG-3548
> Project: Maven 2
> Issue Type: Bug
> Components: Shared
>Affects Versions: Shared Components
>Reporter: Mark Hobson
>
> The scenario:
> {noformat}
> (managed: g:c:t:2)
> g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- g:c:t:1
>\- g:c:t:1{noformat}
> Should result in:
> {noformat}g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
>\- g:c:t:2 (version managed from 1){noformat}
> But becomes:
> {noformat}g:p:t:1
> \- g:a:t:1
>+- g:b:t:1
>| \- (g:c:t:2 - version managed from 1; omitted for duplicate)
>\- g:c:t:2{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] Created: (MECLIPSE-444) Included Resources break the classpath file and prevent eclipse from building
Included Resources break the classpath file and prevent eclipse from building
-
Key: MECLIPSE-444
URL: http://jira.codehaus.org/browse/MECLIPSE-444
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
Affects Versions: 2.5.1
Reporter: Ian Boston
In Apache Shingig we have more than one language using a set of resources (PHP
and Java), so the resources are stored on disk in a relative path.
In the jars we have
features
${basedir}/../../features
${basedir}/../../javascript/
/gadgets/files
**/*.*
etc
which results in a .classpath
shroud:~/Caret/sakai22/devcode/shindig-trunk ieb$ more java/server/.classpath
The first 3 entries are invalid as they are outside the project space the
eclipse project.
Since this breaks the eclipse build, I am classifying this as a bug you
might want to reclassify.
The work around is simple, but it generating questions on the list and
resulting in people not wanting to use the eclipse 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: (SUREFIRE-486) Exlude tests via an external exlude file
Exlude tests via an external exlude file Key: SUREFIRE-486 URL: http://jira.codehaus.org/browse/SUREFIRE-486 Project: Maven Surefire Issue Type: New Feature Reporter: Thomas Diesler Similar to Ant, Surefire should support excludes defined in an external file like this test-excludes-jboss501.txt The exclude file would look like this # [JBWS-2135] WebServiceException: Undefined port type org/jboss/test/ws/jaxws/jbws1822/** # [JBWS-2136] ClassCastException: com.sun.xml.ws.server.EndpointMessageContextImpl org/jboss/test/ws/jaxws/namespace/** # [JBAS-5359] mapped-name is required for context of deployment org/jboss/test/ws/jaxws/jbws1611/** -- 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: (JXR-60) use ${project.build.sourceEncoding} as default value for "inputEncoding" parameter
[
http://jira.codehaus.org/browse/JXR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132613#action_132613
]
Herve Boutemy commented on JXR-60:
--
I forgot this one: thanks for the reminder
done in r651592
> use ${project.build.sourceEncoding} as default value for "inputEncoding"
> parameter
> --
>
> Key: JXR-60
> URL: http://jira.codehaus.org/browse/JXR-60
> Project: Maven JXR
> Issue Type: Improvement
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.2
>
>
> see
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
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-162) Prepend java package declaration to the java file path
Prepend java package declaration to the java file path
--
Key: ARCHETYPE-162
URL: http://jira.codehaus.org/browse/ARCHETYPE-162
Project: Maven Archetype
Issue Type: Improvement
Components: Creator
Affects Versions: 2.0-alpha-2
Reporter: Bruno Bieth
If I define a java class like that :
{code:java}
package ${package}.another.package;
public class AClass {
...
}
{code}
Then I would expect to see this class in folder
src/main/java/${package}/another/package
and not in src/main/java/${package}
--
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-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-3268: --- Attachment: MNG-3268-maven-core.patch Attaching a small patch to allow -P to be specified multiple times. > Command line doesn't handle multiple -P correctly > - > > Key: MNG-3268 > URL: http://jira.codehaus.org/browse/MNG-3268 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Henri Tremblay > Attachments: MNG-3268-maven-core.patch > > > It is currently not possible to have more than one -P on the same command > line. Only the first specified profile is considered. > So if you do > mvn -Pmain -Ptest > only the main profile will be taken into account. > This may sound enough but it's not when your maven call is wrapped into a > batch file. Let's say you have a batch doing the compilation of a given > module: > a.bat > - > mvn install -Pmymodule %* > - > and you want to pass a special integration tests profile you would do: > a.bat -Pintegration-tests > But that won't work since you are not allowed to have two -P. > To merge them in DOS shell is quite a pain in the *** -- 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: (MRELEASE-256) ArrayIndexOutOfBoundsException using custom tagBase.
[ http://jira.codehaus.org/browse/MRELEASE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-256. -- Resolution: Duplicate I believe this is a duplicate of MRELEASE-236 which was fixed in 2.0-beta-7. > ArrayIndexOutOfBoundsException using custom tagBase. > > > Key: MRELEASE-256 > URL: http://jira.codehaus.org/browse/MRELEASE-256 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: Ubuntu 7.04 > Java 1.6.0_02-ea > Maven 2.0.6 >Reporter: Mark Soderquist > > My project SVN connection is: > http://svn.novaworx.org/software/utility/trunk > I would like to put the release tag at > http://svn.novaworx.org/software/utility/1.0. > I specified the following on the command line: > mvn release:prepare -DdryRun=true > -DtagBase="http://svn.novaworx.org/software/utility"; > What is the release version for "Novaworx Utility Library"? > (org.novaworx:utility) 1.0: : [Enter] > What is SCM release tag or label for "Novaworx Utility Library"? > (org.novaworx:utility) utility-1.0: : 1.0[Enter] > What is the new development version for "Novaworx Utility Library"? > (org.novaworx:utility) 1.1-SNAPSHOT: : [Enter] > and received the following exception: > java.lang.ArrayIndexOutOfBoundsException: 48 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:691) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:190) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > 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) -- 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-2443) Don't download pom if artifact is already in the local repository
[ http://jira.codehaus.org/browse/MNG-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132631#action_132631 ] Matthew Buckett commented on MNG-2443: -- One issue is that if a POM isn't present for a artifact then the download of this POM is attempted every build even if the repository is configured to only be checked for updates less frequently, this can make a large build slow down considerably. > Don't download pom if artifact is already in the local repository > - > > Key: MNG-2443 > URL: http://jira.codehaus.org/browse/MNG-2443 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Jason van Zyl > Fix For: 2.1 > > > There are many projects out there just providing their artifact without a pom > (whether this is good or not is a different question). Now in this case m2 > always tries to download a pom for those artifacts, even if the artifact > itself is already in the local repository. And if you have several of those > artifacts combined with more than one repository configured, then there are a > lot of unnecessary download attempts. > I think this falls into the same category as changing a pom in the repository > (which should be forbidden) - so if for the first time the artifact is > downloaded no pom available, then there will never be a pom for this specific > artifact. -- 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-3412) State of Maven Embedder and documentation
[ http://jira.codehaus.org/browse/MNG-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132632#action_132632 ] Jon Lorusso commented on MNG-3412: -- This page: http://www.propellors.net/maven/site/guides/mini/guide-embedding-m2.html seems to reflect the state of the code a bit more accurately (in that the methods exist, and the code almost works). I agree, however, that the disarray made me wonder if the Embedder was still alive. It's version number (2.0.4) also lags behind the rest of the maven modules (2.0.9 as of this writing). I would love to hear from someone "official" as to where this project stands. > State of Maven Embedder and documentation > - > > Key: MNG-3412 > URL: http://jira.codehaus.org/browse/MNG-3412 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Dimitry Voytenko > > Is Meven Embedder project still alive? The documentation in > http://maven.apache.org/guides/mini/guide-embedding-m2.html doesn't match > org.apache.maven/maven-embedder artifact at all (I tried against 2.0.4 > version). -- 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: (MRELEASE-317) release:prepare should fail if any pom depends on SNAPSHOT parent
[ http://jira.codehaus.org/browse/MRELEASE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132634#action_132634 ] Paul Gier commented on MRELEASE-317: I wasn't able to reproduce this. I tried it with a simple project that depends on a SNAPSHOT version of a separate parent, and the release plugin would not allow me to release due to the snapshot dependency. Can you provide more information and/or a sample project for this? > release:prepare should fail if any pom depends on SNAPSHOT parent > - > > Key: MRELEASE-317 > URL: http://jira.codehaus.org/browse/MRELEASE-317 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: maven-2.0.8 > java-1.6 >Reporter: Petr Kozelka >Priority: Critical > > Currently the release plugin happily releases a pom that declares a SNAPSHOT > version of parent. > Such a release is exposed to a danger of irreproducibility: > 1.) on another machine > 2.) at another time (parent may significantly change in the meantime) > While it can be sometimes convenient, it is, as I am quite sure, a bad > behavior. -- 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-487) We're using DynamicJasper to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the applicatio
We're using DynamicJasper to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the application. But when we run our test, the compiler can't find any classes in the classpath. --- Key: SUREFIRE-487 URL: http://jira.codehaus.org/browse/SUREFIRE-487 Project: Maven Surefire Issue Type: Bug Components: classloading Reporter: Márcio. P. D. Priority: Blocker Attachments: TesteCaseDJSureFire.zip We're using DynamicJasper ( http://dynamicjasper.sourceforge.net/ ) to create reports in our web application. DynamicJasper creates a java report file at runtime and compiles it. It works fine in the application. But when we run our test, the compiler can't find any classes in the classpath. A test case is provided with the problematic test. -- 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-488) Document TestNG listeners/reporters
Document TestNG listeners/reporters --- Key: SUREFIRE-488 URL: http://jira.codehaus.org/browse/SUREFIRE-488 Project: Maven Surefire Issue Type: Task Components: documentation, TestNG support Reporter: Dan Fabulich TestNG listeners/reporters are kind of tricky. The TestNG documentation should be updated to explain how to do this. http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/testng-listener-reporter -- 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] Issue Comment Edited: (ARCHETYPE-162) Prepend java package declaration to the java file path
[
http://jira.codehaus.org/browse/ARCHETYPE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132638#action_132638
]
raphael edited comment on ARCHETYPE-162 at 4/25/08 10:23 AM:
-
Put your java class in
src/main/resources/archetype-resources/src/main/java/another/package
was (Author: raphael):
Put your java class in
src/main/resources/archetype-resources/src:main/java/another/package
> Prepend java package declaration to the java file path
> --
>
> Key: ARCHETYPE-162
> URL: http://jira.codehaus.org/browse/ARCHETYPE-162
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Creator
>Affects Versions: 2.0-alpha-2
>Reporter: Bruno Bieth
>
> If I define a java class like that :
> {code:java}
> package ${package}.another.package;
> public class AClass {
> ...
> }
> {code}
> Then I would expect to see this class in folder
> src/main/java/${package}/another/package
> and not in src/main/java/${package}
--
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: (ARCHETYPE-162) Prepend java package declaration to the java file path
[
http://jira.codehaus.org/browse/ARCHETYPE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132638#action_132638
]
Raphaël Piéroni commented on ARCHETYPE-162:
---
Put your java class in
src/main/resources/archetype-resources/src:main/java/another/package
> Prepend java package declaration to the java file path
> --
>
> Key: ARCHETYPE-162
> URL: http://jira.codehaus.org/browse/ARCHETYPE-162
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Creator
>Affects Versions: 2.0-alpha-2
>Reporter: Bruno Bieth
>
> If I define a java class like that :
> {code:java}
> package ${package}.another.package;
> public class AClass {
> ...
> }
> {code}
> Then I would expect to see this class in folder
> src/main/java/${package}/another/package
> and not in src/main/java/${package}
--
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: (ARCHETYPE-162) Prepend java package declaration to the java file path
[
http://jira.codehaus.org/browse/ARCHETYPE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132641#action_132641
]
Bruno Bieth commented on ARCHETYPE-162:
---
Thanks, for the comment.
Yes, that's fine as long as you don't use variable in the package declaration
and you always add ${package} at the beginning.
What if I want :
package ${package}.${artifactId}.apackage;
Maybe nobody defines packages like that :)
I know I'm picky but this would ensure that classes are in the right folder.
Thanks
> Prepend java package declaration to the java file path
> --
>
> Key: ARCHETYPE-162
> URL: http://jira.codehaus.org/browse/ARCHETYPE-162
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Creator
>Affects Versions: 2.0-alpha-2
>Reporter: Bruno Bieth
>
> If I define a java class like that :
> {code:java}
> package ${package}.another.package;
> public class AClass {
> ...
> }
> {code}
> Then I would expect to see this class in folder
> src/main/java/${package}/another/package
> and not in src/main/java/${package}
--
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-3527) profile deactivation has no affect
[ http://jira.codehaus.org/browse/MNG-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3527: --- Fix Version/s: 2.0.10 > profile deactivation has no affect > -- > > Key: MNG-3527 > URL: http://jira.codehaus.org/browse/MNG-3527 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Trenton > Fix For: 2.0.10 > > > Brian looked at the source code, and it appears that deactivation of profiles > should work. I'm using a profile that is active by default, and I want to > override this. > The following command shows that deactivating my profile is not working. I > tried this on 2.0.8 and 2.0.9 > mvn help:active-profiles -P-oros > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building oros web component > [INFO]task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'ca.athabascau.banner:web:war:1.1.23-SNAPSHOT': > The following profiles are active: > - oros (source: settings.xml) > - dev (source: settings.xml) > - oros (source: settings.xml) > - dev (source: settings.xml) > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Apr 15 16:25:15 MDT 2008 > [INFO] Final Memory: 3M/5M > [INFO] > -- 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-321) artifact unavailable to other modules in the same build during 'mvn package'
artifact unavailable to other modules in the same build during 'mvn package'
Key: MASSEMBLY-321
URL: http://jira.codehaus.org/browse/MASSEMBLY-321
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: unix, windows
Maven version: 2.0.9
Java version: 1.5.0_14
Reporter: deckrider
in a multi module build ('mvn package') with two two modules:
assembly-module
other-module
and where other-module depends on assembly-module:
the assembly-module is unavailable to the other-modules as a dependency.
(during 'mvn install' it works fine, since the assembly-module is added to the
local repository before it is needed by the other-module)
--
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-3549) Integration Test Executor Fails to Find Maven Distribution
Integration Test Executor Fails to Find Maven Distribution
--
Key: MNG-3549
URL: http://jira.codehaus.org/browse/MNG-3549
Project: Maven 2
Issue Type: Bug
Components: integration tests
Affects Versions: 2.0.x
Reporter: Shane Isbell
Priority: Minor
Attachments: dist.patch
maven-core-it-runner has a dependency on apache-maven-${version}.tar.gz. But
maven-distribution is packaging as maven-distribution-${version}.tar.gz. On a
clean build, IT tests will fail to build due to missing artifacts. On other
builds, IT tests will test older versions of the build.
--
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-3535) Valid properties which look self referential fail to resolve
[
http://jira.codehaus.org/browse/MNG-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3535:
--
Attachment: model-int.patch
Patch for this issue. If the system property starts with 'pom.' or 'project.'
then self -references are not allowed. But if the self-reference is anything
else (outside of the model), it is allowed.
> Valid properties which look self referential fail to resolve
>
>
> Key: MNG-3535
> URL: http://jira.codehaus.org/browse/MNG-3535
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9
>Reporter: Chris Custine
> Fix For: 2.0.10
>
> Attachments: model-int.patch
>
>
> In 2.0.9 properties which look self referential but would otherwise resolve
> to a system property are failing due to fixes for MNG-2339. Current example
> is any version of jruby shared pom at
> http://repo1.maven.org/maven2/org/jruby/shared/1.0.1/shared-1.0.1.pom
> which contains:
> ${java.specification.version}
> The question is whether this should be valid or not, but it has worked in
> every version up to and including 2.0.8 because System properties were
> available in the first interpolate step. In 2.0.9 this first pass does not
> include the system props and an exception is thrown because of the self
> reference 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] Closed: (MINVOKER-6) Add current's project test classpath to the Bean Shell interpreter classpath
[
http://jira.codehaus.org/browse/MINVOKER-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-6.
Assignee: Benjamin Bentmann (was: John Casey)
Resolution: Fixed
Fix Version/s: 1.2
Added option {{addTestClassPath}} in
[r651733|http://svn.apache.org/viewvc?view=rev&revision=651733] which allows to
extend the BeanShell class path with the test class path of the project under
test.
> Add current's project test classpath to the Bean Shell interpreter classpath
>
>
> Key: MINVOKER-6
> URL: http://jira.codehaus.org/browse/MINVOKER-6
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Samuel Le Berrigaud
>Assignee: Benjamin Bentmann
> Fix For: 1.2
>
>
> It would be interesting to add the test classpath of the current maven
> project to the Bean Shell's interpreter classpath.
> This would allow developing some utilities classes (project specific
> assertions for example) and use them effectively in the post (or pre) Bean
> Shell scripts..
> I tried it and it is fairly easy to do using the
> bsh.BshClassManager#addClassPath(java.net.URL path) method. Just remember to
> add a trailing "/" at the end of folder URLs for the class loader to pick
> them.
> I could possibly look into providing a patch, so far I worked against the 1.0
> tag. Don't know how I would effectively test that 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: (MSHADE-23) ${basedir} is wrong after running shade plugin
[
http://jira.codehaus.org/browse/MSHADE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=132694#action_132694
]
Paul Sundling commented on MSHADE-23:
-
When trying to mix shade with assembly plugin, this can result in several
catastrophic errors that have no obvious relation. I've seen such problems as
the following:
no manifiest section for signature file entry
org/bouncycastle/asn1/DEREnumerated.class
(not sure how this is created indirectly)
The functionality of shaded jar seems to be mostly available in the assembly
plugin, except for filtering specific files within an artifact.
> ${basedir} is wrong after running shade plugin
> --
>
> Key: MSHADE-23
> URL: http://jira.codehaus.org/browse/MSHADE-23
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_06
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Andreas Schouten
>
> After the shade plugin has run, the ${basedir} points to target.
--
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
