[forge-dev] Java Parser API v2

[mbenson]

Hi all,

  As development continues on Forge 2, I think we had all hoped the

improvements to the parser API would be available in time to be used for

the release.  We now have a split between JavaType and JavaSource which

represent the read only and writable portions of the parser API for a given

class|interface|enum|annotation|package-descriptor.  The latest version is

at https://github.com/forge/java-parser/tree/refactor-hierarchy.  Would it

be SOP to proceed by publishing a SNAPSHOT, or...?

  Also, since there are quite a few incompatible API changes, I wonder if

it would make sense to change the package name at some level, e.g.

org.jboss.forge.parser2, as well as the Maven artifact id.  By avoiding

"jar hell" with multiple versions of the library on the classpath, this

would make it possible for dependent Forge plugins to switch over gradually

if necessary and might avoid impacting release timelines.

Thanks,

Matt

[lincolnthree]

As I said in IRC, I worry that allowing both to be on the classpath would

lead to a lot of confusing/partially migrated code.

On Wed, Nov 20, 2013 at 12:30 PM, Matt Benson <[e-mail]> wrote:

Hi all,

  As development continues on Forge 2, I think we had all hoped the

improvements to the parser API would be available in time to be used for

the release.  We now have a split between JavaType and JavaSource which

represent the read only and writable portions of the parser API for a given

class|interface|enum|annotation|package-descriptor.  The latest version is

at https://github.com/forge/java-parser/tree/refactor-hierarchy.  Would

it be SOP to proceed by publishing a SNAPSHOT, or...?

  Also, since there are quite a few incompatible API changes, I wonder if

it would make sense to change the package name at some level, e.g.

org.jboss.forge.parser2, as well as the Maven artifact id.  By avoiding

"jar hell" with multiple versions of the library on the classpath, this

would make it possible for dependent Forge plugins to switch over gradually

if necessary and might avoid impacting release timelines.

Thanks,

Matt

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

--

Lincoln Baxter, III

http://ocpsoft.org

"Simpler is better."

[gastaldi]

Let's keep the same package name, as this is a major version change. I

don't think people will run into problems, unless proven otherwise.

On 11/20/2013 04:09 PM, Lincoln Baxter, III wrote:

As I said in IRC, I worry that allowing both to be on the classpath

would lead to a lot of confusing/partially migrated code.

>

On Wed, Nov 20, 2013 at 12:30 PM, Matt Benson <[e-mail]

<mailto:[e-mail]>> wrote:

    Hi all,

      As development continues on Forge 2, I think we had all hoped

    the improvements to the parser API would be available in time to

    be used for the release.  We now have a split between JavaType and

    JavaSource which represent the read only and writable portions of

    the parser API for a given

    class|interface|enum|annotation|package-descriptor.  The latest

    version is at

    https://github.com/forge/java-parser/tree/refactor-hierarchy.

     Would it be SOP to proceed by publishing a SNAPSHOT, or...?

      Also, since there are quite a few incompatible API changes, I

    wonder if it would make sense to change the package name at some

    level, e.g. org.jboss.forge.parser2, as well as the Maven artifact

    id.  By avoiding "jar hell" with multiple versions of the library

    on the classpath, this would make it possible for dependent Forge

    plugins to switch over gradually if necessary and might avoid

    impacting release timelines.

    Thanks,

    Matt

    _______________________________________________

    forge-dev mailing list

    [e-mail] <mailto:[e-mail]>

    https://lists.jboss.org/mailman/listinfo/forge-dev

>

>

--

Lincoln Baxter, III

http://ocpsoft.org

"Simpler is better."

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

[lincolnthree]

+1

On Wed, Nov 20, 2013 at 1:14 PM, George Gastaldi <[e-mail]>wrote:

Let's keep the same package name, as this is a major version change. I

don't think people will run into problems, unless proven otherwise.

>

On 11/20/2013 04:09 PM, Lincoln Baxter, III wrote:

As I said in IRC, I worry that allowing both to be on the classpath would

lead to a lot of confusing/partially migrated code.

>

On Wed, Nov 20, 2013 at 12:30 PM, Matt Benson <[e-mail]>wrote:

>> Hi all,

>>   As development continues on Forge 2, I think we had all hoped the

>> improvements to the parser API would be available in time to be used for

>> the release.  We now have a split between JavaType and JavaSource which

>> represent the read only and writable portions of the parser API for a given

>> class|interface|enum|annotation|package-descriptor.  The latest version is

>> at https://github.com/forge/java-parser/tree/refactor-hierarchy.  Would

>> it be SOP to proceed by publishing a SNAPSHOT, or...?

>>

>>    Also, since there are quite a few incompatible API changes, I wonder

>> if it would make sense to change the package name at some level, e.g.

>> org.jboss.forge.parser2, as well as the Maven artifact id.  By avoiding

>> "jar hell" with multiple versions of the library on the classpath, this

>> would make it possible for dependent Forge plugins to switch over gradually

>> if necessary and might avoid impacting release timelines.

>>

>>  Thanks,

>> Matt

>>

>> _______________________________________________

>> forge-dev mailing list

>> [e-mail]

>> https://lists.jboss.org/mailman/listinfo/forge-dev

>>

>

>

--

Lincoln Baxter, III

http://ocpsoft.org

"Simpler is better."

>

_______________________________________________

forge-dev mailing [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/forge-dev

--

Lincoln Baxter, III

http://ocpsoft.org

"Simpler is better."