[resources] Supported Build Tools

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[resources] Supported Build Tools

Dave Meikle
Hi,

As per the previous thread on reactivating Commons Resources [0], I have
moved Resources back into Sandbox and made various changes to:

* Refresh the License Headers
* Added a Maven2 Build
* Restructured the folders in-line with the standard maven folder structure

Because of the above changes I have broken the existing Ant and Maven1
builds. Since we are at a stage of reactivation I was wondering what builds
should we be supporting?

Do we need both a Maven1 and Maven2 build? Would a Maven2 build suffice on
its own? Or do we need at least Maven2 + Ant?

Based on what we think I can update the builds accordingly.

Cheers,
Dave

[0] http://www.nabble.com/Reactivate-Commons-Resources...--td23572441.html
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Niall Pemberton
On Sun, May 17, 2009 at 10:58 AM, Dave Meikle <[hidden email]> wrote:

> Hi,
>
> As per the previous thread on reactivating Commons Resources [0], I have
> moved Resources back into Sandbox and made various changes to:
>
> * Refresh the License Headers
> * Added a Maven2 Build
> * Restructured the folders in-line with the standard maven folder structure
>
> Because of the above changes I have broken the existing Ant and Maven1
> builds. Since we are at a stage of reactivation I was wondering what builds
> should we be supporting?
>
> Do we need both a Maven1 and Maven2 build? Would a Maven2 build suffice on
> its own? Or do we need at least Maven2 + Ant?

Its really down to what those that do the work want to maintain. The
only other factor is what JDK version is resources going to target -
if its pre-JDK1.5 then there might be a need for an ant build to be
able to test on that version.

Niall

> Based on what we think I can update the builds accordingly.
>
> Cheers,
> Dave
>
> [0] http://www.nabble.com/Reactivate-Commons-Resources...--td23572441.html
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

robert burrell donkin
Niall Pemberton wrote:

> On Sun, May 17, 2009 at 10:58 AM, Dave Meikle <[hidden email]> wrote:
>> Hi,
>>
>> As per the previous thread on reactivating Commons Resources [0], I have
>> moved Resources back into Sandbox and made various changes to:
>>
>> * Refresh the License Headers
>> * Added a Maven2 Build
>> * Restructured the folders in-line with the standard maven folder structure
>>
>> Because of the above changes I have broken the existing Ant and Maven1
>> builds. Since we are at a stage of reactivation I was wondering what builds
>> should we be supporting?
>>
>> Do we need both a Maven1 and Maven2 build? Would a Maven2 build suffice on
>> its own? Or do we need at least Maven2 + Ant?

oops - just deleted the maven1 build (forgot i'd had this filter setup)

if anyone wants it back, please jump in and i'll revert that patch

> Its really down to what those that do the work want to maintain. The
> only other factor is what JDK version is resources going to target -
> if its pre-JDK1.5 then there might be a need for an ant build to be
> able to test on that version.

i'd prefer just to maintain a maven 2 if we're looking just to maintain
a JDK1.5+ version.

jdk1.4 is now EOL'd and i don't have any particular need to support 1.4
but i'm happy to target 1.4 if there's a need.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Henri Yandell
In reply to this post by Dave Meikle
+1 to project.xml and build.xml going :)

On Sun, May 17, 2009 at 2:58 AM, Dave Meikle <[hidden email]> wrote:

> Hi,
>
> As per the previous thread on reactivating Commons Resources [0], I have
> moved Resources back into Sandbox and made various changes to:
>
> * Refresh the License Headers
> * Added a Maven2 Build
> * Restructured the folders in-line with the standard maven folder structure
>
> Because of the above changes I have broken the existing Ant and Maven1
> builds. Since we are at a stage of reactivation I was wondering what builds
> should we be supporting?
>
> Do we need both a Maven1 and Maven2 build? Would a Maven2 build suffice on
> its own? Or do we need at least Maven2 + Ant?
>
> Based on what we think I can update the builds accordingly.
>
> Cheers,
> Dave
>
> [0] http://www.nabble.com/Reactivate-Commons-Resources...--td23572441.html
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Dave Meikle
In reply to this post by robert burrell donkin
Hi,

2009/5/17 Robert Burrell Donkin <[hidden email]>

> i'd prefer just to maintain a maven 2 if we're looking just to maintain
> a JDK1.5+ version.
>
> jdk1.4 is now EOL'd and i don't have any particular need to support 1.4
> but i'm happy to target 1.4 if there's a need.
>

+1 from me -  that is what I had done with my local copy. Although I have
some Java 1.4 projects, targeting 1.5 sounds good to me as these will be
moving up the way.

We could do what we do in Tika and run the retrotranslator plugin in the
Maven build to allow the classes to be used on 1.4.

Cheers,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Dave Meikle
Hi,

2009/5/17 Dave Meikle <[hidden email]>

> 2009/5/17 Robert Burrell Donkin <[hidden email]>
>
>>  i'd prefer just to maintain a maven 2 if we're looking just to maintain
>> a JDK1.5+ version.
>>
>> jdk1.4 is now EOL'd and i don't have any particular need to support 1.4
>> but i'm happy to target 1.4 if there's a need.
>>
>
> +1 from me -  that is what I had done with my local copy. Although I have
> some Java 1.4 projects, targeting 1.5 sounds good to me as these will be
> moving up the way.
>
> We could do what we do in Tika and run the retrotranslator plugin in the
> Maven build to allow the classes to be used on 1.4.
>

OK, I have went for the above and removed the Ant builds. Coupled with
Robert's earlier change of removing the Maven 1 build, we are now just using
Maven 2.

I have set the Target to 1.5 and added in a retrotranslator just now.

Cheers,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Niall Pemberton
On Sun, May 17, 2009 at 10:40 PM, Dave Meikle <[hidden email]> wrote:

> Hi,
>
> 2009/5/17 Dave Meikle <[hidden email]>
>
>> 2009/5/17 Robert Burrell Donkin <[hidden email]>
>>
>>>  i'd prefer just to maintain a maven 2 if we're looking just to maintain
>>> a JDK1.5+ version.
>>>
>>> jdk1.4 is now EOL'd and i don't have any particular need to support 1.4
>>> but i'm happy to target 1.4 if there's a need.
>>>
>>
>> +1 from me -  that is what I had done with my local copy. Although I have
>> some Java 1.4 projects, targeting 1.5 sounds good to me as these will be
>> moving up the way.
>>
>> We could do what we do in Tika and run the retrotranslator plugin in the
>> Maven build to allow the classes to be used on 1.4.
>>
>
> OK, I have went for the above and removed the Ant builds. Coupled with
> Robert's earlier change of removing the Maven 1 build, we are now just using
> Maven 2.
>
> I have set the Target to 1.5 and added in a retrotranslator just now.

I made a couple of changes since some of what was in resources pom was
duplicating what we already have in the commons-parent pom. The
compiler "properties" you set to 1.5 are used in the parent to
configure the compiler plugin. Also we tie the site and assembly
plugins to the "package" phase in the parent so you can run "mvn -Prc
package" already and it will do the assembly and site stuff.

Niall

> Cheers,
> Dave
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Dave Meikle
2009/5/18 Niall Pemberton <[hidden email]>

> I made a couple of changes since some of what was in resources pom was
> duplicating what we already have in the commons-parent pom. The
> compiler "properties" you set to 1.5 are used in the parent to
> configure the compiler plugin. Also we tie the site and assembly
> plugins to the "package" phase in the parent so you can run "mvn -Prc
> package" already and it will do the assembly and site stuff.
>
> Niall


Great, thanks Niall.

Cheers,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Mohammady Mahdy
Guys I am glad to see this project coming back to life, the viewvc and
repository url on the site are broken though:

jakarta/commons/proper/resources/trunk: unknown location


Can you send the ones you are using ?

On Mon, May 18, 2009 at 7:57 AM, Dave Meikle <[hidden email]> wrote:

> 2009/5/18 Niall Pemberton <[hidden email]>
>
> > I made a couple of changes since some of what was in resources pom was
> > duplicating what we already have in the commons-parent pom. The
> > compiler "properties" you set to 1.5 are used in the parent to
> > configure the compiler plugin. Also we tie the site and assembly
> > plugins to the "package" phase in the parent so you can run "mvn -Prc
> > package" already and it will do the assembly and site stuff.
> >
> > Niall
>
>
> Great, thanks Niall.
>
> Cheers,
> Dave
>
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

robert burrell donkin
Mohammady Mahdy wrote:
> Guys I am glad to see this project coming back to life, the viewvc and
> repository url on the site are broken though:
>
> jakarta/commons/proper/resources/trunk: unknown location
>
>
> Can you send the ones you are using ?

it takes a few hours for the site to sync: try again now and it should
be right (please jump in if it's still wrong).

BTW if you're interested in resources, then all contributions welcomed :-)

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

Mohammady Mahdy
Planning to do so :) will jump the JIRA once I return today, let me know if
there is something specific I can help with.

On Mon, May 18, 2009 at 9:32 AM, Robert Burrell Donkin <
[hidden email]> wrote:

> Mohammady Mahdy wrote:
> > Guys I am glad to see this project coming back to life, the viewvc and
> > repository url on the site are broken though:
> >
> > jakarta/commons/proper/resources/trunk: unknown location
> >
> >
> > Can you send the ones you are using ?
>
> it takes a few hours for the site to sync: try again now and it should
> be right (please jump in if it's still wrong).
>
> BTW if you're interested in resources, then all contributions welcomed :-)
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [resources] Supported Build Tools

robert burrell donkin
Mohammady Mahdy wrote:
> Planning to do so :) will jump the JIRA once I return today, let me know if
> there is something specific I can help with.

cool

i don't have any specific tasks (other than JIRA) ATM but if anyone
does, hopefully they'll jump in...

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

commons-logging version 0.0.0-EMPTY

Ceki Gulcu
In reply to this post by Mohammady Mahdy
Hello all,

I have created an empty Maven project with groupId "commons-logging",
artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
little content (around 500 bytes) in the whole project. This is to be
expected as the original aim was to produce an empty jar file.

For the actual "source code", see
  https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/

Anyway, as discussed previously, how do we go about publishing this
empty jar on ibiblio (Maven's central repository). Is a vote
warranted, or would that be premature?

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

nicolas de loof-2
The POM should include SCM path, url to commons-logging site and licensing
metadata

Maybe you could also include the blog extract as description / comment. The
description explains the jar is empty but not why it is there

2009/5/18 Ceki Gulcu <[hidden email]>

> Hello all,
>
> I have created an empty Maven project with groupId "commons-logging",
> artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
> little content (around 500 bytes) in the whole project. This is to be
> expected as the original aim was to produce an empty jar file.
>
> For the actual "source code", see
>  https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/
>
> Anyway, as discussed previously, how do we go about publishing this
> empty jar on ibiblio (Maven's central repository). Is a vote
> warranted, or would that be premature?
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

sebb-2-2
In reply to this post by Ceki Gulcu
On 18/05/2009, Ceki Gulcu <[hidden email]> wrote:

> Hello all,
>
>  I have created an empty Maven project with groupId "commons-logging",
>  artifactId "commons-logging" and version 0.0.0-EMPTY. There is very
>  little content (around 500 bytes) in the whole project. This is to be
>  expected as the original aim was to produce an empty jar file.
>
>  For the actual "source code", see
>
> https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/
>
>  Anyway, as discussed previously, how do we go about publishing this
>  empty jar on ibiblio (Maven's central repository). Is a vote
>  warranted, or would that be premature?

It would be useful if the Manifest included the following details:

Implementation-Title: commons-logging
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 0.0.0-EMPTY
Specification-Title: commons-logging
Specification-Vendor: The Apache Software Foundation
Specification-Version: 0.0.0-EMPTY

>  --
>  Ceki Gülcü
>  Logback: The reliable, generic, fast and flexible logging framework for
> Java.
>  http://logback.qos.ch
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

Ceki Gulcu
In reply to this post by nicolas de loof-2


nicolas de loof wrote:
> The POM should include SCM path, url to commons-logging site and licensing
> metadata

Done. Note that I've used the url for for svn in commons/proper/trunk.

> Maybe you could also include the blog extract as description / comment. The
> description explains the jar is empty but not why it is there

I've added a few sentences. More documentation will be added on the SLF4J
site expanding on the subject. Similar documentation could be added on
the commons-logging site, but that's not strictly necessary imo.

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

Ceki Gulcu
In reply to this post by sebb-2-2


sebb wrote:

>
> It would be useful if the Manifest included the following details:
>
> Implementation-Title: commons-logging
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Vendor-Id: org.apache
> Implementation-Version: 0.0.0-EMPTY
> Specification-Title: commons-logging
> Specification-Vendor: The Apache Software Foundation
> Specification-Version: 0.0.0-EMPTY

These details provide information to the user who decides to open the
manifest file but other than that, since the jar file comes with no
classes, the information cannot be accessed at runtime, e.g. by the
Package class. Can you think of any additional reasons to include the
above details in the manifest file?

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

sebb-2-2
On 18/05/2009, Ceki Gulcu <[hidden email]> wrote:

>
>
>  sebb wrote:
>
> >
> > It would be useful if the Manifest included the following details:
> >
> > Implementation-Title: commons-logging
> > Implementation-Vendor: The Apache Software Foundation
> > Implementation-Vendor-Id: org.apache
> > Implementation-Version: 0.0.0-EMPTY
> > Specification-Title: commons-logging
> > Specification-Vendor: The Apache Software Foundation
> > Specification-Version: 0.0.0-EMPTY
> >
>
>  These details provide information to the user who decides to open the
>  manifest file but other than that, since the jar file comes with no
>  classes, the information cannot be accessed at runtime, e.g. by the
>  Package class. Can you think of any additional reasons to include the
>  above details in the manifest file?

To document the jar.
It's easy enough to add, and does no harm.

AIUI there needs to be a NOTICE file in every distribution and release.

Also the N&L files need to be added to the jar.

>  --
>  Ceki Gülcü
>  Logback: The reliable, generic, fast and flexible logging framework for
> Java.
>  http://logback.qos.ch
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

Ceki Gulcu


sebb wrote:

> On 18/05/2009, Ceki Gulcu <[hidden email]> wrote:
>>
>>  sebb wrote:
>>
>>> It would be useful if the Manifest included the following details:
>>>
>>> Implementation-Title: commons-logging
>>> Implementation-Vendor: The Apache Software Foundation
>>> Implementation-Vendor-Id: org.apache
>>> Implementation-Version: 0.0.0-EMPTY
>>> Specification-Title: commons-logging
>>> Specification-Vendor: The Apache Software Foundation
>>> Specification-Version: 0.0.0-EMPTY
>>>
>>  These details provide information to the user who decides to open the
>>  manifest file but other than that, since the jar file comes with no
>>  classes, the information cannot be accessed at runtime, e.g. by the
>>  Package class. Can you think of any additional reasons to include the
>>  above details in the manifest file?
>
> To document the jar.
> It's easy enough to add, and does no harm.

Done.

> AIUI there needs to be a NOTICE file in every distribution and release.

Done.

> Also the N&L files need to be added to the jar.

Done.

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: commons-logging version 0.0.0-EMPTY

Matt Benson
In reply to this post by Ceki Gulcu



--- On Mon, 5/18/09, Ceki Gulcu <[hidden email]> wrote:

> From: Ceki Gulcu <[hidden email]>
> Subject: Re: commons-logging version 0.0.0-EMPTY
> To: "Commons Developers List" <[hidden email]>
> Date: Monday, May 18, 2009, 9:14 AM
>
>
> Matt Benson wrote:
>
> >>> For the actual "source code", see
> >>>  https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/
> >
> > Just to point out:  the final location of this
> "code" should AIUI BE a branch under logging/branches... the
> current structure isn't harming anything at the moment,
> however.
>
> Sounds good.
>
> > I think we need to:
> >
> > -agree that the POM is correct/complete according to
> the wishes of the community
> > -"promote" to proper by moving
> > https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/trunk
> > to
> > https://svn.apache.org/repos/asf/commons/proper/logging/branches/logging_EMPTY
> > -update svn information in POM
> > -generate/tag/vote 0.0.0 RC cycle
> > -release/tag 0.0.0 final
>
> +1  (thank you for making the above list)
>
> Is  there a point in making a standalone release for
> an artifact which
> is empty? For someone using ant there is no point in
> including
> commons-logging.0.0.0-EMPTY.jar, as they can just as easily
> remove
> references to commons-logging in their build.xml file.
> (Obviously, for
> a developer using Maven with *transitive* dependencies,
> it's a different
> matter.)

I think you're right; this "release" exists only for the benefit of Maven users, so we probably don't need to make a DL available from the website.  We do need to decide how much documentation we want to provide from [logging]'s site about this "release."

-Matt

>
> -- Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging
> framework for Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234