[jira] Created: (MNGSITE-137) Web page rendering issue on Maven in 5 Minutes
Web page rendering issue on Maven in 5 Minutes -- Key: MNGSITE-137 URL: http://jira.codehaus.org/browse/MNGSITE-137 Project: Maven Project Web Site Issue Type: Bug Environment: Internet Explorer 7.0 Reporter: Jacob Robertson Attachments: maven-in-5-minutes-weird-spacing.PNG Background: my organization is providing hands-on Continuous Integration training courses, and as part of that, we bring up the Maven in 5 Minutes web page (http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html). Every class so far there has been a little moment of huh? when students get to a huge blank part of the guide they have to scroll down through (screen shot attached). The problem only happens on non-wide-screen monitors, and only in IE. However, as you see from the screenshot, it's pretty odd. -- 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: (MPH-78) effective-pom creates invalid xml because it outputs the Resource.mergeId
effective-pom creates invalid xml because it outputs the Resource.mergeId
-
Key: MPH-78
URL: http://jira.codehaus.org/browse/MPH-78
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Jacob Robertson
Priority: Minor
My organization would like to use the output from the effective-pom goal as
part of the deployed meta data in an ear. This is useful for some of our
scripting that needs properties and dependencyManagement versions resolved
(i.e. from parent poms), and the pom that is currently put in the ear does not
have that information. However, once we start generating the effective-pom.xml
file, any tool that uses xml validation will notice that the mergeId tag is
invalid. This is especially annoying in eclipse, as it marks the whole project
as having an error due to the effective-pom.xml file being in the target
directory under the eclipse project. We can of course turn the xml validation
off for the eclipse project or folder, but this is one additional step to ask a
multitude of developers to take in configuring their projects.
I notice that the EffectivePomMojo class has a cleanModel method that appears
to sort the properties. Just to play with this, I added a cleanResources
method that calls Resource.setMergeId(null). This technique does in fact work
as I hoped for outputting the xml without the mergeId, but it requires
upgrading this plugin to use at least Maven 2.0.10.
{code}
private static void cleanModel( Model pom )
{
Properties properties = new SortedProperties();
properties.putAll( pom.getProperties() );
pom.setProperties( properties );
cleanResources( pom.getBuild().getResources() );
cleanResources( pom.getBuild().getTestResources() );
}
private static void cleanResources( List resources )
{
for ( Iterator i = resources.iterator(); i.hasNext(); )
{
Resource resource = (Resource) i.next();
resource.setMergeId( null );
}
}
{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: (MSTAGE-7) Unable to use archiva as http source with maven-stage-plugin
[ http://jira.codehaus.org/browse/MSTAGE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=185770#action_185770 ] Jacob Robertson commented on MSTAGE-7: -- I'm pretty sure this issue applies to the latest version of Nexus as well. We upgraded our version of nexus, and the stage plugin stopped working. The behavior was a never ending console logging of ../ found. I applied this patch locally to the stage plugin, and the problem went away. Unable to use archiva as http source with maven-stage-plugin Key: MSTAGE-7 URL: http://jira.codehaus.org/browse/MSTAGE-7 Project: Maven 2.x Stage Plugin Issue Type: Bug Affects Versions: 1.0-alpha-1 Reporter: Dan Tran Attachments: MSTAGE-7.patch http-wagon-beta-2 currently not able to parse the archiva page ( http://jira.codehaus.org/browse/MRM-891 ). however with the fix from http://jira.codehaus.org/browse/MRM-893 and upgrade to wagon-beta-3 will solve the problem without change in stage plugin source 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] Created: (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations
Adds support for non-CommandExecutor Wagon implementations -- Key: MSTAGE-10 URL: http://jira.codehaus.org/browse/MSTAGE-10 Project: Maven 2.x Stage Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Jacob Robertson Attachments: maven-stage-plugin.patch Here's a patch to generalize support for all Wagon implementations. Note that we can't presume that repository uploading is batched, so it iterates one at a time. We have been using this patched version successfully. -- 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-43) RequireReleaseDeps - allow to execute onlyWhenRelease
RequireReleaseDeps - allow to execute onlyWhenRelease
---
Key: MENFORCER-43
URL: http://jira.codehaus.org/browse/MENFORCER-43
Project: Maven 2.x Enforcer Plugin
Issue Type: Improvement
Components: Standard Rules
Affects Versions: 1.0-alpha-3
Reporter: Jacob Robertson
Assignee: Brian Fox
Priority: Minor
Attachments: onlyWhenRelease.patch.txt
When I setup a project to use the enforcer plugin, I would like to setup the
requireReleaseDeps rule. However, while I am in snapshot mode with my
project, I'm not that concerned about whether that project depends on
snapshots. For example, I may have a small suite of projects which are being
developed at the same time. They may also share a common parent. (Just like
the maven enforcer projects do) Especially in the case where I place the maven
enforcer plugin configuration in that parent pom, it wouldn't make sense for me
to have to comment out the requireReleaseDeps rule during my snapshot
development, only to have to switch it back at release time. Rather, what I
want to express is enforce the requireReleaseDeps rule, but only when I'm a
release.
The pom snippet would look like
{code}
requireReleaseDeps
onlyWhenReleasetrue/onlyWhenRelease
searchTransitivetrue/searchTransitive
/requireReleaseDeps
{code}
I have attached a patch that shows what I'm thinking, and the updated test case
to show that it works as expected.
--
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: (MCLEAN-27) fileset directory does not work as expected when cleaning modules in sub-directories
fileset directory does not work as expected when cleaning modules in
sub-directories
--
Key: MCLEAN-27
URL: http://jira.codehaus.org/browse/MCLEAN-27
Project: Maven 2.x Clean Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Jacob Robertson
Following the example given on the plugin site, I used a fileset with a
directory like so.
{code}
plugin
artifactIdmaven-clean-plugin/artifactId
configuration
filesets
fileset
directory
src/main/application
/directory
includes
include*.jar/include
/includes
/fileset
/filesets
/configuration
/plugin
{code}
I did this, or a variation on it, to several projects. I then created a parent
pom in the directory above those projects, added them as modules in that pom,
and ran mvn clean expecting to have those specified directories cleaned for
me (of all jar files). However, it did not work. To get it to work, I had to
prefix my directories with ${basedir}, for example
${basedir}/src/main/application.
If this is the desired behavior, I recommend adding one sentence to the
documentation to explain 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] Commented: (MNG-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94788 ] Jacob Robertson commented on MNG-2968: -- Making this change would be costly for my company, as our standard is to use dots in all our artifact names instead of dashes. Our group ids and artifact ids are designed to closely mimic the top-level package names in each java project. This allows us to use consistent naming standards in eclipse, maven, cvs, and java packages. All with dots. To make this change, I think you'll first have to quantify very clearly what the actual benefits are versus the risk of making another sweeping backwards incompatible change. Forbid dots in artifactId - Key: MNG-2968 URL: http://jira.codehaus.org/browse/MNG-2968 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.6, 2.1-alpha-1 Reporter: Carlos Sanchez Fix For: 2.1-alpha-1 artifactIds with dots are potential trouble. They prevent using groupId.artifactId as identifier and later parse it back -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94824 ] Jacob Robertson commented on MNG-2968: -- Let me give an example of where you might like to have dots which follow the expected java package structure inside a project. project name:webservices.util cvs module name:webservices.util groupId:com.mycompany.webservices artifactId:webservices.util project name:webservices.xfire cvs module name:webservices.xfire groupId:com.mycompany.webservices artifactId:webservices.xfire We wouldn't want to have an artifact id of just util for the first project, because that would be confusing and problematic with tools like copy-dependencies since we'd undoubtably have more than one project with an artifact of util. So, we'd be more likely to do webservices-util which now means our artifact id is out of synch with (A) the project name, (B) the cvs module name and (C) the java package name. Forbid dots in artifactId - Key: MNG-2968 URL: http://jira.codehaus.org/browse/MNG-2968 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.6, 2.1-alpha-1 Reporter: Carlos Sanchez Fix For: 2.1-alpha-1 artifactIds with dots are potential trouble. They prevent using groupId.artifactId as identifier and later parse it back -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94830 ] Jacob Robertson commented on MNG-2968: -- I certainly understand and respect what you're trying to accomplish, but the sad fact is that if this suggested fix is implemented, it will break 90% of the artifacts in my company, and will mean we have to do re-tooling on the inhouse things we've done that depend on artifact id, cvs module name, and project name all being the same. This is a sweeping, non-backwards-compatible change, and it shouldn't be done lightly. Forbid dots in artifactId - Key: MNG-2968 URL: http://jira.codehaus.org/browse/MNG-2968 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.6, 2.1-alpha-1 Reporter: Carlos Sanchez Fix For: 2.1-alpha-1 artifactIds with dots are potential trouble. They prevent using groupId.artifactId as identifier and later parse it back -- 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: (MCHANGELOG-58) Make the report easier to read by bolding the actual file name
Make the report easier to read by bolding the actual file name -- Key: MCHANGELOG-58 URL: http://jira.codehaus.org/browse/MCHANGELOG-58 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Jacob Robertson Priority: Trivial Attachments: Bolded.JPG, FileNameBoldMarkup.diff The report is a little hard to read, because of the way the file name is fully qualified with the complete path within the Details column. The human eye has a hard time picking out where the path ends and where the actual file name begins. See for example the sample provided on the maven-changelog-plugin website: http://maven.apache.org/plugins/maven-changelog-plugin/images/sample-file-activity-report.PNG I created a very simple example patch that just calls sink.bold() around the actual file name within the link. The resulting output has only a subtle difference, but it makes the report much more readable. See the attached jpg for an example of how this would look. -- 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: (MPMD-30) No way to PMD test the test sources in src/test/java
[ http://jira.codehaus.org/browse/MPMD-30?page=comments#action_80420 ]
Jacob Robertson commented on MPMD-30:
-
Checkstyle has this fix in their head right now that allows a simple flag to
say yes I also want to run checkstyle on my test classes. The pom would look
like
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
configLocationhttp://mylocation/documents/architecture/checkstyle/checkstyle.xml/configLocation
includeTestSourceDirectorytrue/includeTestSourceDirectory
/configuration
/plugin
{code}
No way to PMD test the test sources in src/test/java
Key: MPMD-30
URL: http://jira.codehaus.org/browse/MPMD-30
Project: Maven 2.x Pmd Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Daniel Kulp
There currently isn't ANY way to have PMD check the test sources in
src/test/java.
For the checkstyle plugin, you can do something like:
sourceDirectory${basedir}/src/sourceDirectory
which would allow it to check ALL the java files in src including the ones in
src/test/java. For PMD, however, the sourceDirectory field is readonly so
is not settable in the pom.xml.
Log of discussion on IRC:
[16:28:29] kenney pmd: // TODO: use source roots instead
[16:28:29] kenney String sourceDirectory =
project.getBuild().getSourceDirectory();
[16:28:30] kenney :)
[16:28:43] jdcasey ugh
[16:28:49] jdcasey it's not even using an expression??
[16:28:59] kenney nope
[16:29:08] jdcasey should be ${project.compileSourceRoots}, and not
@readonly
[16:29:24] jdcasey dkulp: only thing I can say is to fix the plugin and
deploy a snapshot...
[16:29:39] dkulp Or not pmd the tests for now.
[16:30:52] kenney btw, you don't want to always run source-checking stuff
on all sources
[16:31:07] kenney generated sources usually don't follow coding style for
instance
[16:31:30] dkulp Right. That's why i want ${basedir}/src and not
target/
[16:31:32] kenney so using compileSourceRoot is tricky..
[16:31:49] kenney well you can do that for checkstyle and specify
includes/excludes
[16:31:58] jdcasey fair enough
[16:32:04] dkulp Right. checkstyle works OK.
[16:32:09] jdcasey but overriding that list should be enough, I would think
[16:32:26] kenney we should actually be able to mark sourceRoots as being
generated or not
--
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: (MJAVADOC-100) Allow JavaDocs to generate for Test Code
Allow JavaDocs to generate for Test Code Key: MJAVADOC-100 URL: http://jira.codehaus.org/browse/MJAVADOC-100 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Reporter: Jacob Robertson Priority: Minor I have two use cases. First, my team is trying to be very diligent in creating JavaDocs for all our code. We have checkstyle checking that javadocs are written for every method within test code. So, since we're putting this much effort into our javadocs, it's a nice to have for those javadocs to actually be generated on the project site. Second, I have some Test Harness code in one project, and this is re-usable code which many projects should make use of in their test code. I would like to have that code's javadocs available on its project site for obvious reasons. There is probably some workaround that I could figure out and make this work, but much like the Checkstyle plugin has an includeTestSourceDirectory property for its goal, adding that type of property to the javadoc plugin would be an intuitive way to turn on javadocs for test 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: (MCHECKSTYLE-45) It should be possible to configure checkstyle:check to fail on warnings.
[ http://jira.codehaus.org/browse/MCHECKSTYLE-45?page=comments#action_75916 ] Jacob Robertson commented on MCHECKSTYLE-45: Let me describe my situation. First off, we use one common checkstyle.xml definition hosted on an internal http server. This same checkstyle.xml is consumed by both the eclipse-cs plugin (as we develop in eclipse) and by maven both when continuum kicks it off and when we run it locally. However, we were very unhappy with using error on any of our checks, because in the IDE it was showing up so as to mask whether it was a true build error or just a checkstyle error. We fought with that for a while, and in the end just changed our checkstyle.xml to declare globally that all checks were just warnings. But now we would also like to explore the possibility of having maven break the build when the checkstyle *warnings* show up. Here is the rationale: while developing in eclipse, we want things to show up as warnings to make our IDE experience livable. However, once we go to check something in, we know that all those warnings must be cleared up or we'll break the build. This way, we get the best of both worlds. All I'm trying to do is demonstrate a practical, real-world scenario under which this feature would be useful. It should be possible to configure checkstyle:check to fail on warnings. -- Key: MCHECKSTYLE-45 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 Project: Maven 2.x Checkstyle Plugin Issue Type: New Feature Affects Versions: 2.1 Reporter: Fabian Bauschulte Attachments: MCHECKSTYLE-45-maven-checkstyle-plugin.patch As mentioned in MCHECKSTYLE-38 it should be possible to configure that checkstyle:check fails on warnings or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-617) javax.jdo.JDODataStoreException: Insert request failed
[ http://jira.codehaus.org/browse/CONTINUUM-617?page=comments#action_70602
]
Jacob Robertson commented on CONTINUUM-617:
---
I am getting this every single night on at least one project. I come in every
morning, and have to force a rebuild those projects, at which time they build
fine. I tried deleting those projects, and re-adding them to continuum, but
that didn't help. This is on continuum 1.0.2.
javax.jdo.JDODataStoreException: Insert request failed
--
Key: CONTINUUM-617
URL: http://jira.codehaus.org/browse/CONTINUUM-617
Project: Continuum
Issue Type: Bug
Components: Core system, Database
Affects Versions: 1.0.2
Reporter: Brian Fox
Fix For: 1.1
This happened apparently randomly during a scheduled build. On the next
scheduled build, it was successfull.
Build Error:
javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO
PROJECTDEPENDENCY (PROJECTDEPENDENCY_ID,ARTIFACT_ID,VERSION,GROUP_ID) VALUES
(?,?,?,?)
at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:329)
at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1774)
at org.jpox.store.StoreManager.insert(StoreManager.java:721)
at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3066)
at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3039)
at
org.jpox.state.StateManagerImpl.attachCopy(StateManagerImpl.java:3452)
at
org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1644)
at org.jpox.sco.List.attachCopy(List.java:326)
at
org.jpox.state.AttachFieldManager.storeObjectField(AttachFieldManager.java:107)
at
org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2394)
at
org.apache.maven.continuum.model.project.Project.jdoProvideField(Project.java)
at
org.apache.maven.continuum.model.project.Project.jdoProvideFields(Project.java)
at
org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:2732)
at
org.jpox.state.StateManagerImpl.internalAttachCopy(StateManagerImpl.java:3518)
at
org.jpox.state.StateManagerImpl.attachCopy(StateManagerImpl.java:3446)
at
org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1644)
at
org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1660)
at
org.apache.maven.continuum.store.JdoContinuumStore.updateObject(JdoContinuumStore.java:679)
at
org.apache.maven.continuum.store.JdoContinuumStore.updateProject(JdoContinuumStore.java:841)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:94)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:171)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
at java.lang.Thread.run(Thread.java:534)
NestedThrowablesStackTrace:
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks
and waiters is:
Lock : ROW, PROJECTDEPENDENCY, (1614,14)
Waiting XID : {31204919, X} , SA, INSERT INTO PROJECTDEPENDENCY
(PROJECTDEPENDENCY_ID,ARTIFACT_ID,VERSION,GROUP_ID) VALUES (?,?,?,?)
Granted XID : {31204120, X}
Lock : ROW, PROJECT, (1,34)
Waiting XID : {31204120, S} , SA, UPDATE PROJECTDEPENDENCY SET
DEPENDENCIES_ID_OWN = ?,DEPENDENCIESINTEGER_IDX = ? WHERE
PROJECTDEPENDENCY_ID = ?
Granted XID : {31204919, X}
. The selected victim is XID : 31204919.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at
org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown Source)
at
org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Source)
at
org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown Source)
at
org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown Source)
at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown
Source)
at
[jira] Created: (MSITE-143) SCP works for deploy goal, but not for site-deploy
SCP works for deploy goal, but not for site-deploy -- Key: MSITE-143 URL: http://jira.codehaus.org/browse/MSITE-143 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-5 Reporter: Jacob Robertson The linux admins did everything necessary to get the deploy goal to work, and now I have to go back to them and try and figure out why the site-deploy goal says Auth failed. Why does deploy work just fine with scp, but not site-deploy? My environment is such that my deploy repository and my deploy site directories are in the same parent directory, and have the exact same permissions. But one goal fails to upload, and the other doesn't... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-144) inherited site url not properly handling parameters
inherited site url not properly handling parameters
---
Key: MSITE-144
URL: http://jira.codehaus.org/browse/MSITE-144
Project: Maven 2.x Site Plugin
Type: Bug
Versions: 2.0-beta-5
Reporter: Jacob Robertson
Here is the test case to reroduce this problem. Take the following two pom.xml
files
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdfoo/artifactId
namefoo/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
distributionManagement
site
idfoo-site/id
urlfile://C:/Documents and
Settings/foo/.m2/site/${project.artifactId}/url
/site
/distributionManagement
/project
?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdbaz/artifactId
namebaz/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
parent
artifactIdfoo/artifactId
groupIdorg.bar/groupId
version1.0-SNAPSHOT/version
/parent
/project
And run the site-deploy goal on each. What you get under the site directory is
this
- site
/- foo
---/site docs
/- baz
---/- baz (extra directory)
--- ---/site docs
This is the simplest test case. In the case where I have a grandparent pom,
the site directory uses the grandparent/parent as the path to the site, and
doesn't use the actual artifactId of the artifact I'm creating the site for.
--
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: (MNGECLIPSE-106) Dependency Resolver and PDE conflicts
[ http://jira.codehaus.org/browse/MNGECLIPSE-106?page=comments#action_65450 ] Jacob Robertson commented on MNGECLIPSE-106: +1 from my company - this is a critical issue for us, and will be a deal breaker for some of our teams, because we cannot develop PDE projects while using the m2eclipse tool as it stands right now. Dependency Resolver and PDE conflicts - Key: MNGECLIPSE-106 URL: http://jira.codehaus.org/browse/MNGECLIPSE-106 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Dependency Resolver Environment: Eclipse PDE Reporter: Dimitry Voytenko Assignee: Eugene Kuleshov Attachments: sample-plugins.zip All tests have been done using the solution provided in the http://jira.codehaus.org/browse/MNGECLIPSE-59. This solution works very well, but there're specifics when using it in the PDE (Plugin Development) environment. Attached are sample plugins that demonstrate the issue (tested under Eclipse 3.1.2). Unpack sample-plugins.zip and import projects in the workspace. Patch from MNGECLIPSE-59 should be applied. Rebuild both projects. Build of com.example.plugins.main should fail with an error: Build path contains duplicate entry: 'com.example.plugins.component' for project com.example.plugins.main The problem occures b/c of conflict b/w PDE classpath container and Maven2 classpath container. They both contain com.example.plugins.component project. PDE's classpath container is defined in the org.eclipse.pde.core plugin as an org.eclipse.pde.core.requiredPlugins extension. It uses META-INF/MANIFEST.MF file as a source. MANIFEST.MF is basically an OSGI manifest that lists all dependent bundles in the form: Require-Bundle: org.eclipse.core.runtime, ... with optionally specified version and transiting information. Both manifest and PDE container are very essential for the PDE work. It's not clear if they can be properly extended to avoid conflicts. If such a way can be found, it is important to keep in mind the similarities and differences b/w Maven and PDE dependency management: a) PDE dependencies have flags optional and re-exported. By default dependencies are required and non-transient. The optional property can be modeled via Maven'2 optional dependency. The re-exported property basically makes the dependency transient. I'm not sure if all of these states can be modelled via Maven's scope. b) Version management is different. PDE allows to specify dependency on the latest found version of a plugin (if version parameters is specified then it should be greater or equal). In Eclipse 3.2 it's actually possible to specify both borders, i.e. version no earlier than 2.0.0 and no later than 3.0.0. c) MANIFEST.MF is a deployable file. It's used at runtime to build the classloader graph. If it's not possible to extend PDE to source it from the Maven's configuration a temporary solution could be to exclude a dependent project from the Maven container if it can be found elsewhere in the classpath. The possible issue here: if it's possible to get the access from Maven container to the content of the other containers. Cooperation with Eclipse team would probably help here as this would also benefit them in the long run. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_65193 ] Jacob Robertson commented on MNGECLIPSE-59: --- My company is evaluating using m2eclipse. Our culture is to check out multiple projects at once while developing, but reference others from the maven repository. We also have a team that is doing PDE development. So this particular issue is basically a deal breaker for us. +1 from us... Allow artifact resolution from workspace projects - Key: MNGECLIPSE-59 URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 Project: Maven 2.x Extension for Eclipse Type: New Feature Components: Dependency Resolver Versions: 0.0.4 Reporter: Leonardo Quijano Vincenzi Assignee: Eugene Kuleshov Fix For: 1.0.0 Attachments: ArtifactResolver-try3.patch, EclipseArtifactResolver-corrected.patch, EclipseArtifactResolver.patch, maven-embedder-2.1-SNAPSHOT-dep.jar Provide artifact resolution from workspace projects, which override the same artifact from the local or remote repositories. This would allow to work with dependant Eclipse projects without specifying the Eclipse dependency manually. The workspace artifact resolution would have to be specified manually, since several Maven-Enabled projects in the same workspace could have the same artifact and version Id. Or at least automatic resolution with an optional override would be nice. More comments here: http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-2191) [Dependencies] Override parent dependency scope without specifying version
[Dependencies] Override parent dependency scope without specifying version -- Key: MNG-2191 URL: http://jira.codehaus.org/browse/MNG-2191 Project: Maven 2 Type: New Feature Components: Dependencies Versions: 2.0.2 Reporter: Jacob Robertson Priority: Minor In my parent pom, I have log4j listed as a runtime dependency (since log4j is discovered by commons-logging). In the child pom, it turns out that I need to depend on it with compile scope (since I have a custom appender). My issue is that I want to minimize the maintenance of these poms, so I'd prefer if the child pom didn't have to specify what version of log4j it depends on. However, if I take out the version element I get Project build error Failed to validate POM (In the Eclipse maven2 console). What I'm looking for is something like this dependency groupIdlog4j/groupId artifactIdlog4j/artifactId scopecompile/scope versionInheritedFromParentPomtrue/versionInheritedFromParentPom /dependency You get the idea... -- 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
