Hi Laurent,
Some words about us: At SAP a lot of development teams spread over
several locations develops applications and libraries. Our focus is on
the central builds (continuous integration, release builds). The
challenge for us it to handle the dependencies. Having the libs on
some shares or checked in into the SCM is of course not an option,
nobody knows which version exactly is in the repo/on the share, such
an approach is a nightmare and does not work at all. Since maven
together with nexus is anyway maintained in our company we decided to
use that infrastructure. So far that approach seems to work well with
regards to central builds. Also from the development teams we get good
feedback since mvn initialize materializes all the dependencies "out
of the box" in a simple way.
The problem reported by you is valid, but it was so far not reported
by our development teams. I understand the advantages of the
xcode-workspace approach . It reduces the turn-around time during
local development during the absolute minimum.
We have continuous-integration jobs on each project. Each time a
check-in is performed the corresponding CI-job is triggered. This job
performs a deployment into a nexus snapshot repository. Each developer
gets the latest changes when (s)he performs a mvn initialize. This
provides also a fast turn-around time, not so fast as with the
workspace, but also fast. The advantage is: everybody sees the changes
from a central build without the works-on-my-machine-problem.
>I would have prefered framework instead of librairies
Since 1.5.0 we support xcode-frameworks. May be you are interested in
checking this feature.
There are working examples contained inside the integration tests. A
good starting point might be
modules/it-xcode-maven-plugin/src/test/java/com/sap/prd/mobile/ios/mios/XCodeFrameworkTest.java
and the corresponding projects under
modules/it-xcode-maven-plugin/src/test/projects/framework.
In order to get the framework related integration tests running it is
required to install the file
https://github.com/sap-production/iOS-Universal-Framework/blob/master/Real%20Framework/UFW-iOSStaticFramework.xcspec
. This can be done with the installation script that can be found
here:
https://github.com/sap-production/iOS-Universal-Framework/blob/master/Real%20Framework/install.sh.
> I'm interested with the xcode ide plugin.Where can i download it ?
The xcode-ide-plugin is available here:
https://github.com/sap-production/xcode-ide-maven-integration
> Do u think it would be possible to update the plugin (or make another
one) so "mvn generate-sources" can be launched from xcode ?
You are invited to fork the project and to implement this change if
this fits into your needs. The relevant line of code is around line
123 in XcodeIDEMavenPlugin/RunInitializeOperation.m
<https://github.com/sap-production/xcode-ide-maven-integration/blob/master/XcodeIDEMavenPlugin/RunInitializeOperation.m>
(I refere to commitId 658a00863c9229d4848e884a6d6e8bea7d89be4f).
Why are you interested in phase generate-sources? Do you configure
your own plugins into the lifecycle? From the point of the
xcode-maven-plugin initialize is sufficient since this resolves all
the dependencies. After that step a developer is able to work locally
in xcode.
Best regards,
Marcus
Marcus Holl
Developer
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
T +49 0227 7-44001
marcus.holl@xxxxxxx
www.sap.com <http://www.sap.com>
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Bill McDermott (Co-CEO), Jim Hagemann
Snabe (Co-CEO), Werner Brandt, Lars Dalgaard, Luisa Delgado, Gerhard
Oswald und Vishal Sikka
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.
*From:*maven4ios-bounce@xxxxxxxxxxxxx
[mailto:maven4ios-bounce@xxxxxxxxxxxxx] *On Behalf Of *Laurent Michenaud
*Sent:* Dienstag, 23. Oktober 2012 15:00
*To:* maven4ios@xxxxxxxxxxxxx
*Subject:* [maven4ios] Re: RE : Re: About Local Development Environment
Thanks for your response.
I can see it is hard to find the best approach.
About us, we are coding some librairies for ios, with dependencies
between them.
These librairies will be used by projects.
So, we need two mode of developpment :
- The first mode is for us : when working on these librairies
(snapshot versions), we need a fast mode of developpment.
Workspace was a good point, because we have all the librairies inside
xcode, and dependency resolution
is done via workspace. We don't have to clean/install a library after
each change on it. But i can see it is
hard to make it work efficiently with xcode-maven-plugin.
- Second mode is for the users of the librairies (tagged versions) :
they need the headers and also the compiled library.
xcode-maven-plugin is ok for this mode. I would have prefered
framework instead of librairies because the headers
can be browsed inside xcode (framework node=>headers).
These are our two problematics. If u have suggestions about them...
I'm interested with the xcode ide plugin.
Where can i download it ?
Do u think it would be possible to update the plugin (or make another
one) so "mvn generate-sources" can be launched from xcode ?
Best regards
Laurent
On 23/10/2012 13:34, Holl, Marcus wrote:
Hi Laurent,
I can reproduce the problem. It was not reported from our xcode
developers so far.
The xcode-maven-plugin resolves the header files and puts these
files into ${build.dir}/headers/...
When a workspace is established the headers can be found in two ways:
1.)Via the workspace inside other projects that are part of the
workspace
2.)Via the header search path as defined in the project.
Obvioulsy xcode makes a "best match". If e.g. a method is not
found in a header inside the workspace then the corresponding
header is fetched from the header search path.
The problem does only occur for the header files. If something is
changed in the *.m files the corresponding change is active in the
iphone simulator when the project is rebuilt.
From the xcode-maven-plugin we cannot change the way how xcode
resolves the header files. The xcode-maven-plugin knows nothing
about an xcode workspace.
As a preliminary solution it is possible to remove the headers for
all libs that are part of the workspace from ${build.dir}/headers
manually. In this case only the headers from the workspace can be
found. This needs to be re-done after each call of mvn initialize.
Another option is to redefine the header search path in a way that
the headers for the projects that are part of the workspace are
not contained in the header search path. But with that approach a
central build with the xcode-maven-plugin will not work since in
this case the headers cannot be found. From my point of view that
proposal is technically possible but actually bad.
The "canonical" way would be not to work with workspaces but to
call "mvn install" each time when something has changed in a
library. It is also possible to spread around changes frequently
by deploying snapshot versions into a binary reposity (nexus). But
I agree: for large projects it might take too much time to call
mvn install after each change. Also the tool-shift (mvn,
xcode-IDE) is not nice.
We also provide an xcode IDE plugin [1]. In the long run we could
think about integrating this step (remove all the headers for the
projects that are part of the xcode-workspace) into this plugin.
But this is nothing that will happen in the near future. But you
are invited to contribute J. Up to now the Xcode-IDE-plugin
triggers "mvn initialize" from within the xcode IDE.
Your feedback is highly appreciated.
Best regards,
Marcus
Footnotes
[1] https://github.com/sap-production/xcode-ide-maven-integration
--
Marcus Holl
Developer
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
T +49 0227 7-44001
marcus.holl@xxxxxxx <mailto:marcus.holl@xxxxxxx>
www.sap.com <http://www.sap.com>
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Bill McDermott (Co-CEO), Jim
Hagemann Snabe (Co-CEO), Werner Brandt, Lars Dalgaard, Luisa
Delgado, Gerhard Oswald und Vishal Sikka
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder
sonstige vertrauliche Informationen enthalten. Sollten Sie
diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe
der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed,
or otherwise confidential information. If you have received this
e-mail in error, you are hereby notified that any review, copying,
or distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for
your cooperation.
*From:*maven4ios-bounce@xxxxxxxxxxxxx
<mailto:maven4ios-bounce@xxxxxxxxxxxxx>
[mailto:maven4ios-bounce@xxxxxxxxxxxxx] *On Behalf Of *Michenaud
Laurent
*Sent:* Montag, 22. Oktober 2012 17:59
*To:* maven4ios@xxxxxxxxxxxxx <mailto:maven4ios@xxxxxxxxxxxxx>
*Subject:* [maven4ios] RE : Re: About Local Development Environment
Question 2, i can't make it work.
Steps:
1- git clone https://github.com/sap-production/xcode-maven-plugin.git
2- straight-forward-with-snapshot-dependency / My Library
mvn -Dxcode.maven.plugin.version=1.5.1 install
3- straight-forward-with-snapshot-dependency / My App
mvn -Dxcode.maven.plugin.version=1.5.1 initialize
mvn -Dxcode.maven.plugin.version=1.5.1 install
=> Build is OK
4- Import My App inside Xcode
5- Create workspace from My App
6- Add My Library to workspace (same level as My App)
=> Build is OK
7- Comment methods printout methods in .h .m of PrintOutObjects
=> Build is still OK, shouldn't
8- Close workspace
9- Edit MyApp.xcodeproj/project.pbxproj (remove paths) :
11D442F138AA1790022678D /* libMyLibrary.a */ = {isa =
PBXFileReference; lastKnownFileType = archive.ar; name =
libMyLibrary.a; path = "libMyLibrary.a"; sourceTree =
BUILD_PRODUCTS_DIR; };
10- ReOpen workspace
=> Build is still OK, shouldn't
Thanks for your help
------------------------------------------------------------------------
*De :*maven4ios-bounce@xxxxxxxxxxxxx
<mailto:maven4ios-bounce@xxxxxxxxxxxxx>
[maven4ios-bounce@xxxxxxxxxxxxx
<mailto:maven4ios-bounce@xxxxxxxxxxxxx>] de la part de Holl,
Marcus [marcus.holl@xxxxxxx <mailto:marcus.holl@xxxxxxx>]
*Date d'envoi :* lundi 22 octobre 2012 16:22
*À :* maven4ios@xxxxxxxxxxxxx <mailto:maven4ios@xxxxxxxxxxxxx>
*Objet :* [maven4ios] Re: About Local Development Environment
Hi Laurent,
Regarding your first question:
I'm able to reproduce the scenario with the disappearing
"descriptor" folder. This seems not to be a bug inside the
xcode-maven-plugin.
The reason for that behavior is inside the configuration of the
project. When you drag the folder containing you header
("descriptor") into your project
with option "Create folder references for any added folders" and
when *that folder* (and not the header(s) itself) is subsequently
added to the public headers (inside Build Phases > Copy Headers)
the folder is not removed.
Attached you can find a simple library which is configured in a
way that a folder level inside your headers is not removed.
Regarding your second question:
The headers are fetched according to the header search path as
defined in your xcode project. When working with the
xcode-maven-plugin the header search path is part of the contract
between your xcode project and the xcode-maven-plugin. The header
search path is expected to be
${PROJECT_DIR}/../../target/headers/${BUILD_STYLE}-${PLATFORM_NAME}.
In order to get the resolution also working with workspaces it is
required to edit the project.pbxproj file manually. It must look
similar to:
833529D516231258000CD672 /* libDirectExchangeLib.a*/ = {isa =
PBXFileReference; lastKnownFileType = archive.ar; name =
libDirectExchangeLib.a; path = libDirectExchangeLib.a; sourceTree
= BUILT_PRODUCTS_DIR; };
The library must appear without path and the sourceTree must be
set to BUILD_PRODUCTS_DIR. Another solution is not known to us so far.
Please come back again if this does not answer your question. In
order to get a better understanding of the problem it would be
helpful to get a short example project alongside with the mail.
Best regards,
Marcus
-----Original Message-----
From: maven4ios-bounce@xxxxxxxxxxxxx
<mailto:maven4ios-bounce@xxxxxxxxxxxxx>
[mailto:maven4ios-bounce@xxxxxxxxxxxxx] On Behalf Of Laurent Michenaud
Sent: Freitag, 19. Oktober 2012 11:42
To: maven4ios@xxxxxxxxxxxxx <mailto:maven4ios@xxxxxxxxxxxxx>
Subject: [maven4ios] About Local Development Environment
Hi,
I'm trying to have a configuration working both with maven and
inside xcode.
I have followed instructions in the article
http://sap-production.github.com/xcode-maven-plugin/site/userguide/Workspace.html
but i can't make it work.
About my environnement, i have created two librairies :
MyLib and MyLibUI.
MyLibUI has a dependency to MyLib.
1) First question
MyLib project has a file header :
MyLib/src/xcode/MyLib/descriptor/descriptor.h
When i do "mvn initialize", the headers are exploded in
target/.../org.company/MyLib/
"org.company" is the groupId.
"MyLib" is the artifactId
=> the sub-directory "descriptor" is not kept.
=> In MyLibUI, i have to declare the import like this : #import
<org.company/MyLib/descriptor.h>
so it can compile with maven.
Is it the correct behaviour ?
2) Second question
I have created the workspace from MyLibUI.
I have added the project MyLib to the workspace.
=> It compiles in xcode.
Then, i wanted to check which header was used for compilation in
xcode :
=> the one in target or the one with workspace resolution ?
So, i tried different things :
- "mvn clean" in MyLibUI to remove installed headers.
- comment a method in descriptor.h to see if compilation is still ok.
=> My conclusion is that the used header is the one in the target
directory.
So, how working in local environnement using workspace resolution
? the
configuration option is well checked.
Other thing, after removing the target directory, the project doesnot
compile anymore :
The import <org.company/MyLib/descriptor.h> is not recognized.
Thanks for helping.
Best regards
