resent with proper email: FOR ALL DEV: Merged modular_build into trunk
by Andersen Max
Hi,
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 running.
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 properly updated.
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 into ASAP:
Denis:
There are some source files with FIXME(modular) which needs looking into (they were added in modular_build)
mozilla is versioned 1.9.1.2, shouldn't it be 1.9.1.2a ?
Daniel:
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 ?
Tom/Dart:
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 target dirs.
Grid:
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.
Thanks,
/max
14 years
Repository location for new eclipse feature.
by John Doyle
I'm working on a Eclipse DTP connectivity implementation for Teiid. My expectation for these plug-ins is that they will eventually be delivered with JBoss Tools and Dev Studio, but initially they will be delivered as a required feature with the Teiid Designer. The feature only depends upon Eclipse DTP, so it could be used in any DTP install.
I'm looking for advice on where I should check this code in permanently in order to support all of these delivery options. If these plugins have their own Athena/Hudson build do you think it's appropriate to check them into the JBoss tools repos?
Thanks
~jd
14 years
Re: [jbosstools-dev] FOR ALL DEV: Merged modular_build into trunk
by Daniel Azarov
I locally restored classes which were deleted by svnmerge:
org.jboss.tools.tests.AbstractRefactorTest
org.jboss.tools.jsf.test.refactoring.ELVariableRefactoringTest
and renamed
org.jboss.tools.cdi.core.test.tck.NamedBeanRefactoringTest.java.fixme to
org.jboss.tools.cdi.core.test.tck.NamedBeanRefactoringTest.java
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
> Hi,
>
> 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
> running.
>
> 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
> properly updated.
> 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
> into ASAP:
>
> Denis:
> There are some source files with FIXME(modular) which needs looking into
> (they were added in modular_build)
> mozilla is versioned 1.9.1.2, shouldn't it be 1.9.1.2a ?
>
> Daniel:
> 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 ?
>
> Tom/Dart:
> 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
> target dirs.
>
> Grid:
> 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.
>
> Thanks,
> /max
>
>
>
>
>
>
14 years
3.1.x branch open for 3.1.1 isues
by Andersen Max
SVN is down at the moment, but once it gets backup please put in the patches/work needed for getting all issues fixed for 3.1.1 this week.
/max
14 years
Problem with org.jboss.tools.common.model.ui plugin
by Jiri Peterka
Hi guys,
I have following problem with JBT plug-in dependencies and hope you
could help me. Simply I can't import
org.jboss.tools.common.editors.ObjectMultiPageEditor. This specific
issues is here since one of recent JBT (3.1) version.
There are simple steps to reproduce.
1. Have JBDS 3.0.0 GA or JBT 3.1 installed
2. Create plugin to test this problem
3. Import org.jboss.common.model.ui on Dependencies tab
4. In plug-in dependencies (Package Explorer)
org.jboss.tools.common.model.ui is missing and for example
ObjectMultiPageEditor (org.jboss.tool.common.editor) can't be imported
Strange is that plugin is here and I can see this plugin in Plug-in
registry, plugin can be added as dependency and it has exported packages
I needed but it's not present in Plug-In Dependencies (Package Explorer)
and can't be imported in the source code. In some earlier JBT 3.1 this
worked.
Any help appreciated, regards
--
Jirka
14 years
FOR ALL: Cleaning up 3.1.1 issues ASAP
by Andersen Max
Hi,
As discussed pre-eclipsecon we want to get 3.1.1 out quickly so we can adopt the fix for WTP bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=305306)
and fix any critical issues we've found after GA.
Right now there is about 100 issues assigned to JBoss Tools 3.1.1 or JBDS 3.0.1 - I don't believe they are all critical nor have patches.
Please go through issues assigned to you or of which you are component lead and move anything that is not crucial of to 3.1.x/3.0.x and mark anything
that you think must get into 3.1.x/3.0.x as BLOCKER (either because it is really important or that we already got a good/safe fix for it).
Tentatively the development and automatic testing of this should be done and ready for 26th April for QA to verify any remaining issues.
i.e. 10 work days from now.
Use that info to prioritize the issues ASAP so we got a list by wednesday afternoon to discuss on the status call Thursday.
THANK YOU!
/max
14 years
Should I check in a few translations for JBoss Tools?
by Sean Flanigan
G'day all
During testing of the Flies project a couple of months back, we had some
of the Red Hat translators do a little bit of translation work for JBoss
Tools. I've finally got around to exporting the translations and
cleaning them up a bit, so I'd like to check them in.
But as I've been out of the JBoss Tools loop, I just want to check that
this won't cause any problems before I do check in.
I've put a copy of the patch here: http://pastebin.com/JtzGLTC6
Here's the patch after running through native2ascii for readability:
http://pastebin.com/QWbJtxig
Any reason I shouldn't apply this to trunk and check it in?
Thanks,
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
14 years
