Releasing a Mojo plugin nowadays...?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Releasing a Mojo plugin nowadays...?

Lennart Jörelid-2
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing a Mojo plugin nowadays...?

Anders Hammar
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <[hidden email]> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing a Mojo plugin nowadays...?

Lennart Jörelid-2
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <[hidden email]>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <[hidden email]> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing a Mojo plugin nowadays...?

Anders Hammar
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <[hidden email]> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <[hidden email]>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <[hidden email]> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Releasing a Mojo plugin nowadays...?

Lennart Jörelid-2
I am somewhat split about the concept of doing special development within a Maven plugin project to support any of the IDEs in the development community. 

An IDE claiming a tooling integration with Maven ought to be able to use the POM and the plugin descriptors out of the box. This seems certainly possible in the case of Netbeans and IntelliJ Idea without any special measures - so my gut reaction is that the Eclipse developers should fix Eclipse's Maven integration to actually work with only the Maven configuration instead of every plugin project developing special support for Eclipse. 

That being said, if the Eclipse integration is decently simple, we could certainly provide it. I would argue that such a solution should be testable in a standard IT within the plugin so the rest of the development community could know when the Eclipse integration works properly. Any Eclipse Developers out there are certainly encouraged to contribute, at least in letting me know how to test and verify that the j-m-p works with Eclipse. I added a screenshot of the Lifecycle mappings - as I can interpret them - from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of origin at least.


2015-04-29 10:11 GMT+02:00 Anders Hammar <[hidden email]>:
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <[hidden email]> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <[hidden email]>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <[hidden email]> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[2]: [mojo-dev] Releasing a Mojo plugin nowadays...?

Sergei Ivanov
Hi Lennart,

I often curse the day when I out of good will decided to support M2E in my Maven plugin (I am a happy user of IntelliJ IDEA), but hopefully my experience helps you.
Note that in M2E prior to 1.5 there was a major classloading issue, which broke quite a few plugins.

I took a look at this: https://github.com/lennartj/jaxb2-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/jaxb2/AbstractXjcMojo.java
...and I see you have already got BuildContext declared as a @Component. All you need to do is use it.

There are three parts to the implementation (in addition to providing lifecycle XML, which you've already done):

1. You build a list of input files and pass them to buildContext.hasDelta() one by one:

    /**
     * Checks if the injected build context has changes in any of the specified files.
     *
     * @param files files to be checked for changes.
     * @return {@code true}, if at least one file has changes; {@code false}, if no files have changes.
     */
    protected boolean hasDelta(final Iterable<File> files) {
        for (final File file : files) {
            if (buildContext.hasDelta(file)) {
                return true;
            }
        }
        return false;
    }

2. You call this method inside mojo execute() before your own staleness detection check:

if (!hasDelta(sourceFiles)) {
  getLog().info("Skipping compilation because build context has no changes.");
  buildContext.refresh(outputDirectory);
  return;
}

3. You also need to call buildContext.refresh(outputDirectory) before exiting the mojo execute() method in all cases where execution succeeded (even if it was skipped due to other checks).

Try it and see whether it works.

Kind regards,
--
Sergei Ivanov

Среда, 29 апреля 2015, 20:17 +02:00 от Lennart Jörelid <[hidden email]>:
I am somewhat split about the concept of doing special development within a Maven plugin project to support any of the IDEs in the development community. 

An IDE claiming a tooling integration with Maven ought to be able to use the POM and the plugin descriptors out of the box. This seems certainly possible in the case of Netbeans and IntelliJ Idea without any special measures - so my gut reaction is that the Eclipse developers should fix Eclipse's Maven integration to actually work with only the Maven configuration instead of every plugin project developing special support for Eclipse. 

That being said, if the Eclipse integration is decently simple, we could certainly provide it. I would argue that such a solution should be testable in a standard IT within the plugin so the rest of the development community could know when the Eclipse integration works properly. Any Eclipse Developers out there are certainly encouraged to contribute, at least in letting me know how to test and verify that the j-m-p works with Eclipse. I added a screenshot of the Lifecycle mappings - as I can interpret them - from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of origin at least.


2015-04-29 10:11 GMT+02:00 Anders Hammar <anders@...>:
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <anders@...>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: [mojo-dev] Releasing a Mojo plugin nowadays...?

Anders Hammar
Technically there is no need for 1) and 2) to make it m2e compatible. The jaxb2 plugin used to be m2e compatible through 3) and a home-grown staleness check instead of 1) and 2).
 
/Anders

On Wed, Apr 29, 2015 at 11:35 PM, Sergei Ivanov <[hidden email]> wrote:
Hi Lennart,

I often curse the day when I out of good will decided to support M2E in my Maven plugin (I am a happy user of IntelliJ IDEA), but hopefully my experience helps you.
Note that in M2E prior to 1.5 there was a major classloading issue, which broke quite a few plugins.

I took a look at this: https://github.com/lennartj/jaxb2-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/jaxb2/AbstractXjcMojo.java
...and I see you have already got BuildContext declared as a @Component. All you need to do is use it.

There are three parts to the implementation (in addition to providing lifecycle XML, which you've already done):

1. You build a list of input files and pass them to buildContext.hasDelta() one by one:

    /**
     * Checks if the injected build context has changes in any of the specified files.
     *
     * @param files files to be checked for changes.
     * @return {@code true}, if at least one file has changes; {@code false}, if no files have changes.
     */
    protected boolean hasDelta(final Iterable<File> files) {
        for (final File file : files) {
            if (buildContext.hasDelta(file)) {
                return true;
            }
        }
        return false;
    }

2. You call this method inside mojo execute() before your own staleness detection check:

if (!hasDelta(sourceFiles)) {
  getLog().info("Skipping compilation because build context has no changes.");
  buildContext.refresh(outputDirectory);
  return;
}

3. You also need to call buildContext.refresh(outputDirectory) before exiting the mojo execute() method in all cases where execution succeeded (even if it was skipped due to other checks).

Try it and see whether it works.

Kind regards,
--
Sergei Ivanov

Среда, 29 апреля 2015, 20:17 +02:00 от Lennart Jörelid <[hidden email]>:

I am somewhat split about the concept of doing special development within a Maven plugin project to support any of the IDEs in the development community. 

An IDE claiming a tooling integration with Maven ought to be able to use the POM and the plugin descriptors out of the box. This seems certainly possible in the case of Netbeans and IntelliJ Idea without any special measures - so my gut reaction is that the Eclipse developers should fix Eclipse's Maven integration to actually work with only the Maven configuration instead of every plugin project developing special support for Eclipse. 

That being said, if the Eclipse integration is decently simple, we could certainly provide it. I would argue that such a solution should be testable in a standard IT within the plugin so the rest of the development community could know when the Eclipse integration works properly. Any Eclipse Developers out there are certainly encouraged to contribute, at least in letting me know how to test and verify that the j-m-p works with Eclipse. I added a screenshot of the Lifecycle mappings - as I can interpret them - from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of origin at least.


2015-04-29 10:11 GMT+02:00 Anders Hammar <anders@...>:
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <anders@...>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: [mojo-dev] Releasing a Mojo plugin nowadays...?

Lennart Jörelid-2
In reply to this post by Sergei Ivanov
All right; so if I understand correctly the m2e plugin uses information in the BuildContext.
According to Sergei's example above, the BuildContext seems to want to consume the whole output directory structure for its refresh method. 

Is the order of things to be:
  1. if files are stale, then
  2. Refresh the buildContext, and then
  3. perform the execution of the tool
In other words - is the buildContext.refresh call correctly placed below?

// 3) Are generated files stale?
if (isReGenerationRequired()) {

// Hack to support M2E
buildContext.refresh(getOutputDirectory());

if (performExecution()) {

// As instructed by the performExecution() method, update
// the timestamp of the stale File.
updateStaleFileTimestamp();
} else if (isInfoEnabled) {
log.info("Not updating staleFile timestamp as instructed.");
}
} else if (isInfoEnabled) {
log.info("No changes detected in schema or binding files - skipping JAXB generation.");
}

2015-04-29 23:35 GMT+02:00 Sergei Ivanov <[hidden email]>:
Hi Lennart,

I often curse the day when I out of good will decided to support M2E in my Maven plugin (I am a happy user of IntelliJ IDEA), but hopefully my experience helps you.
Note that in M2E prior to 1.5 there was a major classloading issue, which broke quite a few plugins.

I took a look at this: https://github.com/lennartj/jaxb2-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/jaxb2/AbstractXjcMojo.java
...and I see you have already got BuildContext declared as a @Component. All you need to do is use it.

There are three parts to the implementation (in addition to providing lifecycle XML, which you've already done):

1. You build a list of input files and pass them to buildContext.hasDelta() one by one:

    /**
     * Checks if the injected build context has changes in any of the specified files.
     *
     * @param files files to be checked for changes.
     * @return {@code true}, if at least one file has changes; {@code false}, if no files have changes.
     */
    protected boolean hasDelta(final Iterable<File> files) {
        for (final File file : files) {
            if (buildContext.hasDelta(file)) {
                return true;
            }
        }
        return false;
    }

2. You call this method inside mojo execute() before your own staleness detection check:

if (!hasDelta(sourceFiles)) {
  getLog().info("Skipping compilation because build context has no changes.");
  buildContext.refresh(outputDirectory);
  return;
}

3. You also need to call buildContext.refresh(outputDirectory) before exiting the mojo execute() method in all cases where execution succeeded (even if it was skipped due to other checks).

Try it and see whether it works.

Kind regards,
--
Sergei Ivanov

Среда, 29 апреля 2015, 20:17 +02:00 от Lennart Jörelid <[hidden email]>:

I am somewhat split about the concept of doing special development within a Maven plugin project to support any of the IDEs in the development community. 

An IDE claiming a tooling integration with Maven ought to be able to use the POM and the plugin descriptors out of the box. This seems certainly possible in the case of Netbeans and IntelliJ Idea without any special measures - so my gut reaction is that the Eclipse developers should fix Eclipse's Maven integration to actually work with only the Maven configuration instead of every plugin project developing special support for Eclipse. 

That being said, if the Eclipse integration is decently simple, we could certainly provide it. I would argue that such a solution should be testable in a standard IT within the plugin so the rest of the development community could know when the Eclipse integration works properly. Any Eclipse Developers out there are certainly encouraged to contribute, at least in letting me know how to test and verify that the j-m-p works with Eclipse. I added a screenshot of the Lifecycle mappings - as I can interpret them - from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of origin at least.


2015-04-29 10:11 GMT+02:00 Anders Hammar <anders@...>:
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <anders@...>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: [mojo-dev] Releasing a Mojo plugin nowadays...?

Anders Hammar
I believe the refresh should be AFTER the generation. It is to notify BuildContext about the changed/updated files.
 
Here's the docs on this that are available:
 
Also, have a look at the old code. It did work in v1.x.
 
/Anders

On Sat, May 2, 2015 at 1:39 PM, Lennart Jörelid <[hidden email]> wrote:
All right; so if I understand correctly the m2e plugin uses information in the BuildContext.
According to Sergei's example above, the BuildContext seems to want to consume the whole output directory structure for its refresh method. 

Is the order of things to be:
  1. if files are stale, then
  2. Refresh the buildContext, and then
  3. perform the execution of the tool
In other words - is the buildContext.refresh call correctly placed below?

// 3) Are generated files stale?
if (isReGenerationRequired()) {

// Hack to support M2E
buildContext.refresh(getOutputDirectory());

if (performExecution()) {

// As instructed by the performExecution() method, update
// the timestamp of the stale File.
updateStaleFileTimestamp();
} else if (isInfoEnabled) {
log.info("Not updating staleFile timestamp as instructed.");
}
} else if (isInfoEnabled) {
log.info("No changes detected in schema or binding files - skipping JAXB generation.");
}

2015-04-29 23:35 GMT+02:00 Sergei Ivanov <[hidden email]>:
Hi Lennart,

I often curse the day when I out of good will decided to support M2E in my Maven plugin (I am a happy user of IntelliJ IDEA), but hopefully my experience helps you.
Note that in M2E prior to 1.5 there was a major classloading issue, which broke quite a few plugins.

I took a look at this: https://github.com/lennartj/jaxb2-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/jaxb2/AbstractXjcMojo.java
...and I see you have already got BuildContext declared as a @Component. All you need to do is use it.

There are three parts to the implementation (in addition to providing lifecycle XML, which you've already done):

1. You build a list of input files and pass them to buildContext.hasDelta() one by one:

    /**
     * Checks if the injected build context has changes in any of the specified files.
     *
     * @param files files to be checked for changes.
     * @return {@code true}, if at least one file has changes; {@code false}, if no files have changes.
     */
    protected boolean hasDelta(final Iterable<File> files) {
        for (final File file : files) {
            if (buildContext.hasDelta(file)) {
                return true;
            }
        }
        return false;
    }

2. You call this method inside mojo execute() before your own staleness detection check:

if (!hasDelta(sourceFiles)) {
  getLog().info("Skipping compilation because build context has no changes.");
  buildContext.refresh(outputDirectory);
  return;
}

3. You also need to call buildContext.refresh(outputDirectory) before exiting the mojo execute() method in all cases where execution succeeded (even if it was skipped due to other checks).

Try it and see whether it works.

Kind regards,
--
Sergei Ivanov

Среда, 29 апреля 2015, 20:17 +02:00 от Lennart Jörelid <[hidden email]>:

I am somewhat split about the concept of doing special development within a Maven plugin project to support any of the IDEs in the development community. 

An IDE claiming a tooling integration with Maven ought to be able to use the POM and the plugin descriptors out of the box. This seems certainly possible in the case of Netbeans and IntelliJ Idea without any special measures - so my gut reaction is that the Eclipse developers should fix Eclipse's Maven integration to actually work with only the Maven configuration instead of every plugin project developing special support for Eclipse. 

That being said, if the Eclipse integration is decently simple, we could certainly provide it. I would argue that such a solution should be testable in a standard IT within the plugin so the rest of the development community could know when the Eclipse integration works properly. Any Eclipse Developers out there are certainly encouraged to contribute, at least in letting me know how to test and verify that the j-m-p works with Eclipse. I added a screenshot of the Lifecycle mappings - as I can interpret them - from a vanilla Eclipse Luna install to the MJAXB-51 issue. It's a point of origin at least.


2015-04-29 10:11 GMT+02:00 Anders Hammar <anders@...>:
As I earlier stated, after some investigation, there is some other change in the code that causes this to stop functioning. It worked in v1.x, but after your refactoring it doesn't any more. IMHO it's very unfortunate to just ignore such a key feature for anyone on Eclipse, especially as it worked in v1.x.
 
/Anders

On Wed, Apr 29, 2015 at 9:23 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
The 2.0 release was cancelled, and since some features were added and some code was refactored in the plugin I felt it better to release version 2.1 instead. 

If someone who actually uses Eclipse feels like pinpointing the problem with why the m2e descriptor below does not work with the 2.x branch, I think all of us would be grateful. However, the goals are the same and annotated on the form

@Mojo(name = "testSchemagen",
defaultPhase = LifecyclePhase.GENERATE_TEST_RESOURCES,
requiresDependencyResolution = ResolutionScope.TEST,
threadSafe = true)
... and the m2e descriptor seem to link to them correctly:

<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
    <pluginExecutions>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>xjc</goal>
                    <goal>testXjc</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>true</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
        <pluginExecution>
            <pluginExecutionFilter>
                <goals>
                    <goal>schemagen</goal>
                    <goal>testSchemagen</goal>
                </goals>
            </pluginExecutionFilter>
            <action>
                <execute>
                    <runOnIncremental>true</runOnIncremental>
                    <runOnConfiguration>false</runOnConfiguration>
                </execute>
            </action>
        </pluginExecution>
    </pluginExecutions>
</lifecycleMappingMetadata>


2015-04-29 8:44 GMT+02:00 Anders Hammar <anders@...>:
What happened to v2.0 of the jaxb-m-p? Also, I really think we need to solve the m2e compat issue as that's a key thing for us on Eclipse (and it worked in v1.x).
 
/Anders

On Wed, Apr 29, 2015 at 2:41 AM, Lennart Jörelid <lennart.jorelid@...> wrote:
Hello all,

It seems we are in the transition between Codehaus and MojoHaus/GitHub.
I would believe that we should place each mojo in a separate Git repo - it makes sense, since they have different release cycles.

However, if we do that, we need new settings for DistributionManagement, URL, IssueManagement and SCM in our mojo-parent (which really should migrate to the groupId "org.mojohaus", right?). I'm assuming that we should perform the releases from GitHub - but if we still can make releases from CodeHaus without changing too much, I would like to release the Jaxb2-Maven-Plugin version 2.1 first.

--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@...
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+




--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: [hidden email]
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Loading...