I locally restored classes which were deleted by svnmerge:
Also I avoid dependence in org.jboss.tools.tests from org.jboss.tools.common
by copying two methods from FileUtil class to AbstractRefactorTest class
It works on my computer. Should I commit it in svn trunk?
----- Original Message -----
From: "Max Rydahl Andersen" <max.andersen(a)gmail.com>
To: "jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>
Sent: Monday, April 26, 2010 4:39 AM
Subject: FOR ALL DEV: Merged modular_build into trunk
It took forever for me to get the merge ready from modular_build to trunk
(too many moving parts in trunk to make it easy) - the commit should be
done when you get to read this assuming my network connection keeps
But now it is done and I hope it all went well (I verified with a local
maven build so it should work ;)
In case I did mess something up then please investigate and see if the
modular_build branch or the previous trunk had the right fix.
Here are the overall changes:
1) All MANIFEST.MF files now have the same version as used in the last
release; something that were previously controlled by the overall build is
now where it should be; now just make sure it stays correct and gets
2) cyclic dependencies have been removed (tests mostly were causing this)
3) sdk feature introduced which is what athena will use, since Maven does
not need the "fake" inclusion of ant.optional.junit
4) genpom.scala and parent-pom.xml for using Maven 3 - still in progress,
will send email about that later.
Anything else, see JBDS-486 for details.
There are some things that I found that were weird which should be looked
There are some source files with FIXME(modular) which needs looking into
(they were added in modular_build)
mozilla is versioned 220.127.116.11, shouldn't it be 18.104.22.168a ?
The EL Refactoring classes were all cyclic, were fixed at EclipseCon but
trunk has now more cyclic dependencies in this area - look for .java.fixme
file and refactoring packages; they need to be "unwinded"
Nick: We need to verify if the manifest.mf versions are still correct -
there were a few examples of versions being out in the future compared to
what were in modular...
org.jboss.tools.struts.feature previously org.jboss.tools.struts_feature,
was that renaming intentional ?
trunk and modular_build branc parent-pom.xml were very different - which
is right ?
smooks plugins has a target directory with a report.html committed - is
that intentional ? It would be good if we could simply svn ignore all
WS code had two different import statements for classpath container -
which is right ? (I've fixed it so core import is used in tests)
..and again - I've done what I could to make it a complete merge, but
there might be a few things not working please
reply back if you find some and let me know what you did to fix it.