Hi,
It's now completely working now !
Both goals of the Release plugin are working great (release:prepare and
release:perform).
Once again, thanks a lot Felix for your help on Maven. ;)
However, I still have one important question.
As it is right now the build will deploy on the Maven
Pierre-Arnaud Marcelot wrote:
Hi,
It's now completely working now !
Both goals of the Release plugin are working great (release:prepare and
release:perform).
Once again, thanks a lot Felix for your help on Maven. ;)
However, I still have one important question.
As it is right now the build
One more thing...
The packaging of the studio-build project is jar.
Don't you think it should be 'pom' instead?
Regards,
Pierre-Arnaud
On Thu, Oct 9, 2008 at 2:42 PM, Pierre-Arnaud Marcelot [EMAIL PROTECTED]wrote:
On Thu, Oct 9, 2008 at 2:34 PM, Felix Knecht [EMAIL PROTECTED] wrote:
I'll
Hi Felix,
I need your help to fix the use of the release plugin in Studio's build.
At the moment, when I try to release I get an error when performing the
'release:perform' goal:
[INFO] [deploy:deploy-file {execution:
Pierre-Arnaud Marcelot schrieb:
On Thu, Oct 9, 2008 at 2:02 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
We can introduce a property for this which is set by default
(studio/pom.xml) to the correct place (e.g.
Felix Knecht schrieb:
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
I need your help to fix the use of the release plugin in Studio's build.
At the moment, when I try to release I get an error when performing
the 'release:perform' goal:
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
I need your help to fix the use of the release plugin in Studio's build.
At the moment, when I try to release I get an error when performing
the 'release:perform' goal:
[INFO]
Pierre-Arnaud Marcelot schrieb:
One more thing...
The packaging of the studio-build project is jar.
Don't you think it should be 'pom' instead?
IIRC there was any reason (?) in the beginning that this didn't worked,
so I used 'jar'. But your right -if 'pom' works now let's do it.
Thanks
Felix
On Thu, Oct 9, 2008 at 2:02 PM, Felix Knecht [EMAIL PROTECTED] wrote:
We can introduce a property for this which is set by default
(studio/pom.xml) to the correct place (e.g.
studio.dist.url${pom.distributionManagement.repository.url}/studio.dist.url
and then overwrite it in the local
On Thu, Oct 9, 2008 at 2:34 PM, Felix Knecht [EMAIL PROTECTED] wrote:
I'll do my best, as I don't know how to test it :-)
Héhé... :)
We'll see it live...
I'll test to release it on my employer's SVN and the CI machine will tell us
if the build is still successful or not.
Commit to trunk or
Felix Knecht schrieb:
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
I need your help to fix the use of the release plugin in Studio's build.
At the moment, when I try to release I get an error when performing
the 'release:perform' goal:
Pierre-Arnaud Marcelot schrieb:
We're almost there...
This time it's not failing, but it is trying to deploy the
distribution on p.a.o, instead of using the altDeploymentRepository
property.
See the log attached to this mail.
Any hints about that?
If this are the just fixed dist from the
Oh yeah. That's a very good idea!
I'm pretty confident it will work now (as it's working on the CI server).
I'm going to test that.
Thanks,
Pierre-Arnaud
On Thu, Oct 9, 2008 at 5:44 PM, Felix Knecht [EMAIL PROTECTED] wrote:
Pierre-Arnaud Marcelot schrieb:
We're almost there...
This
On Wed, Oct 1, 2008 at 7:19 PM, Stefan Seelmann [EMAIL PROTECTED] wrote:
We already have such profiles, they are called integration-core and
integration-ui :-)
Yeah, it's true, but I'm talking about a profile in the root pom that will
include the 'test-integration-core' and
Guys,
The release:prepare goal is working! ;) At last...
Here are the few modifications I had to do to make it work:
- Exclude the 'test-integration-core' and 'test-integration-ui' projects
from the build (so they don't get released).
- Change the version of the studio-maven-plugin to
Stefan Seelmann wrote:
Pierre-Arnaud Marcelot wrote:
I was wondering if it is possible for us to use the released Apache DS
1.5.4 dependencies instead of the 1.5.5-SNAPSHOT ones? Stefan, any
thoughts ?
I just updated because we use shared-0.9.13-SNAPSHOT in the main pom.xml
which is
Hi Emmanuel,
On Wed, Oct 1, 2008 at 9:22 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote:
Stefan Seelmann wrote:
Pierre-Arnaud Marcelot wrote:
I was wondering if it is possible for us to use the released Apache DS
1.5.4 dependencies instead of the 1.5.5-SNAPSHOT ones? Stefan, any
thoughts ?
Pierre-Arnaud Marcelot schrieb:
Hi Emmanuel,
On Wed, Oct 1, 2008 at 9:22 AM, Emmanuel Lecharny [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Stefan Seelmann wrote:
Pierre-Arnaud Marcelot wrote:
I was wondering if it is possible for us to use the
Hi Stefan,
On Tue, Sep 30, 2008 at 11:02 PM, Stefan Seelmann [EMAIL PROTECTED]wrote:
Perhaps a better option is to exclude the integraton-ui and
integration-core plugins from the release?
WDYT?
Yeah, this could be a good idea.
Actually, it does not make sense to release those plugins on
Hi Felix,
On Wed, Oct 1, 2008 at 9:53 AM, Felix Knecht [EMAIL PROTECTED] wrote:
Exactly, that's already what we've done once. For the 1.1.0 release I
think.
When we released it, we also released a version of shared because we
had important fixes in it.
At the time we used a single vote
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
On Wed, Oct 1, 2008 at 9:53 AM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Exactly, that's already what we've done once. For the 1.1.0
release I
think.
When we released it, we also released a version of
On Wed, Oct 1, 2008 at 10:40 AM, Felix Knecht [EMAIL PROTECTED] wrote:
According to some discussions we had lately and also the note David made
about this you should never have a TLP pom snapshot dependency in a
project.
So if there are made any changes to the TLP pom they are just in the
Pierre-Arnaud Marcelot schrieb:
On Wed, Oct 1, 2008 at 10:40 AM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
According to some discussions we had lately and also the note
David made
about this you should never have a TLP pom snapshot dependency in
a
On Wed, Oct 1, 2008 at 11:08 AM, Felix Knecht [EMAIL PROTECTED] wrote:
This depends if you want to make usage of the latest changes done in the
TLP pom since release of version 13 ;-)
e.g. deploy it to the location of your whishes when just rying to do a
test or snapshot deployment using the
Pierre-Arnaud Marcelot wrote:
What we could do is associate them to a special integration-test profile.
They would be run only on demand.
Which would also speed up our build.
We already have such profiles, they are called integration-core and
integration-ui :-)
Regards,
Stefan
Hi guys,
I'm still trying to get the release plugin working.
We've made great improvements with the generation of the MANIFEST.MF files.
However I'm still having a problem when using the release plugin.
Our test-integration-* projects use Apache DS 1.5.5-SNAPSHOT dependencies
which becomes
Pierre-Arnaud Marcelot wrote:
I was wondering if it is possible for us to use the released Apache DS
1.5.4 dependencies instead of the 1.5.5-SNAPSHOT ones? Stefan, any
thoughts ?
I just updated because we use shared-0.9.13-SNAPSHOT in the main pom.xml
which is not compatible with
Hi Felix,
I followed the indications given by David and added the correct files to
src/main/appended-resources/META-INF to the projects that needed to include
others licenses and notice informations.
Everything is fine now:
- The MANIFEST.MF files are now automatically generated by Maven
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
I followed the indications given by David and added the correct files
to src/main/appended-resources/META-INF to the projects that needed to
include others licenses and notice informations.
Everything is fine now:
* The MANIFEST.MF files are
Thanks Felix for the last commit on the DSML Parser jar project.
I think we're done with this refactoring. Everything has been replaced and
still works. :)
While we were doing this, I noticed that the LICENCE.TXT and NOTICE.TXT
files that are located in the META-INF folder are not used, nor
Pierre-Arnaud Marcelot schrieb:
I think we're done with this refactoring. Everything has been replaced
and still works. :)
:-)
While we were doing this, I noticed that the LICENCE.TXT and
NOTICE.TXT files that are located in the META-INF folder are not used,
nor included in the final jar.
I don't know what is in your jars under discussion.
My understanding of the policies about LICENSE and NOTICE files is
that they apply to what is actually in the artifact (jar in this case)
being distributed. The DEPENDENCIES file you mention includes
information about stuff that is not
Thanks David.
I also got David on IRC and he explained me in more details how we could
clean our legal files.
It is possible to remove the files in the META-INF folder of our projects (I
think we can even delete the META-INF folder itself) and relocate them when
it's appropriate as Velocity
David Jencks schrieb:
I don't know what is in your jars under discussion.
My understanding of the policies about LICENSE and NOTICE files is that
they apply to what is actually in the artifact (jar in this case) being
distributed. The DEPENDENCIES file you mention includes information
I've managed to update all our code plugins:
- aciitemeditor
- apacheds
- apacheds-configuration
- connection-core
- connectio-ui
- ldapbrowser-common
- ldapbrowser-core
- ldapbrowser-ui
- ldif-parser
- ldifeditor
- rcp
- schemaeditor
- valueeditors
Pierre-Arnaud Marcelot schrieb:
I've managed to update all our code plugins:
* aciitemeditor
* apacheds
* apacheds-configuration
* connection-core
* connectio-ui
* ldapbrowser-common
* ldapbrowser-core
* ldapbrowser-ui
* ldif-parser
* ldifeditor
On Wed, Sep 24, 2008 at 5:23 PM, Felix Knecht [EMAIL PROTECTED] wrote:
It's only run if the studio-plugin is configured in the specific pom and
skip is set to false.
Maybe we need to to have a another property in the studio-plugin (like
skip) for the execution of the bundle:manifest.
Ok,
Pierre-Arnaud Marcelot schrieb:
On Wed, Sep 24, 2008 at 5:23 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
It's only run if the studio-plugin is configured in the specific pom
and skip is set to false.
Maybe we need to to have a another property in the
Pierre-Arnaud Marcelot schrieb:
I've managed to update all our code plugins:
* aciitemeditor
* apacheds
* apacheds-configuration
* connection-core
* connectio-ui
* ldapbrowser-common
* ldapbrowser-core
* ldapbrowser-ui
* ldif-parser
* ldifeditor
On Wed, Sep 24, 2008 at 5:55 PM, Felix Knecht [EMAIL PROTECTED] wrote:
I couldn't find it, the bundle-plugin is there.
Oh, yeah sorry, I misunderstood. I'll add the studio plugin configuration.
Because otherwise we have done this too:
copyArtifacts( artifactList );
// Update .classpath
Pierre-Arnaud Marcelot schrieb:
On Fri, Sep 19, 2008 at 6:58 PM, Pierre-Arnaud Marcelot
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 5:49 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
If the 2 MF files are identical the one
On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht [EMAIL PROTECTED] wrote:
+1
IIRC the MANIFEST.MF is also used by Eclipse (but I'm not sure).
Yep, it is used to launch the plugin from within Eclipse to debug the plugin
and it's also used as Manifest of the final jar.
If so we need to adapt
On Fri, Sep 19, 2008 at 6:58 PM, Pierre-Arnaud Marcelot [EMAIL
PROTECTED]wrote:
On Fri, Sep 19, 2008 at 5:49 PM, Felix Knecht [EMAIL PROTECTED] wrote:
If the 2 MF files are identical the one from META-INF can be copied to the
target using the resources / section in the
pom.
The idea is
Pierre-Arnaud Marcelot schrieb:
On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
IIRC the MANIFEST.MF is also used by Eclipse (but I'm not sure).
Yep, it is used to launch the plugin from within Eclipse to debug the
plugin and
On Tue, Sep 23, 2008 at 12:00 PM, Pierre-Arnaud Marcelot [EMAIL
PROTECTED]wrote:
On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht [EMAIL PROTECTED] wrote:
+1
IIRC the MANIFEST.MF is also used by Eclipse (but I'm not sure).
Yep, it is used to launch the plugin from within Eclipse to debug
On Tue, Sep 23, 2008 at 12:12 PM, Felix Knecht [EMAIL PROTECTED] wrote:
Not sure if this could also be done by the dependency plugin.
Yeah, you're right, we could use this one. I'm using it for the ApacheDS
plugin.
See also[1] Eclipse/PDE-Integration.
Thanks, that's what I'm already using
Hi Jeff
On Tue, Sep 23, 2008 at 12:00 PM, Pierre-Arnaud Marcelot
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
IIRC the MANIFEST.MF is also used by Eclipse (but
I know that is is possible for a Mojo to launch the goal of another
plugin. This can be done with the execute annotation
(http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
I can't get this working as it never finds the goal eclipse:eclipse
Hi Jeff,
On Tue, Sep 23, 2008 at 12:15 PM, Jeff MAURY [EMAIL PROTECTED]wrote:
I know that is is possible for a Mojo to launch the goal of another plugin.
This can be done with the execute annotation (
On Tue, Sep 23, 2008 at 1:36 PM, Felix Knecht [EMAIL PROTECTED] wrote:
I can't get this working as it never finds the goal eclipse:eclipse
(external plugin) but only plugin internal goals.
Too bad, thanks for trying it out...
But there's another approach looking at the release plugin. The
On Tue, Sep 23, 2008 at 2:07 PM, Felix Knecht [EMAIL PROTECTED] wrote:
If we manage to get the eclipse:eclipse forked this shouldn't be a
problem anymore.
Yeah, as we're running a command line, instead of just running 'mvn
eclipse:eclipse', we could be running 'mvn eclipe:eclipse
Pierre-Arnaud Marcelot schrieb:
On Tue, Sep 23, 2008 at 1:36 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I can't get this working as it never finds the goal eclipse:eclipse
(external plugin) but only plugin internal goals.
Too bad, thanks for trying it out...
Hi all,
[WARNING]
I'm in the process of removing the MANIFEST.MF files from SVN and replace
them by generated ones.
This, and the modifications we've been doing with Felix on the Maven Studio
plugin, may have a huge impact on the build until everything has been
migrated.
Don't be surprised if
Hi all,
I want to give you an update on where I am with the use of the Maven Release
Plugin in Studio.
I still can't get the release plugin to work correctly, but I have made
significant progress...
I'm not working on Apache's SVN repository to do my testing but on my
employer's private SVN
Pierre-Arnaud Marcelot schrieb:
Hi all,
I want to give you an update on where I am with the use of the Maven
Release Plugin in Studio.
I still can't get the release plugin to work correctly, but I have
made significant progress...
I'm not working on Apache's SVN repository to do my
Felix Knecht schrieb:
Just some ideas
- Did your run using the -Prelease profile?
- Did you verify if at this moment the artifact exists in your local
repository?
- Change the default preparationGoals to 'clean install verify' (see
Pierre-Arnaud Marcelot schrieb:
Hi Felix,
On Fri, Sep 19, 2008 at 2:06 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Just some ideas
- Did your run using the -Prelease profile?
Nope.
Is this mandatory ? What does it do ?
More or less mandatory. It's defined
Pierre-Arnaud Marcelot schrieb:
On Fri, Sep 19, 2008 at 2:11 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
- Change the default preparationGoals to 'clean install verify' (see
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html)
Yeah, I've
Hi Felix,
On Fri, Sep 19, 2008 at 2:06 PM, Felix Knecht [EMAIL PROTECTED] wrote:
Just some ideas
- Did your run using the -Prelease profile?
Nope.
Is this mandatory ? What does it do ?
- Did you verify if at this moment the artifact exists in your local
repository?
I have an artifact
On Fri, Sep 19, 2008 at 2:18 PM, Felix Knecht [EMAIL PROTECTED] wrote:
More or less mandatory. It's defined in the TLP pom and forces pgp
signing of the artifacts, generate source jars for deployment (I think)
and runs a king of forked deploy goal (which implicitly invokes install
via maven
On Fri, Sep 19, 2008 at 2:11 PM, Felix Knecht [EMAIL PROTECTED] wrote:
- Change the default preparationGoals to 'clean install verify' (see
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html)
Yeah, I've seen this in the documentation. But I was thinking the maven
default
On Fri, Sep 19, 2008 at 2:11 PM, Felix Knecht [EMAIL PROTECTED] wrote:
- Change the default preparationGoals to 'clean install verify' (see
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html)
It worked. The build is now successful.
However, I still got an error when doing
Pierre-Arnaud Marcelot schrieb:
On Fri, Sep 19, 2008 at 2:11 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
- Change the default preparationGoals to 'clean install verify' (see
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html)
It worked.
Unfortunaltely, version 1.5.2 does not solves the problem.
There's a Jira opened for this issue[1].
I think that's what happened when Alex tried to release Apache DS 1.5.4 the
past week.
Regards,
Pierre-Arnaud
[1] - http://jira.codehaus.org/browse/SCM-406
On Fri, Sep 19, 2008 at 3:25 PM,
On Fri, Sep 19, 2008 at 3:37 PM, Felix Knecht [EMAIL PROTECTED] wrote:
Not sure if it's a Mac OS X problem - I had it also on linux. mvn
release:rollback will rollback the versioning in your poms but won't
delete the svn tag it has created in the repository. I had to delete it
manually before
On Fri, Sep 19, 2008 at 3:44 PM, Pierre-Arnaud Marcelot [EMAIL
PROTECTED]wrote:
Hopefully there's a workaround:
# mvn release:prepare
= fails
# svn up -r head
# mvn release:prepare -Dresume
I confirm that the workaround is working.
I finally get the release:prepare goal to finish
Pierre-Arnaud Marcelot schrieb:
On Fri, Sep 19, 2008 at 3:44 PM, Pierre-Arnaud Marcelot
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hopefully there's a workaround:
# mvn release:prepare
= fails
# svn up -r head
# mvn release:prepare -Dresume
I
On Fri, Sep 19, 2008 at 4:01 PM, Felix Knecht [EMAIL PROTECTED] wrote:
Yep. Otherwise we make it working or add another goal especially for this.
I was too optimistic... It's not working very good.
There are two problems:
- only a few projects get updated
- the changes to the manifest
Pierre-Arnaud Marcelot schrieb:
On Fri, Sep 19, 2008 at 4:01 PM, Felix Knecht [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yep. Otherwise we make it working or add another goal especially for
this.
I was too optimistic... It's not working very good.
There are two
On Fri, Sep 19, 2008 at 5:49 PM, Felix Knecht [EMAIL PROTECTED] wrote:
If the 2 MF files are identical the one from META-INF can be copied to the
target using the resources / section in the
pom.
The idea is to get rid of the current META-INF folder. This will not be in
SVN anymore.
The
70 matches
Mail list logo
