[Studio] Using the Maven Release Plugin

[Felix Knecht-2]

Pierre-Arnaud Marcelot schrieb:

> On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht <felixk@...
> <mailto:felixk@...>> 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 the documentation about the intial mvn
>     eclipse:eclipse
>     studio:eclipse stuff.
>
>
> Yeah, and no... We will still need the use of the studio:eclipse
> plugin I think (at least for copying the dependencies into the 'lib'
> folder).

Not sure if this could also be done by the dependency plugin. See also
[1] Eclipse/PDE-Integration.

> BTW, I was wondering if it's possible in Maven to attach the launch of
> a goal of a plugin to another goal (of another plugin), or if it's
> only possible to attach it to a phase of the build.
> Do you have an idea ?

I don't have any idea if it's possible. At that time I was looking to
extend the eclipse:eclipse goal, but wasn't successful. Maybe it was the
wrong way and attaching to another goal of a plugin is more successful.
It would really be nice if we could :-)

>  
>
>     Note also that studio:eclipse does some modifications in the
>     MANIFEST.MF. This need to be verified if it still works or isn't
>     needed
>     anymore when switching to felix bundle plugin.
>
>
> This won't be need anymore. The generated Manifest will work out of
> the box.

[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

[Jeff MAURY]

On Tue, Sep 23, 2008 at 12:00 PM, Pierre-Arnaud Marcelot <pa@...> wrote:

On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht <felixk@...> 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 the documentation about the intial mvn eclipse:eclipse
studio:eclipse stuff.

Yeah, and no... We will still need the use of the studio:eclipse plugin I think (at least for copying the dependencies into the 'lib' folder).
BTW, I was wondering if it's possible in Maven to attach the launch of a goal of a plugin to another goal (of another plugin), or if it's only possible to attach it to a phase of the build.

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)

Regards
Jeff MAURY

Do you have an idea ?
 

Note also that studio:eclipse does some modifications in the
MANIFEST.MF. This need to be verified if it still works or isn't needed
anymore when switching to felix bundle plugin.

This won't be need anymore. The generated Manifest will work out of the box.

Regards,
Pierre-Arnaud

--
La mélancolie c'est communiste
Tout le monde y a droit de temps en temps
La mélancolie n'est pas capitaliste
C'est même gratuit pour les perdants
La mélancolie c'est pacifiste
On ne lui rentre jamais dedans
La mélancolie oh tu sais ça existe
Elle se prend même avec des gants
La mélancolie c'est pour les syndicalistes
Il faut juste sa carte de permanent

Miossec (2006)

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.lastfm.fr/listen/user/jeffmaury/personal
Mes CDs à récupérer: http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en

[Pierre-Arnaud Marcelot-2]

On Tue, Sep 23, 2008 at 12:12 PM, Felix Knecht <felixk@...> 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 actually... :)
 

I don't have any idea if it's possible. At that time I was looking to
extend the eclipse:eclipse goal, but wasn't successful. Maybe it was the
wrong way and attaching to another goal of a plugin is more successful.
It would really be nice if we could :-)

I came to the same conclusion, Maven does not seem to be built to do that.

Thanks,
P-A

[Felix Knecht-2]

Hi Jeff

>
>
> On Tue, Sep 23, 2008 at 12:00 PM, Pierre-Arnaud Marcelot
> <pa@... <mailto:pa@...>> wrote:
>
>     On Tue, Sep 23, 2008 at 11:48 AM, Felix Knecht <felixk@...
>     <mailto:felixk@...>> 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 the documentation about the intial mvn
>         eclipse:eclipse
>         studio:eclipse stuff.
>
>
>     Yeah, and no... We will still need the use of the studio:eclipse
>     plugin I think (at least for copying the dependencies into the
>     'lib' folder).
>     BTW, I was wondering if it's possible in Maven to attach the
>     launch of a goal of a plugin to another goal (of another plugin),
>     or if it's only possible to attach it to a phase of the build.
>
> 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)
>

Sounds good.
IIUC this would allow us just to do a mvn studio:eclipse and the
eclipse:eclipse is executed implicitly before our stuff is done. I need
to dive deeper into this of finding an example already using this.

Thanks
Felix
> Regards
> Jeff MAURY

[Felix Knecht-2]

>>
>> 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
(external plugin) but only plugin internal goals.

But there's another approach looking at the release plugin. The fork a
mvn execution within the plugin to run the goals.
See
http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/ForkedMavenExecutor.java

Do you think it's worth to give it a try for eliminating the
eclipse:eclipse goal and run it (forked) by the studio:eclipse?

Regards
Felix

[Pierre-Arnaud Marcelot-2]

Hi Jeff,

On Tue, Sep 23, 2008 at 12:15 PM, Jeff MAURY <jeffmaury@...> 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 (http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)

Thanks. Unfortunately, we're trying to do that only in the pom.xml file (with the need to write another plugin).

To be clearer, let me detail what we want to do.
Right now in studio when you checkout the code and want to import it in Eclipse, you need to run the 'mvn eclipse:eclipse studio:eclipse' command line.
This command generates the .classpath, .project files for Eclipse (eclipse:eclipse goal) and, updates the manifest file (META-INF/MANIFEST.MF) and copies the needed dependencies in a 'lib' folder (studio:eclipse goal).
Recently, I've discovered the Felix Bundle plugin which let us easily generate a functionnal manifest file from the pom.xml file. We're also thinking with Felix, about replacing the use of the Studio plugin for copying our dependencies by the corresponding goal in the Dependencies plugin.
Then I was wondering if we could not replace our 'mvn eclipse:eclipse studio:eclipse' by 'mvn eclipse:eclipse', and have the generation of the manifest and the copy of the dependencies triggered by this 'eclipse:eclipse' goal.
Here's the idea...

If you have any trail on that... ;)

Regards,
Pierre-Arnaud

[Pierre-Arnaud Marcelot-2]

On Tue, Sep 23, 2008 at 1:36 PM, Felix Knecht <felixk@...> 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 fork a
mvn execution within the plugin to run the goals.
See
http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/ForkedMavenExecutor.java

Do you think it's worth to give it a try for eliminating the
eclipse:eclipse goal and run it (forked) by the studio:eclipse?

Yeah, maybe. Then we'll only need to run 'mvn studio:eclipse' to do the whole thing...

We could even run the 'manifest' goal of the Felix Bundle plugin in it too.
WDYT ?

Regards,
Pierre-Arnaud

[Felix Knecht-2]

Pierre-Arnaud Marcelot schrieb:

> On Tue, Sep 23, 2008 at 1:36 PM, Felix Knecht <felixk@...
> <mailto:felixk@...>> 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 fork a
>     mvn execution within the plugin to run the goals.
>     See
>     http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/ForkedMavenExecutor.java
>
>     Do you think it's worth to give it a try for eliminating the
>     eclipse:eclipse goal and run it (forked) by the studio:eclipse?
>
>
> Yeah, maybe. Then we'll only need to run 'mvn studio:eclipse' to do
> the whole thing...

Yep.

>
> We could even run the 'manifest' goal of the Felix Bundle plugin in it
> too.

If we manage to get the eclipse:eclipse forked this shouldn't be a
problem anymore. We then also should think about adding the manifest
goal to the release plugin definition (meaning clone the one from the
TLP pom and add the manifest goal) to make sure that the latest uptodate
manifest is in the release.

ATM I try to get the eclipse:eclipse forked stuff running.
> WDYT ?
>
> Regards,
> Pierre-Arnaud

[Pierre-Arnaud Marcelot-2]

On Tue, Sep 23, 2008 at 2:07 PM, Felix Knecht <felixk@...> 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 bundle:manifest'.

We then also should think about adding the manifest
goal to the release plugin definition (meaning clone the one from the
TLP pom and add the manifest goal) to make sure that the latest uptodate
manifest is in the release.

I don't think it's necessary, because it will still be defined in the pom.xml file of the project and the file won't be in SVN anymore... So the generated manifest will contain up-to-date informations about the version, dependencies versions etc.
 

ATM I try to get the eclipse:eclipse forked stuff running.

Thanks!

Regards,
Pierre-Arnaud

[Pierre-Arnaud Marcelot-2]

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 1.5.5 dependencies when using the release plugin which makes the build fail because Apache DS 1.5.5 is not there yet. This is plain normal.

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 think this is the last issue we'll be having to make the release plugin work. The generated jars look fine.

Thanks,
Pierre-Arnaud

On Tue, Sep 23, 2008 at 2:15 PM, Pierre-Arnaud Marcelot <pa@...> wrote:

On Tue, Sep 23, 2008 at 2:07 PM, Felix Knecht <felixk@...> 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 bundle:manifest'.

We then also should think about adding the manifest
goal to the release plugin definition (meaning clone the one from the
TLP pom and add the manifest goal) to make sure that the latest uptodate
manifest is in the release.

I don't think it's necessary, because it will still be defined in the pom.xml file of the project and the file won't be in SVN anymore... So the generated manifest will contain up-to-date informations about the version, dependencies versions etc.
 

ATM I try to get the eclipse:eclipse forked stuff running.

Thanks!

Regards,
Pierre-Arnaud

[Stefan Seelmann-3]

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 apacheds-1.5.4. However we need 0.9.13
because it fixes some problems with the LdapDN.toString() method. I
guess we will release a shared-0.9.13 before we release DirStudio?

We could revert to the apacheds-1.5.4 dependencies, if it makes life
easier for you. Everything will compile, only the UI tests will not
work. We could upgrade as soon as apacheds-1.5.5 is released.

Perhaps a better option is to exclude the integraton-ui and
integration-core plugins from the release?

WDYT?

Regards,
Stefan

[Emmanuel Lecharny]

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 not compatible with apacheds-1.5.4. However we need 0.9.13
> because it fixes some problems with the LdapDN.toString() method. I
> guess we will release a shared-0.9.13 before we release DirStudio?
>  

At some point, we might also decide to release 'shared' separately from
ApacheDS, as it's now used by both projects.

It should not be such a big deal.

wdyt ?

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[Pierre-Arnaud Marcelot-2]

Hi Emmanuel,

On Wed, Oct 1, 2008 at 9:22 AM, Emmanuel Lecharny <elecharny@...> 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 ?

   

I just updated because we use shared-0.9.13-SNAPSHOT in the main pom.xml
 which is not compatible with apacheds-1.5.4. However we need 0.9.13
because it fixes some problems with the LdapDN.toString() method. I
guess we will release a shared-0.9.13 before we release DirStudio?
 

At some point, we might also decide to release 'shared' separately from ApacheDS, as it's now used by both projects.

It should not be such a big deal.

wdyt ?

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 to release both Studio and Shared.

I think that's the way to go.

Regards,
Pierre-Arnaud

[Felix Knecht-2]

Pierre-Arnaud Marcelot schrieb:

> Hi Emmanuel,
>
> On Wed, Oct 1, 2008 at 9:22 AM, Emmanuel Lecharny <elecharny@...
> <mailto:elecharny@...>> 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 ?
>
>                
>
>         I just updated because we use shared-0.9.13-SNAPSHOT in the
>         main pom.xml
>          which is not compatible with apacheds-1.5.4. However we need
>         0.9.13
>         because it fixes some problems with the LdapDN.toString()
>         method. I
>         guess we will release a shared-0.9.13 before we release DirStudio?
>          
>
>     At some point, we might also decide to release 'shared' separately
>     from ApacheDS, as it's now used by both projects.
>
>     It should not be such a big deal.
>
>     wdyt ?
>
>
> 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 to release both Studio and Shared.
>
> I think that's the way to go.

Don't mind, but would this also include TLP pom?

Regards
Felix
>
> Regards,
> Pierre-Arnaud

[Pierre-Arnaud Marcelot-2]

Hi Stefan,

On Tue, Sep 30, 2008 at 11:02 PM, Stefan Seelmann <seelmann@...> 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 the maven repositories.
This is for our testing only.

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.

WDOT ?

Regards,
Pierre-Arnaud

[Pierre-Arnaud Marcelot-2]

Hi Felix,

On Wed, Oct 1, 2008 at 9:53 AM, Felix Knecht <felixk@...> 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 to release both Studio and Shared.
>
> I think that's the way to go.

Don't mind, but would this also include TLP pom?

If the dependency to the TLP pom is a SNAPSHOT, of course ;)

Regards,
Pierre-Arnaud

[Felix Knecht-2]

Pierre-Arnaud Marcelot schrieb:

> Hi Felix,
>
> On Wed, Oct 1, 2008 at 9:53 AM, Felix Knecht <felixk@...
> <mailto:felixk@...>> 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 to release both Studio and Shared.
>     >
>     > I think that's the way to go.
>
>     Don't mind, but would this also include TLP pom?
>
>
> If the dependency to the TLP pom is a SNAPSHOT, of course ;)

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
snapshot of it and not used yet in any project.

>
> Regards,
> Pierre-Arnaud
>

[Pierre-Arnaud Marcelot-2]

On Wed, Oct 1, 2008 at 10:40 AM, Felix Knecht <felixk@...> 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
snapshot of it and not used yet in any project.

Oh, ok. I was not aware of that. Thanks for the heads up.

Then I guess, we won't need to release the TLP pom, right ?

Thanks,
Pierre-Arnaud

[Felix Knecht-2]

Pierre-Arnaud Marcelot schrieb:

> On Wed, Oct 1, 2008 at 10:40 AM, Felix Knecht <felixk@...
> <mailto:felixk@...>> 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
>     snapshot of it and not used yet in any project.
>
>
> Oh, ok. I was not aware of that. Thanks for the heads up.
>
> Then I guess, we won't need to release the TLP pom, right ?

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 release.altDeploymentRepository
property.
See also
http://www.archivum.info/dev@.../2008-09/msg00692.html
http://cwiki.apache.org/confluence/display/DIRxDEV/Guide+to+Directory+Releases

Regards
Felix

[Pierre-Arnaud Marcelot-2]

On Wed, Oct 1, 2008 at 11:08 AM, Felix Knecht <felixk@...> 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 release.altDeploymentRepository
property.
See also
http://www.archivum.info/dev@.../2008-09/msg00692.html
http://cwiki.apache.org/confluence/display/DIRxDEV/Guide+to+Directory+Releases

Thanks, I remember this discussion now.

Yeah, I think we'll need to release version 14 of the TLP pom then.

Regards,
Pierre-Arnaud