You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Pierre-Arnaud Marcelot <pa...@marcelot.net> on 2007/12/27 18:52:03 UTC
[Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Hi all,
I'm happy to tell you that I have successfully generated new launchers (for
each platform we support - Mac OS X, Linux and Windows) using Eclipse
3.3.1dependencies (the latest 3.3.1.1
to be precise).
They can be tested on this branch :
https://svn.apache.org/repos/asf/directory/studio/branches/studio-eclipse-3.3
I think that moving from the old 3.2 to the latest 3.3.1.1 Eclipse
dependencies could be another great feature for Apache Directory Studio
1.1.0. This update has fixed bugs in the core of Eclipse (and has
significantly improved the way widgets are drawn on Mac OS X - at last...).
I was wondering if everybody was OK with releasing Studio 1.1.0 with Eclipse
3.3 dependencies. WDYT ?
I also had a talk with Emmanuel about the "mavenization" of the trunk before
releasing Studio 1.1.0.
Stefan Seelmann and I were more thinking of switching from Ant+Ivy to Maven
after the release, but it could also be interesting to delay a little bit
the release and use this time to switch our build system. This would help us
a lot for future releases, especially if we need to release a 1.1.1 soon
after 1.1.0.
Do you think we should "Mavenize" the build before releasing Studio 1.1.0 ?
Thanks in advance for your wise answers,
Pierre-Arnaud Marcelot
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Stefan Seelmann <se...@apache.org>.
Hi,
> I think that moving from the old 3.2 to the latest 3.3.1.1
> <http://3.3.1.1> Eclipse dependencies could be another great feature for
> Apache Directory Studio 1.1.0. This update has fixed bugs in the core of
> Eclipse (and has significantly improved the way widgets are drawn on Mac
> OS X - at last...).
>
> I was wondering if everybody was OK with releasing Studio 1.1.0 with
> Eclipse 3.3 dependencies. WDYT ?
>
That is great. I really think we should switch to 3.3 as it fixes a lot
of bugs, especially for MacOS ;-)
>
> I also had a talk with Emmanuel about the "mavenization" of the trunk
> before releasing Studio 1.1.0.
> Stefan Seelmann and I were more thinking of switching from Ant+Ivy to
> Maven after the release, but it could also be interesting to delay a
> little bit the release and use this time to switch our build system.
> This would help us a lot for future releases, especially if we need to
> release a 1.1.1 soon after 1.1.0.
>
> Do you think we should "Mavenize" the build before releasing Studio 1.1.0 ?
>
Felix made great efforts with the maven build. I think it is OK to
switch to maven before the 1.1.0 release, if Felix has time to make the
distribution build working. I am still a maven fool, so I could only
help with testing and error reporting...
Regards,
Stefan
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Emmanuel Lecharny <el...@gmail.com>.
Pierre-Arnaud Marcelot wrote:
> Hi all,
>
> I'm happy to tell you that I have successfully generated new launchers
> (for each platform we support - Mac OS X, Linux and Windows) using
> Eclipse 3.3.1 dependencies (the latest 3.3.1.1 <http://3.3.1.1> to be
> precise).
Just great !!!
>
> They can be tested on this branch :
> https://svn.apache.org/repos/asf/directory/studio/branches/studio-eclipse-3.3
> <https://svn.apache.org/repos/asf/directory/studio/branches/studio-eclipse-3.3>
>
> I think that moving from the old 3.2 to the latest 3.3.1.1
> <http://3.3.1.1> Eclipse dependencies could be another great feature
> for Apache Directory Studio 1.1.0. This update has fixed bugs in the
> core of Eclipse (and has significantly improved the way widgets are
> drawn on Mac OS X - at last...).
>
> I was wondering if everybody was OK with releasing Studio 1.1.0 with
> Eclipse 3.3 dependencies. WDYT ?
+1 for me.
>
>
> I also had a talk with Emmanuel about the "mavenization" of the trunk
> before releasing Studio 1.1.0.
> Stefan Seelmann and I were more thinking of switching from Ant+Ivy to
> Maven after the release, but it could also be interesting to delay a
> little bit the release and use this time to switch our build system.
> This would help us a lot for future releases, especially if we need to
> release a 1.1.1 soon after 1.1.0.
>
> Do you think we should "Mavenize" the build before releasing Studio
> 1.1.0 ?
We are not in a hurry, I think. We can wait a bit to get maven in the
loop : otherwise, we will have to wait a long time before having maven
for studio. And also, I think that we need to leverage Felix work,
because it's ok to work in a sandbox, but at some point, going for real
is much better :)
>
> Thanks in advance for your wise answers,
> Pierre-Arnaud Marcelot
Thanks for your great work !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
Fantastic! That's exactly what I was thinking.
Thanks a lot.
Pierre-Arnaud
On Jan 3, 2008 1:53 AM, Felix Knecht <fe...@apache.org> wrote:
> > I was looking at the help plugins (studio-apacheds-configuration-help,
> > studio-ldapbrowser-help, studio-ldifeditor-help, studio-rcp-help,
> > studio-schemaeditor-help) and there's a lot of duplicated instructions
> > to generate the user guides in various formats (html for web, pdf, html
> > for eclipse). It would be very good to have that stored only at one
> place.
>
> Can we go this way for the *-help plugins?
> See http://svn.apache.org/viewvc?view=rev&revision=608298
>
> Regards
> Felix
>
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
> I was looking at the help plugins (studio-apacheds-configuration-help,
> studio-ldapbrowser-help, studio-ldifeditor-help, studio-rcp-help,
> studio-schemaeditor-help) and there's a lot of duplicated instructions
> to generate the user guides in various formats (html for web, pdf, html
> for eclipse). It would be very good to have that stored only at one place.
Can we go this way for the *-help plugins?
See http://svn.apache.org/viewvc?view=rev&revision=608298
Regards
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> On Jan 3, 2008 6:27 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> and them adapt the distribution process in the {sandbox}/studio/pom.xml.
> (the horrible tasks ... in the maven-antrun-plugin sections ...)
>
>
> Yeah... lol
> That's what I tried to do, but with no success. Not so easy to dive in
> these tasks... :(
So it would be ok to 'pollute' especially the studio/pom.xml with a lot more comments?
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> On Jan 3, 2008 6:27 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> and them adapt the distribution process in the {sandbox}/studio/pom.xml.
> (the horrible tasks ... in the maven-antrun-plugin sections ...)
>
>
> Yeah... lol
> That's what I tried to do, but with no success. Not so easy to dive in
> these tasks... :(
>
Remember the good old times with ant/ivy - maven-antrun-plugin just runs core anttasks
> BTW, there also another "hack" we will need to do.
> On all Linux and Windows distributions the plugins and features folders
> are located at the root of the ApacheDirectoryStudio folder, aside the
> ApacheDirectoryStudio (or 'Apache Directory Studio.exe') application.
> On Mac OS X, they not located there but they are hidden inside the
> Apache Directory Studio.app folder (which is actually the application
> itself - it behaves like a single file and not a folder on Mac OS X).
> Their correct location is under the '/Apache Directory
> Studio.app/Contents/Resources/Java' folder.
> So, I think we need also some platform specific variables here.
That's what we have profiles for.
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On Jan 3, 2008 6:27 PM, Felix Knecht <fe...@apache.org> wrote:
> and them adapt the distribution process in the {sandbox}/studio/pom.xml.
> (the horrible tasks ... in the maven-antrun-plugin sections ...)
Yeah... lol
That's what I tried to do, but with no success. Not so easy to dive in these
tasks... :(
BTW, there also another "hack" we will need to do.
On all Linux and Windows distributions the plugins and features folders are
located at the root of the ApacheDirectoryStudio folder, aside the
ApacheDirectoryStudio (or 'Apache Directory Studio.exe') application.
On Mac OS X, they not located there but they are hidden inside the Apache
Directory Studio.app folder (which is actually the application itself - it
behaves like a single file and not a folder on Mac OS X). Their correct
location is under the '/Apache Directory Studio.app/Contents/Resources/Java'
folder.
So, I think we need also some platform specific variables here.
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> That's what I was trying to do in the pom.xml files. But I could not
> get It working for now... :(
> There are still some things I don't understand very well in the build.
Just ask and I'll try to explain what the pom is doing :-)
>
> What I'm going to do is uploading the 'studio launchers' (so you can
> replicate them in your online repo) and explain what I wanted to do.
> I think with your help and knowledge on the build system, we'll be
> able to make it work...
>
Uploaded.
Now we need to replaced the dependencies below with
<dependency>
<groupId>org.apache.directory.studio</groupId>
<artifactId>launcher-*</artifactId>
<version>1.1.0</version>
<type>zip</type>
</dependency>
and them adapt the distribution process in the {sandbox}/studio/pom.xml.
(the horrible tasks ... in the maven-antrun-plugin sections ...)
Felix
> <dependency>
> <groupId>org.eclipse</groupId>
> <artifactId>eclipse-RCP-macosx-carbon</artifactId>
> <version>3.3.1.1 <http://3.3.1.1></version>
> <type>tar.gz</type>
> </dependency>
> ...
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> Ok,
>
> Here are the new 'Studio Launchers' ->
> http://svn.apache.org/viewvc?rev=608563&view=rev
> <http://svn.apache.org/viewvc?rev=608563&view=rev>
>
> Now, here's what I wanted to do in the build (and couldn't...):
>
> --> Profile Simplification
> I think we can simplify the profiles and update them to follow the
> eclipse naming for platforms.
>
That's good. The notests profile is just a dummy profile for my and shorter to type than -Dmaven.tes ....
> I would rename the profiles as is:
> - notests
> - linux-x86
> - linux-x86_64
> - linux-ppc
> - macosx
> - win32
>
> This means:
> - merging the two Mac OS X profiles into a single one (the
> application is the same if it's a PowerPC Mac or an Intel Mac).
> - dropping the windows 64bits profile as we don't have such a machine
I do ;-), but RCP are only available in milestone versions for eclipse 3.4
> (so we can't generate the appropriate launcher) and no one has been
> complaining on the ML for the lack of such a release.
>
<snip />
>
> WDYT ? (I hope it is clear enough... If not, don't hesitate to ask...)
As you've seen it's even enough to think about it ;-)
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Ok,
Here are the new 'Studio Launchers' ->
http://svn.apache.org/viewvc?rev=608563&view=rev
Now, here's what I wanted to do in the build (and couldn't...):
--> Profile Simplification
I think we can simplify the profiles and update them to follow the eclipse
naming for platforms.
I would rename the profiles as is:
- notests
- linux-x86
- linux-x86_64
- linux-ppc
- macosx
- win32
This means:
- merging the two Mac OS X profiles into a single one (the application is
the same if it's a PowerPC Mac or an Intel Mac).
- dropping the windows 64bits profile as we don't have such a machine (so
we can't generate the appropriate launcher) and no one has been complaining
on the ML for the lack of such a release.
--> Add new platform specific variables
With the arrival of the new studio launchers we need to add new platform
specific variables:
- two for the studio launcher itself (there is one per platform) :
studio.launcher.platformrelated.groupId and
studio.launcher.platformrelated.artifactId
- two for the equinox launcher dependency needed by the new studio launcher
: equinox.launcher.platformrelated.groupId and
equinox.launcher.platformrelated.artifactId
I have edited the root pom.xml to reflect these changes
Here is the profiles section:
<profiles>
<!-- Skip tests -->
<profile>
<id>notests</id>
<properties>
<maven.test.skip>true</maven.test.skip>
</properties>
</profile>
<!-- Linux x86 -->
<profile>
<id>linux-x86</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<swt.platformrelated.groupId>org.eclipse.swt.gtk.linux
</swt.platformrelated.groupId>
<swt.platformrelated.artifactId>x86</swt.platformrelated.artifactId>
<equinox.launcher.platformrelated.groupId>
org.eclipse.equinox.launcher.gtk.linux
</equinox.launcher.platformrelated.groupId>
<equinox.launcher.platformrelated.artifactId
>x86</equinox.launcher.platformrelated.artifactId>
<studio.launcher.platformrelated.groupId>org.apache.directory.studio
</studio.launcher.platformrelated.groupId>
<studio.launcher.platformrelated.artifactId
>launcher-linux</studio.launcher.platformrelated.artifactId>
</properties>
</profile>
<!-- Linux x86_64 -->
<profile>
<id>linux-x86_64</id>
<properties>
<swt.platformrelated.groupId>org.eclipse.swt.gtk.linux
</swt.platformrelated.groupId>
<swt.platformrelated.artifactId
>x86_64</swt.platformrelated.artifactId>
<equinox.launcher.platformrelated.groupId>
org.eclipse.equinox.launcher.gtk.linux
</equinox.launcher.platformrelated.groupId>
<equinox.launcher.platformrelated.artifactId
>x86_64</equinox.launcher.platformrelated.artifactId>
<studio.launcher.platformrelated.groupId>org.apache.directory.studio
</studio.launcher.platformrelated.groupId>
<studio.launcher.platformrelated.artifactId
>launcher-linux</studio.launcher.platformrelated.artifactId>
</properties>
</profile>
<!-- Linux PPC -->
<profile>
<id>linux-ppc</id>
<properties>
<swt.platformrelated.groupId>org.eclipse.swt.gtk.linux
</swt.platformrelated.groupId>
<swt.platformrelated.artifactId>ppc</swt.platformrelated.artifactId>
<equinox.launcher.platformrelated.groupId>
org.eclipse.equinox.launcher.gtk.linux
</equinox.launcher.platformrelated.groupId>
<equinox.launcher.platformrelated.artifactId
>ppc</equinox.launcher.platformrelated.artifactId>
<studio.launcher.platformrelated.groupId>org.apache.directory.studio
</studio.launcher.platformrelated.groupId>
<studio.launcher.platformrelated.artifactId
>launcher-linux</studio.launcher.platformrelated.artifactId>
</properties>
</profile>
<!-- Windows -->
<profile>
<id>win32</id>
<properties>
<swt.platformrelated.groupId>org.eclipse.swt.win32.win32
</swt.platformrelated.groupId>
<swt.platformrelated.artifactId>x86</swt.platformrelated.artifactId>
<equinox.launcher.platformrelated.groupId>
org.eclipse.equinox.launcher.win32.win32
</equinox.launcher.platformrelated.groupId>
<equinox.launcher.platformrelated.artifactId
>x86</equinox.launcher.platformrelated.artifactId>
<studio.launcher.platformrelated.groupId>org.apache.directory.studio
</studio.launcher.platformrelated.groupId>
<studio.launcher.platformrelated.artifactId
>launcher-win32</studio.launcher.platformrelated.artifactId>
</properties>
</profile>
<!-- Mac OS X -->
<profile>
<id>macosx</id>
<properties>
<swt.platformrelated.groupId>org.eclipse.swt.carbon
</swt.platformrelated.groupId>
<swt.platformrelated.artifactId
>macosx</swt.platformrelated.artifactId>
<equinox.launcher.platformrelated.groupId>
org.eclipse.equinox.launcher.carbon
</equinox.launcher.platformrelated.groupId>
<equinox.launcher.platformrelated.artifactId
>macosx</equinox.launcher.platformrelated.artifactId>
<studio.launcher.platformrelated.groupId>org.apache.directory.studio
</studio.launcher.platformrelated.groupId>
<studio.launcher.platformrelated.artifactId
>launcher-macosx</studio.launcher.platformrelated.artifactId>
</properties>
</profile>
</profiles>
Theses dependencies must be added to the eclipse dependencies section:
<dependency>
<groupId>org.eclipse.equinox.launcher.gtk.linux</groupId>
<artifactId>x86</artifactId>
<version>1.0.2.R331_v20071019</version>
</dependency>
<dependency>
<groupId>org.eclipse.equinox.launcher.gtk.linux</groupId>
<artifactId>x86_64</artifactId>
<version>1.0.2.R331_v20071019</version>
</dependency>
<dependency>
<groupId>org.eclipse.equinox.launcher.gtk.linux</groupId>
<artifactId>ppc</artifactId>
<version>1.0.2.R331_v20071019</version>
</dependency>
<dependency>
<groupId>org.eclipse.equinox.launcher.win32.win32</groupId>
<artifactId>x86</artifactId>
<version>1.0.2.R331_v20071019</version>
</dependency>
<dependency>
<groupId>org.eclipse.equinox.launcher.carbon</groupId>
<artifactId>macosx</artifactId>
<version>1.0.2.R331_v20071019</version>
</dependency>
And these ones to the Apache Directory Studio dependencies
<dependency>
<groupId>org.apache.directory.studio</groupId>
<artifactId>laucher-linux</artifactId>
<version>1.1.0</version>
</dependency>
<dependency>
<groupId>org.apache.directory.studio</groupId>
<artifactId>laucher-macosx</artifactId>
<version>1.1.0</version>
</dependency>
<dependency>
<groupId>org.apache.directory.studio</groupId>
<artifactId>laucher-win32</artifactId>
<version>1.1.0</version>
</dependency>
Finally (this is the part I could not achieve correctly...), we need to
update the build to use the new 'studio launcher' with its 'equinox
dependency' instead of the old eclipse distribution we were using.
WDYT ? (I hope it is clear enough... If not, don't hesitate to ask...)
Pierre-Arnaud
On Jan 3, 2008 6:02 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> That's what I was trying to do in the pom.xml files. But I could not get
> It working for now... :(
> There are still some things I don't understand very well in the build.
>
> What I'm going to do is uploading the 'studio launchers' (so you can
> replicate them in your online repo) and explain what I wanted to do.
> I think with your help and knowledge on the build system, we'll be able to
> make it work...
>
> Pierre-Arnaud
>
>
> On Jan 3, 2008 5:54 PM, Felix Knecht < felixk@apache.org> wrote:
>
> > Pierre-Arnaud Marcelot schrieb:
> > > On Jan 3, 2008 4:56 PM, Felix Knecht < felixk@apache.org
> > > <ma...@apache.org>> wrote:
> > >
> > > If this are the new 'eclipse starters':
> > > Zip them to zip or tar.gz and deploy them into the local-repo like
> > > above
> > > using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as
> > artifact
> > > and be unpacked be a dependency goal.
> > >
> > >
> > > No, these are not the new 'eclipse starters'.
> >
> > There are still dependencies for the RCP dist:
> > <dependency>
> > <groupId>org.eclipse</groupId>
> > <artifactId>eclipse-RCP-macosx-carbon</artifactId>
> > <version>3.3.1.1</version>
> > <type>tar.gz</type>
> > </dependency>
> > ...
> >
> > Do we still need them after you added the starters or can we skip them?
> >
> > Felix
> >
> >
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
That's what I was trying to do in the pom.xml files. But I could not get It
working for now... :(
There are still some things I don't understand very well in the build.
What I'm going to do is uploading the 'studio launchers' (so you can
replicate them in your online repo) and explain what I wanted to do.
I think with your help and knowledge on the build system, we'll be able to
make it work...
Pierre-Arnaud
On Jan 3, 2008 5:54 PM, Felix Knecht <fe...@apache.org> wrote:
> Pierre-Arnaud Marcelot schrieb:
> > On Jan 3, 2008 4:56 PM, Felix Knecht <felixk@apache.org
> > <ma...@apache.org>> wrote:
> >
> > If this are the new 'eclipse starters':
> > Zip them to zip or tar.gz and deploy them into the local-repo like
> > above
> > using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as
> artifact
> > and be unpacked be a dependency goal.
> >
> >
> > No, these are not the new 'eclipse starters'.
>
> There are still dependencies for the RCP dist:
> <dependency>
> <groupId>org.eclipse</groupId>
> <artifactId>eclipse-RCP-macosx-carbon</artifactId>
> <version>3.3.1.1</version>
> <type>tar.gz</type>
> </dependency>
> ...
>
> Do we still need them after you added the starters or can we skip them?
>
> Felix
>
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> On Jan 3, 2008 4:56 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> If this are the new 'eclipse starters':
> Zip them to zip or tar.gz and deploy them into the local-repo like
> above
> using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
> and be unpacked be a dependency goal.
>
>
> No, these are not the new 'eclipse starters'.
There are still dependencies for the RCP dist:
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>eclipse-RCP-macosx-carbon</artifactId>
<version>3.3.1.1</version>
<type>tar.gz</type>
</dependency>
...
Do we still need them after you added the starters or can we skip them?
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> On Jan 3, 2008 4:56 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> If this are the new 'eclipse starters':
> Zip them to zip or tar.gz and deploy them into the local-repo like
> above
> using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
> and be unpacked be a dependency goal.
>
>
> No, these are not the new 'eclipse starters'. I have been able to put
> the new 'eclipse starters' in the local repo using the "mvn
> deploy:deploy-file" command.
>
> These 3 folders are new eclipse dependencies needed by the new
> 'eclipse starters'. They are platform specific and there's one for
> linux, one Mac OS X and one for Windows.
> Strangely in the orginal eclipse distribution, they are not packaged
> as jar or zip files but as folders.
> Maybe I shoud zip them (like the new 'eclipse starters') and use the
> "mvn deploy:deploy-file" command.
Yep, I think this is best, having them as a dependency. We can unzip
them whenever we need them during the build process.
>
> Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On Jan 3, 2008 4:56 PM, Felix Knecht <fe...@apache.org> wrote:
> If this are the new 'eclipse starters':
> Zip them to zip or tar.gz and deploy them into the local-repo like above
> using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
> and be unpacked be a dependency goal.
No, these are not the new 'eclipse starters'. I have been able to put the
new 'eclipse starters' in the local repo using the "mvn deploy:deploy-file"
command.
These 3 folders are new eclipse dependencies needed by the new 'eclipse
starters'. They are platform specific and there's one for linux, one Mac OS
X and one for Windows.
Strangely in the orginal eclipse distribution, they are not packaged as jar
or zip files but as folders.
Maybe I shoud zip them (like the new 'eclipse starters') and use the "mvn
deploy:deploy-file" command.
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> No there the same as the one found on each eclipse distribution (Mac
> OS X, Linux and Windows).
> The .DS_Store and ._.DS_Store are files generated by Mac OS X and can
> be removed.
> I think this is the same for the other files.
> Mac OS X loves to generate files which are then a real nightmare for
> developers... :'(
> I can also see that my folder contains also some .svn folder that
> should be removed as well. I copy/pasted the folders from the svn
> studio-eclipse-3.3 branch. They should be removed as well.
> Sorry about that.
NP.
They are up at as tar.gz. @
http://people.apache.org/~felixk/studio-eclipse-m2/org/eclipse/equinox/launcher/
. I had some problems to jar the win32 stuff, that's why I tared them.
Next step adding them as dependencies and untaring when building a
distribution. It'll take it's time ;-)
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
No there the same as the one found on each eclipse distribution (Mac OS X,
Linux and Windows).
The .DS_Store and ._.DS_Store are files generated by Mac OS X and can be
removed.
I think this is the same for the other files.
Mac OS X loves to generate files which are then a real nightmare for
developers... :'(
I can also see that my folder contains also some .svn folder that should be
removed as well. I copy/pasted the folders from the svn
studio-eclipse-3.3branch. They should be removed as well.
Sorry about that.
Pierre-Arnaud
On Jan 3, 2008 5:22 PM, Felix Knecht <fe...@apache.org> wrote:
> Pierre-Arnaud Marcelot schrieb:
> > The mail is gone. ;)
>
> I do also have some strange looking files like in the root folder as
> well as in the subfolders.
> .DS_Store
> ._.DS_Store
> ._org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019*
> ._org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.2.R331_v20071019*
>
>
> Do the also go to any dependency or are it just the 3 folder, for each a
> dependency? Looking at an unzip eclipse I can see the folders there as
> well. Are these the same folders or did you change/added/deleted
> anything from the original folders?
>
> Thanks
> Felix
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> The mail is gone. ;)
I do also have some strange looking files like in the root folder as
well as in the subfolders.
.DS_Store
._.DS_Store
._org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019*
._org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.2.R331_v20071019*
Do the also go to any dependency or are it just the 3 folder, for each a
dependency? Looking at an unzip eclipse I can see the folders there as
well. Are these the same folders or did you change/added/deleted
anything from the original folders?
Thanks
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
The mail is gone. ;)
Thanks,
Pierre-Arnaud
On Jan 3, 2008 5:04 PM, Felix Knecht <fe...@apache.org> wrote:
> Felix Knecht schrieb:
> > Sorry, hit send by mistake. Here comes what I wanted to write.
> >
> > Pierre-Arnaud Marcelot schrieb:
> >
> >> On Jan 3, 2008 2:49 PM, Felix Knecht <felixk@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Just unzipped all the eclipse stuff in the {mysandox}/tools and
> >> run the
> >> last command from tools/shell-commands.txt.
> >>
> >> But please don't even if it sounds easy - I had to do some weird
> >> patching in the maven-eclipse-plugin to get it working because of
> >>
> http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
> >> (don't know if this is a bug in maven itself or in the
> >> maven-eclipse-plugin ...)
> >>
> >>
> >> I have 3 new dependencies to add. They are not packaged as jar or zip
> >> files but as simple folders.
> >> How should I do ?
> >>
>
> Or zip them all and mail them to felix at felixknecht.ch with a small
> explanation what to do with them ;-)
> Felix
>
> > I'm not sure what you mean.
> >
> > If this are the new 'eclipse starters':
> > Zip them to zip or tar.gz and deploy them into the local-repo like above
> > using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
> > and be unpacked be a dependency goal.
> >
> >
> >> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
> >> deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
> >> -Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=
> 1.0.0
> >> -DgeneratePom=true
> >>
> >>
> >
> >
>
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
>
>
> On Jan 3, 2008 2:49 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> Just unzipped all the eclipse stuff in the {mysandox}/tools and
> run the
> last command from tools/shell-commands.txt.
>
> But please don't even if it sounds easy - I had to do some weird
> patching in the maven-eclipse-plugin to get it working because of
> http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
> (don't know if this is a bug in maven itself or in the
> maven-eclipse-plugin ...)
>
>
> I have 3 new dependencies to add. They are not packaged as jar or zip
> files but as simple folders.
> How should I do ?
>
> I tried what you explained above but I got a failure:
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Required goal not found: eclipse:to-maven
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Jan 03 16:43:02 CET 2008
> [INFO] Final Memory: 1M/3M
> [INFO]
> ------------------------------------------------------------------------
>
>
>
> Yes. you can do like this and sha/md5 are generate (see also
> http://maven.apache.org/plugins/maven-deploy-plugin/usage.html at the
> bottom):
>
> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ touch
> sample.jar
> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
> deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
> -Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=1.0.0
> -DgeneratePom=true
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'deploy'.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Maven Default Project
> [INFO] task-segment: [deploy:deploy-file] (aggregator-style)
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] [deploy:deploy-file]
> Uploading:
> file:../local-repository/myGroup/sample/1.0.0/sample-1.0.0.jar
> 0b uploaded
> [INFO] Retrieving previous metadata from remote-repository
> [INFO] Uploading repository metadata for: 'artifact myGroup:sample'
> [INFO] Retrieving previous metadata from remote-repository
> [INFO] Uploading project information for sample 1.0.0
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Jan 03 14:40:11 CET 2008
> [INFO] Final Memory: 2M/5M
>
>
> Thanks for the hint. It worked well.
>
> Pierre-Arnaud
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Felix Knecht schrieb:
> Sorry, hit send by mistake. Here comes what I wanted to write.
>
> Pierre-Arnaud Marcelot schrieb:
>
>> On Jan 3, 2008 2:49 PM, Felix Knecht <felixk@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Just unzipped all the eclipse stuff in the {mysandox}/tools and
>> run the
>> last command from tools/shell-commands.txt.
>>
>> But please don't even if it sounds easy - I had to do some weird
>> patching in the maven-eclipse-plugin to get it working because of
>> http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
>> (don't know if this is a bug in maven itself or in the
>> maven-eclipse-plugin ...)
>>
>>
>> I have 3 new dependencies to add. They are not packaged as jar or zip
>> files but as simple folders.
>> How should I do ?
>>
Or zip them all and mail them to felix at felixknecht.ch with a small
explanation what to do with them ;-)
Felix
> I'm not sure what you mean.
>
> If this are the new 'eclipse starters':
> Zip them to zip or tar.gz and deploy them into the local-repo like above
> using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
> and be unpacked be a dependency goal.
>
>
>> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
>> deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
>> -Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=1.0.0
>> -DgeneratePom=true
>>
>>
>
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Sorry, hit send by mistake. Here comes what I wanted to write.
Pierre-Arnaud Marcelot schrieb:
>
>
> On Jan 3, 2008 2:49 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> Just unzipped all the eclipse stuff in the {mysandox}/tools and
> run the
> last command from tools/shell-commands.txt.
>
> But please don't even if it sounds easy - I had to do some weird
> patching in the maven-eclipse-plugin to get it working because of
> http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
> (don't know if this is a bug in maven itself or in the
> maven-eclipse-plugin ...)
>
>
> I have 3 new dependencies to add. They are not packaged as jar or zip
> files but as simple folders.
> How should I do ?
I'm not sure what you mean.
If this are the new 'eclipse starters':
Zip them to zip or tar.gz and deploy them into the local-repo like above
using -Dpackaging=[zip¦tar.gz]. So they can be downloaded as artifact
and be unpacked be a dependency goal.
>
> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
> deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
> -Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=1.0.0
> -DgeneratePom=true
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On Jan 3, 2008 2:49 PM, Felix Knecht <fe...@apache.org> wrote:
> Just unzipped all the eclipse stuff in the {mysandox}/tools and run the
> last command from tools/shell-commands.txt.
>
> But please don't even if it sounds easy - I had to do some weird
> patching in the maven-eclipse-plugin to get it working because of
> http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
> (don't know if this is a bug in maven itself or in the
> maven-eclipse-plugin ...)
>
I have 3 new dependencies to add. They are not packaged as jar or zip files
but as simple folders.
How should I do ?
I tried what you explained above but I got a failure:
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'eclipse'.
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Required goal not found: eclipse:to-maven
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Jan 03 16:43:02 CET 2008
[INFO] Final Memory: 1M/3M
[INFO]
------------------------------------------------------------------------
> Yes. you can do like this and sha/md5 are generate (see also
> http://maven.apache.org/plugins/maven-deploy-plugin/usage.html at the
> bottom):
>
> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ touch
> sample.jar
> felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
> deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
> -Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=1.0.0
> -DgeneratePom=true
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'deploy'.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Maven Default Project
> [INFO] task-segment: [deploy:deploy-file] (aggregator-style)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [deploy:deploy-file]
> Uploading: file:../local-repository/myGroup/sample/1.0.0/sample-1.0.0.jar
> 0b uploaded
> [INFO] Retrieving previous metadata from remote-repository
> [INFO] Uploading repository metadata for: 'artifact myGroup:sample'
> [INFO] Retrieving previous metadata from remote-repository
> [INFO] Uploading project information for sample 1.0.0
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Jan 03 14:40:11 CET 2008
> [INFO] Final Memory: 2M/5M
Thanks for the hint. It worked well.
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> On Jan 3, 2008 12:16 PM, Felix Knecht <felixk@apache.org
> <ma...@apache.org>> wrote:
>
> I neither don't now. I can test at home if it could work. But I'm not
> sure if it's a good idea to misuse svn for this.
>
>
> That's also the reason why I was wondering if we were able to do
> this... That's not really the purpose of the svn server.
>
> Thinking about resources and performance I can imagine it's better to
> put it somewhere in http://p.a.o/~.../maven2
> <http://p.a.o/%7E.../maven2>.
> I can put it to http://p.a.o/~/felix/studio-eclipse-m2
> <http://p.a.o/%7E/felix/studio-eclipse-m2> e.g.
>
>
> Yes, that's a better idea. We could test with this location and move
> the repo to another location under
> http://directory.apache.org/studio/... once we switch the build system.
I'll try (hopefully this evening).
>
>
> It makes definitely more sense to use my sandbox than creating you own
> branch. It's open to everyone working on the mavenization of
> studio and
> the easiest way to share code when working on the same problems :-)
>
>
> Cool. :)
>
> I was wondering how you (prepared and) installed the eclipse
> dependencies in the m2 repo.
Just unzipped all the eclipse stuff in the {mysandox}/tools and run the
last command from tools/shell-commands.txt.
But please don't even if it sounds easy - I had to do some weird
patching in the maven-eclipse-plugin to get it working because of
http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html
(don't know if this is a bug in maven itself or in the
maven-eclipse-plugin ...)
> I have a few new dependencies to add to it.
> I added the Studio launchers zip archives to the repo using the 'mvn
> instal:install-file' command but it does not generate the associated
> *.sha1 files.
> Here's what I have done to install one of the packages :
> mvn install:install-file -Dfile=launcher-linux-1.1.0.zip
> -DgroupId=org.apache.directory.studio -DartifactId=launcher-linux
> -Dversion=1.1.0 -Dpackaging=zip
>
> Should I use another command ?
Yes. you can do like this and sha/md5 are generate (see also
http://maven.apache.org/plugins/maven-deploy-plugin/usage.html at the
bottom):
felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ touch sample.jar
felix@lapfelix ~/svn/apache/directory/maven-studio/tools $ mvn
deploy:deploy-file -Durl=file:../local-repository -Dfile=sample.jar
-Dpackaging=jar -DgroupId=myGroup -DartifactId=sample -Dversion=1.0.0
-DgeneratePom=true
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
------------------------------------------------------------------------
[INFO] [deploy:deploy-file]
Uploading: file:../local-repository/myGroup/sample/1.0.0/sample-1.0.0.jar
0b uploaded
[INFO] Retrieving previous metadata from remote-repository
[INFO] Uploading repository metadata for: 'artifact myGroup:sample'
[INFO] Retrieving previous metadata from remote-repository
[INFO] Uploading project information for sample 1.0.0
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Jan 03 14:40:11 CET 2008
[INFO] Final Memory: 2M/5M
HTH
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On Jan 3, 2008 12:16 PM, Felix Knecht <fe...@apache.org> wrote:
> I neither don't now. I can test at home if it could work. But I'm not
> sure if it's a good idea to misuse svn for this.
That's also the reason why I was wondering if we were able to do this...
That's not really the purpose of the svn server.
Thinking about resources and performance I can imagine it's better to
> put it somewhere in http://p.a.o/~.../maven2 <http://p.a.o/%7E.../maven2>.
> I can put it to http://p.a.o/~/felix/studio-eclipse-m2<http://p.a.o/%7E/felix/studio-eclipse-m2>
> e.g.
Yes, that's a better idea. We could test with this location and move the
repo to another location under http://directory.apache.org/studio/... once
we switch the build system.
It makes definitely more sense to use my sandbox than creating you own
> branch. It's open to everyone working on the mavenization of studio and
> the easiest way to share code when working on the same problems :-)
Cool. :)
I was wondering how you (prepared and) installed the eclipse dependencies in
the m2 repo.
I have a few new dependencies to add to it.
I added the Studio launchers zip archives to the repo using the 'mvn
instal:install-file' command but it does not generate the associated *.sha1
files.
Here's what I have done to install one of the packages :
mvn install:install-file -Dfile=launcher-linux-1.1.0.zip -DgroupId=
org.apache.directory.studio -DartifactId=launcher-linux
-Dversion=1.1.0-Dpackaging=zip
Should I use another command ?
Thanks
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> Hi Felix,
>
> I'm still fighting with the 'local-repository'.
> We can also create our 'own' maven2 remote repository with the
> needed eclipse dependencies and have it online instead of
> putting all the binaries into the repository, e.g.
> http://people.apache.org/~felixk/maven2
> <http://people.apache.org/%7Efelixk/maven2> (or any other url)
> and add this repository in the studios root pom.xml.
>
>
> I agree with that.
>
> It could be great to create a specific Maven2 repo in a new branch in
> SVN at the root of the Directory project space, something like "
> http://svn.apache.org/repos/asf/directory/maven2/trunk". But I don't
> know if it possible (and/or allowed).
I neither don't now. I can test at home if it could work. But I'm not
sure if it's a good idea to misuse svn for this.
Thinking about resources and performance I can imagine it's better to
put it somewhere in http://p.a.o/~.../maven2.
I can put it to http://p.a.o/~/felix/studio-eclipse-m2 e.g.
>
>
> Doing so we could avoid definitely the problems we the generation
> of those nasty '${local-repository}' (or so)
> directories which happens depending of the location (studio root
> or subproject) you start the mvn command from.
>
>
> It would be great.
>
>
> I'm working on the generation of the zip packages for the specific RCP
> launcher applications for Linux, Mac OS X and Windows.
> When I have something working, do I commit in your sandbox, Felix, or
> do I create a branch in my own sandbox and commit there ?
It makes definitely more sense to use my sandbox than creating you own
branch. It's open to everyone working on the mavenization of studio and
the easiest way to share code when working on the same problems :-)
Regards
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
I'm still fighting with the 'local-repository'.
> We can also create our 'own' maven2 remote repository with the needed
> eclipse dependencies and have it online instead of
> putting all the binaries into the repository, e.g.
> http://people.apache.org/~felixk/maven2<http://people.apache.org/%7Efelixk/maven2>(or any other url)
> and add this repository in the studios root pom.xml.
I agree with that.
It could be great to create a specific Maven2 repo in a new branch in SVN at
the root of the Directory project space, something like "
http://svn.apache.org/repos/asf/directory/maven2/trunk". But I don't know if
it possible (and/or allowed).
> Doing so we could avoid definitely the problems we the generation of those
> nasty '${local-repository}' (or so)
> directories which happens depending of the location (studio root or
> subproject) you start the mvn command from.
It would be great.
I'm working on the generation of the zip packages for the specific RCP
launcher applications for Linux, Mac OS X and Windows.
When I have something working, do I commit in your sandbox, Felix, or do I
create a branch in my own sandbox and commit there ?
Thanks,
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> Hi Felix,
>
>
> I wonder if we need
> a) the prefix 'studio' for the modules
> b) having the org.apache.directory.studio in the artifact name
>
>
> so a checkout directory structure could look like
> .../studio/trunk
> .../studio/trunk/studio
> .../studio/trunk/aciitemeditor
> .../studio/trunk/apacheds-configuration
> .../studio/trunk/apacheds-configuration-feature
> to be continued
>
>
> and a dependency would look like
> <dependency>
> <groupId>org.apache.directory.studio</groupId>
> <artifactId>aciitemeditor</artifactId>
> </dependency>
>
> WDOT?
>
>
> I'm completely OK with that.
> +1
>
> In fact we can separate to modules on it's own projects, because
> they are not 'immediately' involved in the studio project:
> - studio-plugin (parent pom is already
> org.apache.directory.project:project)
> - studio-dsml-parser (need to change the parent pom to ?)
> - All the others I'd them as they are now.
>
> If taking also the dsml-parser out of the build process we need
> either to make sure that it exists as dependency in a
> remote repository or have a note in the documentation saying that
> you also need to build the dsml-parser (like the
> plugin) before the studio can be built.
>
> I don't now if it's a good idea but e.g. we can have a new directory
> project called directory-plugins where the
> maven-studio-plugin comes into and also the ones from apacheds which
> are intend of a more global use in future.
> The dsml-parser could be moved into the shared project. If you think
> that dsml parser can be used that globally why not
> put it in the studio-ldapbrowser-core module? I couldn't find any
> other place where it's used.
>
>
> Yeah, at some time, we'll need to integrate the dsml-parser inside
> shared-ldap.
> We have ideas to use it to build a DSML gateway for Apache DS.
>
> I think most of these duplications are a result of trying to do all
> of it in one build. If we can create the above
> mentioned modules on it's own it probably would make things easier.
>
>
> I'm not sure....
>
> I was looking at the help plugins (studio-apacheds-configuration-help,
> studio-ldapbrowser-help, studio-ldifeditor-help, studio-rcp-help,
> studio-schemaeditor-help) and there's a lot of duplicated instructions
> to generate the user guides in various formats (html for web, pdf, html
> for eclipse). It would be very good to have that stored only at one place.
I agree. Let's try to find a solution for this.
>
> I'm also wondering if the repositories definitions we can find at the
> end of each pom.xml could not be moved up in the pom inheritance tree.
I'm still fighting with the 'local-repository'.
We can also create our 'own' maven2 remote repository with the needed eclipse dependencies and have it online instead of
putting all the binaries into the repository, e.g.
http://people.apache.org/~felixk/maven2 (or any other url)
and add this repository in the studios root pom.xml.
Doing so we could avoid definitely the problems we the generation of those nasty '${local-repository}' (or so)
directories which happens depending of the location (studio root or subproject) you start the mvn command from.
>
> Yes, please go ahead. I think tar (or zip) is a more logical format
> than a jar (which would also be possible)
>
>
> Yes, I agree, tar or zip is more appropriate for our need here.
> I'll try to prepare these package as soon as possible. ;)
Thanks
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
> I wonder if we need
> a) the prefix 'studio' for the modules
> b) having the org.apache.directory.studio in the artifact name
>
>
> so a checkout directory structure could look like
> .../studio/trunk
> .../studio/trunk/studio
> .../studio/trunk/aciitemeditor
> .../studio/trunk/apacheds-configuration
> .../studio/trunk/apacheds-configuration-feature
> to be continued
>
>
> and a dependency would look like
> <dependency>
> <groupId>org.apache.directory.studio</groupId>
> <artifactId>aciitemeditor</artifactId>
> </dependency>
>
> WDOT?
I'm completely OK with that.
+1
In fact we can separate to modules on it's own projects, because they are
> not 'immediately' involved in the studio project:
> - studio-plugin (parent pom is already
> org.apache.directory.project:project)
> - studio-dsml-parser (need to change the parent pom to ?)
> - All the others I'd them as they are now.
>
> If taking also the dsml-parser out of the build process we need either to
> make sure that it exists as dependency in a
> remote repository or have a note in the documentation saying that you also
> need to build the dsml-parser (like the
> plugin) before the studio can be built.
>
> I don't now if it's a good idea but e.g. we can have a new directory
> project called directory-plugins where the
> maven-studio-plugin comes into and also the ones from apacheds which are
> intend of a more global use in future.
> The dsml-parser could be moved into the shared project. If you think that
> dsml parser can be used that globally why not
> put it in the studio-ldapbrowser-core module? I couldn't find any other
> place where it's used.
Yeah, at some time, we'll need to integrate the dsml-parser inside
shared-ldap.
We have ideas to use it to build a DSML gateway for Apache DS.
I think most of these duplications are a result of trying to do all of it in
> one build. If we can create the above
> mentioned modules on it's own it probably would make things easier.
>
I'm not sure....
I was looking at the help plugins (studio-apacheds-configuration-help,
studio-ldapbrowser-help, studio-ldifeditor-help, studio-rcp-help,
studio-schemaeditor-help) and there's a lot of duplicated instructions to
generate the user guides in various formats (html for web, pdf, html for
eclipse). It would be very good to have that stored only at one place.
I'm also wondering if the repositories definitions we can find at the end of
each pom.xml could not be moved up in the pom inheritance tree.
Yes, please go ahead. I think tar (or zip) is a more logical format than a
> jar (which would also be possible)
Yes, I agree, tar or zip is more appropriate for our need here.
I'll try to prepare these package as soon as possible. ;)
Regards,
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Felix Knecht schrieb:
> Pierre-Arnaud Marcelot schrieb:
>> Hi Felix,
>>
>> Building .classpath and Manifest file seems to work with 3.3
>> dependencies and I can start the plugins from within
>> eclipse without any error messages.
>>
>>
>> I just tested them and they work fine. Except the name of the projects
>> (which are very long now),
>
> I wonder if we need
> a) the prefix 'studio' for the modules
> b) having the org.apache.directory.studio in the artifact name
>
>
> so a checkout directory structure could look like
> .../studio/trunk
> .../studio/trunk/studio
> .../studio/trunk/aciitemeditor
> .../studio/trunk/apacheds-configuration
> .../studio/trunk/apacheds-configuration-feature
> to be continued
>
>
> and a dependency would look like
> <dependency>
> <groupId>org.apache.directory.studio</groupId>
> <artifactId>aciitemeditor</artifactId>
> </dependency>
We really should name them like this looking at the threads (discussions about mavenization of eclipse artifacts)
http://mail-archives.apache.org/mod_mbox/maven-dev/200711.mbox/%3c262c6c680711260553h322053c4o7950a01c3f5f11fa@mail.gmail.com%3e
and
http://mail-archives.apache.org/mod_mbox/maven-dev/200711.mbox/%3c474C024B.9070401@ukf.net%3e
(Sorry, haven't found a better link)
and (Eclipse jars now in maven by Carlos Sanchez)
http://www.jroller.com/carlossg/entry/eclipse_jars_now_in_maven
Reagards
Felix
PS and BTW
I'm going to 'migrate' the local-repository to the same structure as Carlos used (unfortunately most of the eclipse
3.3.1.1 are not yet in the official maven repository) and adapt the maven-studio-plugin/build process to work with the
migrated local-repository.
>
> WDOT?
>
> everything is really great and works very
>> very well within Eclipse. Thanks a lot for that. :)
>
> I'm happy it's working :-)
>
>> I had a look at the different pom.xml files and they are pretty long
>> now, and there seem to be some duplicate build instructions.
>> I'm wondering if we should not try to create differents parents pom
>> files, 1 for each type of project we have.
>>
>> I can see 4 different types of projects that requires 4 different builds:
>> - Classic java project (e.g. 'studio-dsml-parser')
>> - Eclipse plugin project (e.g. 'studio-ldapbrowser-core' or
>> 'studio-connection-ui')
>> - Feature project (e.g. 'studio-schemaeditor-feature')
>> - Help plugin project (e.g. 'studio-ldapbrowser-help')
>>
>> WDYT?
>
> In fact we can separate to modules on it's own projects, because they are not 'immediately' involved in the studio project:
> - studio-plugin (parent pom is already org.apache.directory.project:project)
> - studio-dsml-parser (need to change the parent pom to ?)
> - All the others I'd them as they are now.
>
> If taking also the dsml-parser out of the build process we need either to make sure that it exists as dependency in a
> remote repository or have a note in the documentation saying that you also need to build the dsml-parser (like the
> plugin) before the studio can be built.
>
> I don't now if it's a good idea but e.g. we can have a new directory project called directory-plugins where the
> maven-studio-plugin comes into and also the ones from apacheds which are intend of a more global use in future.
> The dsml-parser could be moved into the shared project. If you think that dsml parser can be used that globally why not
> put it in the studio-ldapbrowser-core module? I couldn't find any other place where it's used.
>
> I think most of these duplications are a result of trying to do all of it in one build. If we can create the above
> mentioned modules on it's own it probably would make things easier.
>
>
>> Distribution build needs still some work.
>>
>>
>> I can help with that. :)
>> I tested the distribution build on Linux and it works great.
>
> Happy to read :-)
>
> It fails on
>> Mac OS X and Windows but it's easy to fix.
>> The key is to use our specific application launchers (the ones located
>> in the /dependencies/eclipse/3.3.1/macosx,
>> /dependencies/eclipse/3.3.1/linux, /dependencies/eclipse/3.3.1/win32
>> folders) instead of re-using the ones from the eclipse distribution (
>> e.g. eclipse-RCP-macosx-carbon-3.3.1.1). They all work great and include
>> the correct branding (with the correct icons for example).
>> So I think we have to tar gzip these launchers, install them in our
>> local-repository and use them when building the application instead of
>> the ones we use at the moment.
>
> Yes, please go ahead. I think tar (or zip) is a more logical format than a jar (which would also be possible)
>
> Regards
> Felix
>
>
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
Pierre-Arnaud Marcelot schrieb:
> Hi Felix,
>
> Building .classpath and Manifest file seems to work with 3.3
> dependencies and I can start the plugins from within
> eclipse without any error messages.
>
>
> I just tested them and they work fine. Except the name of the projects
> (which are very long now),
I wonder if we need
a) the prefix 'studio' for the modules
b) having the org.apache.directory.studio in the artifact name
so a checkout directory structure could look like
.../studio/trunk
.../studio/trunk/studio
.../studio/trunk/aciitemeditor
.../studio/trunk/apacheds-configuration
.../studio/trunk/apacheds-configuration-feature
to be continued
and a dependency would look like
<dependency>
<groupId>org.apache.directory.studio</groupId>
<artifactId>aciitemeditor</artifactId>
</dependency>
WDOT?
everything is really great and works very
> very well within Eclipse. Thanks a lot for that. :)
I'm happy it's working :-)
>
> I had a look at the different pom.xml files and they are pretty long
> now, and there seem to be some duplicate build instructions.
> I'm wondering if we should not try to create differents parents pom
> files, 1 for each type of project we have.
>
> I can see 4 different types of projects that requires 4 different builds:
> - Classic java project (e.g. 'studio-dsml-parser')
> - Eclipse plugin project (e.g. 'studio-ldapbrowser-core' or
> 'studio-connection-ui')
> - Feature project (e.g. 'studio-schemaeditor-feature')
> - Help plugin project (e.g. 'studio-ldapbrowser-help')
>
> WDYT?
In fact we can separate to modules on it's own projects, because they are not 'immediately' involved in the studio project:
- studio-plugin (parent pom is already org.apache.directory.project:project)
- studio-dsml-parser (need to change the parent pom to ?)
- All the others I'd them as they are now.
If taking also the dsml-parser out of the build process we need either to make sure that it exists as dependency in a
remote repository or have a note in the documentation saying that you also need to build the dsml-parser (like the
plugin) before the studio can be built.
I don't now if it's a good idea but e.g. we can have a new directory project called directory-plugins where the
maven-studio-plugin comes into and also the ones from apacheds which are intend of a more global use in future.
The dsml-parser could be moved into the shared project. If you think that dsml parser can be used that globally why not
put it in the studio-ldapbrowser-core module? I couldn't find any other place where it's used.
I think most of these duplications are a result of trying to do all of it in one build. If we can create the above
mentioned modules on it's own it probably would make things easier.
>
> Distribution build needs still some work.
>
>
> I can help with that. :)
> I tested the distribution build on Linux and it works great.
Happy to read :-)
It fails on
> Mac OS X and Windows but it's easy to fix.
> The key is to use our specific application launchers (the ones located
> in the /dependencies/eclipse/3.3.1/macosx,
> /dependencies/eclipse/3.3.1/linux, /dependencies/eclipse/3.3.1/win32
> folders) instead of re-using the ones from the eclipse distribution (
> e.g. eclipse-RCP-macosx-carbon-3.3.1.1). They all work great and include
> the correct branding (with the correct icons for example).
> So I think we have to tar gzip these launchers, install them in our
> local-repository and use them when building the application instead of
> the ones we use at the moment.
Yes, please go ahead. I think tar (or zip) is a more logical format than a jar (which would also be possible)
Regards
Felix
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
Building .classpath and Manifest file seems to work with 3.3 dependencies
> and I can start the plugins from within
> eclipse without any error messages.
I just tested them and they work fine. Except the name of the projects
(which are very long now), everything is really great and works very very
well within Eclipse. Thanks a lot for that. :)
I had a look at the different pom.xml files and they are pretty long now,
and there seem to be some duplicate build instructions.
I'm wondering if we should not try to create differents parents pom files, 1
for each type of project we have.
I can see 4 different types of projects that requires 4 different builds:
- Classic java project (e.g. 'studio-dsml-parser')
- Eclipse plugin project (e.g. 'studio-ldapbrowser-core' or
'studio-connection-ui')
- Feature project (e.g. 'studio-schemaeditor-feature')
- Help plugin project (e.g. 'studio-ldapbrowser-help')
WDYT?
Distribution build needs still some work.
>
I can help with that. :)
I tested the distribution build on Linux and it works great. It fails on Mac
OS X and Windows but it's easy to fix.
The key is to use our specific application launchers (the ones located in
the /dependencies/eclipse/3.3.1/macosx, /dependencies/eclipse/3.3.1/linux,
/dependencies/eclipse/3.3.1/win32 folders) instead of re-using the ones from
the eclipse distribution (e.g. eclipse-RCP-macosx-carbon-3.3.1.1). They all
work great and include the correct branding (with the correct icons for
example).
So I think we have to tar gzip these launchers, install them in our
local-repository and use them when building the application instead of the
ones we use at the moment.
Regards,
Pierre-Arnaud
Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Posted by Felix Knecht <fe...@apache.org>.
>
> I also had a talk with Emmanuel about the "mavenization" of the trunk
> before releasing Studio 1.1.0.
> Stefan Seelmann and I were more thinking of switching from Ant+Ivy to
> Maven after the release, but it could also be interesting to delay a
> little bit the release and use this time to switch our build system.
> This would help us a lot for future releases, especially if we need to
> release a 1.1.1 soon after 1.1.0.
>
> Do you think we should "Mavenize" the build before releasing Studio 1.1.0 ?
Of course my non-binding +1 for this :-)
As it's quite clear now that the mavenized build will have at least eclipse-3.3.1.1 for sure I'm going to remove the 3.2
dependencies.
Building .classpath and Manifest file seems to work with 3.3 dependencies and I can start the plugins from within
eclipse without any error messages.
Distribution build needs still some work.
Regards
Felix