Joachim Joachim Grüneis wrote: > Hello, > > I think we're currently in a transition from one big project to many > small projects - and there are still a couple of things that require a > solution/fix: Yes, there are. Most definitely.
> * My experience with 'multi-projects', Maven and Eclipse is that the > super project should be nearly empty - meaning that all documentation > should be moved into an own documentation project. Sure. And at the same time one could move to Maven site generation incl. documentation, move to DocBook, etc. Problem is that things don't happen by talking about them. I don't know (anymore) how much time I have spent to get we we are now (a fully working Maven build, incl. the ability to deploy to Maven repos), and I know that it would take weeks to get the complete web site out of Maven (site). Unless we all dedicate some time to this, it simply ain't gonna happen. > * Documentation cannot be build with Maven (at least that is what I > understood in a talk with Werner, I haven't tried it personally) It can, of course, but first you'd have to convert all XML documnets in src/doc to a format Maven *fully* understands. Currently, we'd lose some layout things (as we use some custom XSLT stylesheets. Iow, yes it can be done, but it'd take weeks. > * Release notes should be in each project and linked from the > documentation project.... > * Different JDK versions within one project are be a problem... but I > hope that we will soon move all of Castor to JDK 5 ;-) and until that > day we will have to life with it Why. It is completely simple to instruct the maven-compiler-plugin to use 1.4, 1.5 or 6.0 Whatever you prefer. Run mvn eclipse:eclipse and you'll get Eclipse projects configured with the corresponding compiler settings etc. > * Working on modules will require that we increase the number of unit > tests that reside in each module (to check all contracts of the > module) - today we have all tests in own modules (e.g. xmlctf) which > of course is not sufficient to check if a change in one module breaks > the others... Yes, correct. But after a quick 'mvn install' in root, you can even today run 'mvn test' in xmlctf and check whether you've broken anything or not. It would be even better if one could include the xmlctf module in the <modules> section of the root POM, but problem is that there's two errors when doing this (probably due to a bug related to relative mapping file resolution). > * Currently the test modules are not successful on continuous build! Yes, but Ralf started converting all these tests months ago to real JUni ttests, I started working on the cpactf a few days ago to fully mavenize it, Lukas is looking into enabling Derby embedded for this suite, etc. It just takes time, and some dedication. And some good patches to be committed. Discussed. Agreed upon. > This should be fixed soon for our module base approach because then at > least on the continuous build we will see if all changes in all > modules really work together.... Yes, it should. And it will. It just depends on how much time you (and anybody else) is willing to spend on this (when there's 80 open bugs raised in the last 9 months where there's folks asking again and again whether a fix will be included in the next release). When it's time to ship a new release. And make JAXB partially available. And agree on a refactoring of XMLClassDescriptor(Imlp) without breaking thousands of classes that have been generated over 6+ years. > > Just my 2c ;-) A bit more than just 0.02 (euro) cents ... but then again, the exchange rate seems to be different these days. > Joachim > > > 2008/8/4 Ralf Joachim <[EMAIL PROTECTED]>: >> Problem with the per-module setup is that you can't commit changes per >> module as at least the release notes are not part of the modules. >> Because of this you will always need 2 projects. One with the whole >> Castor project where you edit release notes and commit all changes and >> at least one other for the module you like to do changes at. >> >> Maybe we can solve this by module specific release notes. Module >> specific docs would also make sense in this context. >> >> Another thing to care about with the per-module setup is, that you may >> not recognize that changes at one module brake something at another >> module. You will recognize such things only when you try to compile the >> whole project before commit. So we have the same problem with the >> per-module setup compared with using Java 5 settings with the >> single-project setup. You recognize problems only when compiling with >> maven. It seams to me that both setup options are not ideal. >> >> Having said that I'm open if you like to commit the per-module settings >> to SVN. In the past I thought this isn't required as they get generated >> with mvn eclipse:eclipse. >> >> Ralf >> >> >> Werner Guttmann schrieb: >>> Hi Ralf, >>> >>> Ralf Joachim wrote: >>>> I increased Java version to Java 5 only in cpa pom so maven will use the >>>> right settings if you work with an eclipse project per Castor module. >>> Yes, I have sen that and that should be fine (as we'll be soon doing the >>> same on the codegen POM). >>>> Only if you work with a single eclipse project for whole Castor the >>>> .settings are taken into account. In this case I don't see another >>>> chance as to increase dependency for the whole project as any Java 5 >>>> syntax, be it in cpa or codegen, will result in compile errors. If you >>>> think this should not go into trunk we can take care on this when >>>> merging the branch. >>> I am afraid that there's no other way to go forward about this, is there >>> ? Other than providing .eclipse and .classpath files on a per-module >>> base, I don't have any other idea. >>>> Ralf >>>> >>>> >>>> Werner Guttmann schrieb: >>>>> Hi Ralf, >>>>> >>>>> just had a look at the patch attached below, and it looks to me like you >>>>> are raising compiler version for the complete Eclipse project to Java 5. >>>>> I' like to have a brief discussion about the side-effects of this, as >>>>> clearly this will render it impossible to spot Java version compliance >>>>> issues. >>>>> >>>>> Regards >>>>> Werner >>>>> >>>>> -------- Original Message -------- >>>>> Subject: [castor-scm] [7797] castor/branches/query_engine/cpa: Increase >>>>> dependency of cpa to Java 5 >>>>> Date: Sun, 3 Aug 2008 09:36:15 -0500 (CDT) >>>>> From: [EMAIL PROTECTED] >>>>> Reply-To: dev@castor.codehaus.org >>>>> To: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> Revision >>>>> 7797 <http://fisheye.codehaus.org/changelog/castor/?cs=7797> >>>>> Author >>>>> rjoachim >>>>> Date >>>>> 2008-08-03 09:36:15 -0500 (Sun, 03 Aug 2008) >>>>> >>>>> >>>>> Log Message >>>>> >>>>> Increase dependency of cpa to Java 5 >>>>> >>>>> >>>>> Modified Paths >>>>> >>>>> * castor/branches/query_engine/.settings/org.eclipse.jdt.core.prefs >>>>> <#castorbranchesquery_enginesettingsorgeclipsejdtcoreprefs> >>>>> * castor/branches/query_engine/cpa/pom.xml >>>>> <#castorbranchesquery_enginecpapomxml> >>>>> >>>>> >>>>> Diff >>>>> >>>>> >>>>> Modified: >>>>> castor/branches/query_engine/.settings/org.eclipse.jdt.core.prefs >>>>> (7796 => 7797) >>>>> >>>>> --- castor/branches/query_engine/.settings/org.eclipse.jdt.core.prefs >>>>> 2008-08-03 11:33:45 UTC (rev 7796) >>>>> +++ castor/branches/query_engine/.settings/org.eclipse.jdt.core.prefs >>>>> 2008-08-03 14:36:15 UTC (rev 7797) >>>>> @@ -1,4 +1,4 @@ >>>>> -#Sat Oct 28 18:16:43 CEST 2006 >>>>> +#Sun Jul 20 15:37:40 GMT+01:00 2008 >>>>> eclipse.preferences.version=1 >>>>> org.eclipse.jdt.core.codeComplete.argumentPrefixes= >>>>> org.eclipse.jdt.core.codeComplete.argumentSuffixes= >>>>> @@ -9,21 +9,21 @@ >>>>> org.eclipse.jdt.core.codeComplete.staticFieldPrefixes=s_ >>>>> org.eclipse.jdt.core.codeComplete.staticFieldSuffixes= >>>>> org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled >>>>> -org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.1 >>>>> +org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5 >>>>> org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve >>>>> -org.eclipse.jdt.core.compiler.compliance=1.3 >>>>> +org.eclipse.jdt.core.compiler.compliance=1.5 >>>>> org.eclipse.jdt.core.compiler.debug.lineNumber=generate >>>>> org.eclipse.jdt.core.compiler.debug.localVariable=generate >>>>> org.eclipse.jdt.core.compiler.debug.sourceFile=generate >>>>> org.eclipse.jdt.core.compiler.problem.annotationSuperInterface=warning >>>>> -org.eclipse.jdt.core.compiler.problem.assertIdentifier=ignore >>>>> +org.eclipse.jdt.core.compiler.problem.assertIdentifier=error >>>>> org.eclipse.jdt.core.compiler.problem.autoboxing=ignore >>>>> org.eclipse.jdt.core.compiler.problem.deprecation=warning >>>>> >>>>> org.eclipse.jdt.core.compiler.problem.deprecationInDeprecatedCode=disabled >>>>> >>>>> org.eclipse.jdt.core.compiler.problem.deprecationWhenOverridingDeprecatedMethod=enabled >>>>> org.eclipse.jdt.core.compiler.problem.discouragedReference=warning >>>>> org.eclipse.jdt.core.compiler.problem.emptyStatement=ignore >>>>> -org.eclipse.jdt.core.compiler.problem.enumIdentifier=ignore >>>>> +org.eclipse.jdt.core.compiler.problem.enumIdentifier=error >>>>> org.eclipse.jdt.core.compiler.problem.fieldHiding=ignore >>>>> org.eclipse.jdt.core.compiler.problem.finalParameterBound=warning >>>>> >>>>> org.eclipse.jdt.core.compiler.problem.finallyBlockNotCompletingNormally=warning >>>>> @@ -62,4 +62,4 @@ >>>>> >>>>> org.eclipse.jdt.core.compiler.problem.unusedParameterWhenOverridingConcrete=enabled >>>>> org.eclipse.jdt.core.compiler.problem.unusedPrivateMember=warning >>>>> org.eclipse.jdt.core.compiler.problem.varargsArgumentNeedCast=warning >>>>> -org.eclipse.jdt.core.compiler.source=1.3 >>>>> +org.eclipse.jdt.core.compiler.source=1.5 >>>>> >>>>> >>>>> Modified: castor/branches/query_engine/cpa/pom.xml (7796 => 7797) >>>>> >>>>> --- castor/branches/query_engine/cpa/pom.xml 2008-08-03 11:33:45 >>>>> UTC >>>>> (rev 7796) >>>>> +++ castor/branches/query_engine/cpa/pom.xml 2008-08-03 14:36:15 >>>>> UTC >>>>> (rev 7797) >>>>> @@ -54,8 +54,8 @@ >>>>> <groupId>org.apache.maven.plugins</groupId> >>>>> <artifactId>maven-compiler-plugin</artifactId> >>>>> <configuration> >>>>> - <source>1.4</source> >>>>> - <target>1.4</target> >>>>> + <source>1.5</source> >>>>> + <target>1.5</target> >>>>> <!-- >>>>> <includes> >>>>> <include >>>>> implementation="java.lang.String">org/exolab/castor/builder/**</include> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> To unsubscribe from this list please visit: >>>>> >>>>> http://xircles.codehaus.org/manage_email >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >> -- >> >> Syscon Ingenieurbüro für Meß- und Datentechnik GmbH >> Ralf Joachim >> Raiffeisenstraße 11 >> 72127 Kusterdingen >> Germany >> >> Tel. +49 7071 3690 52 >> Mobil: +49 173 9630135 >> Fax +49 7071 3690 98 >> >> Internet: www.syscon.eu >> E-Mail: [EMAIL PROTECTED] >> >> Sitz der Gesellschaft: D-72127 Kusterdingen >> Registereintrag: Amtsgericht Stuttgart, HRB 382295 >> Geschäftsleitung: Jens Joachim, Ralf Joachim >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
