-
Patch
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: All
-
Powered by SuggestiMate
Code changed in hudson
User: : kohsuke
Path:
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=16746
Log:
[FIXED JENKINS-3251] Concluding the issue as resolved. Targeted for 1.296.
[JENKINS-3251] move the native maven integration to a plugin
I also like this idea because it could allow for faster changes and/or bug fixes
in maven integration as the plugin could be built independently.
How will this affect existing plugins that support the existing m2 project type?
Will they have to list this plugin as a dependency?
Or does your patch leave the interfaces and abstract classes as stubs in core
with concrete implementations in the plugin?
My main concern is that we'll end up with everyone having to install this m2
plugin just to be able to use any of the other plugins that provide m2 support...
Yes I personally would favor ripping the current m2 support out into a plugin as
the current m2 project type has IMHO a lot of problems with it... but if the end
result is that everyone has to add the m2 project back in just so they can use
the warnings/findbugs/checkstyle/coverage/etc plugins... what exactly do we gain?
Stephen has some good points.
Just tossing out an idea here...not sure that I really like it...but it might help get the thought process
rolling.
How about making a jar dependency that that the impl that could be included in each plugin and then a
maven plugin to simply enable maven functionality in Hudson. I believe this would allow for plugins
that support non-maven and maven to work, but would only work with maven when the maven plugin
is installed, but it could be built against the jar.
However, the more I think about this...it has some drawbacks as well because their could be
compatibility issues between the maven plugin and other plugins if they used a different version of the
jar dependency.
It's not that simple....
some plugins that do not have m2 support reference the m2 classes (in order to
disable support for the m2 projects that they do not support)
Thus if you don't have the m2 classes on the classpath, the plugin will not load
at all.
Another example would be the javancss plugin which I wrote to minimise the pain
of integrating with the crappy-m2 project type and so all project types share
the same code... with the side-effect that even for freestyle projects you need
the m2 classes on the classpath.
I should note that I have not had a chance to look at tom's patch as i'm
currently sitting on a tram....
If tom's patch leaves the interfaces and classes but turns them into
non-functional stubs I think we'd be OK... but if his patch purely pulls the
classes out into a plugin then I do not see what we gain...
The other route is to just fork a branch, call it Hudson 2.0 and pull out the
crappy m2 support replacing it with the propper m2 support that tom is working
on....
The patch mostly moves all the classes to a different plugin, and makes sure
that plugins built before Hudson 1.X get this dependency transparently, while
plugins built after that need to declare it. Included in the patch are pom
updates for all plugins in SVN.
The main advantage of having this as a plugin, is that the Maven (and Plexus)
dependencies are isolated in the plugin classloader now. So at least it is
possible for other plugins to have different versions of these dependencies.
What Stephen mentioned is completely valid. Every plugin that was built to
support m2 projects, has a classpath dependency to it. So even if this is a
plugin now, it is still mandatory for most current installations.
One way to fix that would be to create a new plugin state where a plugin is
installed (so available as a dependency) but its extensions are not registered.
"Every plugin that was built to support m2 projects, has a classpath dependency
to it." - IMHO that means the plugin should be factored into two plugins: base
feature, and Maven2 add-on support.
That's not realistic and not necessary. We should make sure that optional
dependencies work well, and that Maven extensions don't break the entire plugin
when the Maven plugin is not available. With the sezpoz auto-registration that
shouldn't even be that hard.
Is factoring out optional dependencies so unrealistic? We do it all the time
among the hundreds of officially distributed NetBeans modules, and Maven seems
to make it even easier to manage sets of related modules with related
dependency lists. Seems to me simpler and clearer than introducing a new ghostly
"enabled but unused" state into the plugin system itself, which besides being an
odd UI would imply that every plugin needs to be prepared to be in this state
sometimes.
You might want a "recommends" metadata flag in a plugin so the plugin installer
can suggest installing satellite plugins when you pick out a core plugin. This
could be useful independently. Linux packages typically work this way.
I'm not contributing to the separation work, this is just an unsolicited opinion.
SezPoz also makes it pretty simple for an add-on to inject optional services
into a core plugin, though it is not clear to me if it is recommended for SezPoz
to be used directly by plugin code, or only to be used as a default
implementation of @Extension registration with a possible override from some
Plexus system. ServiceLoader (augmented with the natural @ServiceProvider
annotation, such as NetBeans 6.7 introduces pending something in the JRE) makes
it even simpler; SezPoz's primary advantage is in class loading scalability,
which is of little concern for Hudson, though it also adds static field & method
registrations.
I'm still in the process of going through the patch, but I believe the new
maven-plugin will continue to be bundled in the standard hudson.war distribution
to prevent upgrade problems.
With a bit of changes in PluginManager (by checking Hudson core version they are
built against and making maven-plugin visisble in the dependency), we should be
able to keep existing plugin binaries operational. As Stephen and Jesse noted,
this is necessary to prevent disruption during upgrades.
Yes, the patch does keep the maven-plugin bundles with Hudson by default, and it
makes sure this plugin will be an implicit dependency for plugins built against
Hudson 1.XXX or earlier.
Code changed in hudson
User: : kohsuke
Path:
http://fisheye4.cenqua.com/changelog/hudson/?cs=16689
Log:
JENKINS-3251 (1/18) moving maven-related source to maven-plugin
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/matrix/MatrixRun.java
branches/JENKINS-3251/core/src/main/resources/hudson/matrix/Messages.properties
branches/JENKINS-3251/core/src/main/resources/hudson/matrix/Messages_de.properties
branches/JENKINS-3251/core/src/main/resources/hudson/matrix/Messages_ja.properties
branches/JENKINS-3251/core/src/main/resources/hudson/matrix/Messages_nl.properties
branches/JENKINS-3251/core/src/main/resources/hudson/matrix/Messages_tr.properties
http://fisheye4.cenqua.com/changelog/hudson/?cs=16690
Log:
JENKINS-3251 (3/18) moved KeptBecauseOfParent message
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/model/AbstractBuild.java
branches/JENKINS-3251/core/src/main/java/hudson/model/AbstractProject.java
branches/JENKINS-3251/core/src/main/java/hudson/model/Fingerprint.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16691
Log:
JENKINS-3251 (4/18) removed imports and javadoc links to Maven-related classes
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/Functions.java
branches/JENKINS-3251/core/src/main/java/hudson/model/Items.java
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16692
Log:
JENKINS-3251 (5/18) moving maven-related functionality to maven plugin.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/PluginImpl.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16693
Log:
JENKINS-3251 (5/18) moving maven-related functionality to maven plugin
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/test/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16695
Log:
JENKINS-3251 (6/18) updating poms and packaging to bundle maven plugin (with a minor adjustment to revert forkMode change)
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/pom.xml
branches/JENKINS-3251/maven-plugin/pom.xml
branches/JENKINS-3251/pom.xml
branches/JENKINS-3251/test/pom.xml
branches/JENKINS-3251/war/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16696
Log:
JENKINS-3251 (6/18) updating poms and packaging to bundle maven plugin (with a minor adjustment to revert forkMode change)
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/PluginManager.java
branches/JENKINS-3251/test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
branches/JENKINS-3251/war/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16697
Log:
JENKINS-3251 (7/18) add a hudson.bundled.plugins property that can override the default bundled plugins.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/slaves/SlaveComputer.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16701
Log:
JENKINS-3251 (8/18) finding Maven jars through reflection for now. TODO: introduce a post-initialization hook
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/ClassicPluginStrategy.java
branches/JENKINS-3251/core/src/main/java/hudson/PluginManager.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16702
Log:
JENKINS-3251 (10/18) use lastModified to avoid unpacking bundled plugins unnecessarily.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/maven-plugin/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16703
Log:
JENKINS-3251 (12/18) updating poms and packaging to bundle maven plugin
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/remoting/src/main/java/hudson/remoting/Which.java
branches/JENKINS-3251/test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16704
Log:
JENKINS-3251 (15/18) resolve plugins from the classpath in tests. Slightly reworked.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/maven-plugin/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16705
Log:
JENKINS-3251 (16/18) update hpi plugin version
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/MavenBuild.java
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/PluginImpl.java
branches/JENKINS-3251/maven-plugin/src/main/resources/hudson/maven/MavenBuild/executedMojos.jelly
http://fisheye4.cenqua.com/changelog/hudson/?cs=16706
Log:
JENKINS-3251 (17/18) moved createExecutedMojoCache
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16707
Log:
JENKINS-3251 after looking at (18/18), I think the same effect can be achieved more easily by not setting this system property at all.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/tasks/ArtifactArchiver.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/BuildWrappers.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/Fingerprinter.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/JavadocArchiver.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/Mailer.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/Maven.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/Publisher.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/junit/JUnitResultArchiver.java
branches/JENKINS-3251/core/src/main/java/hudson/tasks/test/AggregatedTestResultAction.java
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16709
Log:
JENKINS-3251 ignore certain builders and publishers in Maven2 job type. This does the same thing as (2/18) in Tom's patch, but I believe this is better. Still needs to figure out how to do this for MavenModule, which doesn't have a descriptor.
Code changed in hudson
User: : kohsuke
Path:
branches/JENKINS-3251/core/src/main/java/hudson/slaves/ComputerListener.java
branches/JENKINS-3251/core/src/main/java/hudson/slaves/SlaveComputer.java
branches/JENKINS-3251/maven-plugin/src/main/java/hudson/maven/MavenComputerListener.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16712
Log:
JENKINS-3251 revisited patch (8/18). ComputerListener is extended to support the preOnline step, so that some operations can be carried out whose failure will result in the node failing to become online.
OK, merging is now complete, and from what I can tell, all the tests pass.
TODOs:
- redo 2/18 and move the logic to MavenProject's descriptor.
-> done with MavenModuleSet but still needs to be done for MavenModule. - patch 14/18 needs to be applied later since I messed up branching.
Code changed in hudson
User: : kohsuke
Path:
http://fisheye4.cenqua.com/changelog/hudson/?cs=16729
Log:
Initialized merge tracking via "svnmerge" with revisions "1-16688" from
https://www.dev.java.net/svn/hudson/branches/JENKINS-3251
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/pom.xml
trunk/hudson/main/core/src/main/java/hudson/ClassicPluginStrategy.java
trunk/hudson/main/core/src/main/java/hudson/Functions.java
trunk/hudson/main/core/src/main/java/hudson/PluginManager.java
trunk/hudson/main/core/src/main/java/hudson/matrix/MatrixRun.java
trunk/hudson/main/core/src/main/java/hudson/model/AbstractBuild.java
trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
trunk/hudson/main/core/src/main/java/hudson/model/Fingerprint.java
trunk/hudson/main/core/src/main/java/hudson/model/Items.java
trunk/hudson/main/core/src/main/java/hudson/slaves/ComputerListener.java
trunk/hudson/main/core/src/main/java/hudson/slaves/SlaveComputer.java
trunk/hudson/main/core/src/main/java/hudson/tasks/ArtifactArchiver.java
trunk/hudson/main/core/src/main/java/hudson/tasks/BuildWrappers.java
trunk/hudson/main/core/src/main/java/hudson/tasks/Fingerprinter.java
trunk/hudson/main/core/src/main/java/hudson/tasks/JavadocArchiver.java
trunk/hudson/main/core/src/main/java/hudson/tasks/Mailer.java
trunk/hudson/main/core/src/main/java/hudson/tasks/Maven.java
trunk/hudson/main/core/src/main/java/hudson/tasks/Publisher.java
trunk/hudson/main/core/src/main/java/hudson/tasks/junit/JUnitResultArchiver.java
trunk/hudson/main/core/src/main/java/hudson/tasks/test/AggregatedTestResultAction.java
trunk/hudson/main/core/src/main/resources/hudson/matrix/Messages.properties
trunk/hudson/main/core/src/main/resources/hudson/matrix/Messages_de.properties
trunk/hudson/main/core/src/main/resources/hudson/matrix/Messages_ja.properties
trunk/hudson/main/core/src/main/resources/hudson/matrix/Messages_nl.properties
trunk/hudson/main/core/src/main/resources/hudson/matrix/Messages_tr.properties
trunk/hudson/main/pom.xml
trunk/hudson/main/remoting/src/main/java/hudson/remoting/Which.java
trunk/hudson/main/test/pom.xml
trunk/hudson/main/test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java
trunk/hudson/main/war/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16734
Log:
Merged revisions 16689-16697,16701-16710,16712-16714 via svnmerge from
https://www.dev.java.net/svn/hudson/branches/JENKINS-3251
mvn -f main/war/pom.xml hudson-dev:run
does not load the Maven plugin. Intentional or bug?
mvn -f main/maven-plugin/pom.xml hpi:run
also doesn't seem to work:
[INFO] [hpi:run]
[ERROR] Unable to locate hudson.war. Add the following dependency in your POM:
....
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Unable to find hudson.war
> mvn -f main/war/pom.xml hudson-dev:run
> does not load the Maven plugin. Intentional or bug?
This is a bug.
> mvn -f main/maven-plugin/pom.xml hpi:run
> also doesn't seem to work:
There must be some directory sensitivity. They both work if you "cd main/war"
and run Maven without the -f option.
Investigating.
Code changed in hudson
User: : jglick
Path:
trunk/hudson/main/war/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16740
Log:
JENKINS-3251 'mvn -f main/war/pom.xml' failed to load maven-plugin due to CWD issue.
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenComputerListener.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=16748
Log:
With JENKINS-3251, maven-agent and maven-interceptor are no longer available on WEB-INF/lib, so let's create the jar file on the fly.
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/plugins/accurev/pom.xml
trunk/hudson/plugins/batch-task/src/main/java/hudson/plugins/batch_task/BatchTaskInvoker.java
trunk/hudson/plugins/build-publisher/pom.xml
trunk/hudson/plugins/checkstyle/pom.xml
trunk/hudson/plugins/ci-game/pom.xml
trunk/hudson/plugins/cobertura/pom.xml
trunk/hudson/plugins/dry/pom.xml
trunk/hudson/plugins/findbugs/pom.xml
trunk/hudson/plugins/groovy/pom.xml
trunk/hudson/plugins/ircbot/pom.xml
trunk/hudson/plugins/javancss/pom.xml
trunk/hudson/plugins/jira/pom.xml
trunk/hudson/plugins/nunit/pom.xml
trunk/hudson/plugins/pmd/pom.xml
trunk/hudson/plugins/pom.xml
trunk/hudson/plugins/promoted-builds/pom.xml
trunk/hudson/plugins/sfee/pom.xml
trunk/hudson/plugins/tasks/pom.xml
trunk/hudson/plugins/violations/pom.xml
trunk/hudson/plugins/warnings/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16752
Log:
applied patch (14/18) from JENKINS-3251
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/plugins/accurev/pom.xml
trunk/hudson/plugins/build-publisher/pom.xml
trunk/hudson/plugins/checkstyle/pom.xml
trunk/hudson/plugins/ci-game/pom.xml
trunk/hudson/plugins/cobertura/pom.xml
trunk/hudson/plugins/dry/pom.xml
trunk/hudson/plugins/findbugs/pom.xml
trunk/hudson/plugins/groovy/pom.xml
trunk/hudson/plugins/ircbot/pom.xml
trunk/hudson/plugins/javancss/pom.xml
trunk/hudson/plugins/jira/pom.xml
trunk/hudson/plugins/nunit/pom.xml
trunk/hudson/plugins/pmd/pom.xml
trunk/hudson/plugins/promoted-builds/pom.xml
trunk/hudson/plugins/sfee/pom.xml
trunk/hudson/plugins/tasks/pom.xml
trunk/hudson/plugins/violations/pom.xml
trunk/hudson/plugins/warnings/pom.xml
http://fisheye4.cenqua.com/changelog/hudson/?cs=16903
Log:
[FIXED JENKINS-3442] Applied patch (14/18) from JENKINS-3251 to fix compilation problems
Am I right in the assumption that the changes for this issue are responsible
for the problem described in issue 3473 ?
create a maven plugin, so that it's possible to turn off or replace the maven
integration