Is there any reason for having after an eclipse import references to a non existing shared_impl package?
Manfred Geiler schrieb: > Problem should be fixed now. > Though I do not understand why it worked for me. > Sean, did you use the current shared or did you use a modified version > (ie. without AddResource.properties)? > > Manfred > > > On 3/1/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> Manfred, >> >> I am unable to build the core. I get the following error message: >> >> [INFO] >> ------------------------------------------------------------------------- >> --- >> [ERROR] BUILD ERROR >> [INFO] >> ------------------------------------------------------------------------- >> --- >> [INFO] Error executing ant tasks >> >> Embedded error: The following error occurred while executing this line: >> D:\open-source\myfaces-core-1.1.2\impl\build.xml:30: >> D:\open-source\myfaces-core >> -1.1.2\impl\target\refactored-shared-sources\main\resources not found. >> [INFO] >> ------------------------------------------------------------------------- >> --- >> [INFO] For more information, run Maven with the -e switch >> [INFO] >> ------------------------------------------------------------------------- >> >> >> I made some progress on the merge but I will need to resolve this >> before I can check in. >> >> Sean >> >> On 2/28/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >>> Ok, I did some major modifications: >>> * shared module does not longer have submodules, instead the >>> refactoring is now done directly in impl and tomahawk >>> * shared creates two artifacts: one myfaces-shared-X.Y.Z.jar and one >>> myfaces-shared-X.Y.Z-sources.jar >>> * myfaces-shared-X.Y.Z.jar contains the pre-refactore shared classes >>> is not needed (ie. no other project should depend on it and it will >>> never be part of an assembly) >>> * myfaces-shared-X.Y.Z-sources.jar contains all sources and resources >>> and is used to "transfer" the shared sources two impl and tomahawk >>> * impl and tomahawk now both take the >>> myfaces-shared-X.Y.Z-sources.jar, unpack and refactor the sources and >>> finally compile the modified shared classes together with there own >>> classes >>> >>> There are still some quirks with the simple examples. So, please stay >>> tuned or better: Please help to find the cause. >>> >>> Note: We are still speaking of core and tomahawk on branches 1_1_2 >>> until Sean is finsihed with merging down the trunk. >>> >>> Thanks, >>> Manfred >>> >>> >>> On 2/28/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >>>> Hmm, then I made things even worse with my last checkin... >>>> There are now no more relative paths without a basedir, but in >>>> addition to depending on the parent src I have also added one central >>>> build.xml into the parent dir. So, this one won't work with continuum >>>> as well. :-( >>>> >>>> To be compatible to continuum one must not depend on directory >>>> hierarchy. Is that really true? >>>> What is the solution? Modify shared so that it produces a jar with >>>> source files, that the two subprojects depend on? That will make the >>>> build process even more complex than it is right now. >>>> >>>> Thoughts? >>>> >>>> Manfred >>>> >>>> >>>> On 2/28/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >>>>> OK the problem is that continuum puts each build in its own build with >>>>> a version number. Say you build shared first, it goes in >>>>> working-directory/102. Then you build shared-impl and it will have >>>>> its own build number. It goes in working-directory/103. The two >>>>> builds are not necessarily in the same directory. >>>>> >>>>> You can reproduce this problem (I think) by checking out *only* the >>>>> shared-impl dir and trying to build it. The parent artifact is >>>>> available in the apache snapshot repos now (thanks to continuum) and >>>>> also probably exists in your local repos. Yet you can't build because >>>>> you are assuming a complete directory hiearchy. >>>>> >>>>> This is probably only relevant to continuum since I don't think there >>>>> is much of a reason to try the usecase I have mentioned above. Still >>>>> if there is a way to get the src from the snapshot jar of the parent >>>>> process that would be nice. >>>>> >>>>> Sean >>>>> >>>>> >>>>> >>>>> On 2/28/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >>>>>> Hmm, perhaps the "../src/main/java" (relative path) in the ant task >>>>>> does not work when run with continuum? Perhaps we should move ant task >>>>>> to an external build.xml and set the basedir explicitly. Will try this >>>>>> right now. >>>>>> >>>>>> Manfred >>>>>> >>>>>> >>>>>> On 2/28/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >>>>>>> Manfred, >>>>>>> >>>>>>> I added shared to continuum but its choking on the refactoring[1]. I >>>>>>> will look into it tomorrow but if you can point me in the right >>>>>>> direction ... >>>>>>> >>>>>>> Sean >>>>>>> >>>>>>> [1]http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=536&id=102 >>>>>>> >>>>>>> On 2/27/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >>>>>>>> Manfred, >>>>>>>> >>>>>>>> I did a checkout and test build. Everything compiled ok. Later today >>>>>>>> I will look into the contents of the jar file and the behind the >>>>>>>> scenes maven stuff. If it looks good I think we should try to merge >>>>>>>> the core down to the trunk so people can continue to make changes >>>>>>>> there. >>>>>>>> >>>>>>>> Sean >>>>>>>> >>>>>>>> On 2/26/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >>>>>>>>> Step 3 is now done as well. >>>>>>>>> >>>>>>>>> Well, some examples already work but unfortunately not all. >>>>>>>>> I think most of the problems are related to ExtensionsFilter and/or >>>>>>>>> expression evaluation. >>>>>>>>> >>>>>>>>> Any help appreciated! >>>>>>>>> >>>>>>>>> You need: >>>>>>>>> shared (SVN: trunk) >>>>>>>>> core (SVN: branch 1_1_2) >>>>>>>>> tomahawk (SVN: branch 1_1_2) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Manfred >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/26/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >>>>>>>>>> First two (of three) steps of commons-->shared refactoring is done: >>>>>>>>>> >>>>>>>>>> Step 1: All former commons classes have been copied to a new shared >>>>>>>>>> module and have been refactored to package >>>>>>>>>> "org.apache.myfaces.shared.*" >>>>>>>>>> >>>>>>>>>> Step 2: An intermediate myfaces-shared-impl-2.0.0-SNAPSHOT.jar is now >>>>>>>>>> built automatically. It includes all shared classes auto-refactored >>>>>>>>>> to >>>>>>>>>> "org.apache.myfaces.shared_impl.*" namespace. >>>>>>>>>> Note: The "org.apache.myfaces.shared_impl" package is different to >>>>>>>>>> the >>>>>>>>>> originally proposed "org.apache.myfaces.impl.shared". I will explain >>>>>>>>>> the reasons why I chose another package name later in separate mail. >>>>>>>>>> All impl classes in branch 1_1_2 have been refactored as well and now >>>>>>>>>> use those "org.apache.myfaces.shared_impl" classes. In addition to >>>>>>>>>> that the shared_impl classes are now automatically bundled together >>>>>>>>>> with the impl classes and included in the >>>>>>>>>> myfaces-impl-1.1.2-SNAPSHOT.jar. >>>>>>>>>> >>>>>>>>>> Step 3 is pending: Do all that was done for impl in Step 2 for the >>>>>>>>>> tomahawk classes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> To try out you will need: >>>>>>>>>> shared (trunk) >>>>>>>>>> impl (branch 1_1_2) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Manfred >>>>>>>>>> >
